MX Records confusion - possible noobishness

I recently moved my site over from another hosting company, and almost everything is working beautifully over here, except that emails sent to my internal email addresses, from my server, are somehow still landing on the old server (which only has a few more days to live!). If I send to the same email addresses from, for example, my work email, they arrive exactly where they're meant to.

I'm using Google Apps, but also have postfix, so my phpbb forums can still send notification emails & a couple of webforms can still send email to my site staffers. It's mostly working beautifully - emails to external addresses are going out from phpbb just fine.

I used dig mx to check what was going on, and despite the MX records being updated in the Linode DNS manager 3 days ago, it returned the records for the old server. I am perplexed - I would have thought that linode's own records would be updated by now? Checking the MX records on IPTools.com produces the new ones.

So, I'm really out of my depth at this point. How do I get those MX records up to date? Any help gratefully received! I feel like I may have overlooked something terribly obvious…

edit: Just in case it's relevant, I'm using Ubuntu 10.04.

5 Replies

Is your MX record still in your old DNS manager? You should ensure all remnants of your domain are removed from the old one.

If the old DNS manager doesn't have anything else left of your domain, you can always try verifying that everything's correct in Google Apps. Since I don't use Google Apps, I don't know if you would have to change anything, though you would need to make sure that you inserted the MX records they provide into your Linode's DNS manager (and make sure that you remove them from your old DNS manager).

EDIT: Make sure that you set the correct priorities for all of your MX records. You should make sure that the priorities in Linode's DNS manager match up to the priorities you used in the old DNS manager.

Sadly, I don't have the necessary access to the old server (reseller/friend hosting us thing), but I would expect that the DNS manager there does still have our old MX records. I doubt very much anything has been changed there. I just thought that when the DNS changed over to the Linode manager, those records would become obsolete fairly quickly.

If the likely issue is the continued existence of the old DNS manager, though, it suggests that it'll resolve itself on October 1st when the account disappears completely. Which is, at least, only a few more days of this craziness!

Thanks for the suggestions, I appreciate it.

It might be good to contact whoever controls the old DNS manager to make sure. Having your site in two different DNS entries can cause conflict, especially if both DNS systems list your domain as active. When the ISPs around the world go to update their DNS, they will choose one based on whatever priority system they use, so some will choose the old DNS records, some will choose Linode's, and if the old ones don't go away with your account, that can cause more issues than you are experiencing right now – when your account goes away, you no longer have access to the other company's support. Of course, you could always get your domain registrar to help with this if the domains are in your name because they would recognize you as the owner, but that could take a bit longer than contacting the other web host now before the account closes.

hmm. Excellent point. I'll get in touch and try to get the records removed pronto. Thanks again!

The local nameservers you use for resolving addresses probably have the old MX record cached.

You can check the TTL of the record from your home machine.

$ dig dotat.at mx

; <<>> DiG 9.3.2 <<>> dotat.at mx
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11934
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 4

;; QUESTION SECTION:
;dotat.at.                      IN      MX

;; ANSWER SECTION:
dotat.at.               3600    IN      MX      1 mx.cam.ac.uk.

;; ADDITIONAL SECTION:
mx.cam.ac.uk.           86400   IN      A       131.111.8.148
mx.cam.ac.uk.           86400   IN      A       131.111.8.149
mx.cam.ac.uk.           86400   IN      A       131.111.8.146
mx.cam.ac.uk.           86400   IN      A       131.111.8.147

;; Query time: 494 msec
;; SERVER: 205.133.7.2#53(205.133.7.2)
;; WHEN: Wed Sep 28 01:12:14 2011
;; MSG SIZE  rcvd: 118

In this example, the TTL for the dotat.at MX record is 3600 seconds. This means that if the record changed, it would take an hour before the old record expired and I saw the new address.

There's not much you can do to retroactively reduce the TTL of an existing record. You could switch to a different nameserver on your home machine (this is defined in /etc/resolv.conf), but this would only solve the problem for you, not anyone else out there who may have cached the old record.

The moral is: when you are going to change DNS entries, plan ahead and reduce the TTL of the corresponding records a few days (or weeks) before, so that any cached entries will have time to expire.

Oh, you may also want to check your /etc/hosts file to make sure you haven't hard-coded the old address in there.

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct