DNS cache after migration during a TLS cert change: inbound runbook

The decision in plain terms

If inbound mail fails right after an MX/host migration that also swapped TLS certificates, assume two independent failure modes until proven otherwise: senders still caching old DNS answers, and SMTP clients failing TLS because the new certificate does not match what they connect to. Diagnose from the edge inward, measure each hop, and roll back the smallest lever that restores accept.

This runbook is for operators of legitimate inbound mail you own. It is not a Mailby internal panel tour and not advice for intercepting third-party mail.

TLS certificate change + migration context

Cutovers often combine:

• New MX hostnames or new A/AAAA behind the same MX
• New SMTP banner / new MTA
• New TLS cert (hostname SAN changes, chain changes, or “temporary self-signed during bring-up”)

DNS TTLs determine how long senders keep old answers. Even with low TTL, recursive resolvers and application-side caches misbehave. Meanwhile, a cert issued for mail-b.example presented on connections still aimed at mail-a.example produces handshake errors that look like “mail is down” in user reports.

Temporary end-user inboxes are irrelevant to fixing your MX—except as an external probe target if you intentionally send test messages to a disposable address you control. Prefer supervised test accounts on your domain.

Earliest failing hop: ordered checks

1. Authoritative DNS — dig MX/A/AAAA at the authority; confirm published truth.
2. Public recursive view — dig via multiple resolvers; detect split-horizon / lingering old A.
3. TCP 25 reachability — connect to the IP you believe is current.
4. TLS handshake — openssl s_client -connect host:25 -starttls smtp and verify SAN vs. connected name.
5. SMTP dialogue — EHLO, STARTTLS, MAIL/RCPT against a test recipient.
6. MTA logs — correlate timestamps with sender retries.
7. Queue on senders you control — Postfix/Exim deferred reasons (TLS, NXDOMAIN, connection refused).

Working path

TTL was 300s. After 10 minutes, public dig shows new A. s_client shows cert SAN matching the MX hostname. Testers receive mail. Deferred queues drain.

Counterexample / failure

Ops re-pointed MX quickly but left an old load balancer IP answering on port 25 with the previous certificate for the old name. Half of senders (cached new DNS) succeeded; half (cached old IP) saw cert mismatch and deferred. Dashboards showed “intermittent inbound,” which was actually bimodal DNS cache, not random flakiness.

Layer table

Layer	check	expected observation	failure clue	rollback
Auth DNS	dig @ns MX/A	New targets only	Old A still published	Fix zone; raise care on serial
Resolver cache	dig @8.8.8.8 / @1.1.1.1	Converging to new	Sticky old A past TTL	Wait; flush only what you control
Network	nc/telnet IP 25	Banner	Timeout/refuse	Restore LB backend
TLS	openssl STARTTLS	Verify OK; SAN match	alert handshake failure	Reinstall prior cert/name
SMTP	RCPT accepted	250	550/451 loops	Revert MX or policy
App	message in store	Row/file appears	Empty with 250 upstream	Check filters/LMTP

Concrete worked example

Change window: migrate mx.example.com from 10.0.0.10 to 10.0.0.20; issue Let’s Encrypt cert for mx.example.com.

Symptoms at T+15m: internal probes to .20 succeed; partner MTA logs SSL_accept error against .10.

Root cause: A record TTL 3600s; .10 still served old cert after hostname reuse confusion on the retired host.

Fix: shut down SMTP on .10 (refuse > silent wrong cert), keep .20 healthy, communicate TTL wait, monitor deferrals. Optional: temporary dual-cert strategy only if names still match—do not present unrelated SANs.

Safe rollback: restore MX to .10 with matching cert if .20 is the broken side—not a blind DNS toggle without TLS alignment.

Related product reading for receive-only concepts (not your MTA): /how-it-works. For application-level verification testing rather than MX ops, see Next.js signup verification tests.

Measurable signals

• Percentage of dig results returning old A over time (should decay with TTL)
• Count of TLS handshake failures vs. connection refusals
• Deferred queue age on a canary sender
• Inbound acceptance rate for a tagged test message ID

If TLS failures dominate while dig still shows mixed A records, you are in the bimodal regime—fix the retired listener first.

Alternatives and scope limits

• Blue/green MX hostnames (mx1 → mx2) with overlapping TTL windows — cleaner than recycling IPs
• Preload certs on both environments for the same public name before traffic shift
• Lower TTL days before cutover — classic, still forgotten
• Do not use public temporary inboxes as proof your corporate MX is correct; use domain-owned canaries

Mailby’s consumer Quick Inbox will not repair your DNS. Engineering docs: /developers for API receive testing after your MX is healthy.

Short answers

What causes DNS cache pain during TLS changes?
Senders keep old IPs while new hosts present different cert identity.

What should I do first?
Compare authoritative dig vs. public dig; probe TLS on each live IP still accepting 25.

When is a “permanent” mail hostname safer?
Stable MX names with predictable SANs beat frequent renames during cert automation.

What evidence changes the recommendation?
All public resolvers agree and TLS verify OK, but mail still missing → move downstream to filtering/storage, not more DNS waiting.

Pre-change checklist (prevent the incident)

Days before cutover:

1. Lower MX/A TTLs to 300s (or your safe minimum)
2. Issue and install certificates on the new hosts for the public names you will serve
3. Validate STARTTLS on new hosts from outside your network
4. Send canary messages to a domain you control
5. Document rollback owners and chat channel
6. Freeze unrelated DNS edits during the window

Skipping TTL reduction is the most common self-own.

Dual-stack and IPv6 surprises

If AAAA still points at a retired host while A is updated—or vice versa—some senders prefer v6 and hit the broken path. Dig both record types. TLS certs must cover the names clients use, not only the IPv4 story you tested from your laptop.

Load balancers and SNI

Modern SMTP may present different certs by SNI. Ensure health checks do not terminate TLS with a default junk cert that occasional clients see. During migration, draining an old backend should refuse connections rather than serve the wrong identity.

Communications template for stakeholders

Tell app owners:

• Expected deferral window ≈ max(TTL, residual cache)
• Symptoms users may see (delay, not necessarily permanent loss)
• Status page blurb
• When to escalate (TLS verify failures after dig convergence)

Quiet cutovers without comms create duplicate “fixes” that fight each other.

Post-incident review questions

• Did we recycle IPs without shutting SMTP?
• Did cert automation race the DNS change?
• Did we monitor mixed dig results?
• Did we have a canary sender outside our recursive resolvers?

Write the answers down; the next migration will arrive sooner than you think.

Canary sender setup (minimal)

Run a small VPS or container with Postfix that sends a uniquely tagged message every minute during the window:

Subject: canary-<timestamp>

Receive on a mailbox under your domain with logging. Graph acceptance. When canaries fail, dig and openssl from the canary host—not only from your laptop on corporate DNS.

Certificate automation races

ACME hooks that reload MTA configs can restart SMTP mid-cutover. Sequence:

1. New hosts healthy with certs
2. DNS switch
3. Only then decommission old hosts
4. Cert renewals scheduled outside the cutover hour

If certbot runs on the old host after traffic moves, you may renew the wrong place and wonder why production expired weeks later.

Greylisting and deferred mail

After a migration, greylisting can make “success” look delayed even when DNS/TLS are correct. Distinguish deferrals with 4xx greylist reasons from TLS handshake failed. Only the latter points at cert identity.

Scope boundary vs Mailby

Mailby operates receive-only inboxes for users and developers. This runbook is for operators of their own inbound infrastructure. Do not interpret consumer Quick Inbox behavior as a monitor for your corporate MX. After your MX is healthy, application tests may use /developers.

Tabletop exercise

Once per quarter, simulate “half dig old / half dig new” on a staging domain and practice shutting the ambiguous listener. The muscle memory pays off at 2 a.m.

Related application testing: Next.js verification email tests. Product explainers: /how-it-works, /security.

Monitoring signals to wire before the next cutover

• External SMTP probe (TCP + STARTTLS verify) every 60s
• Certificate expiry alerts at 30/14/7 days
• DNS configuration drift detection on MX/A/AAAA
• Inbound accept-rate anomaly alerts on your MTA metrics

Without probes, users become your monitoring. Temporary consumer inboxes are not a substitute for these signals on domains you operate.

Keep a printed (or locally saved) copy of this runbook offline—DNS problems sometimes coincide with the wiki being unreachable for unrelated reasons.

Practice openssl commands on a staging MX quarterly so syntax recall is automatic during incidents.

When dig looks fine but mail still fails

Move down the stack: firewall rules on port 25, provider blocking residential probes, RBL on the new IP, disk full on the MTA, or LDAP/recipient lookup failures. DNS/TLS fixation is common after a cert cutover, but it is not the only failure mode. Keep the layer table in this article as a ticket template—fill expected vs observed per row before changing more DNS.

If you changed SPF/DKIM at the same time as MX, separate those experiments; authentication failures produce different bounce text than TLS handshake errors.

Certificate chain completeness

Clients validate the full chain. Presenting a leaf without intermediates causes verify failures that look identical to name mismatch in some logs. On the new host, inspect openssl s_client output for “unable to get local issuer certificate.” Install the intermediate bundle your CA provides before DNS cutover.

OCSP stapling misconfiguration rarely blocks SMTP the way HTTPS browsers do, but keep stapling configs consistent across blue/green hosts so you do not chase ghosts.

Change tickets should list both DNS and TLS owners

Migrations fail socially when DNS is owned by one team and certs by another. Put both names on the change ticket with a shared bridge call. The bimodal IP problem in this article is often a coordination problem wearing technical clothes.

After success, raise TTLs back to normal carefully—do not leave 60-second TTLs forever unless you enjoy extra recursive load.

Sources, test date, limitations

• RFC 5321 SMTP
• RFC 3207 STARTTLS for SMTP
• CA/Browser expectations for name matching—operational practice via OpenSSL verify

Date: 2026-09-24. Environments differ (cloud LB, Kubernetes nodeports, dual-stack). No disclosure of Mailby concealed operations. No guarantee a specific public resolver flushed on your schedule.

Conclusion

Inbound cutovers fail loudly when DNS cache and TLS identity diverge. Measure both, disable ambiguous listeners, and roll back the smallest broken layer. Keep user-facing disposable mail discussions separate from MX runbooks—and keep your canary addresses under domains you operate.