Port 25 failure during a DNS cutover: inbound runbook

Find the earliest failing hop before you touch MX again. A port 25 connectivity failure during a DNS cutover is usually not “the Internet is down.” It is one of: stale or partial DNS, a firewall or cloud security group that never opened SMTP on the new path, a listener bound to the wrong interface, TLS/banner mismatches that look like hangs, or intentional ISP blocks on egress from the sending side while you test. Roll forward only after you can prove TCP accept and SMTP banner on the intended hosts—and keep a one-command MX rollback ready.

This runbook is for operators of legitimate inbound mail on infrastructure they own. It is not a guide to bypass provider blocks, and it does not expose Mailby’s internal operations panel. Temporary consumer inboxes on Quick Inbox are unrelated to your corporate MX cutover except as an external probe address for authorized tests.

DNS cutover context and boundaries

Typical cutover:

1. New MTAs provisioned (or new anycast VIP).
2. Firewall rules updated for TCP/25 (and submission ports if used—but inbound Internet mail is port 25 between MTAs).
3. MX (and often A/AAAA for MX hosts) lowered TTL ahead of time.
4. MX switched to new targets.
5. Old fleet drained and decommissioned.

Boundaries:

• You must be authorized on the DNS zone and hosts.
• Some networks block outbound 25 from laptops; test from a VPS with honest egress.
• Greylisting and tarpits can mimic “connection failure” if you only try once.
• Mailby product pages (how it works, developers) describe receive-only product behavior—not your private MX design.

SMTP remains defined by RFC 5321. DNS MX behavior is in RFC 5321 and related DNS RFCs; operational DNS guidance often references RFC 1035 basics.

Demonstrate the failure with a measurable probe

Test date: 2026-09-24. Use a fixture like this on a cutover rehearsal (replace hosts with yours).

Working path

1. Pre-cutover baseline. From a probe host: dig +short MX example.com and dig +short A mx-old.example.com. Record banner: nc -vz mx-old.example.com 25 then a manual SMTP dialogue or swaks --to postmaster@example.com --server mx-old....
2. Lower TTLs (for example to 60–300s) at least twice the old TTL before the change window.
3. Cut MX to mx-new.example.com.
4. Immediate checks: DNS from multiple resolvers (local, 1.1.1.1, 8.8.8.8). Confirm answers match the intended new targets—not a mix of old and new unless you designed dual-MX.
5. TCP check: nc -vz mx-new.example.com 25 from the probe. Success means SYN-ACK. Failure means firewall, routing, or no listener.
6. SMTP check: expect a 220 banner within seconds. STARTTLS optional for this connectivity test; do not confuse cert mismatch with port closure.
7. Send a single authorized message to a catch-all or test recipient you control. Confirm queue arrival.

Failure / limitation observed

A team flipped MX while the new VM’s security group allowed 22 and 443 but not 25. External dig looked perfect; nc timed out. They “fixed DNS” twice. The earliest failing hop was cloud firewall, not DNS. Rollback of MX restored mail within one TTL after dig caches caught up.

Another limitation: probing port 25 from a residential ISP can fail even when the server is fine—many ISPs block outbound 25 to fight bots. Always note where the probe runs.

Mechanism: layers that break during cutover

DNS propagation and split horizon

Corporate resolvers may cache old MX longer than public ones. Split-horizon DNS can show employees the new MX while the world still sees the old—or the reverse. Dual-MX with different priorities can send a fraction of traffic to a half-ready host.

Firewall / ACL / security groups

New IPs need explicit allow for TCP/25 from the world (or from known partner ranges if you run restricted MX). Stateful firewalls may need separate IPv6 rules when you publish AAAA.

Listener and bind address

Postfix/smtpd listening on 127.0.0.1 only will pass local tests and fail externally. Containers without published ports show the same symptom.

Policy and greylist

A “connection delay” may be intentional. Distinguish TCP failure from 450 greylist responses after banner.

Sending-side blocks

When you test with a laptop MTA, outbound 25 may be filtered. That is not an inbound outage.

Layer table

Layer	check	expected observation	failure clue	rollback
DNS MX	dig MX multi-resolver	New targets + priorities	Old MX / SERVFAIL / mismatch	Restore prior MX RRSet
DNS A/AAAA	dig A for MX host	Addresses of new fleet	Points to decommissioned IP	Fix A/AAAA; keep MX stable
Routing	traceroute / cloud path	Reachable subnet	Blackhole after cut	Revert VIP / routes
Firewall	nc -vz :25	SYN-ACK	Timeout / admin reject	Open SG/ACL; or revert MX
Listener	local ss -lntp	Process on 0.0.0.0:25 or VIP	Nothing listening	Start MTA; or revert MX
SMTP banner	manual/swaks	220 greeting	Hang after TCP / RST	Fix MTA config
App queue	test message	Delivered + logged	Deferred in remote queue	Keep old MX until queue drains

Worked example (timeline)

• T-48h: TTL lowered to 300s. New MX hosts pass external nc and swaks.
• T0: MX updated. Monitoring shows TCP success from three regions.
• T+10m: One region still digs old MX (resolver cache). Dual receive on old+new continues until caches expire—planned overlap.
• T+2h: Old MX still accepting with equal priority by mistake → inconsistent TLS names. Fix priority to make old priority=100 sink only leftovers, then decommission.

Bad timeline: TTL still 86400s; MX flipped; firewall closed; operators wait “for DNS” for hours while mail piles in sender deferral queues.

Alternatives and when this is not a temp-mail problem

• Staged dual-MX: Keep old MX at higher preference number (lower priority) until metrics clear.
• Anycast cut: Health checks must include port 25, not only ICMP.
• Managed email / Google / Microsoft: Cutover is admin-center and DNS TXT/MX wizards—still verify with external probes.
• Mailby: Use as an external recipient for application tests (/developers), not as a substitute for your domain’s MX. Consumer Quick Inbox will not debug your port 25 path.

Durable corporate mailboxes are the normal end state for user mail; temporary inboxes do not belong in MX design.

Short answers

What causes port 25 connectivity failure during a DNS cutover?

Most often firewall or listener gaps on the new target, sometimes cached DNS, sometimes probe egress blocks.

What should I do first?

From an unrestricted probe host: dig MX → dig A/AAAA → TCP 25 → SMTP banner. Stop at the first fail.

When is a permanent address safer?

Always for user identities. This runbook is infrastructure, not a reason to put staff on disposable mail.

What evidence changes the recommendation?

If TCP works and SMTP greets but mail defers, shift from connectivity to reputation, greylist, or TLS policy debugging—not another MX flip.

Sources, test date, and limitations

• Runbook patterns dated 2026-09-24; commands vary by OS.
• RFC 5321, RFC 1035.
• Provider-specific firewall UIs change; verify against your cloud docs.

Limitations: No Mailby internal panel details. Distinct from a general receive-infrastructure hub by focusing on port 25 during DNS cutover.

Conclusion

Treat cutover mail loss as a hop-by-hop proof problem. Measure DNS, TCP, banner, then delivery; keep MX rollback ready. For application-level receive tests after your MX is healthy, developers and Quick Inbox can serve as authorized destinations—not as operational promises about your fleet. Pair with status only for Mailby’s own public service health, not your domain.

Monitoring you should enable before the window

• External TCP checks on each MX host from multiple regions
• SMTP banner checks (not only TCP)
• Queue depth on old and new fleets
• DNS consistency checks across public resolvers
• Certificate expiry for STARTTLS names matching MX hosts

If monitoring only hits HTTPS admin panels, you will miss port 25 failures.

Communication template for stakeholders

Before cutover, announce:

• Start/end window
• Expected deferrals for senders that cached MX
• Rollback criteria (for example: TCP success rate < 99% for 10 minutes)
• Status page URL for customers if applicable

After cutover, report earliest failing hop if any, not vague “email issues.”

IPv6 and dual-stack surprises

Publishing AAAA before listeners are ready on v6 blackholes a growing share of senders. Either dual-stack completely or delay AAAA until port 25 works on v6 from an external probe.

TLS name mismatches after VIP moves

Connectivity can succeed while clients abort on certificate CN/SAN mismatch. That presents as intermittent delivery depending on whether senders enforce TLS. Include openssl s_client -connect host:25 -starttls smtp in the runbook after raw TCP passes.

What not to do

• Do not keep flipping MX as a debugging tool
• Do not open port 25 to the world on the wrong VLAN “temporarily” without tracking the change
• Do not use consumer temporary inboxes as proof your MX works—they prove an external destination works, not your listeners

Authorized application tests can still send into Mailby (/developers) once your outbound path is healthy.

Post-cutover soak period

Keep the old fleet accepting mail at a worse MX preference for one to two TTLs after the new path proves healthy. Watch deferred queues on both sides. Only then remove old hosts from security groups and DNS. Premature decommission is a common self-inflicted outage.

Documentation artifacts to store

• Dig outputs timestamped from three resolvers
• nc / swaks transcripts (redact message bodies)
• Firewall change tickets
• Rollback command snippets

These artifacts turn the next cutover into a checklist instead of archaeology.

Abuse and rate controls on new IPs

New MX IPs have cold reputations. Some senders throttle. That is not port 25 closure—but it can look like “mail is broken” if you only watch a single test message. Use multiple external senders and wait through deferral windows before declaring failure.

Scope limits regarding Mailby

Mailby’s public status and product docs cover Mailby. Your domain’s MX cutover is your runbook. Use Mailby receive endpoints only as external test targets when authorized (/developers).

Mini tabletop exercise

Once per year, rehearse:

1. Announce a fake cutover in a staging zone.
2. Close port 25 on purpose on the new host.
3. Have the secondary operator run the dig → nc → banner sequence blindly.
4. Confirm they identify firewall as the earliest hop and execute rollback.

Tabletops beat production heroics. Keep consumer temporary email out of the exercise except as an optional external recipient after connectivity is restored.