DNS cache after migration: inbound mail deployment runbook

If inbound mail stalls during an initial deployment after you change MX or related DNS, assume DNS cache after migration until proven otherwise—then verify with authoritative answers, TTL remaining, and dual-path receives. Do not flip records repeatedly. Measure the earliest failing hop, keep the old receive path warm for TTL, and roll back only when signals say the new path is wrong—not merely slow.

Temporary consumer inboxes are unrelated to your MX cutover; use them only as external probe addresses if useful. This runbook is for operators of legitimate inbound mail.

Initial deployment context

“Initial deployment” here means the first time a domain’s inbound mail points at a new receiving stack (new MX host, new provider, or self-hosted MTA). Symptoms operators report:

• Some senders deliver; others bounce to the old host
• Delivery works from one network but not another
• Cuts over “instantly” in dig against the authoritative NS but not against public resolvers

Those patterns scream resolver cache, not application bugs.

Boundaries:

• Authorized systems only
• No exposure of private ops panels
• Mailby product pages explain receive-only consumer inboxes; they are not your MX vendor console

What “DNS cache after migration” actually means

DNS resolvers cache MX (and A/AAAA for MX targets) for up to the record TTL. After you publish new MX data:

1. Authoritative nameservers serve the new answer immediately (once zones propagate across your NS set).
2. Recursive resolvers keep the old answer until their cached TTL expires—or until they refetch.
3. Sending MTAs use whatever their resolvers return.

So two senders can disagree for hours if TTLs were large.

Field test: working path

On 2026-09-24, in a lab cutover for a test domain:

1. Lowered MX TTL to 300s at least one TTL period before cutover.
2. Published new MX to the staging receive host.
3. Queried authoritative NS → new MX visible.
4. Queried popular public resolvers → mixed old/new for ~5 minutes, then converged.
5. Sent probe messages from two networks; both landed on the new host after convergence.
6. Decommissioned old receive only after 2× old TTL with zero logs on the old path.

Failure / limitation

A rushed cutover kept TTL at 86400s. Authoritative looked correct; corporate resolvers served old MX for most of a day. Operators “fixed” it by toggling MX twice more, extending confusion. Limitation: you cannot flush the internet’s caches on demand. You wait out TTL or accept dual-receive.

Layer table

Layer	Check	Expected observation	Failure clue	Rollback
Authoritative NS	dig MX @ns1...	New MX + low TTL	NS disagree	Fix zone before touching public story
Public resolver	dig MX @1.1.1.1 etc.	Converging to new	Sticky old MX	Wait TTL; keep old RX alive
MX target A/AAAA	dig target host	Correct IPs	Stale A toward old IP	Dual publish IPs carefully
SMTP banner / logs	Connect to :25	New greeting	Still old banner	Traffic following old DNS
TLS cert	STARTTLS	Name matches new RX	Cert name mismatch	Fix cert before cutover
App receive	Message store	Probe visible	Accepted SMTP but no store	App/queue issue, not DNS

Safe runbook (ordered)

1. Pre-cutover: lower TTL on MX and MX target address records; wait one full old TTL.
2. Inventory: document old and new MX, IPs, cert SANs, monitoring hooks.
3. Publish new MX (and required A/AAAA).
4. Verify authoritative answers on every NS.
5. Probe resolvers in multiple regions; record TTL remaining on cached answers.
6. Send controlled probes from external accounts; watch both old and new receive logs.
7. Keep old RX accepting until probes and logs show zero legitimate traffic (or until TTL×2).
8. Only then decommission old path.
9. Rollback means restoring prior MX and ensuring old RX still works—not deleting the new stack in panic while caches still point at it.

External references: RFC 1034/1035 DNS concepts; RFC 5321 SMTP for the receive hop after DNS resolves.

Worked example

Domain mail.example moves MX from old.rx.example to new.rx.example.

Time	Action	Signal
T−48h	TTL → 300	Dig shows TTL 300
T0	Publish new MX	Auth NS OK
T+2m	Resolver A still old	Expected
T+12m	Resolvers mostly new	Dual RX still on
T+25m	Old RX silent 20m	Safe to drain
T+2h	Decommission old	Done

If at T+12m new RX shows TLS errors, rollback MX and keep investigating the new host offline—do not leave senders on a broken new path.

Relation to temporary inboxes

Consumer Quick Inbox addresses ride on Mailby’s receive infrastructure, not your corporate MX. They can serve as external probe recipients if you send yourself a test—but diagnosing your migration still depends on your DNS and logs. See how it works for product receive semantics; see Laravel welcome testing for app-level send checks after DNS is healthy.

When “permanent” mail infrastructure is the topic

This article assumes you operate durable inbound for a domain. Disposable addresses do not replace MX planning. If you only need disposable receive for QA, you do not need this runbook—use /inbox or /developers instead.

Short answers

What causes DNS cache pain after MX migration?
Resolvers honoring prior TTL; senders using different resolvers.

What should I do first?
Query authoritative vs public resolvers; compare receive logs on old and new.

When is a permanent address safer?
N/A as consumer advice—operators should always use durable operational domains for MX.

What evidence changes the recommendation?
Auth NS wrong → fix zone; SMTP/TLS failure on new host → rollback MX; only caches sticky → wait.

Sources, test date, limitations

• Lab narrative: 2026-09-24.
• RFCs 1034/5321 as linked.
• No claim about Mailby’s internal MX operations.
• Internet cache flush is not a product feature anyone can offer globally.

Pre-migration communications

Tell internal stakeholders the dual-receive window length. Finance and support should know that some partners may see delays equal to old TTL. Silence creates duplicate tickets that pressure you into unsafe flapping.

Measuring TTL remaining

When dig shows an old MX, note the TTL value in the answer—that is roughly how long that resolver will keep lying. Different resolvers show different remaining TTLs. Build a small spreadsheet during cutover: resolver, answer, TTL left, timestamp.

Split-brain receive

During dual-receive, both old and new hosts must accept mail for the domain. If the new host accepts but the app database is not ready, you will store mail in a black hole. Application readiness is a release gate equal to DNS.

TLS and DANE pitfalls

If you pin TLSA/DANE records, update them in lockstep with MX targets. A correct MX with a wrong TLSA breaks authenticating senders. If you do not use DANE, still ensure certificates match the MX hostnames senders validate.

IPv6 surprises

New AAAA records with broken routing cause intermittent failures for IPv6-capable senders while IPv4-only paths succeed. Test both address families.

Monitoring signals

• Connection counts on :25 old vs new
• Bounce rates with diagnostic codes
• Queue sizes on senders you control
• Synthetic probes every minute from three networks

Rollback drills

Practice restoring old MX in staging. Document the exact dig checks that declare rollback successful. People under stress skip verification—your runbook must make the checks copy-pasteable.

Relation to product receive testing

After DNS is healthy, validate app messages with layered tests (Laravel welcome guide). DNS lies create symptoms that look like application bugs; separate the timelines in incident docs.

Sample dig commands (operator crib)

dig +short MX example.com @ns1.example-dns.net
dig +short MX example.com @1.1.1.1
dig +short MX example.com @8.8.8.8
dig +short A new.rx.example @1.1.1.1

Compare answers. If authoritative and public disagree, you are in cache-wait territory—or NS replication lag. Check all authoritative NS for agreement first.

Change window etiquette

Schedule cutovers when send volume is lower if possible. Keep voice/chat staffing for the dual-receive window. Announce “do not open tickets for delays under TTL unless bounce codes appear.”

Post-mortem template lines

• Planned TTL lowers completed? Y/N
• Auth NS consistent at T0? Y/N
• Max observed cache stickiness?
• Dual-receive duration?
• Rollback used? Why?

These notes make the next migration boring—the goal.

Extended failure stories

Story 1 — “Dig looks fine”

Operator queried only 8.8.8.8 after a 300s TTL lower. Green. Corporate resolvers with leftover 24h cache still pointed old. Sales in that office bounced. Fix: probe resolver diversity, including customer networks when feasible.

Story 2 — “New MX, old A”

MX updated to new.rx.example but new.rx.example A still pointed to a decommissioned IP briefly due to a second forgotten record set. SMTP SYN timeouts. DNS cache was blamed incorrectly. Always validate target address records.

Story 3 — “Cert name mismatch”

Senders validating certificates failed after cutover. Mail queued or bounced depending on policy. Rollback MX until cert fixed.

Runbook roles

• DNS owner — publishes records
• MTA owner — ready to receive
• App owner — stores messages
• Comms owner — status page notes

Four roles prevent one person flipping records blind.

Customer-facing status text (template)

We are migrating inbound mail for example.com. Some delays up to [TTL] are expected. Messages remain safe on either receive path during the window.

No need to expose internal hostnames.

Final operator mantra

Authoritative truth first, caches second, app third. Flapping MX is last. Dual-receive until the old path is quiet. Document TTLs like you document versions—because for a while, the internet runs both.

Appendix: when it is not DNS

• Full disk on MTA
• Firewall dropping :25 from some ASNs
• Greylisting delays
• Recipient policy rejections
• Application bug after accept

Use the layer table; do not chant “DNS cache” for every late message.

Tabletop exercise

Once a year, rehearse an MX migration on a lab domain with intentionally high TTL leftovers. Time how long dual-receive lasts. The muscle memory matters more than perfect docs when a real cutover hits an unexpected resolver population.

Patience with TTL is operational maturity. The loud fix is rarely the correct fix on cutover night.

Keep dual-receive long enough that the quietest resolver population you care about has caught up—not merely the resolvers on your laptop.

Conclusion

DNS cache after migration is a timing problem dressed up as an outage. Lower TTLs early, verify authoritative truth, probe widely, keep dual receive, and roll back only on hard failures. For application email QA once DNS is stable, return to layered testing—not record flapping.

Operators shipping receive features can also review features and status for product-side health, separate from customer DNS.