What really happens when you change MX records

You've signed up with the new mail provider, imported the mailboxes, and there is one thing left: change the MX record. It's a two-minute edit in a DNS panel.

Then, three days later, someone mentions that a purchase order went to the old system and nobody saw it.

The edit really is two minutes. The window either side of it is not, and almost nothing written about mail migrations describes that window honestly.

What an MX record does, and when

An MX record answers one question, asked by a sending mail server the moment it has a message for you: which host do I connect to for this domain?

example.com.  3600  IN  MX  10  mx1.provider.net.
example.com.  3600  IN  MX  20  mx2.provider.net.

The number before the hostname is a preference, not a weight or a percentage. Lower wins, and a sender only falls back to 20 if it can't connect to 10. This is the first place people go wrong: leaving the old provider's host in the list at a higher number "just in case." That isn't a safety net. It's an instruction to deliver to the old server whenever the new one is briefly slow to answer — and that mail lands somewhere nobody is looking.

When you change the record, senders do not find out. Nothing pushes the change anywhere. Every sending server in the world learns the new value only when the copy it already has expires.

TTL is a countdown that started before you got there

The 3600 in that record is the time to live, in seconds. It tells a resolver how long it may keep the answer before asking again. An hour, in that example.

Here's the part the guides skip, and it's the whole post. Lowering the TTL on the day of the cutover does nothing. The TTL governing how long a resolver keeps the old value is the one attached to the answer when that resolver last fetched it — not the one you just published. If your MX has been sitting at 86400 and you drop it to 300 an hour before you switch, every resolver holding a cached copy is still working from the 24-hour number. You changed the future, not the present.

The correct sequence is to lower the TTL at least one full old-TTL in advance. Old TTL is 24 hours? Lower it to 300 a day and a half before you touch the MX record. Let the long-lived copies expire and be replaced by short-lived ones. Then make the change, and the world picks it up in five minutes instead of a day.

Do that and the cutover window shrinks from a day to minutes. Skip it and you get a full day of split delivery no matter how carefully you did everything else.

The mail that shows up after you're finished

Even with a clean TTL plan, mail keeps arriving at the old system, for three separate reasons.

Queued mail. A sender that accepted a message for you and couldn't deliver it keeps retrying against the address it resolved earlier — most mail servers for four or five days before giving up. Some of what lands in the old mailbox on Thursday was accepted on Monday.

Resolvers that ignore you. Some corporate resolvers cap or extend TTLs to suit themselves. You cannot make them behave.

The local exchanger trap. This one is specific and it catches almost everybody moving off shared hosting. A shared hosting server that has hosted your mail is usually configured to treat your domain as local — meaning when something on that machine sends to you@yourdomain.com, it delivers into a mailbox on itself and never performs an MX lookup at all. Change your MX and that server does not care; it still thinks your mail belongs to it. Your website's contact form, order confirmations, and password resets keep dropping into a mailbox on the old host indefinitely. In cPanel the setting lives under Email Routing and has to be switched from Local Mail Exchanger to Remote Mail Exchanger by hand. Nothing in the DNS change touches it.

What to do

A day or two ahead: lower the MX TTL to 300. Confirm it took effect by querying an outside resolver, not your own machine.
Ahead of time: create every mailbox on the new platform and confirm users can log in. Mail to a mailbox that doesn't exist yet is rejected, and rejections don't retry.
Cutover: replace the MX records entirely. Remove the old host — do not leave it as a backup preference.
Update SPF at the same time. MX governs mail coming in. If the new platform also sends your outbound mail, its hosts must be authorized in SPF and its DKIM keys published, or your first message after the move fails authentication.
Switch the old host's routing to remote if you're leaving shared hosting, then re-test the website's contact form.
Leave the old mailboxes running for two weeks and open them daily. Anything arriving there is a sender or a system you missed.
Raise the TTL back to 3600 once you're satisfied it's done.

The migration isn't finished when the MX record changes. It's finished when a week has gone by and nothing new has landed in the old mailbox.

Moving mail and a website at the same time is where this gets genuinely fiddly — that's staged and tested before your domain switches.