Incorrect MX during a TLS cert change: inbound mail runbook

If inbound mail fails during a TLS certificate change, assume the certificate work and the MX target can fail independently—and find the earliest wrong hop before you reissue anything. Incorrect MX (pointing at a staging host, old LB, or parked domain) presents like a TLS incident because both surface as “mail isn’t arriving.” Temporary consumer inboxes are irrelevant to fixing your MX; use them only as external probes. This runbook is for operators of legitimate receive infrastructure—not a tour of Mailby’s internal ops panel.

TLS certificate change context

Teams rotate certs on mail.example.com (submission or MX targets) when expiry nears, when switching CAs, or when enabling new SANs. Parallel changes often include:

• DNS MX updates
• Load balancer backend swaps
• Firewall allowlists
• MTA TLS policy (smtp_tls_security_level, STS, DANE)

Scope this article to authorized environments you operate. Do not probe third-party MX without permission.

Mailby’s public product remains a receive-only temporary email service (/how-it-works). Customer Quick Inbox addresses depend on Mailby’s MX—not on your corporate cert rotation. Linking here is educational for operators building similar receive paths.

Symptom → earliest failing hop

Typical reports:

• External senders bounce with “cannot connect” / TLS handshake errors
• Messages delay for hours then arrive
• Only some networks fail (middlebox TLS inspection)
• Webmail works (IMAP) but SMTP inbound fails—or the reverse

Field notes (decision guide + counterexample, 2026-09-24)

Working path: During a staged cert swap, MX still pointed at the production pool. New cert deployed to the pool with matching CN/SAN for the MX hostname. Probe from an external host: TCP 25 open, STARTTLS advertises expected name, certificate chain validates. Inbound test message accepted.

Failure / counterexample: Operators updated the certificate on staging mail-staging.example.com but also changed MX to that staging name during a “cutover rehearsal” that was never reverted. Production cert was fine; MX was wrong. Hours were spent reissuing production certificates. Rollback: restore MX to production targets; leave staging cert alone.

Lesson: Validate DNS MX before you touch CA tooling again.

Layer table

Layer	Check	Expected observation	Failure clue	Rollback
DNS MX	dig MX example.com	Priority targets you intend	Old/staging hostname	Restore prior MX TTLs permitting
Address records	dig A/AAAA on MX host	IPs of current receive pool	Stale IP to decommissioned VM	Fix A/AAAA or LB
TCP reachability	nc -vz host 25 from external	Connect succeeds	Firewall / security group	Reopen 25/465/587 as designed
TLS name	Handshake to MX host	Cert SAN matches MX hostname	Name mismatch alert	Serve correct cert or fix DNS name
Chain trust	openssl s_client	Chain to trusted root	Missing intermediate	Install full chain
MTA accept	Auth test message	250 OK	4xx/5xx in logs	Fix config; replay queue
App mapping	Recipient resolution	User/inbox found	Orphaned domain routing	Fix virtual maps

Mechanism: why cert changes collide with MX mistakes

Certificates bind names. MX binds routes. If you rename the receive endpoint as part of a cert SAN cleanup, you must move MX in lockstep—or traffic hits a host whose cert does not match, or a host that never ran an MTA. Monitoring that only checks HTTPS on www will not catch SMTP breakage.

Useful references:

• RFC 5321 — SMTP
• RFC 3207 — STARTTLS
• MTA-STS — policy for MX TLS expectations when deployed

Safe probe sequence (authorized)

1. Record current MX and TTLs (screenshot + zone export).
2. From an external VPS you control, resolve MX and connect to port 25.
3. Inspect certificate names with openssl s_client -connect host:25 -starttls smtp.
4. Send a unique-token message to a test recipient on that domain.
5. Confirm acceptance in MTA logs and mailbox store.
6. Only then retire old certs / old backends.

If step 2 points at the wrong host, stop and fix DNS. Do not reissue certificates as a ritual.

Worked example: cutover rehearsal gone wrong

Timeline:

• T0: MX 10 mail.example.com
• T1: Rehearsal sets MX 10 mail-staging.example.com (TTL 300)
• T2: Staging gets new Let’s Encrypt cert
• T3: Production still healthy but receives no mail
• T4: On-call sees TLS expiry alerts on a different hostname and misattributes

Fix: Revert MX to mail.example.com; wait TTL; confirm probes; schedule a real cutover checklist with two-person review.

Alternatives and continuity

While repairing corporate MX, staff still need email. Use secondary MX if you have a warm standby, or a provider failover—not consumer temporary inboxes for executive mail. Temporary addresses (/inbox) are for disposable tasks, not as a silent MX backup for a company domain.

Developers testing app mail during the incident should sink to controlled QA inboxes (/developers) rather than production mailboxes that may be delayed.

Related reading: Next.js welcome delivery tests, /security for how Mailby frames receive-only trust.

How this differs from a receive-infrastructure hub

The hub describes inbound architecture patterns. This page is a runbook for incorrect MX during TLS certificate change, with a staging-cutover counterexample and a layer table emphasizing rollback of DNS before CA work.

Short answers

What causes incorrect MX during cert work? Cutover rehearsals, SAN renames, and LB swaps that update DNS without reverting.

What should I do first? dig MX and compare to the host you just certificated.

When is a permanent address safer? Always for organizational identity mail; temp mail is not an MX failover strategy.

What evidence changes the recommendation? If TCP/TLS to the correct MX host succeeds but recipients 5xx, shift from cert/DNS to MTA mapping.

Sources, test date, limitations

• Runbook synthesis: 2026-09-24
• RFCs 5321, 3207, 8461 linked above
• Mailby product (separate system): /how-it-works, /status

Limitations: Exact openssl flags and MTA log formats vary. We do not disclose Mailby internal panel procedures. Always follow your change-management policy.

TTL traps and cached resolvers

Even after you fix MX, some senders cache the old target until TTL expires. Low TTLs (300s) before planned cutovers reduce pain; lowering TTL after a mistake cannot rewind caches that already fetched the bad record. During incidents, communicate expected convergence time to stakeholders instead of thrashing certificates.

Corporate recursive resolvers may cache longer than public DNS. Probe from multiple networks: home ISP, cloud VPS, mobile hotspot. Disagreement between probes points to cache skew, not “random TLS bugs.”

Certificate inventory discipline

Maintain a sheet of:

• Hostname
• Role (MX target, submission, webmail, MTA-STS policy host)
• SANs
• Expiry
• Owner

TLS tickets that only list www hostnames miss mail. and smtp. endpoints. Certificate automation (Let’s Encrypt hooks) should deploy to every listener that presents TLS for those names—including load balancers that terminate SMTP STARTTLS.

Dual-stack and firewall asymmetries

An MX host with working IPv4 and broken IPv6 AAAA records creates sender-dependent failures. Some IPv6-first senders fail TLS or TCP while IPv4-only senders succeed. During cert changes, operators sometimes update IPv4 pools only. Include AAAA in the layer table checks.

Security groups that allow 25/tcp from “the office” but not the public Internet create false confidence in internal tests. External probes are mandatory for inbound MX validation.

Communication template for stakeholders

Inbound mail MX was pointing at staging since HH:MM UTC. We reverted MX to production. TTL is N minutes. Some senders may retry on their own schedules. Do not reissue certificates unless probes show name mismatch on the current MX target.

Clear communication prevents parallel “helpful” changes that extend the outage.

Post-incident hardening

After restoring mail:

1. Add synthetic probes: external SMTP connect + TLS name check every minute.
2. Alert on MX diffs against an approved desired-state file.
3. Require two-person approval for MX changes in DNS.
4. Separate staging hostnames permanently (mail-staging.) so rehearsals cannot steal production MX by typo alone.
5. Document the rollback command in the runbook sticky.

Probes should not spam real user mailboxes—use dedicated canary recipients.

Distinguishing submission TLS from MX TLS

Users often test by sending from their laptop via port 587 submission. That path can succeed with a renewed submission certificate while inbound MX on port 25 still points at a dead host. Always clarify which role you certified. Inbound runbooks start at MX, not at “I can send from Thunderbird.”

Vendor DNS UI footguns

Some DNS panels silently add parking MX records when you “enable email.” Others rewrite @ apex records during certificate wizard flows meant for web only. After any wizard, re-run dig MX and compare to the desired-state file. Wizards optimize for web HTTPS, not SMTP.

DANE and MTA-STS interactions

If you publish MTA-STS or DANE TLSA records, a certificate change without policy updates causes authenticated senders to refuse delivery even when “openssl looks fine” from casual probes that ignore STS. Include policy hosts in the inventory. After cert rotation, confirm STS policy still pins acceptable MX names and that TLSA hashes match the new cert if DANE is in play. Skipping this layer creates intermittent failures only from STS-aware senders—nightmarish to triage.

Training on-call without touching production

Build a lab domain with intentional wrong MX and expired certs. Walk new on-calls through the layer table until dig/openssl muscle memory sticks. Do not use customer mail domains for training. Lab reps prevent the “reissue first” reflex during real incidents.

Change calendar hygiene

Never schedule MX cutovers on the same day as certificate mass-renewal bots without a human gate. Calendar the dig-MX verification as its own checklist item with a named owner. Automation that renews certs should not have DNS MX edit credentials.

Customer communications during inbound loss

Status pages should say “inbound SMTP degraded” with the hop you are fixing. Vague “email issues” causes people to reset passwords unnecessarily. If you operate a receive-only product for others, keep customer temp-mail expectations scoped—your corporate MX outage is not their Quick Inbox outage unless shared infrastructure says so.

Reader takeaway box

Match the tool to the downside. Temporary receive-only mail excels at short verification and throwaway curiosity. Durable addresses and aliases excel at recovery, money, travel, and reputation. Product pages: /inbox, /pricing, /data-retention, /security, /developers, /how-it-works.

Packet captures as last resort

tcpdump on port 25 can confirm whether SYN packets arrive during suspected firewall issues. Only capture on systems you own and with policy approval. Most MX/TLS incidents resolve at dig/openssl layers without captures.

Conclusion

Certificate expiry pages and MX mistakes wear the same “mail is down” costume. Dig MX first, match TLS names second, accept a test message third, roll back the earliest wrong hop. Keep disposable inboxes out of your corporate failover fantasy—and use them only as external probes when that is an authorized, intentional choice.