Incorrect MX during a DNS cutover: inbound mail runbook

When inbound mail breaks during a DNS cutover, check whether MX points at the intended receive hosts before debugging application code. An incorrect MX target—stale hostname, wrong priority, or half-propagated record—fails at the earliest public hop. Measure with authoritative lookups, keep the previous MX ready for rollback, and limit claims to what headers and SMTP transcripts prove.

This runbook is for operators of legitimate inbound mail. It does not expose Mailby’s internal operations panel. Disposable Quick Inbox is unrelated to your corporate MX—use it only as a side channel while you repair production receive.

DNS cutover context and boundaries

A cutover moves receiving from provider A (old MX) to provider B (new MX), or between your own MTAs. Common triggers: migrating to Google Workspace / Microsoft 365, bringing mail in-house, or changing ESP inbound gateways.

Boundaries:

• You must be authorized to change the zone. Do not alter domains you do not operate.
• Mailby consumer Quick Inbox uses Mailby’s MX, not yours. This article is about your domain’s MX.
• Developer receive APIs at /developers help test app mail; they are not a substitute for fixing corporate MX.
• Lower MX priority number = higher preference. Mis-ordered priorities send mail to the wrong cluster first.

Demonstrating an incorrect MX target

Working path (healthy cutover):

1. Lower TTL on MX days ahead (e.g., 300 seconds).
2. Publish new MX alongside old with correct priorities during dual-receive if supported.
3. dig MX example.com +short against multiple resolvers shows expected hosts.
4. Send test messages from external networks; receive on new system.
5. Raise TTL after soak.

Failure fixture (incorrect target):

; intended
example.com.  300  IN  MX  10 mx-new.mail.example.net.

; accidentally published
example.com.  300  IN  MX  10 mx-old.deprecated.example.net.

Symptoms: senders get bounce “connection refused,” or mail silently still lands on the old system you planned to decommission. App teams file tickets about “email bug” while DNS is wrong.

Editorial checklist date: 2026-09-24.

Mechanism: earliest failing hop

1. Sender MTA resolves MX.
2. Connects to the highest-priority host that answers.
3. If that host is wrong/decommissioned → deferral or bounce.
4. Your app never sees SMTP DATA.

So “check the app inbox UI” is late. Start with DNS and TCP 25 reachability to the published targets.

Propagation: recursive resolvers cache MX until TTL expiry. During cutover, different senders can see different targets. That split-brain is expected until TTLs die.

Reference: RFC 5321 for SMTP; RFC 1035 for DNS basics.

Layer table

Layer	Check	Expected observation	Failure clue	Rollback
Authoritative DNS	dig MX example.com @ns-auth	New MX hosts/priorities	Old host still authoritative	Restore previous RRSet
Resolver cache	dig MX via 8.8.8.8 / 1.1.1.1	Matches auth after TTL	Divergence beyond TTL	Wait or notify; do not thrash
TCP/SMTP	nc -vz mx 25 / banner	Banner from intended MTA	Timeout / wrong banner	Point MX back to known-good
TLS	STARTTLS policy	Cert matches hostname	Name mismatch	Fix cert or roll MX
Filtering	Gateway logs	Test message accepted	Reject policies	Temporarily allowlist test senders
App mailbox	Store delivery	Message visible	Empty while SMTP OK	Debug LDA/store—not MX

Worked example

1. Incident: “Customers stop getting verification mail after migration day.”
2. dig MX brand.com @auth-ns → still lists mx.oldvendor.com.
3. Root cause: zone push failed; CDN/UI cut over but DNS did not.
4. Action: publish correct MX; keep old MX live until caches clear; re-send verification for affected users.
5. Verify with external probe accounts (including a Mailby inbox as an unrelated external receiver for your outbound tests—not as your MX).

Alternatives and scope of claims

• Dual MX during migration reduces hard cut risk.
• Temporary secondary for disaster receive.
• Do not use consumer disposable addresses as your organization’s MX target.

When is a “permanent” mailbox relevant? Always for staff identities. Disposable tools help QA outbound templates (Playwright isolation guide) while MX is repaired—they do not replace inbound infrastructure.

See how it works for Mailby’s own receive metaphor, and security for transport expectations.

Short answers

What causes an incorrect MX target during a DNS cutover?

Wrong hostname, wrong priority, failed zone publish, or cached old RRSet after a rushed cut.

What should I do first?

Query authoritative NS for MX; compare to intended hosts; test port 25; prepare rollback RRSet.

When is a permanent address safer?

Staff and customer domains always need durable, correctly targeted MX. Disposable inboxes are side tools.

What evidence changes the recommendation?

Headers proving mail reached the new MTA (then debug filtering/store). Or registrar lock preventing updates—escalate DNS access.

Sources, test date, and limitations

Test date: 2026-09-24.

External sources:

• RFC 1035
• RFC 5321
• M3AAWG best practices — operator-oriented mail hygiene context

Limitations: Provider-specific admin UIs differ. We do not publish Mailby concealed ops procedures. Commands assume you have shell access and authorization.

Pre-cutover checklist (copy into your change ticket)

• TTL lowered at least 2× TTL hours before change
• New MTA accepts mail for the domain (conversation test)
• TLS certificates match MX hostnames
• SPF updated if you also send from new infrastructure (send path ≠ MX but tickets confuse them)
• Rollback MX RRSet documented
• On-call knows dig/openssl s_client basics
• Stakeholders know dual-delivery may duplicate messages briefly

Soft vs hard cut

Soft: both old and new MX published; drain old. Hard: swap abruptly. Soft is kinder to cached resolvers. Hard is acceptable only with tiny TTLs and accepting bounce risk.

Monitoring signals

• Inbound volume dashboards on old vs new
• Bounce rates with SMTP codes 4xx vs 5xx
• External synthetic probes every minute during the window

Customer communications

If verification mail fails during cutover, say so. Re-issue tokens after MX heals rather than telling users to “check spam” alone.

How this differs from a receive-infrastructure hub

Hub material surveys inbound architecture. This runbook is the incorrect MX during DNS cutover incident path: earliest hop, measurable checks, rollback first.

Common incorrect-target variants

1. Typo in hostname (mx1 vs mx-1).
2. CNAME used illegally at MX apex — some providers forbid MX → CNAME patterns; validate.
3. Priority inversion sending all mail to a sinkhole host meant for disaster only.
4. Stale glue / NS set so you edited the wrong zone view.
5. Registrar “email forwarding” MX silently restored by a panel toggle.

Each variant still starts with authoritative dig and banner checks.

SPF/DKIM confusion during cutovers

Teams “fix mail” by editing SPF while MX is wrong. Separate tickets: inbound MX vs outbound auth. Mixing them lengthens outages.

Using external probes ethically

Sending yourself tests from personal accounts is fine. Do not recruit strangers’ addresses. A Mailby inbox as an outbound test recipient from your staging app is fair use of receive-only tooling; pointing your corporate MX at Mailby is not a supported migration path.

Post-incident review prompts

• Did TTL discipline exist?
• Was rollback rehearsed?
• Were synthetics watching MX?
• Did app teams get a status page update?

Command cookbook (authorized zones only)

dig NS example.com +short
dig MX example.com @<auth-ns> +noall +answer
dig MX example.com +noall +answer   # recursive view
openssl s_client -connect mx-host:25 -starttls smtp </dev/null | head

Interpret banners carefully—load balancers may present generic names. Confirm the certificate DNS SAN matches what senders validate under DANE or MTA-STS if you publish those policies.

MTA-STS / DANE interactions

If you publish MTA-STS with old MX hostnames, senders may refuse new targets even when DNS MX looks right. Update policy files in lockstep. This is a frequent “invisible” cutover bug.

Runbook severity levels

• SEV1: No inbound for payments/support domain
• SEV2: Partial dual-delivery confusion
• SEV3: Delayed propagation within TTL

Page differently. Do not SEV1 for a marketing subdomain you meant to decommission.

Documentation debt

Store the last known-good MX RRSet in your change ticket template. Memory is not a rollback plan.

Annotated failure timeline (example)

• 09:00 Lower TTL to 300s.
• 14:00 Intended cutover; UI status green; DNS push fails silently.
• 14:05 Customers report missing OTPs.
• 14:20 App team digs Redis; waste.
• 14:45 Ops runs authoritative dig; sees old MX.
• 14:50 Publish correct MX; leave old host accepting for 1 hour.
• 15:10 Recursive views converge; synthetics green.
• 15:30 Re-issue OTPs for failed signups.

The expensive gap is 14:05–14:45. Put dig first in the runbook so that gap shrinks to minutes.

Coordination with ESP and support

Support macros should say: “We are repairing inbound DNS; your mail may queue; we will resend verification after the window.” Silence creates duplicate tickets and more resend storms.

What Mailby is not in this incident

Mailby is not your backup MX. Using consumer disposable addresses as a “temporary company inbox” loses audit trails and violates most enterprise policies. Keep Mailby in the probe/testing lane (developers, inbox).

Rollback decision tree

Authoritative MX correct?
  no → publish known-good RRSet; stop app debugging
  yes → Recursive views converged?
         no → wait TTL; communicate; keep old host warm
         yes → Port 25 banner/TLS OK?
                no → fix MTA/LB; MX may be fine
                yes → Check gateway filters / LDA / store

Walk top-down. Skipping to store debugging is the classic time sink.

Dual-delivery surprises

During soft cuts, users may receive duplicates. Prefer duplicate mail over lost mail. Tell support duplicates are expected for N hours.

Change windows

Prefer mid-week mid-day for B2B domains when admins are awake. Consumer domains may prefer low-traffic early mornings—pick based on audience, not habit.

Closing operator note

DNS lies differently to each resolver for the length of a TTL. Measure authoritative truth first, keep rollback warm, and only then blame the application store. Incorrect MX is common; long outages from skipping dig are optional.

Synthetic probe sketch

Every minute during the window, from an external VPS:

1. Resolve MX via public resolver.
2. Connect to top-priority host port 25.
3. Send a uniquely tagged message to a canary mailbox on the new system.
4. Alert if missing after N minutes.

Canaries catch wrong targets even when dashboards look calm. Keep the canary off customer domains if possible.

People process

Name a DNS DRI and an MTA DRI before the change. Split-brain ownership—“I thought you published MX”—is how incorrect targets linger.

Conclusion

Incorrect MX is an early-hop failure. Measure DNS, confirm the banner, roll back fast, then debug the app. Cutovers fail safely when TTLs were lowered and the previous target remains ready.

For app-level receive testing while infrastructure settles, use developers or Quick Inbox as external probes—not as your domain’s MX.