MX Troubleshooting: A Diagnostic Workflow for Broken Mail Delivery

Diagnose the Layer, Not the Symptom

"Mail isn't arriving" describes a symptom, not a cause, and it can originate from at least four genuinely different layers: DNS resolution of the MX record itself, network reachability to the host that record points at, SMTP-level acceptance or rejection once connected, and internal routing after the message has already cleared your perimeter. Jumping straight to changing DNS records because "it's probably DNS" wastes time when the actual fault is a firewall rule or a full disk on the mail server. A structured diagnostic sequence, worked from the outside in, isolates the failing layer in minutes rather than hours of guessing.

This guide is that sequence, plus a ranked list of what actually causes MX-related delivery problems in practice, ordered by how often each one turns out to be the real culprit.

The Diagnostic Sequence

1. Confirm the MX record resolves correctly, from an external resolver. Run dig MX yourdomain.com +short @8.8.8.8 and compare the result against what you expect. If nothing returns, or it returns a hostname you didn't set, the problem is at the DNS layer — check your zone file or DNS provider's dashboard directly.
2. Confirm every MX hostname resolves to an IP address. Run dig A mxhostname.example.com +short for each listed host. An MX record pointing at a hostname with no A/AAAA record is a dead end — sending servers will skip it entirely, silently degrading you to whatever's next in priority, or failing completely if it was your only host.
3. Confirm the host actually accepts connections on port 25 from outside your network. A quick telnet mxhost.example.com 25 from an external vantage point (not your own office network, which may have permissive internal firewall rules that don't reflect what the internet sees) tests basic reachability. No banner within a few seconds means a firewall or the mail service itself is the blocker.
4. Check whether the connection is accepted but rejected at the SMTP protocol level. If telnet connects and you see a banner, issue EHLO test.com manually and watch for an immediate 4xx/5xx response — this points to a policy-level rejection (rate limiting, blocklisting, greylisting) rather than a network problem.
5. If external delivery succeeds but the message doesn't reach the intended mailbox, the fault has moved past MX entirely and into internal routing — check gateway logs, transport rules, and connector configuration next.

Resolver Behavior and Why Results Differ by Location

A frequent source of confusion: an MX change looks "not applied" from one network but works fine from another. This is caching behavior, not a real inconsistency in your DNS. Every resolver — corporate, ISP, public — caches a DNS answer for the duration of its TTL, independently of every other resolver on the internet. A resolver that queried your domain an hour before you made a change will keep serving its cached (stale) answer until that specific cache entry expires, regardless of what any other resolver, or the authoritative server itself, is now returning. This is why testing from a single location and declaring a fix "confirmed" is unreliable — the authoritative answer may be correct while multiple cached copies around the internet still lag behind it.

Common Misconfigurations Ranked by Frequency

Based on the patterns that come up repeatedly in mail delivery troubleshooting, roughly in order of how often each turns out to be the actual cause:

1. Stale MX record left over from a platform migration — an old on-prem or previous-provider host still listed, sometimes at a lower priority than the current platform by mistake, silently intercepting mail intended for the new system.
2. Firewall blocking inbound port 25 — often introduced by an unrelated security hardening pass that didn't account for mail server exceptions.
3. MX hostname with no A/AAAA record — usually from a partial DNS migration where the MX record was updated but the corresponding host record wasn't created on the new provider.
4. Two hosts accidentally sharing the same priority — intended as primary/backup but configured identically, splitting traffic to a backup host that isn't provisioned to handle full load.
5. TTL left extremely high during an emergency change — the fix is correct in DNS but propagation across the internet takes far longer than expected because nobody lowered TTL ahead of time.
6. Recipient validation out of sync (in gateway/relay scenarios) — legitimate mail bounced because an intermediate relay's recipient list wasn't updated when a mailbox was added.

Reading Bounce Messages Correctly

A non-delivery report (NDR/bounce) usually contains the exact SMTP response code the sending server received, and that code narrows the layer immediately. A permanent failure in the 550 range with wording about the recipient not existing points to a mailbox-level problem, not MX. A 421 or other 4xx temporary failure with a connection-related message points toward network or availability issues at the MX-listed host. A bounce citing a security policy or reputation block points toward IP or domain reputation rather than anything MX-related at all. Reading the bounce text carefully before touching any configuration avoids fixing the wrong layer.

Enterprise Scale: Troubleshooting Across Many Domains

Organizations managing MX configuration for dozens or hundreds of domains — agencies, hosting providers, large enterprises with acquired subsidiaries — face a different problem: not diagnosing one broken domain, but catching drift across many before it becomes a support ticket. A periodic automated sweep (scripted dig queries against the full domain list, diffed against an expected-state record) catches stale records, unexpected priority ties, and dead-end hostnames well before someone reports missing mail, turning troubleshooting into prevention.

Related Tools

Start every diagnosis with MX Lookup for a fast, external view of the current record set. Check propagation status across resolvers with DNS Propagation Checker. Confirm the mail host's port reachability with Open Port Checker. For the mechanics behind why a specific host was or wasn't tried, see MX Priority Explained and MX Failover Guide.