Fixing MX Record Propagation Delays During Cutover

Cutover hit at 2am. By 3am, half the test messages are arriving at the new tenant and half are still landing in the old mailboxes. The DNS check tool says "propagated" from one location and "not yet" from another. This is the most common cutover-night drama in any email migration, and most of the time the cause isn't your DNS provider being slow — it's a TTL that wasn't pre-lowered, a registrar cache layer you didn't know existed, or a dual-MX setup that's splitting mail between two servers. Here's how to figure out which one is hitting you and how to clear it.

Why MX propagation goes wrong#

The MX record itself is simple: it tells sending mail servers where to deliver mail for your domain. DNS distribution is what makes it complicated. Five common failure modes account for almost every "MX won't update" ticket:

1. TTL was never lowered before cutover. If your old MX record had a TTL of 86400 (24 hours), some resolvers will keep serving the old record for a full day after your authoritative record changes. Always lower TTL to 300 seconds at least 48 hours before cutover.
2. Registrar has its own caching layer. Some registrars cache zone changes for 5–10 minutes inside their own nameserver fleet before propagating to public resolvers. The change shows in the UI immediately but isn't queryable for several minutes.
3. Secondary DNS lag. If you use a secondary DNS provider for redundancy, the secondary may not pull zone updates in real time. Check that the secondary has the new record.
4. Missing trailing dot. When entering MX hosts in raw zone files, the trailing dot (aspmx.l.google.com.) marks the name as fully qualified. Without it, some resolvers append your zone and resolve to a broken hostname.
5. Dual-MX confusion. Leaving two priority MX records pointing at different providers splits delivery: senders pick whichever responds first, and you end up with mail in both inboxes.

For background on how MX records work, see the MX record glossary entry.

Diagnose first, change second#

Don't start editing records until you know which failure mode you're seeing. Run these checks:

dig +short MX yourdomain.com @8.8.8.8
dig +short MX yourdomain.com @1.1.1.1
dig +short MX yourdomain.com @9.9.9.9
dig +short MX yourdomain.com @<your-isp-resolver>

If all four return the new record, propagation is done and the problem is elsewhere — usually a sender's local resolver cache or a transport rule on the old server still pulling mail. If they disagree, you have genuine propagation lag.

Then query your authoritative nameservers directly:

dig +short MX yourdomain.com @ns1.yourdnsprovider.com

If the authoritative answer is wrong, the change never took effect at your DNS provider. If it's right but public resolvers disagree, you're waiting on cache expiry.

Step-by-step fix#

1. Confirm the change is live at authoritative

   Query each authoritative nameserver directly with dig +short MX yourdomain.com @ns1.yourdnsprovider.com. If even one returns the old record, the change didn't replicate within your DNS provider. Re-save the record or contact provider support.

2. Check the TTL you actually set

   dig MX yourdomain.com returns the TTL alongside the record. If the TTL on the old cached record was 86400, the longest possible stragglers will clear in 24 hours from the moment your change went live. There is no way to force this faster on someone else's resolver.

3. Test from outside your network

   Use a public DNS checker or your phone on cellular data to query from different geographic regions. ISPs have their own caching layers and may lag the public resolvers by a few minutes.

4. Verify trailing dots if you edit zone files directly

   For raw BIND zone files or Cloudflare's API, the trailing dot is required. aspmx.l.google.com without the dot becomes aspmx.l.google.com.yourdomain.com. The fix is one character.

5. Resolve dual-MX confusion

   If both the old and new MX are listed with different priorities, mail will deliver to whichever responds first on a given attempt. For a clean cutover, remove the old MX record entirely once you're confident the new server is receiving correctly. Keep mail forwarding on the old server pointed at the new domain for at least 30 days to catch slow-cache senders.

How this fits into your cutover plan#

Most propagation pain is avoidable with two changes to your cutover runbook: lower TTL 48 hours ahead, and keep the old server accepting mail for a week after the flip. Mailbox Taxi's incremental sync mode is designed for exactly this overlap — it catches any mail that lands on the old server during the propagation tail and ships it to the destination so the user sees a single, unified inbox.

For broader planning, see the complete email migration guide. For tenant-specific guidance, the Office 365 migration guide covers MX changes in the context of the wider tenant cutover. The choice of cutover style matters here too — cutover vs staged vs hybrid explains why a staged approach can sidestep most DNS pain.

When stragglers persist past 24 hours#

If a specific sender is still hitting the old server more than 24 hours after cutover, the cause is usually one of these:

• The sender's mail server has a private DNS cache with a long minimum TTL.
• The sender hardcoded your old MX into their relay configuration.
• Your old MX record is still present alongside the new one, and the sender's resolver happens to be picking it.

Confirm by checking the Received: headers on a delivered message that arrived at the old server. The receiving server's hostname will tell you exactly where it landed. For the wider context of cutover-day issues, the email migration troubleshooting hub collects related failures.