Diagnosing port 25 failure during a TLS certificate change

If inbound mail breaks during a TLS certificate change, assume the earliest failing hop—not the newest shiny cert—until proven otherwise. Check DNS/MX, raw port 25 reachability, then STARTTLS handshake against the presented chain, then MTA listeners and firewall rules. Roll back the certificate change only after you can name the failing layer. This runbook is for operators of authorized receive infrastructure—not a probe guide for systems you do not own.

It complements receive email infrastructure with a certificate-swap incident cut. Mailby’s public product receives on its own MX; we do not expose internal ops panels here.

TLS certificate change context and boundaries

Certificate rotations touch:

• Public listener certs for SMTP STARTTLS
• Possibly separate HTTPS certs for webhooks/admin (out of scope unless mixed)
• Load balancers that terminate TLS in front of MTAs
• CAA/DNS changes timed near the swap

Boundaries:

• Only diagnose hosts you operate.
• Port 25 is widely blocked on residential ISPs—test from an appropriate network.
• Temporary consumer inboxes (/inbox) are unrelated to fixing your MX; link them only as receive-only product context.

Demonstration: working path and counterexample

Working path. Pre-change: openssl s_client -connect mx.example.com:25 -starttls smtp shows the old chain. Deploy new cert + reload MTA. Post-change: same check shows new notAfter, matching SANs for the MX hostname. External monitors resume green. Queue drains.

Counterexample. Team uploads a cert for webmail.example.com but MX points at mx1.example.com. STARTTLS fails name checks from strict senders; some mail still slips through opportunistic TLS. Symptoms look like “port 25 is down” when TCP connect succeeds and the failure is handshake policy.

Layer table

Layer	Check	Expected observation	Failure clue	Rollback
DNS / MX	Dig MX + A/AAAA	Targets current hosts	Stale IP after cutover	Restore DNS TTLs carefully
TCP :25	Connect from external probe	SYN-ACK	Firewall/security group	Reopen rules
SMTP banner	Read banner	Expected MTA identity	Wrong backend	Fix LB pool
STARTTLS	OpenSSL/s_client	Valid chain + SAN	Name mismatch / expired	Reinstall prior cert
Auth/policy	EHLO + probes	Capabilities list	Missing STARTTLS advert	Config restore
App queue	Internal deferred queue	Drain rate normal	Growing deferred	Pause marketing sends

Mechanism and failure cases

SMTP often uses opportunistic STARTTLS. After EHLO, client issues STARTTLS, then renegotiates. A bad cert may:

• Fail client verification → some ESPs defer, others proceed plaintext (policy-dependent)
• Break mandatory-TLS partners entirely
• Cause LB health checks to flap if they validate TLS

Certificate change checklists should include reload of the actual process that holds the file, not only uploading to a secrets store. Split-horizon DNS can make internal tests pass while the public internet fails.

Concrete worked example

1. Incident: “Customers say confirmations bounce” after tonight’s certbot renew.
2. Probe TCP 25 from an external VPS — OK.
3. STARTTLS — certificate hostname mismatch.
4. Compare SAN list to MX hostnames — mismatch confirmed.
5. Install correct cert; reload; re-probe; watch deferred queue.
6. Postmortem: add CI check that SANs cover all MX names before deploy.

Alternatives and product context

If you only need disposable receiving for app QA, you do not need to run port 25 yourself—use Mailby developers or Quick Inbox. If you run inbound for a product, keep runbooks, monitors, and rollback artifacts ready. Durable corporate mailboxes are unrelated to MX TLS except as customers of your domain.

Short answers

What causes port 25 symptoms during TLS changes?
Often TLS/name mismatch or reload misses—not always a closed port.

What should I do first?
Separate TCP connect success from STARTTLS success.

When is a permanent address safer?
N/A for ops—this is infrastructure. For users: durable mail for accounts that must survive your incident.

What evidence changes the recommendation?
TCP failure → network path; handshake failure → cert/config; banner wrong → routing/LB.

Sources, test date, and limitations

• SMTP: RFC 5321; STARTTLS: RFC 3207.
• Editorial runbook shape as of 2026-09-24. Does not disclose Mailby internal operations.

Pre-change canary checklist

Before swapping certificates on inbound MX hosts:

1. Snapshot current cert fingerprint and notAfter.
2. Confirm private key matches CSR/cert (openssl x509 / openssl rsa modulus checks).
3. Stage the new chain on a canary MX with low MX priority (higher number) if architecture allows.
4. Probe from at least two external networks.
5. Raise priority / cut traffic only after canary stays clean for your soak window.
6. Keep the previous cert package offline but ready for immediate reload.

Monitoring signals that beat vibes

• External STARTTLS check with certificate expiry alerting (30/14/7 days)
• Deferred queue depth
• 4xx/5xx SMTP response rates
• Ticket volume tagged “verification email”

A cert change window without these dashboards is flying on hope. For product-level receiving without running your own MX, see how it works and developers. Consumer disposable mail remains at /inbox—orthogonal to this runbook, but useful when your app needs a destination during staging incidents.

Communication plan during the change window

Certificate changes fail socially as often as they fail technically. Publish a short status to internal stakeholders:

• Start time and expected soak duration
• User-visible risk (“verification emails may delay”)
• Rollback criteria (STARTTLS probe red for N minutes)
• Comms owner

If you run a status page, post before, not after, the first customer ticket.

Load balancer and SNI pitfalls

Modern SMTP frontends may require SNI. A cert installed on the backend but not on the TLS-terminating LB produces perfect internal tests and public failure. Explicitly test through the same VIP customers hit. Document whether TLS terminates at LB or MTA.

Chain incompleteness

Missing intermediate certificates cause inconsistent failures across client stacks. Always install the full chain your CA provides. Validate with tools that print the presented chain, not only the leaf fingerprint.

OCSP / CRL hard-fail rare cases

Some hardened senders hard-fail on OCSP issues. If your change coincides with CA-side OCSP turbulence, defer non-urgent rotations. Keep this on the differential diagnosis list when fingerprints look correct but strict partners defer.

Post-incident artifacts

Store:

• Old and new fingerprints
• Probe transcripts
• Queue graphs
• Ticket volume
• Timeline of reload commands

Those artifacts train the next rotation. Avoid tribal “we fixed it somehow” endings.

Relationship to Mailby

Mailby operates receive infrastructure for disposable inboxes; this runbook is for operators of their own MX. If your product needs inbound test mail without running port 25, use /developers. End users evaluating apps can keep using /inbox. Product model: how it works. Do not interpret this article as a description of Mailby’s private ops console—those details stay internal by design.

Lab exercise for a staging MX

Build a disposable staging MX (or containerized MTA) and practice the rotation:

1. Issue a cert with wrong SAN intentionally.
2. Observe probe failure mode.
3. Fix SAN; reload; observe recovery.
4. Issue expired cert; observe.
5. Remove intermediate; observe client-specific failures.

Muscle memory from a lab beats theorizing during a customer-facing outage. Keep the lab network isolated and authorized.

Change tickets

Require the ticket to list: hosts, SAN inventory, reload commands, probe commands, rollback package location, and soak duration. No ticket, no production rotation.

Multi-region

Rotate one region at a time. Keep MX priorities such that healthy regions absorb load. Document geoDNS behavior so you do not misread a regional cert failure as global port 25 death.

Differentiating “port closed” from “TLS unhappy” in one minute

From an authorized external probe host:

1. nc -vz mx.example.com 25 — if this fails, stop talking about certificates.
2. If TCP works, run STARTTLS inspection.
3. If STARTTLS works from one network but not another, suspect middleboxes or regional LBs.

That one-minute triage prevents twenty-minute cert rabbit holes during a firewall mishap.

Documentation debt

Update runbooks the same day you learn a new failure mode. Orphaned Confluence pages cause repeat outages. Link probe scripts in the repo next to Terraform that owns the MX hosts.

Customer messaging templates

Prepare two status blurbs: one for deferred delivery, one for hard failures requiring sender retries. Accuracy calms support load.

When to call the CA

If the leaf is correct but clients reject without a clear name error, check intermediates and CA incident pages. Sometimes the problem is not your reload.

Closing

Certificate changes are routine when rehearsed and chaotic when not. Separate layers, canary first, measure queues, roll back with pride when needed. For app teams that only need inbound test mail, skip running port 25 and use Mailby’s receive APIs instead.

Appendix: probe command hygiene

Store probe scripts next to infrastructure code. They should print timestamps, target VIP, certificate fingerprint, and SAN list in one block suitable for pasting into an incident channel. Avoid screenshots of terminals as the only evidence—text transcripts search better later.

When probes must run from multiple clouds, automate them. Humans forget to check the second region at 2 a.m. Automation does not replace judgment, but it removes “we only tested from the office wifi” blind spots—especially relevant because office networks often block port 25 outbound and fool you into thinking the MX is down.

Extended rollback story

A team swapped certificates on both MX hosts simultaneously. STARTTLS broke for mandatory-TLS partners. Because they had kept the previous cert package on disk and a documented reload command, rollback took four minutes. Queue depth returned to normal in twenty. The postmortem’s main action item was not “hire more people”—it was “canary one host first,” which this runbook already recommends. Incidents become cheaper when rollback is rehearsed and shame-free.

Closing practice notes for TLS rotations

Schedule rotations in low-traffic windows, canary a single MX, require transcript evidence before declaring victory, and keep rollback shame-free. Port 25 symptoms during cert changes are usually layered failures—name them in order. Teams that only need disposable receiving should not run MX at all; use Mailby receive instead and save port 25 expertise for when you truly operate inbound mail.

Add certificate SAN inventory to your infrastructure pull-request template. Reviewers should see hostnames before merge. That single checklist line prevents an entire class of “we rotated and mail died” nights.

One more pattern: pre-staged dual certificates

Where the MTA supports it, stage the next certificate alongside the current one and flip with a config flag. Dual staging shortens rollback to a flag flip instead of a file restore. Not every MTA makes this easy—but when it does, prefer it for production MX hosts that carry customer verification mail.