1

Last Friday night we changed mail servers. We moved off Office 365 to another hosted Exchange Solution (Intermedia.net).

We use Godaddy for DNS, and after the server migration stuff was ready and clients were good to go, I edited our MX records. Godaddy is fast so within an hour or so I saw on whatsmydns.com that the new, proper MX records had been propagating nicely.

Queue Monday morning. Email is coming through but I'm starting to hear about bouncebacks. More of the same Tuesday. I'd been pulling my hair out when I just eyeball our DNS entries on Tuesday night and see that the TTL on the new MX record is 1 Week. Yikes. I change it to 1/2 an hour. Today, one bottleneck messagelabs/symantec) has updated to point to the right server, but we're still getting some unfortunately large external senders, ie Postini, bouncing their messages off the old server.

Is that initial 1 week TTL to blame? Would Postini resepct that initial TTL despite my haviong shortened it yesterday? I'm going nuts because it seems pretty helpless. I had IT folks at one of our clients contact Postini to open a ticket, since their user emails to us are bouncing, but it could take time to move on that front. My only hope is that it's Thanksgiving so work is mostly over until the weekend. Friday night will be the official 1 week from that initial bad TTL. Should I have hope that things will 'just work' come Monday? I don't know what else to check. The domain is removed from O365, the new MX records seem nicely propagated. I'm about to jump off a pier.

2 Answers 2

4

Never shutdown the old server until you know that the TTL of the MX record pointing to the old server has expired. If the TTL is/was 1 week then leave the old server running for 1 week to catch any emails from clients that may have that MX record cached.

When implementing an email cutover always check the MX record during your planning phase and adjust it accordingly. Personally I don't see any good reason to set the TTL on the MX record to anything more or less than 1 hour.

The new TTL on the MX record doesn't have any bearing on the old TTL of the MX record. So if the old MX record TTL was 1 week (or whatever) then any client that has that cached is going to hold it for that period of time (for whatever remaining TTL is in their cache). The fact that you changed it has no bearing, because those clients aren't going to look it up again until it expires in their cache.

3
  • I have remaining, active, domains on O365 and they could not email the transferred domain users until I removed it from O365. The user accounts still exist, for access to mail in case of a bad transfer, but linked to one of the remaining domain names. I would have loved to leave the domain up so we could catch mail sent to the old server, but I didn't know how to leave it up and still allow our O365 users to be able to communicate with the now migrated domain. Nov 26, 2014 at 23:13
  • Understood. The solution in this scenario would have been to assess and adjust the TTL of the MX record beforehand, but that's spilt milk at this point. The only thing I can see that you can do is... wait... unfortunately.
    – joeqwerty
    Nov 26, 2014 at 23:16
  • At this point, if it resolves over the weekend, I'll be launching fireworks. Since I'm otherwise out of options, just wanted opinions/confirmation that TTL is the likely culprit, to give me some hope that this has an end in sight. Nov 26, 2014 at 23:22
2

Your scenario is most plausible.

Remember that DNS does not "propagate"; rather, records are cached by other DNS servers for the duration of the TTL. So some sites may be caching that old record for as long as a week. (And broken DNS servers may cache it even longer, but those are fortunately few and far between.)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .