MX Record Propagation

Myth? Kind of.

There are 2 aspects that people often confuse. If you make a change to your domain name with your domain name registrar, for example changing the name servers, that is pushed to the name servers for your TLD (.com, .ca, .fr, etc). That's where the propagation comes into play. In years past, that could take hours or even days waiting for the registrar to take the information you provided, push that to their deployment servers which would update the TLD root servers twice per day. That's improved rapidly over the years and often times changes made to your domain name take take effect nearly immediately.

On the other hand, if you make a change to your DNS zone, like adding an A record or an MX change, that should take 'up to' as long as the TTL setting to be updated everywhere. That's not really propagation though, it's caching. Microsoft DNS, for example, defaults to 1 hour TTL.

With the caching, if you happen to use the domain name just before making a change, and the TTL is 1 hour, then it will take an hour for it to be updated. However, if you haven't tested anything with the domain name just prior to the change, then your change will be immediate for you. (i.e. add a new A record that you haven't tested with yet, and it will take effect immediately).

So, nowadays almost all changes will take affect within an hour (or whatever your DNS TTL is set for). The only exceptions are if a DNS server doesn't honor the TTL (spammers often don't), or if your domain name registrar's servers aren't updating properly to the internet and you make a registrar level change. That isn't often though.

1. Do you really need to build a new server as opposed to just moving the old server?

2. Change the rDNS and A records at the same time. I don't see any value in changing the rDNS ahead of time.

3. Good idea.

4. That's not how DNS works. The DNS record doesn't "get out there". DNS is a pull technology not a push technology. You want the TTL to be low enough so that the DNS record is not cached for an inordinately long period of time on servers that have already resolved the DNS record and have it in their cache. Servers that don't have the DNS record in their cache already will get the new DNS information immediately when they perform a lookup for the DNS record.

5. Good idea, but 24 hours seems a little long to me. I normally set 1 hour as my TTL. It's short enough to allow for quick changes on our part and long enough to not put any undue load on our name servers.

6. Good idea

DNS records don't propagate, they cache. There's no need to wait until they "get out there" as that's not how DNS works. A mail server that hasn't sent email to you during the period of time specified in the TTL will perform a lookup for the DNS record and will find the new DNS information immediately. Any server that has sent email to you during the period of time specified in the TTL will have the old DNS information in their cache for the life of the TTL. When the life of the TTL expires they'll perform a new lookup and get the new information immediately. Setting the TTL to 1 hour about 24 hours before the planned cutover should be sufficient to reduce your risk of missing some incoming email. In addition, most mail servers will try to send email for a period of 48 hours, so even if a few email servers "miss" you during the cutover, they should keep retrying for 48 hours and deliver the email when they are able to connect.

We do this kind of thing for our customers all the time. We change the DNS records at 8PM on a Friday evening and by 9PM or so email is flowing perfectly to the new server.