SPF / DMARC Analyzer

Fetch and analyse a domain's SPF, DMARC and DKIM records, flagging the lookup limits and weak policies that quietly break mail authentication.

Live lookup DNS & Domain Queries a public API
Queries <selector>._domainkey.<domain>
Try:

Result

Ready to analyse
Press "Run analysis" to fetch the SPF, DMARC records for example.com and check them for the failures that break mail authentication quietly.

What gets checked

  • SPF: presence, terminal mechanism, the RFC 7208 ten-lookup limit and duplicate records
  • DMARC: policy strength, reporting address and percentage rollout
  • DKIM: whether the selector you supply is actually published

About SPF / DMARC Analyzer

SPF, DKIM and DMARC together decide whether your mail is trusted. Each is a DNS record, and each fails in quiet ways: an SPF record one include too deep, a DMARC policy left at p=none for three years, a DKIM selector that was never published. This tool fetches all three and points at the specific problems.

The ten-lookup limit

RFC 7208 caps SPF evaluation at ten DNS-querying mechanisms - include, a, mx, ptr, exists and redirect. Nested includes count towards the same budget, so adding one SaaS sender can push you over the edge. Past ten, receivers return permerror and SPF fails completely, which usually means DMARC fails with it.

Reading the terminal mechanism

-all is a hard fail: nothing else may send. ~all is a soft fail, the normal rollout step. ?all is neutral and provides no protection at all, and +all authorises the entire internet. Alignment matters too: DMARC only passes if the SPF-validated domain or the DKIM signing domain matches the visible From header.

Common use cases

  • Investigating why legitimate mail is landing in spam.
  • Auditing a domain before moving DMARC from p=none to p=quarantine or p=reject.
  • Checking a newly added SaaS sender has not blown the SPF lookup budget.
  • Confirming a DKIM selector was actually published after a provider migration.

Edge cases and gotchas

  • Only one SPF record may exist per domain - two TXT records starting v=spf1 breaks SPF entirely.
  • SPF does not survive forwarding; DKIM usually does. Do not go to p=reject without checking your forwarding paths and aggregate reports.
  • Subdomains inherit DMARC via sp= - a strict policy on the parent can break mail from a subdomain you forgot about.

Frequently asked questions

What order should I roll DMARC out in?
Publish p=none with a rua address, collect aggregate reports for a few weeks until you recognise every legitimate sender, move to p=quarantine (optionally with pct=), then to p=reject. Never start at reject on a domain with real mail flow.
Do I need SPF if I have DKIM?
DMARC passes if either aligns, so DKIM alone can be enough - and it survives forwarding, which SPF does not. Publish both anyway; some receivers still weigh SPF independently.
How do I fix "too many DNS lookups"?
Remove unused includes, replace an include with the explicit ip4/ip6 blocks it resolves to (they cost no lookups), or use an SPF flattening service - accepting that flattened records go stale when the provider changes their infrastructure.