← Email Authentication Checker
Email Authentication Checker vs. checking DNS records by hand with dig
Every developer and admin already has this move: run dig txt against a domain and read the record back. For a single top-level SPF or DMARC record, that is enough. This checker exists for the three things one dig call cannot show: the true recursive cost of an SPF include chain, which of many possible DKIM selector names your provider actually uses, and whether DMARC enforcement is strict enough for BIMI to display.
Where one dig call stops being enough
| What you're trying to answer | dig by hand | This checker |
|---|---|---|
| What does my top-level SPF or DMARC record say? | Works well. dig txt yourdomain.com and dig txt _dmarc.yourdomain.com show exactly this in one call each. | Reads the same records, in the same run as the checks below. |
| Is my SPF record actually under RFC 7208's 10-DNS-lookup limit? | Invisible to a single dig call -- each include:/redirect= mechanism can itself contain more of the same, and the limit counts the whole chain. Confirming it means recursively dig-ing every nested include and keeping a running total by hand. | Follows every include:/redirect= mechanism recursively and sums the total against the 10-lookup budget automatically. |
| Which DKIM selector does my provider actually use? | Not discoverable from DNS alone -- there is no fixed selector name, so you guess one, run dig txt <selector>._domainkey.yourdomain.com, and an NXDOMAIN only proves you guessed wrong, not that DKIM is missing. | Checks nine common selector names used by major providers in one run and flags a revoked (empty p=) key if it finds one. |
| Will BIMI actually display in Gmail or Yahoo? | Not answerable from the BIMI record alone -- it can look perfectly valid while staying invisible, because display also requires DMARC enforcement at p=quarantine/reject with pct=100. Answering this means reading two separate records and cross-checking them by hand. | Reads the BIMI record and the DMARC policy together and reports whether enforcement is actually strong enough for BIMI to be honored. |
| Re-checking all of the above after a DNS or provider change. | Several separate dig calls, recomputed and cross-referenced by hand, every time. | One command, or one page load -- and the identical logic is a zero-dependency CLI you can gate CI on. |
A single well-aimed dig txt call is still the fastest way to read a record you
already know the name of, and this checker's own lookups are not doing anything dig
couldn't -- they are the same kind of DNS queries, just walked recursively through every SPF
include, tried against nine DKIM selector names, and cross-checked between BIMI and DMARC,
instead of leaving that walking and cross-checking to be done, and remembered, by hand.
This tool needs no account: the browser page queries Cloudflare's public DNS-over-HTTPS resolver directly from your own browser, and the CLI does the same from your own machine. Neither ever sends the domain you check, or the records read, through this site.
Common questions
Can't I just run dig txt myself?
Yes, for the most obvious case: dig txt yourdomain.com will show your top-level SPF record, and dig txt _dmarc.yourdomain.com will show your DMARC policy. For that specific, most-obvious read, one command each is enough. The problem is the other three checks this tool does are not visible in any single dig response -- they only show up when you compare several DNS queries against each other, which is where running dig by hand stops being enough evidence.
How do I know which DKIM selector to check?
You don't, from DNS alone -- the selector is chosen by whichever provider sends your mail, and there is no single fixed name to dig for. By hand, that means guessing a selector, running dig txt selector._domainkey.yourdomain.com, getting NXDOMAIN, and trying another -- and NXDOMAIN on a guess you invented yourself proves nothing about whether DKIM is actually configured, only that you guessed a name nobody published a key at.
Why doesn't a clean top-level SPF record mean SPF actually passes?
Because RFC 7208 counts the whole recursive chain, not just your own record. A record with three include: mechanisms looks short in a single dig txt call, but each of those includes can itself contain further include:/redirect= mechanisms, and the 10-DNS-lookup budget is spent across the entire chain. Confirming you're under the limit means recursively dig-ing every nested include and keeping a running total by hand -- skip one level and you can be well over 10 while a single top-level read looks fine.
Can I tell from DNS alone whether BIMI will actually display?
Not from the BIMI record by itself. A dig txt default._bimi.yourdomain.com can return a perfectly valid-looking record while BIMI stays invisible in Gmail or Yahoo, because both require DMARC enforcement to be strict enough first -- p=quarantine or p=reject at pct=100. Answering "will this display" means reading the BIMI record and the DMARC record separately and cross-checking one against the other, not reading either alone.
Is this page making a live comparison against a tool or company?
No. This page describes a manual method every developer and admin already has -- running dig (or nslookup, or a browser-based DNS lookup tool) and reading the TXT records by eye. It names no competing product or company. The checker's own browser page and CLI query Cloudflare's public DNS-over-HTTPS resolver directly, never through this site.
Already comparing this checker to a broader network-diagnostic dashboard? See this checker vs. MXToolbox. For the mechanics of the recursive SPF count itself, see how to fix an SPF PermError from too many DNS lookups.