How to Change MX Records Without Losing Email

An MX record change is the moment your domain's mail switches from one provider to another, and it's also the moment mail can silently vanish if you get the order wrong. The fix isn't a special DNS trick — it's sequencing: lower the TTL first, get the destination ready before you touch anything, make one clean change, and leave the old server standing as a safety net until you've confirmed the new one actually works.

This is a cutover runbook, not a definition of what an MX record is. If you need the fundamentals first, see what an MX record is; if you're ready to move mail, keep reading.

Before you start#

Everything below happens before you touch a single MX value. Skipping this stage is where most "we lost three days of email" stories start — not the DNS change itself, but changing it before the destination or the DNS itself was ready.

• Look up your current MX records (dig MX yourdomain.com or an online DNS lookup) and write down every hostname and priority. You'll want this as a rollback reference.
• Lower the TTL on the existing MX records to something short — 300 seconds (5 minutes) is standard — at least 24 hours before the real change, 48 if you can. TTL only shrinks the cache window going forward; it does nothing retroactively.
• Create every mailbox at the destination provider and get at least one test message sitting in each inbox before cutover. Provisioning after the MX change means mail can arrive at an address that doesn't exist yet.
• Confirm SPF, and DKIM if the new provider issues its own selector, are ready to publish alongside the MX change. A domain that starts sending through a new provider without matching SPF often lands in spam even though delivery technically "worked."
• Pick a low-traffic window — early morning in your primary time zone, not the middle of a business day — and tell anyone who might also touch DNS that this is happening.

Steps: how to change your MX records#

1. 1

   Confirm the new provider's exact MX values

   Copy the hostnames and priority numbers from the new provider's setup page verbatim. A typo in the hostname is the single most common cause of mail going nowhere after a cutover.

2. 2

   Lower the TTL and wait it out

   If you haven't already, drop the TTL to 300 seconds and wait at least one full TTL cycle of the old value (if it was 86400 seconds / 24 hours, wait a day) before changing the records themselves.

3. 3

   Remove the old MX records and add the new ones in the same edit

   Most registrar and DNS panels let you edit the record set in one save. Do it as one action rather than deleting the old records and adding new ones as separate saves — a gap between the two can leave the domain with no valid MX record at all.

4. 4

   Publish matching SPF and DKIM records

   Update the SPF TXT record to include the new provider's sending mechanism and add its DKIM selector. Do this in the same window as the MX change, not days later.

5. 5

   Send and receive real test mail

   From an external account — Gmail or Outlook, not another mailbox on the same domain — send a message to the domain and confirm it lands in the new mailbox. Then send outbound and check the headers at the receiving end.

6. 6

   Leave the old mail server running

   Don't decommission, delete the mailboxes, or cancel the old plan yet. Keep it accepting connections so any straggling delivery attempt still succeeds instead of bouncing.

7. 7

   Watch both mailboxes for 48–72 hours

   Check the old server's inbox as well as the new one during this window. Anything that arrives at the old address, forward it manually or set up temporary forwarding if the platform supports it.

Platform differences: MX setup by provider#

Why some mail still arrives at the old server after you switch#

A sending server doesn't look up your MX record on every message. It caches the answer for as long as the TTL says, then reuses that cached value until it expires. If your old TTL was a day and you didn't lower it in advance, some senders keep delivering to the old server for up to 24 hours after you change the record — through no fault of the new setup.

This is exactly why the old server has to stay reachable through the transition instead of being switched off the moment the new one works. Think of it as a bridge: both ends stay open until every sender's cache has caught up, not as a single door that closes the instant you flip the record.

TTL is a request, not a guarantee, in one more sense: the resolver each sender happens to use decides how literally to honor it. Most public and ISP resolvers cache for close to the exact TTL you publish, but some large corporate and cloud-based resolvers apply their own floor and won't cache anything shorter than a few minutes, no matter what you asked for. That's why two senders can finish picking up the same change at slightly different times even when they were both reading the same published TTL.

Adding a second, lower-priority MX record at the new provider ahead of the cutover doesn't shorten this window, either. Priority only decides which record a sender tries first once it already has a fresh answer for the domain — it does nothing for senders still working from a cached lookup that predates the change. A lower-priority fallback record is useful after propagation, as a backup if the top host is briefly unreachable, not as a way around the wait itself.

Reading your own MX lookup during the transition#

You'll be running the same lookup repeatedly during the cutover window, so it helps to know what each part of the answer is telling you. Run dig MX yourdomain.com +short and you'll get one line per record: a priority number, then a hostname. Two lines reading 1 smtp.google.com. and nothing else means only the new provider is live; a leftover line pointing at your old host means the old record is still in the answer, whether from an incomplete edit or a slow-to-clear cache.

Query a public resolver directly with dig @8.8.8.8 MX yourdomain.com instead of dig MX yourdomain.com on its own. The plain form asks whatever resolver your machine or network is already configured to use, which may hold its own cached copy of the old answer; pointing at 8.8.8.8 (or another public resolver) bypasses that local cache and shows you what a resolver picking the record up fresh would see.

Watch the TTL number in the full (non +short) output, too. Most resolvers report the remaining time left on their cached copy, and that number counts down each time you re-run the query against the same resolver. A TTL close to the value you set means you're looking at a fresh answer; a TTL still counting down from the old, longer value means that particular resolver hasn't picked up the change yet, and any sender using it won't either.

What to do when it doesn't work#

If mail stops arriving after the change, the cause is almost always one of these, roughly in order of likelihood.

• Typo in the MX hostname — re-check it character for character against the provider's setup page, not from memory.
• Mailbox not provisioned at the destination before mail started arriving — the message bounced with a "no such user" error instead of queueing.
• SPF not updated — mail delivers but lands in spam, or the new provider's own outbound mail gets rejected by recipients checking SPF alignment.
• Old and new MX records both still present — some DNS panels append rather than replace, so a leftover old record splits delivery unpredictably between two servers.
• DNS not actually propagated yet at the resolver you're testing from — use a tool like dig against a public resolver (8.8.8.8) rather than trusting your ISP's cached answer.

A faster way to handle mailbox setup after the cutover#

The MX change itself is a one-time event, but everything downstream of it — reconnecting every account, re-filing rules, re-training spam handling for a new inbox — is what actually eats the week after a migration. AI Emaily connects to the new mailbox over standard IMAP or the provider's OAuth, so once mail is flowing to the new server, triage, drafting and filing pick up immediately instead of starting from a blank inbox.

It doesn't touch DNS or the migration itself — the steps above still apply exactly as written. We build AI Emaily, and where it's useful is the day after cutover, when the manual steps are done and someone still has to work through what landed.