When email breaks, the pressure is high and the temptation is to change five things at once. Don't. Email delivery is a chain, and outages almost always live at one specific link. Walk the chain in order and you'll find the break in minutes instead of guessing for hours.
Step 1: Can mail be routed to you at all? (MX)
Start at the front door. A domain receives mail only if it publishes working MX records pointing at reachable mail servers. Run an MX / mail server test and confirm:
- MX records exist and point at real hostnames (not a dangling CNAME or an IP).
- Each MX target resolves and answers.
- If you deliberately receive no mail, a null MX is fine, but then inbound failure is expected.
If MX is missing or points somewhere stale (common right after a provider move), that's your outage. Stop here and fix it.
Step 2: Do the mail servers actually answer? (SMTP)
MX records can look perfect while the server behind them refuses connections. Use the SMTP / STARTTLS probe to open a real conversation: banner, EHLO, and STARTTLS support. A server that times out or won't negotiate TLS explains bounced or deferred mail. (Note: from cloud networks that block outbound port 25, an "unreachable" result can reflect the tester's network, verify from one that permits 25.)
Step 3: Is your mail authorized? (SPF, DKIM, DMARC)
If mail sends but lands in spam or is rejected for "authentication," the problem is your sending identity. Check SPF, DKIM and DMARC together:
- SPF lists who may send for you, and must stay under 10 DNS lookups or it "permerrors."
- DKIM signs each message; a rotated or missing selector breaks signatures.
- DMARC ties them together with alignment and tells receivers what to do on failure.
A recent DNS edit that dropped an include: or changed a selector is a classic cause.
Step 4: Is your reputation the problem? (Blacklists + URIBL)
If auth is clean but big providers still defer or junk your mail, check reputation from two angles:
- Blacklist / DNSBL checks your sending IPs.
- URIBL checks the domains in your message, links, shorteners, tracking domains. A clean IP can still be filtered because a domain in the body is listed.
Step 5: Read the evidence (Email headers)
When a specific message misbehaved, stop theorizing and read it. Paste the raw headers into the Email Header Analyser to see the delivery timeline, where the delay happened, and the exact SPF/DKIM/DMARC results the receiver recorded. The headers usually name the culprit outright.
The order matters
Routing (MX) → reachability (SMTP) → authorization (SPF/DKIM/DMARC) → reputation (DNSBL/URIBL) → evidence (headers). Working top-down means each step rules out a whole class of causes, so you never fix the wrong thing.
FAQ
Mail sends fine but always lands in spam. Where do I start?
Skip routing and go to Step 3 (authentication) and Step 4 (reputation). Spam-foldering is almost always an auth-alignment or reputation issue, not a routing one.
One recipient domain bounces, the rest are fine. Now what?
That points at the receiver or a specific reputation signal, not your setup. Read that message's headers (Step 5) for the exact rejection reason.
How long after a DNS fix before mail recovers?
As soon as caches expire, often minutes, up to a TTL window. Confirm the corrected records have propagated with a DNS propagation check.