How email authentication actually works

When you send an email, the message claims to come from a domain ([email protected]). But that claim is just text — anyone can type any address they like into the "From" field. Email authentication exists so the receiving mail server can independently verify, using public DNS records, that the sender is actually authorized by that domain. Three systems do this job, and they answer three different questions:

SPF and DKIM are the evidence; DMARC is the policy that says what to do when the evidence is missing or contradictory. A domain with all three, configured with an enforcing DMARC policy, is very hard to spoof. A domain with none of them can be impersonated by essentially anyone.

Reading an SPF record

An SPF record is a space-separated list. It starts with v=spf1 and then contains mechanisms (things to match against) and modifiers (options). Each mechanism can carry a qualifier that says what to do when it matches:

The most important mechanism is all, which matches everything. It almost always appears last and sets the default outcome for any sender not matched earlier: -all (hard fail, strongest), ~all (soft fail, common), ?all (neutral, weak) or +all (pass — this authorizes everyone and defeats SPF entirely).

The 10-lookup limit. RFC 7208 says an SPF check must not require more than 10 DNS queries (including the SPF record itself). Mechanisms like include:, a, mx, ptr and redirect: each trigger lookups — and an include: can itself contain more includes. When a record exceeds the limit, most receivers stop evaluating it and treat the result as a permerror, which often means your legitimate mail starts failing. This tool counts the lookups for you.

Reading a DMARC record

A DMARC record lives at _dmarc.yourdomain.com and is a set of key=value tags separated by semicolons. The ones that matter:

The recommended path is: publish p=none with a rua address first, read the aggregate reports for a couple of weeks to make sure your legitimate senders are authenticating, then move to p=quarantine, and finally p=reject. That gradual enforcement is what stops spoofing without breaking your own mail.

Common email-authentication problems (and what they mean)

• No SPF record — the receiver has no list of authorized senders, so anyone can send mail claiming to be your domain. This is the single biggest spoofing enabler.
• Multiple SPF records — invalid. A domain may publish exactly one SPF record; with two or more, receivers pick one (often arbitrarily), so your policy is unpredictable. Consolidate to one.
• SPF over the 10-lookup limit — too many include: chains. Receivers give up (permerror) and your real mail can be rejected or downgraded.
• SPF ends in +all — authorizes every IP on the internet. SPF is present but provides zero protection.
• No DMARC record — even with good SPF/DKIM, the receiver has no policy for what to do on failure, and you get no reports. A top cause of legitimate mail landing in spam.
• DMARC p=none — monitoring only. Nothing is enforced, so spoofed mail is still delivered. Fine as a starting point, not as an end state.
• No DKIM key — outgoing mail is unsigned, so receivers can't verify it wasn't altered in transit, and DMARC alignment has one less signal to work with.
• Weak DKIM key (1024-bit) — 1024-bit RSA is considered breakable in the long term; 2048-bit is the current minimum, 3072+ is better.
• SPF/DKIM pass but don't align with the "From" domain — e.g. you send from mail.yourcompany.com but the "From" address is @yourcompany.com and DMARC uses strict alignment. DMARC then fails even though SPF and DKIM individually passed. Relaxed alignment (aspf=r / adkim=r) fixes most of these.

A sensible starting configuration

For a domain that sends mail through a single provider (Google Workspace, Microsoft 365, a hosting provider, etc.):

1. SPF — one record listing your provider, ending in -all. Example for Google Workspace: v=spf1 include:_spf.google.com -all. For Microsoft 365: v=spf1 include:spf.protection.outlook.com -all.
2. DKIM — enable signing in your provider's admin console and publish the key it gives you (this is what this tool's DKIM probe is looking for).
3. DMARC — start with v=DMARC1; p=none; rua=mailto:[email protected], then after a clean couple of weeks of reports move to p=quarantine and finally p=reject.

Do one change at a time and re-run this checker after each — watch the score climb and the findings clear. Re-check 24–48h after any change so you're reading the propagated records, not a stale cache.