Creating a seamless DNS propagation

I often have to change my clients' nameservers when switching them to new hosts, and every time is a new experience. Sometimes it'll be easy, and other times it won't populate fast enough, and then email goes down, and then the client's angry.

I've been reading up on lowering the TTL on the A records, MX records, and nameservers 1-5 days before changing the name servers.

I also read that I should switch the A and MX records first, and then once those have propagated, then switch the nameservers.

What I would like to know is what is the best solution towards not having any downtime, particularly in the email area. If I set the email addresses up on the new server before making any changes, can I add the MX records in addition to the pre-existing ones? That way if it is propagating, it tries the original MX records, and if those fails, it'll have the new ones to fall back on until the name servers refresh them?

Sorry if any of this is confusing.

Usually the best option is to set the TTL low (like 60 seconds) and don't touch anything else for the duration of the previous TTL. So if your TTL is currently 86400, change the TTL to 60 seconds and then wait an additional 86400 seconds before changing the actual record. Once the record is changed, you can bump up the TTL immediately to what ever you want. Maximum "downtime" in that example is 60 seconds.

If you are switching records and name servers, set up the new name servers first and make sure they work. Double check everything. Once the new servers work, you can do the record change process on the old servers, wait the longest TTL and then switch the glue records at the registrar. Once the glue records are switched, it's again best to keep the old name servers up and running for the longest TTL you have. This is because some queries may still trickle in to your old name servers. After all the records expire, your old name servers shouldn't get any more new queries. That should prevent any downtime except for the 60 seconds or whatever the low TTL is during the record change.

Of course that's in an ideal situation. The best thing to do is sit down and plan it all out on paper. Look at all your records and make a decision.

Also, I work for an email hosting company. I wouldn't suggest having MX records for two companies and assume it will fail over. Usually the "old" provider will return a permanent failure and that will bounce the message. It would normally only "fail over" if the server was unreachable. The smoothest transition would be to have both the new and the old system working simultaneously for a little while.

Let me know if I'm interpreting this correctly...

Lower the TTL from 1 hour to say 60 seconds (although GoDaddy only allows 30 minutes) then wait the duration of the original TTL (1 hour) before changing the A and MX records. Wait an additional hour to make the A and MX records have resolved, then change the nameservers.

I wasn't sure what you meant by "glue" records, but this is how I interpreted it. Let me know if I'm wrong.

Changing the name servers changes your domains glue records in the TLD servers.

But yes that is essentially the process. Once your current servers have the records changed and everything is good, make sure your new servers are all ready to go. Once both sets of name servers are resolving correctly, make the name server change with your registrar. After you change name servers, you may want to keep the old ones around a little longer, but after a while any new queries will only come to the new name servers.

And the waiting time isn't solely based on what records you are changing. Look at the largest TTL for any of your records is probably the best idea.

Thank you.

Another big concern of mine is when you do switch the nameservers, as you said it changes all the glue records in the TLD servers, and I have to wait for the nameservers to resolve before I can change the MX records. My clients usually have their mail hosted elsewhere, andI don't want to cause any downtime while I play the waiting game.