Email Authentication Validator

Check the SPF, DKIM and DMARC records a domain actually publishes

Enter a domain and this tool queries its live DNS and reports what is really published: the SPF record with every mechanism parsed and its DNS lookups counted, a DKIM public key at whichever selector it can find, and the DMARC record with its policy, subdomain policy and reporting addresses broken out. Each of the three gets a score and a letter grade, and the three combine into an overall grade weighted SPF 35%, DKIM 30%, DMARC 35%.

This is a read of the published state. It is the tool for "what does this domain have configured right now, and what is wrong with it" — auditing your own domain before a migration, checking a domain you have inherited, or vetting a supplier. If you are instead trying to author a new DMARC record from scratch, build it with the DMARC generator and come back here to verify what you published.

How the lookups run

Queries go out server-side over DNS-over-HTTPS against Cloudflare's resolver, which means you get an authoritative public view rather than whatever your local resolver has cached — useful, because "it works on my machine" in email authentication is usually a stale cache. Three checks run in parallel: TXT at the domain for SPF, TXT at _dmarc.<domain> for DMARC, and TXT at <selector>._domainkey.<domain> for DKIM.

Results are presented as a summary plus a tab per mechanism, with the raw record text copyable from each. Nothing about the domain is stored.

SPF: the mechanisms and the 10-lookup limit

SPF answers one narrow question: is this sending IP allowed to use this domain in the envelope sender? The tool splits the record after v=spf1 and shows every term with its qualifier resolved, so you can read the policy without parsing it in your head:

The single most consequential thing SPF gets checked for is the 10-DNS-lookup limit in RFC 7208. Evaluating an SPF record must not require more than ten DNS-querying mechanisms. Exceed it and a conforming receiver returns permerror — and a permerror is not a pass. Under DMARC, SPF then contributes nothing, and if DKIM is not also passing and aligned, your mail fails DMARC entirely.

What counts and what does not:

The counter here does the recursion for you: it follows each include:, fetches that domain's SPF record, parses it, and adds its lookup-causing mechanisms to the total, descending several levels. That is what makes the number meaningful, because a record with four includes routinely resolves to eleven or twelve real lookups — and the record looks fine to the eye. Over ten is reported as exceeding the limit and caps the SPF grade; over eight is reported as approaching it, because a vendor adding one include: to their own record can push you over without touching your DNS.

When you are over the limit, the options in order of preference are: remove senders you no longer use (audit before you engineer), replace a vendor's include: with the specific ip4: ranges it resolves to, use a subdomain for bulk sending so it carries its own SPF budget, or use a maintained flattening service. Flattening by hand is a trap — the vendor's IPs change and your record silently stops authorising real mail.

Other SPF findings the tool reports: +all, which authorises the entire internet to send as your domain and scores zero on its own; a missing terminator; ~all, noted because unauthenticated mail is only flagged rather than refused; ?all, which asserts nothing; and any use of ptr.

DKIM: finding the selector

DKIM is the awkward one to check, because there is no way to enumerate a domain's selectors from DNS. The public key lives at selector._domainkey.example.com, and unless you know the selector, you cannot ask. This is why DKIM checkers so often report "no record" for domains that sign perfectly well.

The tool works around it. If the selector you supply (or the default) returns nothing, it tries to discover which providers the domain uses and derive selectors from that. It reads the domain's MX records, its SPF record and its other TXT records, and matches them against a library of 48 email services — mailbox providers, ESPs, CRM and helpdesk platforms — each with the selector names it is known to use. Detect Google Workspace from the MX records and it tries google; detect Microsoft 365 and it tries selector1 and selector2; detect SendGrid, Mailgun, Postmark, Klaviyo, Zendesk and so on, and it tries theirs. A set of generic selectors is always included, and if nothing is detected it falls back to trying every service's selectors.

You can also supply your own selectors explicitly, which is what you want for a self-hosted signer or an internal naming convention.

Once a key is found, the record's tags are parsed:

• v=DKIM1 — version. Missing or wrong is a real error.
• p= — the base64 public key. An empty p= is a revoked key, not a broken record; it is the defined way to retire a selector.
• k= — key type, RSA unless stated otherwise.
• t=y — testing mode. Receivers are told to treat failures leniently, which means your DKIM is not actually being enforced. Flagged, because it gets left on after a migration and nobody notices.

Key strength is reported too, with 1024-bit flagged as deprecated and anything below it as too weak. Be aware this is estimated from the length of the encoded key rather than read out of the key structure, so treat it as a strong indicator rather than a precise measurement — it is there to catch a legacy 1024-bit key that should have been rotated, and it does that reliably.

What this cannot tell you is whether signing actually works. A published key proves a key exists; it does not prove your mail server is signing with the matching private key, signing the right headers, or that the signature survives your relay chain. For that you need a real message, and that is a different job from checking DNS.

DMARC and how policy reaches subdomains

The DMARC record at _dmarc.<domain> is parsed into its tags:

Subdomain inheritance is the part people get wrong. The rules:

• A receiver evaluating mail from news.example.com looks for _dmarc.news.example.com first. If that exists, it governs, and the organisational domain's record is irrelevant.
• If it does not exist, the receiver falls back to the organisational domain's record — _dmarc.example.com.
• In that fallback, sp= governs the subdomain if present. If sp= is absent, the subdomain inherits p=.

Two consequences follow. First, p=reject with no sp= means every subdomain is at reject, including ones you forgot about, including ones a team is about to start sending marketing mail from. Second, publishing sp=none alongside p=reject leaves a wide-open hole: attackers spoof accounts.example.com just as happily as the bare domain, and the recipient cannot tell the difference. The tool flags a missing sp= for this reason.

It also flags p=none as monitoring-only with no enforcement, and caps the DMARC grade accordingly. A domain sitting at p=none for a long time gets all the reporting and none of the protection — it is a starting position, not a destination. A missing rua= is flagged too, because without aggregate reports you have no way to know what you would break by tightening the policy.

One important behaviour to know: this checks the exact name you enter. To see what actually applies to a subdomain, check the subdomain and the organisational domain and apply the inheritance rules above — the tool does not walk up the tree for you.

Alignment: why SPF passes and DMARC still fails

This is the single most confusing thing in email authentication, and it explains most "but SPF passes!" tickets.

SPF and DKIM authenticate different identifiers, and neither of them authenticates the address your recipient sees:

• SPF authenticates the envelope sender — the MAIL FROM / Return-Path domain, used for bounces. It is invisible in a mail client.
• DKIM authenticates the domain in the signature's d= tag — whoever's key signed the message.
• The From: header is what the recipient actually reads, and on its own nothing verifies it.

DMARC's contribution is to tie those together. It passes only if at least one of SPF or DKIM passes and the identifier it authenticated aligns with the From: header domain. In relaxed mode alignment means the same organisational domain, so mail.example.com aligns with example.com. In strict mode it means an exact match.

Now the classic failure. You send through an email service provider. The ESP sets the Return-Path to its own bounce domain — bounces.esp-vendor.net — because it needs to process your bounces. SPF is evaluated against that domain, against that domain's SPF record, and it passes cleanly. Your headers say spf=pass. But the authenticated domain is the ESP's, and your From: says example.com. They do not align. SPF contributes nothing to DMARC, and if DKIM is not signing with an aligned d=, the message fails DMARC despite a green SPF result.

The fix is one of two things, and usually both:

• Set up a custom return path with the ESP — a CNAME to a subdomain of yours — so the envelope sender is a subdomain of example.com and SPF aligns.
• Set up DKIM with the ESP using a selector under your own domain, so d=example.com and DKIM aligns. This is the more robust of the two, because DKIM survives forwarding and SPF does not — a forwarded message is relayed from an IP your SPF never authorised, while the DKIM signature travels with the message.

That last point is worth restating: DKIM alignment is what keeps mailing lists and forwarding working under a strict DMARC policy. If you are moving toward p=reject, aligned DKIM on every sending path is the prerequisite.

Reading the grades

Each mechanism starts from a baseline and loses points for each finding, with the weightings noted at the top. The letter is a shorthand for triage, not a compliance verdict — a domain can grade well and still fail in production because a signing key is not deployed, or grade poorly on a domain that never sends mail at all.

For a domain that sends no email, the strongest configuration is not a good grade but a deliberate null configuration: v=spf1 -all, a DMARC record at p=reject, and a wildcard DKIM record publishing an empty key. That combination tells the world nothing legitimate ever comes from this domain, and it is the right answer for parked domains, look-alikes you defensively registered, and anything that only serves a website.

Limits worth knowing

• This examines published DNS records. It does not evaluate a message, verify a signature, or compute alignment for real traffic — alignment mode is read from the DMARC tags, not measured.
• DNS caching means a change you just made may not appear immediately; TTLs on the old record still apply.
• DKIM selectors that no service library covers and that you do not supply will not be found. "No DKIM record" here means "not at the selectors tried", never "this domain does not sign".
• The 10-lookup count reflects the includes as they resolve at this moment. Vendors change their records; a record that passes today can permerror next month without you editing anything, which is a good argument for re-checking on a schedule.