DMARC + SPF + DKIM Checker
Email authentication checker. Audits SPF (sender policy), DMARC (enforcement + reporting), and DKIM (signing) records via Cloudflare DoH. Parses policies into plain English (-all = strict, p=reject = strict, etc.). Tries 9 common DKIM selectors.
DMARC + SPF + DKIM Checker
How the check works
Enter a domain
The tool queries DNS for all 3 email authentication records simultaneously. Just the bare domain — no protocol prefix.
SPF (at the apex)
Looks for a TXT record at domain.com starting with v=spf1. The tool parses the policy (-all / ~all / ?all / +all) and explains what it means.
DMARC (at _dmarc)
Looks for a TXT record at _dmarc.domain.com starting with v=DMARC1. The tool parses the policy (p=none / quarantine / reject) and other tags.
DKIM (common selectors)
Tries 9 common selectors (default, selector1, google, k1, s1024, mandrill, mailchimp, mail, dkim). Custom selectors aren't detected — you'd need to know yours.
SPF + DMARC + DKIM — the email authentication trinity
Email was designed in the 1970s with zero authentication. By the 2000s, this had become a crisis: spammers and phishers could spoof any sender address trivially. Three standards emerged to fix this: SPF (RFC 4408, 2006; now RFC 7208, 2014) says which IP addresses are allowed to send mail for a domain; DKIM (RFC 4871, 2007; now RFC 6376, 2011) cryptographically signs outgoing mail; DMARC (2012, RFC 7489) ties them together with a published policy and reporting framework.
Why all three matter
SPF alone fails when mail is forwarded (the original sender IP is lost). DKIM alone doesn't tell receiving servers what to do with unsigned mail. DMARC alone has no signal to evaluate. The three combined: a receiving server checks SPF + DKIM, and DMARC tells it what to do if both fail — accept (p=none), quarantine, or reject. Modern best practice is SPF + DKIM + DMARC with p=quarantine or p=reject.
"In 2024 Google + Yahoo started requiring DMARC for bulk senders. Domains without proper email auth get their mail silently dropped — invisible to the sender, fatal for the recipient."
The policy ladder
Recommended progression: (1) Publish SPF first (easiest, immediate spam-folder relief). (2) Add DKIM via your email provider (often automatic with Gmail Workspace, Microsoft 365, SendGrid, Mailgun). (3) Publish DMARC at p=none with a reporting address — watch reports for 2-4 weeks. (4) Tighten to p=quarantine once you've verified all your legit senders pass. (5) Tighten to p=reject after another monitoring period. This ladder takes 1-3 months but is the only safe way to deploy strict DMARC.
Privacy stance
The tool queries Cloudflare's public DoH endpoint (1.1.1.1) for TXT records. Your queried domain reaches Cloudflare — no other party. No data is stored by RECATOOLS.
p=none enforces nothing, and SPF breaks silently at ten lookups
SPF was first specified in RFC 4408 (April 2006) and is now RFC 7208 (2014); DKIM was RFC 4871 (May 2007) and is now RFC 6376 (2011); DMARC was RFC 7489 (March 2015) — which was obsoleted by RFC 9989 in May 2026. RFC 9989 removed the pct, rf and ri tags, so a record still carrying a fractional pct now gets its policy applied in full.
Google + Yahoo began enforcing DMARC for bulk senders (5,000+ messages/day) in February 2024.
A domain with no DMARC record publishes no policy for receivers to apply — which is why checking whether the record exists at all is the first step, not the last.
p=none means "monitor only" — no actual enforcement. Many domains stay here permanently, defeating DMARC's purpose.
An SPF record ending in +all is a security disaster — it explicitly permits any IP to send mail as your domain.
SPF has a hard limit of 10 DNS lookups per evaluation (RFC 7208). Many domains exceed it and break silently.
DKIM signatures protect against tampering in transit — but only against modifications. They don't verify the sender is who they say.
The DMARC RUA tag sets where to send aggregate reports — invaluable for spotting impersonators trying to use your domain.
BIMI (Brand Indicators for Message Identification) displays your logo in inboxes — but requires DMARC at p=quarantine or p=reject as a prerequisite.
The brands impersonated most often in phishing are the ones with the biggest login footprints — which is exactly why those domains publish p=reject.
Frequently asked questions
SPF = which IPs are allowed to send mail for your domain. DKIM = cryptographic signature on each message. DMARC = ties the two together with a policy (none/quarantine/reject) and reporting. All three together = strong protection.
Modern best practice: ~all (soft fail) initially, then -all (strict reject) after you've verified all legitimate senders. ~all gives you a safety net if you forget a sender; -all is the goal.
Monitor only — receiving servers will accept the mail but send you reports about failures. Useful for the first 2-4 weeks of DMARC deployment. Don't stay at p=none long-term; that defeats DMARC's purpose.
No. Use the ladder: p=none for monitoring → p=quarantine after verification → p=reject after final verification. Each step typically takes 2-4 weeks. Skipping ahead breaks mail flow.
DKIM uses domain-specific selectors. The tool tries 9 common ones (default, selector1, google, k1...). If you use a custom selector, the tool won't find it — check your email provider's admin panel for your actual DKIM selector(s).
Yes. Without DMARC, receiving servers have no instructions on what to do when SPF or DKIM fails. DMARC is the policy layer — without it, the other two have no teeth.
Bulk senders (>5,000 messages/day to Gmail or Yahoo) MUST have proper SPF, DKIM, and DMARC (at least p=none). Mail without these is silently dropped or marked spam. This effectively makes DMARC mandatory for any business.
It stops <em>direct</em> spoofing of your exact domain (e.g. legit-domain.com → fake email from legit-domain.com). It does NOT stop lookalikes (legit-domian.com with a typo) or display-name spoofing.
Brand Indicators for Message Identification — adds your verified logo to email previews in Gmail, Apple Mail, etc. Requires DMARC at p=quarantine or p=reject + a Verified Mark Certificate ($1000+/year typically).
No. Queries go from your browser directly to Cloudflare's public DoH endpoint. The tool itself has no backend — nothing is logged.
Method & sources
How it computes
Reads the domain's published TXT records: SPF from the domain apex, DMARC from _dmarc.<domain>, and a DKIM selector record when one is given. Each is parsed against its own syntax and reported as present, malformed or absent — the tool inspects what is published, it does not send or receive mail.
What this tool implements
- SPF: RFC 7208 (2014), which replaced the experimental RFC 4408 (2006). §4.6.4 caps a single evaluation at 10 DNS-querying terms; exceeding it is a permerror, which is why long include chains fail silently.
- DKIM: RFC 6376 (2011), which obsoleted RFC 4871 (2007).
- DMARC: RFC 7489 (2015), obsoleted by RFC 9989 (May 2026). RFC 9989 Appendix C.5.2 removes the pct, rf and ri tags.
- Google has required SPF or DKIM from all senders, and DMARC from senders of 5,000+ messages a day to Gmail, since 1 February 2024.
Sources
- Kitterman S. RFC 7208, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 (2014). https://www.rfc-editor.org/rfc/rfc7208.txt
- Levine J (ed). RFC 9989, Domain-based Message Authentication, Reporting, and Conformance (DMARC) (2026). https://www.rfc-editor.org/rfc/rfc9989.txt
- Crocker D, Hansen T, Kucherawy M (eds). RFC 6376, DomainKeys Identified Mail (DKIM) Signatures (2011). https://www.rfc-editor.org/rfc/rfc6376.txt
- Google. Email sender guidelines — requirements for sending 5,000 or more messages per day. https://support.google.com/a/answer/81126
What can make this go out of date
- Public DNS resolution of the domain's TXT records at the time of the check
Pick up where you left off
Stored only in this browser — never sent to our servers.