How do you update MX records safely without downtime?

Still have a question, spotted an error, or have a better explanation or a source we should cite?

Switching to a new mail server is one of those tasks that sounds simple until you realize a single wrong move can cause incoming email to vanish into the void. The good news is that MX record migrations have a well-worn playbook, and if you follow it in order, you won't lose a single message.

Before you touch anything in your DNS, lower your TTL (Time to Live) on the existing MX record to 300 seconds (five minutes). TTL is the number of seconds other servers are allowed to cache your DNS record before checking again. Right now it's probably set to 3,600 or 86,400 seconds. Lowering it means that when you make the actual switch, the new records spread across the internet in minutes instead of hours. Wait out the old TTL before moving on. If your current TTL was 3,600 seconds, wait at least an hour after lowering it so you know everyone's cache has expired.

While you're waiting, make sure the new mail server is fully ready. Test that it accepts connections on port 25. Confirm your authentication records (SPF, DKIM) already reference the new server if needed. Don't start redirecting mail to a server that isn't ready to receive it.

Now comes the overlap period, and this is the key step most guides skip over. Don't delete the old MX record yet. Instead, add the new mail server as an additional MX entry with a lower priority number than the old one. Priority numbers work counterintuitively: a lower number means higher preference. So if your old record is priority 10, set the new one to 5. Sending servers will now try the new server first and fall back to the old one if needed. Both servers are active. No mail gets dropped.

Watch your logs on both servers for at least 30 to 60 minutes. You want to confirm that mail is arriving on the new server and that nothing unexpected is hitting the old one. Once you're confident the new server is handling everything cleanly, remove the old MX record and raise your TTL back to something sensible (3,600 seconds is a common default, 86,400 is fine for stable setups).

Here's the full order to keep in mind:

  1. Lower TTL on existing MX record to 300 seconds
  2. Wait out the old TTL so caches expire
  3. Confirm new server is ready and tested
  4. Add new MX record at a higher priority (lower number) than the old one
  5. Keep both records active during the overlap window (30 to 60 minutes minimum)
  6. Monitor delivery logs on both servers
  7. Remove old MX record once the new one is confirmed working
  8. Raise TTL back to normal

If you're migrating to a hosted provider like Google Workspace or Microsoft 365, their setup wizards will give you the exact MX values and priority numbers to use. Follow those exactly, but still run through the overlap steps above rather than doing a hard cutover.

Want to verify the change propagated correctly? Our free Email Header Analyzer can show you which server is actually receiving your mail after the switch. Or if something's going sideways mid-migration, our SOS hotline is free and we actually pick up.

Contributors

Who worked on this answer

Every name links to their profile. Every company links to their site. Real people, real accountability.

Ask an AI · tailored to your setup

Build my MX migration checklist

I'm migrating to a new mail server and want to update my MX records without any email downtime or lost messages. Based on my current setup, help me create a migration checklist that includes: (1) what my current TTL should be changed to and when, (2) what priority value to use for the new MX record relative to the old one, (3) how long to run both servers in parallel, and (4) how to verify the new server is receiving mail correctly before I remove the old record.

Edit the yellow boxes, then send to the AI of your choice.