SPF, DKIM & DMARC Record Checker
Check whether a domain's email authentication is actually configured correctly — not just present.
Also known as: SPF checker, DMARC checker, DKIM checker, Email DNS record checker
How it works
- 1Enter a domain name to check.
- 2Optionally add a DKIM selector (try the common ones shown if you don't know it).
- 3Review the SPF, DMARC, and DKIM results and their plain-English warnings.
- 4Fix any flagged issues (too many SPF lookups, a monitor-only DMARC policy) at your DNS provider.
Why use SPF, DKIM & DMARC Record Checker
Counts real SPF DNS lookups, not just record presence
Parses every mechanism and flags the record the moment it crosses RFC 7208's 10-lookup limit — the #1 cause of silent SPF failures.
Decodes every DMARC tag
Shows policy, subdomain policy, enforcement percentage, and report addresses — not just whether a record exists.
Flags monitor-only DMARC policies
Calls out when p=none means spoofed mail is only being logged, not blocked.
Checks DKIM for a selector you provide
Decodes key type and confirms a real public key is present, with common selector suggestions to try.
Verified against real, live domains
Parsing logic checked against real SPF, DMARC, and DKIM records from major providers, not just synthetic examples.
No account or API key needed
DNS-over-HTTPS lookups run directly from your browser against a public resolver — no backend of ours involved.
Who uses SPF, DKIM & DMARC Record Checker
Auditing your own domain's email authentication
Check whether SPF, DKIM, and DMARC are actually configured correctly before relying on them to stop spoofed mail.
Debugging why legitimate email is landing in spam
Check for an SPF record exceeding the DNS lookup limit or a missing/misaligned DKIM signature.
Verifying a new email service provider's setup instructions worked
Confirm the SPF include and DKIM selector a new provider asked you to add actually resolved correctly.
Checking a domain before trusting mail claiming to be from it
See whether a domain enforces DMARC strictly (p=reject) or only monitors (p=none) before deciding how much to trust its authentication.
Planning a move from monitor-only to enforced DMARC
Check the current policy and percentage enforced as a starting point before tightening it.
Reviewing a vendor or partner's email security posture
Quickly check whether a domain you're evaluating has baseline email authentication in place.
About SPF, DKIM & DMARC Record Checker
SPF, DKIM, and DMARC are the three DNS-based mechanisms that let a receiving mail server verify a message claiming to be from your domain actually is — and having a record present is only the first step. An SPF record that triggers more than 10 DNS lookups fails outright under RFC 7208 regardless of what it says, and a DMARC policy left at p=none only monitors spoofed mail without blocking any of it — both are common misconfigurations that look fine at a glance but don't do what most people assume.
This tool parses the actual mechanisms in an SPF record — include, a, mx, ptr, exists, redirect — and counts exactly how many trigger a DNS lookup, flagging the record the moment it crosses the 10-lookup ceiling that causes real mail servers to reject SPF evaluation entirely (a permerror). It also checks for the more basic mistakes: no "all" mechanism, or more than one SPF record on the same domain (itself invalid per the spec).
For DMARC, it decodes every tag in the record — p= (policy), sp= (subdomain policy), pct= (percentage enforced), rua=/ruf= (report addresses), adkim=/aspf= (alignment mode) — and calls out when the policy is set to "none" (monitoring only) or when only a fraction of failing mail is actually subject to enforcement. DKIM is checked for a selector you provide (there's no way to discover a DKIM selector purely from the domain — it has to be known or guessed from common defaults like "google," "selector1," or "default"), decoding the key type and confirming a real public key is present.
All three lookups run as plain DNS TXT queries via Cloudflare's public DNS-over-HTTPS resolver, sent directly from your browser — not through our server. That means the domain you check is visible to Cloudflare (the same as any DNS query would be to whichever resolver handles it), but never to us; there's no server-side processing for this tool at all.
SPF, DKIM & DMARC Record Checker vs. other options
How Open Tools Library compares to desktop software and other online tools.
| Feature | Open Tools Library | Desktop software | Other online tools |
|---|---|---|---|
| Price | Free, unlimited | N/A | Often free |
| SPF lookup-count validation | Counts every lookup-triggering mechanism against the RFC limit | N/A | Inconsistent — some just show the raw record |
| DMARC tag decoding | All standard tags explained in plain English | N/A | Varies |
| DKIM selector guidance | Common selectors suggested as quick picks | N/A | Often requires knowing the selector already |
| Explains warnings | Plain-English reason for every issue found | N/A | Often just pass/fail with no explanation |
| Data path | Browser to Cloudflare's public resolver directly — never our server | N/A | Usually routed through the tool's own server |
Pro tips
- An SPF record with more than 10 lookup-triggering mechanisms (include, a, mx, ptr, exists, redirect) fails entirely under RFC 7208 — a permerror, not a partial pass.
- DMARC's p=none means spoofed mail is only reported, never blocked — treat it as "monitoring phase," not "protected."
- DKIM selectors aren't discoverable from the domain alone — check your email provider's setup documentation, or try common defaults like google, selector1, selector2, or default.
- A domain having SPF and DMARC but no DKIM (or vice versa) is common and not necessarily wrong — but DMARC enforcement is strongest when both SPF and DKIM are aligned.
Technical specs
- SPF validation
- Full mechanism parsing, DNS lookup counting, RFC 7208 10-lookup limit check
- DMARC validation
- All standard tags (p, sp, pct, rua, ruf, adkim, aspf) decoded
- DKIM validation
- Selector-based lookup, key type, public key presence, CNAME delegation detection
- DNS resolver
- Cloudflare public DNS-over-HTTPS (1.1.1.1), queried directly from your browser
- Record types checked
- TXT records only — SPF/DMARC/DKIM are all published as TXT
- Processing location
- Client-side DNS queries to Cloudflare — no processing on our own server
Privacy & security
Checking a domain's public DNS records is already public information — this tool doesn't need to add any of its own.
DNS lookups run directly from your browser to Cloudflare's public DNS-over-HTTPS resolver — never through our server.
No account, no email, no login — just a domain in, a record breakdown out.
The domain you check is visible to Cloudflare (as it would be to any DNS resolver), never to us.
Equally private whether you're checking one domain or auditing several.
Frequently asked questions
What's the difference between SPF, DKIM, and DMARC?
SPF lists which servers are allowed to send mail for a domain. DKIM cryptographically signs outgoing mail so it can't be altered in transit. DMARC ties both together and tells receiving servers what to do when a message fails either check.
Why do I need to provide a DKIM selector?
Unlike SPF and DMARC (which live at predictable DNS locations), a DKIM record's location depends on a selector name chosen by whoever set it up — there's no way to discover it purely from the domain.
Is my domain lookup sent to a third party?
Yes, by necessity — DNS lookups go directly from your browser to Cloudflare's public DNS-over-HTTPS resolver (1.1.1.1), the same as any DNS query would go to some resolver. They never pass through our own server.
What does "multiple SPF records found" mean, and why is it a problem?
RFC 7208 requires exactly one SPF record per domain — having more than one is itself invalid and causes SPF evaluation to fail, regardless of what either record says.
Why is a DMARC policy of "none" flagged as a warning?
p=none only tells receiving servers to report on failing mail, not to quarantine or reject it — it's a common (and reasonable) starting point, but it doesn't actually stop spoofed mail from being delivered.
Can I check DKIM without knowing the selector?
Not directly — try the common selector suggestions first (google, selector1, selector2, default), or check your email provider's documentation, since selectors are provider- and setup-specific.
Troubleshooting
SPF shows "too many DNS lookups" — what does that mean?
RFC 7208 caps SPF at 10 lookup-triggering mechanisms (include, a, mx, ptr, exists, redirect). Beyond that, mail servers treat the record as a permanent error and SPF evaluation fails outright — reduce the number of includes or flatten some of them.
DKIM says "not found" but I know we have DKIM set up
DKIM selectors aren't guessable from the domain alone — check your email provider's setup documentation for the exact selector name, or try the common ones suggested (google, selector1, selector2, default, k1, s1).
DKIM says it's delegated via CNAME — what does that mean?
Some providers (especially for enterprise email) point a DKIM selector to a CNAME record instead of a direct TXT record, meaning the actual key lives at a different domain the CNAME target manages.
DMARC found but no warnings shown even though policy is "none"
A p=none policy always generates a warning explaining it's monitor-only — if you're not seeing it, double check you're looking at the correct domain's result, since a subdomain may inherit a different effective policy (sp=) than the root domain.
Related searches
Landed here looking for something worded a little differently? SPF, DKIM & DMARC Record Checker covers all of these too:
Ready to use SPF, DKIM & DMARC Record Checker?
Free, private, and ready right now — no signup required.
Scroll to SPF, DKIM & DMARC Record Checker