Six layers, one report
Email DNS problems rarely come alone. A domain missing DMARC usually has an SPF record assembled years ago by someone who left, an MX host nobody has looked at since migration, and no idea what DKIM selector its ESP signs with. Checking these one record at a time means five tools and a notepad. This audit runs all of them in a single pass against live DNS and puts the results side by side, ordered the way they should be fixed.
The layers, and what a failure in each one costs you:
- SPF: which servers may send as your domain. Missing or broken (past the 10-lookup limit, or duplicated) means receivers cannot validate your sending sources — critical.
- DKIM: cryptographic proof the message wasn't altered, and the alignment mechanism that survives forwarding. The audit probes common selectors; a custom selector needs a manual check.
- DMARC: the policy that ties SPF and DKIM to the From address your recipients see. Missing is critical — it is also a Gmail and Yahoo requirement for bulk senders. Stuck at p=none is the most common warning on real domains.
- MX: where your inbound mail goes. The audit also handles the two edge cases people miss: a null MX (RFC 7505, an intentional "this domain takes no mail") and the fallback trap below.
- PTR / FCrDNS: whether each MX host's IP has forward-confirmed reverse DNS — the hygiene test receivers apply to any mail server they talk to.
- BIMI: optional logo display. Reported as info, never as a failure — it is cosmetic, not authentication.
The apex-A fallback trap
One check here exists because of a rule most people have never read. RFC 5321 §5.1 says that when a domain has no MX records but does have an A record, senders must treat the A record as the mail destination. So a domain that runs a website but publishes no MX does not bounce mail cleanly — sending servers connect to your web server on port 25, wait, retry for days, and only then bounce. Senders see silent loss; you see nothing at all. The audit flags exactly this combination and recommends either real MX records or an explicit null MX.
Fix order matters
When the report shows several findings, resist alphabetical order. Criticals first, and among criticals: MX (mail is being lost now), then SPF and DKIM (authentication foundations), then DMARC (the policy on top of them). Publishing DMARC at p=reject before SPF and DKIM are right causes your own mail to be rejected — the one way to make things worse with a TXT record. The per-item recommendations in the report follow this ordering.
What this audit is, and what comes next
This is a configuration audit — the honest scope of what DNS can tell you from outside. It cannot see your sending reputation, your engagement rates, or the content filters at Gmail; a domain can pass every check here and still earn the spam folder through its sending behavior. What the audit gives you is the floor: with these six layers green, every message you send gets judged on its merits instead of being discounted for missing authentication. For how mailbox providers behave beyond DNS, see the platform data in our deliverability rankings and the testing methodology behind them.
Re-run the audit after every infrastructure change — a new ESP, a new corporate tool that sends mail, a DNS migration. Records drift, and drift is invisible until the day it isn't.
Want the same audit as one trackable number? The deliverability setup score runs these exact checks and weights them into a 0–100 configuration score.
Frequently asked questions
Which DNS records does the email DNS check audit?
Six layers in one pass: the SPF record (with the 10-lookup count), a DKIM probe across common selectors, the DMARC record and policy, MX records with resolution checks, the PTR / forward-confirmed reverse DNS of each MX host's IP, and the optional BIMI record. Each result carries a severity — critical, warning, OK, or info — and links to the dedicated checker for the full detail.
What does each severity mean?
Critical means mail is being lost or the domain is spoofable today: no SPF, no DMARC, no MX, or a broken record receivers ignore. Warning means the setup works but has a known gap — DMARC at p=none, a single MX host, an unconfirmed PTR. OK means the layer checks out. Info marks items that are inconclusive (DKIM probe found nothing) or optional (BIMI).
Why is the DKIM result sometimes 'inconclusive'?
DKIM keys live at {selector}._domainkey.{domain}, and the selector name is chosen by whoever sends your mail — there is no way to enumerate them from outside. The audit probes 16 selectors that major platforms use (google, selector1, k1, and so on). Finding one proves DKIM exists; finding none proves nothing. Get your real selector from a sent message's DKIM-Signature header and verify it in the DKIM checker.
The audit says my MX host has no PTR — does that hurt my sending?
Not directly. The PTR section audits your inbound mail hosts, because those are the only mail IPs discoverable from your domain's public DNS. Your outbound sending IP — the one receivers judge — may be entirely different, especially if you send through an email platform. Check it separately in the reverse DNS checker. An MX host without reverse DNS is still worth fixing; it usually signals a loosely-run server.
Is a clean audit the same as good deliverability?
No — and any tool that says otherwise is mislabeling. This audit verifies configuration: the DNS layer that decides whether receivers can authenticate your mail. Reputation, content, and list quality sit on top of it. Broken DNS guarantees problems; correct DNS makes the rest of the work count. That distinction is why we call this a DNS audit and not a deliverability score.