MX Record updated hours ago, still bouncing mail

5,613

Solution 1

It all depends on whether or not the SMTP server you're sending your emails through has an up-to-date MX record. A lot of ISPs do not obey the TTL and make their own up, and I'm guessing this could particularly be the case for MX.

I've seen cases of up to 72 hours before MX's are updated, particularly with South African ISPs.

If it's still bouncing for everyone after 24 hours, that's when I'd be more concerned.

-- Update --

I did an nslookup on your domain and got the following:

C:\Users\Mark>nslookup
Default Server:  bladedc1.live.local
Address:  192.168.163.50

> set q=mx
> ttanet.com
Server:  bladedc1.live.local
Address:  192.168.163.50

ttanet.com
        primary name server = NS87.WORLDNIC.COM
        responsible mail addr = namehost.WORLDNIC.COM
        serial  = 110011012
        refresh = 10800 (3 hours)
        retry   = 3600 (1 hour)
        expire  = 604800 (7 days)
        default TTL = 3600 (1 hour)
>

It looks like your DNS is not serving any MX records at all, however your aforementioned A record for mail.example.com DOES exist:

> set q=a
> mail.ttanet.com
Server:  bladedc1.live.local
Address:  192.168.163.50

Name:    mail.ttanet.com
Address:  206.188.207.108

And the authoriative nameserver is set to:

> set q=ns
> ttanet.com
Server:  bladedc1.live.local
Address:  192.168.163.50

Non-authoritative answer:
ttanet.com      nameserver = ns87.worldnic.com
ttanet.com      nameserver = ns88.worldnic.com

ns87.worldnic.com       internet address = 205.178.190.44
ns88.worldnic.com       internet address = 205.178.144.44

Are we seeing records from the correct DNS server?

-- Update #2 --

I believe I'm seeing the correct details now:

> ttanet.com
Server:  bladedc1.live.local
Address:  192.168.163.50

ttanet.com      MX preference = 10, mail exchanger = ttamail.ttanet.com
ttamail.ttanet.com      internet address = 67.78.188.51

So it's just a propgation/caching issue for your end users. It's definately set up correctly.

Solution 2

When my company moved our sites to new IPs we discovered that a LOT of DNS servers out there ignore the TTL which is configured in the DNS zone records and use their own settings. We set our TTL to an hour and after 2 weeks we still had customers hitting the old IPs.

Mail wasn't quite as bad as the mail traffic comes from a much smaller group than our web traffic does, but when we moved from our old mail provider to our Exchange server we had mail being delivered to the old provider for a couple of days.

There isn't much you can do about it except to contact the people who manage the DNS server that has the wrong information in it and request that the flush the DNS cache for your domain. Some will, some will ignore you.

Share:
5,613

Related videos on Youtube

cinqoTimo
Author by

cinqoTimo

Updated on September 17, 2022

Comments

  • cinqoTimo
    cinqoTimo over 1 year

    We just moved our website to a hosted server - but are keeping Exchange 2003 to manage our mail for the meantime. The DNS change has taken effect, but I think there maybe something wrong with the MX records.

    I have:

    mail.mydomain.com  A  Points to x.x.x.x which is the destination of the exchange server
    And
    mydomain.com       MX Points to mail.mydomain.com
    

    I updated the MX records after changing the domain DNS, but my understanding is that the MX record change time is typically the TTL (1 hour in my case) however, it's been several hours and I'm still bouncing mail.

    Can someone give me their experiences with record changes and TTL times? Are they usually consistent?

    Update: - from farseeker and mrdennys answers, it's just a slow update on the DNS cache. I hope it doesn't take 72 hours - but as long as the configuration is right, then it takes as long as it takes. I'll keep checking every 10 minutes and report the results. Thanks

    This is the Non Delivery Report:

    Delivery to the following recipient failed permanently:
    
        [email protected]
    
        Technical details of permanent failure:
        Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 sorry, no mailbox here by that name. (#5.7.17)
         (state 14).
    

    This is my first experience with Plesk. I thought I was modifying my DNS records but I think it may be having no effect.

    Latest Update: - Alright, mail.mydomain.com is now pointing to my mail exchange server, but emails are still getting the same NDR. Are there other variables to consider, such as ports - since the emails are being routed through an external server?

    • joeqwerty
      joeqwerty over 14 years
      Can you elaborate? What do you mean you're still bouncing mail?
    • cinqoTimo
      cinqoTimo over 14 years
      By bouncing, I mean when I send mail from an external address to an address within my sites domain, it bounces back to the external address saying that the address doesn't exist
    • joeqwerty
      joeqwerty over 14 years
      Well that doesn't sound like an MX problem. How could you get a response that the address doesn't exist if the sending server can't connect to your server at the new ip address? If the sending server were getting your old MX info it would attempt to connect to the old ip, and not succeeding, would put the email in a queue for later retry. Can you post the exact NDR?
    • cinqoTimo
      cinqoTimo over 14 years
      I add the NDR. Thanks for having a look. I had a feeling that something was wrong
    • MrGigu
      MrGigu over 14 years
      It could be that the old MX record is still running an MTA, but the account has been closed and thus it's bouncing the email
    • joeqwerty
      joeqwerty over 14 years
      @Farseeker: Based on the NDR I think you're right on the money. My recommendation would be to shut down the old MTA. That way sending servers cannot make a connection, put the email in their outbound queue, retry at their configured retry intervals (hopefully up to 48 hours), and eventually connect to the new ip and deliver the mail. Otherwise, as it is, they'll drop the mail based on the current NDR so the OP may lose some mail as a result.
  • cinqoTimo
    cinqoTimo over 14 years
    This is hosted, so I'm working through a UI (plesk & Virtuozzo), so I was doing it through plesk under the domain, but I just found an area under my host login that has IP addresses more like what you've posted. I've added the records there, and I'm going to wait and see if they update.
  • MrGigu
    MrGigu over 14 years
    Good stuff. I'll check it in a few hours (if I remember) to see if it's changed
  • joeqwerty
    joeqwerty over 14 years
    Here's what I see at the moment: There is no MX record for ttanet.com but there is an A record (206.188.207.108). Sending email servers are currently attempting to send mail to this ip address, which is an SMTP server at Network Solutions.
  • joeqwerty
    joeqwerty over 14 years
    That ip address may not be a Network Solutions address, I think I was querying the wrong ip address. Now I'm seeing an MX record: 67.78.188.51. Is that correct?
  • MrGigu
    MrGigu over 14 years
    Hi cinqoTimo - I've updated my answer, looks like the correct MX details are now being shown
  • MrGigu
    MrGigu over 14 years
    No worries, it's what we're all here for :)
  • joeqwerty
    joeqwerty over 14 years
    Glad to help and glad it's all working again.