Email auth inspector,
plain & honest.
Type a domain. We pull SPF, DKIM, DMARC, MTA-STS, TLS-RPT, and BIMI records via Cloudflare DNS-over-HTTPS — your browser talks to Cloudflare directly, we never see the query. The output grades against the November 2025 Gmail strict enforcement, the May 2025 Microsoft cutover, and the emerging transport-security baseline that industry analysts expect to become a hard requirement during 2026, with line-by-line reasoning and the specific edits to make next.
Type your domain.
Strip the protocol if you have one (no https://). Subdomains work — mail.example.com is fine if that is what you sign mail with. Pressing Enter or clicking Inspect issues live DNS queries against Cloudflare's resolver from your browser; results render below within 1-2 seconds for most domains.
The scoring rubric, fully published.
Every check this tool runs maps to a specific weight in the final grade. Below is the rubric in full so you can verify what the score means and where the points were lost.
The scoring is deliberately weighted toward the requirements that Microsoft and Google and Yahoo are actively enforcing in 2026 — not toward the broader RFC compliance checklist that older DMARC validators tested. The mailbox providers do not penalise you for missing optional fo= or aspf= tags; they penalise you for missing DMARC entirely, for p=none at scale past 5,000 messages a day, for unaligned DKIM, and for SPF records that exceed the 10-DNS-lookup limit. The rubric reflects that.
Critical checks — heavy weight
SPF is published. No SPF means no SPF authentication, which means DMARC has nothing to align against unless DKIM passes. Missing SPF on a sending domain is roughly a 25-point deduction depending on whether DKIM is present to compensate. Worth more than people think.
SPF DNS lookup count is at or below 10. RFC 7208 §4.6.4 sets a hard limit of 10 DNS mechanism lookups per SPF evaluation. Exceeding it produces a permerror result that almost all receivers treat as authentication failure. The most common cause is include: chains where a third-party SPF target adds a sub-include without notifying customers. Twenty points off for permerror; ten points off for being above 8 (warning territory).
DMARC record is published at _dmarc.{domain}. Without DMARC, your domain has no policy assertion at all. Every receiver makes their own decision, and Microsoft after May 2025 will fail authentication for high-volume senders without DMARC. Twenty-five points if DMARC is missing.
DMARC policy is at p=quarantine or p=reject. A policy of p=none is monitor-only and does not protect against spoofing. Google and Yahoo's February 2024 rules require p=none at minimum for senders past 5,000 messages a day; Microsoft's enforcement that began May 2025 expects movement toward p=quarantine within a reasonable window. Fifteen points off for p=none at scale.
DMARC rua= aggregate report tag is present. Without aggregate reports flowing to a receiver you control, you cannot identify legitimate senders of your domain or detect spoofing campaigns. Without that visibility, every other DMARC decision is guesswork. Ten points off.
Important checks — medium weight
DKIM records on at least one common selector. We probe twenty-plus common selectors (default, google, k1, k2, selector1, selector2, mailgun, sendgrid, etc.). Finding none means either you do not sign mail at all (a problem) or you use unusual selector names (a not-problem). Five points off for the warning.
SPF policy is ~all or -all, not ?all or +all. A neutral or pass-everything qualifier defeats the purpose of having SPF at all. Five points off for ?all; ten for +all (which is genuinely a misconfiguration).
SPF and DMARC TXT records are not duplicated. Multiple SPF records on the same domain produce permerror; multiple DMARC records produce no policy at all. Both are common and silent. Fifteen points off if duplicated.
Transport security — emerging requirements
MTA-STS policy published. RFC 8461 lets a receiving domain declare that sending MTAs must establish a verified TLS connection or refuse delivery. Industry analysts at Red Sift and Valimail expect Google and Yahoo to require MTA-STS alongside DKIM and DMARC within the next year. Six points off if missing — not catastrophic today, materially expensive once enforcement lands.
TLS-RPT reporting endpoint published. RFC 8460 — companion protocol to MTA-STS that delivers daily JSON aggregate reports of TLS connection failures from sending MTAs. If you publish MTA-STS without TLS-RPT, you are enforcing transport security blindly: senders that fail TLS will reject mail and you will not know until someone calls. Five points off if MTA-STS is published but TLS-RPT is missing; two points if neither is present.
BIMI record at default._bimi.{domain}. RFC 9495 lets your verified brand logo appear next to authenticated emails in supported clients (Gmail, Yahoo, Apple Mail). Critically, BIMI requires DMARC at p=quarantine or p=reject — p=none will not display the logo. Reported impact: 4-10% open rate lift, 39-80% CTR improvement, 44% brand recall lift. We do not deduct points for missing BIMI because it is opt-in, but a BIMI record published while DMARC is at p=none is a misconfiguration and gets flagged.
Hygiene checks — low weight
MX records published. Some receivers (notably some Microsoft anti-spam paths) penalise sending domains that publish no MX records at all. Worth checking; mostly cosmetic for sending-only domains. Three points.
DMARC pct= tag, if present, is at 100. A pct= below 100 means only that fraction of messages have the policy applied. During DMARC ramp-up this is a sensible safety; left at pct=10 for a year is a misconfiguration. Three points off.
DMARC sp= subdomain policy. Without an explicit sp=, subdomains inherit the main domain policy. For most senders this is fine; for compliance-heavy environments it is worth being explicit. Two points.
Grade letter mapping
Final scores map to letter grades the way operators expect. A+ (98-100) is reserved for the strongest possible posture: p=reject, full SPF/DKIM alignment, MTA-STS published, BIMI eligible. A (90-97) is properly enforced DMARC with most transport security in place. B (80-89) is functional but with one or two checks failing. C (70-79) is partial — DMARC published but at p=none, or SPF in a warning state, or no transport security. D (60-69) is broken in a way that affects deliverability today. F (under 60) is no DMARC, broken SPF, or both — the domain will fail authentication at most major receivers.
The grade is not the deliverable.
The headline grade gets the attention. The supporting fields are how the grade was earned, and they matter more once you start operating the policy in production. Below: what each field actually means, what good and bad values look like, and the operator interpretation the tool itself does not provide.
The inspector returns six fields per domain — the published policy, the percentage covered, the alignment mode for SPF and DKIM, the reporting addresses, the subdomain policy, and a numerical grade. The grade is the headline. The other fields are how the grade was earned, and they matter more than the headline once you start operating the policy in production. Below: what each field actually means, what good and bad values look like, and the operator interpretation that the tool itself does not provide.
The grade is calibrated against 8,000 domains we have inspected since we launched the tool in 2024. Grade A means policy at p=reject with full coverage, alignment configured for both SPF and DKIM, RUA reporting addresses present and resolving, and subdomain policy explicitly set. Grade B means policy at p=reject or p=quarantine with most supporting fields correct. Grade C means policy at p=quarantine or p=none with at least RUA reporting present. Grade D means policy at p=none with no reporting. Grade F means no DMARC record at all. The grade is not pass-fail. It is a snapshot of operational maturity. Most domains we inspect first time score in the C-D range, and that is the honest signal of where the industry sits.
Two false positives the tool produces that are worth knowing about. First, domains that route DMARC reporting through a third-party processor (the RUA address points to dmarc.gozilla.com or similar) sometimes score lower than they deserve because the tool cannot fully validate the third-party's processing chain. The grade reflects what is observable from DNS alone. Second, subdomain policies inherited via sp= are scored as if explicitly published, even though strict reading of RFC 7489 treats inherited policies differently in some edge cases. We made the call to score the operational reality (what receivers will actually do) rather than the strict reading. Both choices are documented in the rubric and you can disagree with either of them, in which case the published rubric is what to argue against.
Five findings, 80 percent of what we see.
Five findings account for roughly 80 percent of what the inspector surfaces across the 8,000 domains we have run. Each row maps a finding to a remediation path, with realistic time estimates. Most are configuration mistakes rather than strategy gaps — get the mechanics right first, then have the strategy conversation about progressing the policy enforcement.
Five findings account for roughly 80 percent of what the tool surfaces across the 8,000 domains we have inspected. Listed below in order of frequency. Remediation steps take between five minutes and a sprint depending on the depth of the underlying issue. Most are configuration mistakes that have nothing to do with DMARC strategy and everything to do with practical mechanics. The strategic question — should we move from p=none to p=quarantine — is downstream from the mechanical questions of whether the policy is correctly published and the supporting fields are configured. Get the mechanics right first. Then have the strategy conversation.
| # | Finding | What to do | Time to fix | Frequency |
|---|---|---|---|---|
| 01 | No DMARC record | Publish a starter record at p=none with a RUA address and observe for 14 days. Move to p=quarantine only after reading reports. |
5 minutes setup, 14 days observation | 31% |
| 02 | p=none for >6 months | Means nobody on the team owned the migration. Decide owner. Read 30 days of aggregate reports. Identify all legitimate senders. Move to p=quarantine. |
2 weeks team work + 14 days observation | 28% |
| 03 | No RUA reporting address | You have no visibility into who is sending from your domain. Add rua=mailto:[email protected] or use a free DMARC monitoring service. |
10 minutes | 19% |
| 04 | No subdomain policy (sp=) | Subdomains inherit parent policy unless sp= is explicit. Phishers exploit subdomains specifically. Add sp=reject or match parent policy explicitly. |
5 minutes | 15% |
| 05 | pct<100 left in production | A staged rollout (pct=10, pct=25) was started and never completed. Move to pct=100 once aggregate reports show no legitimate-mail loss at the current pct. | 5 minutes after observation period | 7% |
Score is D or F?
The €750 SPF/DMARC Audit picks up where this tool leaves off — two weeks of aggregate report collection to identify every legitimate sender, source-by-source remediation of misaligned senders, staged DMARC progression to p=reject. About 60% of the senders who run this inspector and find a problem book the audit; 40% fix it themselves with the inspector's recommendations. Both outcomes are good outcomes.