Diagnosing DNS cache after migration during a DNS cutover: an inbound-mail runbook

When inbound mail splits or stalls after an MX migration, assume DNS caches still point some senders at the old host until TTLs expire—keep the old receive path alive, compare resolver answers, and measure which hop fails first. Do not lower TTL to zero mid-incident without a plan. Temporary consumer inboxes are irrelevant to your domain’s cutover; they only help as external probes. This runbook is for operators of legitimate inbound mail—not for probing Mailby’s private operations.

DNS cutover context and boundaries

A typical MX cutover:

1. Lower TTL on MX (and related A/AAAA) hours or days ahead
2. Stand up new MTAs with TLS certs and accept policies
3. Publish new MX priorities
4. Dual-receive until old MX traffic drains
5. Decommission old hosts

DNS cache after migration means recursive resolvers (ISP, corporate, public) continue answering with prior RRSets until their cached TTL hits zero. SMTP senders use those resolvers, so two senders can diverge for hours.

Boundaries: Only operate on zones you control. Do not expose or guess Mailby internal panels. Product links like how it works explain the public receive-only product; they are not your MX vendor console.

Demonstrate the cache problem

Annotated fixture:

• Old MX: mx1.old-provider.example → 203.0.113.10
• New MX: mx1.new-provider.example → 198.51.100.20
• Prior TTL: 3600s; you forgot to lower it before flipping
• Symptom: some customers’ mail arrives; others bounce or delay

Working path:

1. Query authoritative NS directly: shows new MX.
2. Query 1.1.1.1 / 8.8.8.8 / a corporate resolver: mixed old/new for a window.
3. Keep old MTA accepting mail; queue or journal inbound.
4. After max(TTL) drain, old MX traffic ≈ 0; decommission.

Failure / limitation: You decommission the old MTA at flip time. Cached senders deliver to a black hole. Bounces look like “your email is down” even though authoritative DNS is correct. Restoring the old host (or temporary forward) is the rollback—if you still can.

This differs from a general receive-infrastructure hub by focusing on post-migration cache divergence specifically.

Mechanism

Resolvers cache MX and the A/AAAA they chase. Even with correct authoritative data, senders using stale caches connect to old IPs. Related gotchas:

• Transparent middlebox DNS in enterprises
• TTL clamping by some resolvers
• CNAMEs at zone apex anti-patterns creating confusion (MX must be hostnames with addresses)
• IPv6 AAAA only updated on one stack

Standards references: RFC 1034 / RFC 1035 (rel="nofollow noopener") for DNS concepts; RFC 5321 (rel="nofollow noopener") for SMTP retry behavior when destinations fail.

Layer table

Layer	Check	Expected observation	Failure clue	Rollback
Authoritative	dig MX example.com @ns1	New MX set	Old MX still published	Re-publish intended set
Public resolver	dig MX example.com @8.8.8.8	Converging to new	Persistent old answers	Wait TTL; avoid early teardown
Old MTA logs	Connections after flip	Declining accept rate	Sudden zero after kill	Restore old listener
New MTA logs	TLS + RCPT accepts	Rising volume	No connections	Fix DNS/firewall
Queue on senders	NDR / delay notices	Transient delays	Hard bounce host unreachable	Re-enable old MX IP
Probe message	External test send	Delivered to new	Delivered only to old	Dual-receive longer

Concrete worked example

T-48h: Set MX TTL to 300s.

T-0: Publish new MX priority 10; keep old at 20 for safety.

T+15m: dig via corporate DNS still shows old-only (cache). Send probe from that network → hits old MX (priority 20 still accepts).

T+2h: Most public resolvers updated. Corporate DNS still stale.

T+6h: Corporate cache drains. Old MX connections near zero for 24h → remove old MX RR → decommission.

Rollback: If new MTA TLS fails (cert name mismatch), raise old MX priority back and pause cutover. Cert issues are not DNS cache, but they present similarly (“mail fails after migration”).

External probe idea: From a laptop on a consumer network, send a message to a test recipient on your domain. Separately, a disposable address on Quick Inbox is only useful if you are testing some other system’s outbound to Mailby—not for your domain’s MX. For productized receive testing of apps you build, see /developers.

Alternatives and when “durable” matters

Inbound domains are inherently durable infrastructure. Temporary email does not replace MX planning. Soft alternatives:

• Dual-provider receive during migration
• Staged subdomain cutover (mail-migrate.example.com) before apex MX flip
• Longer dual-receive windows for enterprises with aggressive caching

Consumer durable mailboxes matter for humans reading NDRs during the cutover; ops aliases should be durable and monitored.

See security and data retention for Mailby’s public product policies—not for your zone’s SOA.

Short answers

What causes DNS cache issues after migration during a cutover?

Resolvers honoring prior TTLs; operators tearing down old targets too early.

What should I do first?

Compare authoritative vs recursive answers; confirm old MTA still accepts.

When is a permanent address safer?

Always for ops aliases receiving NDRs and vendor notices during cutover.

What evidence changes the recommendation?

• Authoritative wrong → fix publish, not cache
• Authoritative right, recursive stale → wait / dual-receive
• New MTA rejecting → fix accept/TLS, not DNS

Sources, test date, and limitations

Test date: 2026-09-24. Dig/Drill examples assume standard tooling. We do not publish Mailby’s private MX runbooks.

Limitations: CDN/email-gateway vendors add proprietary cache layers; always read their migration guides. This is not legal advice for deliverability SLAs.

Pre-cutover checklist (copy into your change ticket)

• MX/A/AAAA TTLs lowered at least 2× max observed resolver clamp ahead of time
• New MTA accepts TLS with correct hostname
• New MTA permits your test senders and does not greylist them into oblivion during dual-receive
• Monitoring on both old and new: connection count, 4xx/5xx, queue depth
• On-call knows rollback is “restore old MX priority / reattach old IP,” not “tweet status”
• Customer-facing status page draft ready if enterprise senders cache for many hours

Measuring “cache drain” without guessing

Sample recursive resolvers on a schedule:

for r in 8.8.8.8 1.1.1.1 9.9.9.9; do
  echo "== $r =="; dig +short MX example.com @$r
done

Track percentage of sampled resolvers still returning old MX. Decommission only after that percentage stays at zero for a business-appropriate window (often 24–48h for global audiences; longer for enterprises you know run recursive caches with high TTL clamp).

Remember SMTP clients retry. A sender that resolved old MX once may continue using that answer until its own cache expires even if public dig looks clean from your laptop.

Related failures that look like DNS cache

• Firewall allowlists still permit only old IP
• ACME/TLS cert missing SAN for new hostname
• SPF still authorizes only old infrastructure (outbound problem, but tickets arrive during inbound cutovers)
• DANE/TLSA records stale if you use them

Bisect by connecting manually: openssl s_client -connect new.host:25 -starttls smtp. If TLS fails, it is not a recursive DNS mystery.

Communication template

Tell stakeholders: “Authoritative DNS is updated; some networks will use cached MX until TTL drain; dual-receive is intentional; do not hard-bounce reports until T+drain.” That single message prevents well-meaning engineers from shutting off the old listener early.

Dual-receive implementation patterns

1. Equal priority MX during transition (some operators prefer primary/backup priorities instead)
2. Store-and-forward on old host to new host if vendor supports it
3. Shared storage backend so either MTA writes to one message store

Pick one; document it. The failure mode of “two stores, no sync” is silent split-brain where support cannot find a message that a customer definitely sent.

Validate with seeded probe messages from diverse networks (home cable, mobile LTE, cloud VM, partner office). Diversity beats repeating dig from one laptop.

Additional practical notes

Some DNS hosts UI-show “propagated globally” based on a small probe set. Do not trust marketing maps as drain proof. Your enterprise customers’ resolvers are the ones that matter; ask a few to dig from their networks.

When using anycast MTAs, confirm that cutting old addresses does not also remove geo routes still advertised. Address management and DNS MX are coupled but not identical.

Keep a paper timeline: TTL change time, MX publish time, first customer report, dual-receive end. Postmortems without timestamps invent false root causes.

If you outsource inbound to a filtering vendor, their cutover runbook may require opening a ticket hours ahead. Vendor SLAs can dominate DIY dig results. Read their migration guide before yours.

Probe messages should use unique subjects so you can find them in either store. “test” subjects collide with noise and waste minutes during incidents.

Rollback drill

Before the real cutover, practice:

1. Publish temporary MX change on a lab domain
2. Generate traffic
3. Roll back priorities
4. Confirm mail flows on restored path within minutes

Teams that never drill rollback discover broken old listeners only during panic. Keep old certs and configs bootable until drain completes.

Customer communication FAQ

Q: Dig shows new MX but my mail failed.
A: Your resolver may still be cached; retries should succeed as TTL ends; we dual-receive during the window.

Q: Can I force update?
A: Flushing local stub caches helps some users; corporate recursive caches need time or IT flush.

Temporary consumer inboxes do not change your MX physics; they are unrelated except as outbound test targets for other systems.

Post-cutover hardening

After drain: remove old MX RRs, revoke old IPs from allowlists that no longer need them, update SPF if those IPs were shared with outbound, update monitoring dashboards, and archive dig samples from the incident folder. Schedule a follow-up a week later to catch late-caching networks. Some mobile carriers cache aggressively; keep an ear on support for “email started bouncing after your migration” tickets even after you think you are done.

Reader checklist

Before you act on this guide, confirm: (1) you are authorized to test or decide for this account, (2) you understand Mailby is receive-only and does not send or forward mail, (3) you have opened the linked policy or product pages when making retention or security claims, and (4) you picked durable mail whenever recovery, receipts, or multi-day continuity matter. Temporary inboxes excel at short receive tasks and fail loudly when pressed into identity roles they were never meant to fill. Re-read the decision table above if you are unsure; tables compress the judgment call better than memory under time pressure. When evidence disagrees with a default recommendation—vendor blocks, legal holds, employer policy—let that evidence win. Update your personal defaults after each surprising failure so the next decision is faster and safer.

Conclusion

DNS cache after an MX cutover is expected physics, not mystery packet loss. Dual-receive until recursive answers converge, verify layer by layer, rollback by restoring the old accept path. Use public product pages like how it works only as product context—not as an operational promise for your domain.