"Email is broken" rarely has one cause. Deliverability depends on four independent layers, and a failure in any of them looks identical from the recipient's side: the message does not arrive. Checking them in the wrong order wastes hours, so this guide works from the bottom up.
Layer 1 — Can the domain receive mail at all
Before touching authentication, confirm the basics resolve. A missing or wrong MX record means inbound mail fails regardless of how perfect your SPF is, and a typo here is far more common than a DNSBL listing.
- MX records — one or more hosts, with sane priorities. Confirm with the MX Lookup.
- NS delegation — the zone is actually served by the nameservers you think it is.
- PTR for outbound — the sending IP should resolve back to a hostname that matches your HELO name. Missing PTR is a common reason for rejection at large providers.
Layer 2 — Do messages authenticate
This is the layer most guides start with, and it is where SPF, DKIM and DMARC are decided. Check each one separately before checking the combination:
- SPF — does the record authorise every sender, and is it inside the 10-lookup budget? Use the SPF Checker.
- DKIM — is a signature present and does it verify against the published key? Use the DKIM Checker.
- DMARC — is a policy published, and do the passing mechanisms align with the visible From domain? Use the DMARC checker.
A message can pass SPF and DKIM and still fail DMARC, because DMARC evaluates alignment rather than raw pass. Paste a real message into the Header Analyzer to see what actually happened rather than what you intended.
Layer 3 — Is the sending IP trusted
Authentication proves the message is yours. It does not prove your IP has a good reputation. Check the sending IP against public blocklists with the Blacklist Checker. A listing is not always fatal — many receivers weight it alongside authentication and complaint history — but an unexplained listing on a shared host is worth fixing before it spreads.
Layer 4 — Does the message survive content filters
Once the technical layers are clean, remaining failures are usually about what the message contains or how it is sent: a new domain with no sending history, a sudden volume spike, a link shortener, an image-only email, or a list that has not been cleaned in a year. Test placement across providers rather than a single inbox, and note that one provider filtering you is a reputation signal, not necessarily a broken record.
Run it as a routine, not an emergency
- Record the current state: MX, SPF, DKIM selector, DMARC policy, sending IPs. A baseline is what makes the next change visible.
- Re-check after any DNS edit, provider migration or new sending tool. Most outages are introduced by a change, not by decay.
- Repeat weekly for active sending domains, and immediately after any complaint or bounce spike.
- Keep one known-good message header on file so you can compare a failing message against it.
The Email Health check runs the DNS and authentication layers in one pass, and the Deliverability Test covers placement across providers.
FAQ
Which layer should I fix first?
Always the lowest one that fails. Fixing DKIM when MX is wrong changes nothing. Fixing authentication when the IP is listed produces correctly signed mail that is still rejected.
How often should this be checked?
Weekly for a domain that sends regularly, and after every change to DNS, hosting or sending tools. A green result today says nothing about next month.
Everything passes but mail still lands in spam
Authentication is not a reputation guarantee. Look at volume patterns, list quality, complaint rate and content. A brand-new domain sending a large first batch fails on history alone, no matter how correct the records are.
