Five mechanisms, one answer
When a mailbox provider receives a message claiming to be from your domain, it runs a series of DNS checks before deciding anything else. This tool runs the same series and shows the results side by side, because the mechanisms only make sense together:
- SPF — is the sending server on the domain's published list? The board shows whether a record exists, whether it parses, and how many DNS lookups it burns against the limit of 10.
- DKIM — does the domain publish signing keys? We probe 16 selectors the major platforms use (google, selector1/2, k1, s1…) and list every key found.
- DMARC — what happens to mail that fails? The board shows the policy: reject, quarantine, or the monitoring-only p=none.
- MX — can the domain receive mail? Some receivers distrust send-only domains, and a broken MX setup often signals broader DNS neglect.
- BIMI — is a logo record published at
default._bimi? Optional, and reported as such.
A domain in good shape produces a board like: SPF ✅, DKIM ✅ (keys on google), DMARC ✅ (p=reject), MX ✅ (5 hosts), BIMI — (not published). A domain in trouble reads differently: SPF ⚠️ (11 of 10 lookups), DKIM —, DMARC ❌ (no record), MX ✅, BIMI —. The second domain will struggle with Gmail and Yahoo regardless of what it sends, because since 2024 both require SPF or DKIM plus a DMARC record from bulk senders, and alignment between them for the mail itself to pass.
How to work through a mixed board
Fix in dependency order, not left to right. SPF and DKIM come first — DMARC evaluates on top of them, so a DMARC policy over broken SPF and absent DKIM enforces against your own mail. Each row links to the dedicated checker, which carries the detail this summary omits: the SPF checker resolves the full include tree, the DKIM checker accepts an exact selector, and the DMARC checker breaks the policy down tag by tag. Records missing entirely? The SPF generator and DMARC generator build correct ones.
Two rows deserve a careful reading. The DKIM row is a probe, so a dash means “nothing found on the selectors we know”, never “no DKIM” — custom selectors are invisible to any list. And the BIMI row is informational: publishing a logo record without DMARC at enforcement does nothing, so chase it last, if at all.
Configuration is the floor, not the ceiling
Everything on this board is configuration — verifiable from DNS, fixable in an afternoon. It is also the easy part. Authentication decides whether receivers can trust the domain's identity; it does not decide whether they want the mail. Sender reputation, list hygiene, complaint rates, and the sending platform's infrastructure decide placement, and none of that is visible in DNS. A domain can score five green rows here and still send newsletters into spam folders.
That gap is the reason this site exists. We measure the part DNS cannot show: real campaigns sent through each major platform to a controlled seed list, with inbox rates published per provider — Gmail, Outlook, and Yahoo separately — in our deliverability rankings. The protocol, formula and test dates are public in the methodology. Verify your DNS here first; it is the entry ticket. Then, if you are choosing where to send from, compare the measured inbox rates across the services we review.
Frequently asked questions
Does this tool verify email addresses?
No — different job. Address verifiers test whether a specific mailbox like jane@example.com exists. This tool audits a domain's authentication configuration: the SPF, DKIM, DMARC, MX and BIMI records that decide whether receivers trust mail claiming to come from that domain.
What is a passing setup in 2026?
SPF present with a valid record inside the 10-lookup limit, DKIM keys published for your senders, and a DMARC record at quarantine or reject with a report address. That combination satisfies the Gmail and Yahoo bulk-sender requirements. BIMI stays optional — it's a logo, not a requirement.
Why does DKIM show a dash instead of pass or fail?
The DKIM column comes from probing 16 common selectors, and a probe can only prove presence. A dash means none of the probed selectors answered — the domain may still sign with a custom selector we can't guess. Get the real selector from a message header (the s= tag) and confirm on the DKIM checker page.
Is missing BIMI a problem?
No. BIMI displays your logo next to authenticated mail in supporting inboxes; it improves recognition, changes nothing about delivery, and requires DMARC at enforcement plus (for most inbox providers) a paid Verified Mark Certificate. This checker reports it as informational, never as a failure.
Why doesn't this check PTR (reverse DNS)?
PTR records belong to the sending IP address, not the domain — and a domain-only check has no way of knowing which IPs your mail leaves from. If you send through an ESP, the PTR is theirs to manage. A reverse DNS checker for your own IPs is planned in our next tools wave.