DMARC & SPF checker
Look up and parse the SPF and DMARC records a domain publishes — the all qualifier, includes, DMARC policy, reporting, and pct — with an honest verdict. Runs in your browser over encrypted DNS-over-HTTPS. It reads published policy only; it can't test real mail delivery.
Reads the SPF (TXT on the domain) and DMARC (TXT on _dmarc.) records a domain publishes, then parses the policy. This inspects published DNS only — it doesn't send test mail. Nothing is stored.
This checks only the SPF and DMARC records a domain publishes in DNS. It doesn't send or receive mail, so it can't confirm that DKIM is signing your outgoing messages, that SPF/DKIM alignment passes at delivery time, or that a specific mail stream authenticates. Queries run in your browser over Cloudflare DNS-over-HTTPS; we don't store the domains you check.
What SPF and DMARC do
SPF and DMARC
SPF is a DNS TXT record that lists which servers may send mail for a domain. DMARC is a TXT record at _dmarc.yourdomain that tells receivers what to do when a message fails authentication, and where to send reports. Together they let mail providers reject spoofed mail claiming to be you.
SPF (Sender Policy Framework) answers "which servers are allowed to send mail for
this domain?" You publish a single TXT record listing your mail providers, ending in an
all mechanism that says how to treat everyone else.
DMARC (Domain-based Message Authentication, Reporting & Conformance) sits on top. It tells receiving servers what to do when a message fails authentication — do nothing, quarantine it, or reject it — and asks them to send back reports so you can see who is sending mail as your domain.
DKIM (DomainKeys Identified Mail) is the third layer: it adds a cryptographic signature to each message so receivers can verify it wasn't tampered with and really came from an authorized sender. DMARC passes when SPF or DKIM authenticates and aligns with the visible From address — which is why DKIM matters even though this tool can't enumerate it (the DNS selector is chosen per sender and isn't discoverable from the domain alone).
How the checker works
When you enter a domain, your browser makes two DNS-over-HTTPS queries directly to a public resolver:
one for the TXT records on the domain (to find the record beginning
v=spf1), and one for the TXT records on _dmarc. +
your domain (to find the record beginning v=DMARC1). It then parses each and shows the
raw value, a present/absent status, and a plain-language breakdown.
How to read the results
The most important part of an SPF record is the all mechanism at the end — the qualifier
in front of it decides how unlisted servers are treated:
- -all
- Hard fail. Any server not listed in the record is explicitly unauthorized — receivers should reject its mail. The strictest, most protective setting.
- ~all
- Soft fail. Unlisted servers are treated as suspicious but not outright rejected — usually delivered to spam. A common, safe middle ground.
- ?all
- Neutral. The record expresses no opinion about unlisted servers, so SPF provides almost no protection. Little better than having no policy.
- +all
- Pass all. Every server is treated as authorized — this accepts spoofed mail and should essentially never be used. The checker flags it.
For DMARC, the p= tag is the policy — what receivers should do with mail that fails:
- p=none
- Monitor only. Receivers take no special action on mail that fails DMARC, but they send you aggregate reports. The right starting point while you verify your senders.
- p=quarantine
- Failing mail is accepted but diverted to the spam or junk folder. A strong enforcement step once your legitimate mail reliably passes.
- p=reject
- Receivers reject failing mail outright, so it never reaches the inbox or spam. The strongest policy, and the goal for most domains that send mail.
The tool also surfaces DMARC's rua (aggregate report address), ruf (forensic
report address), and pct (the percentage of mail the policy applies to, defaulting to
100%). The strongest published posture is an SPF record ending in -all or
~all paired with DMARC at p=quarantine or p=reject.
Honest limitations
A published policy is necessary but not sufficient. Because this tool inspects DNS only, there are real things it deliberately does not claim to know:
Treat a strong verdict as "the foundation is in place." Treat a warning as a concrete gap to close. Neither replaces monitoring your DMARC reports over time.
DMARC & SPF — frequently asked questions
What is the difference between SPF and DMARC?
SPF lists which servers are allowed to send mail for a domain, published as a TXT record starting with v=spf1. DMARC, published as a TXT record at _dmarc.yourdomain, tells receiving servers what to do when a message fails authentication (none, quarantine, or reject) and where to send reports. SPF authorizes senders; DMARC sets the policy and reporting on top of SPF and DKIM.
Does this tool test whether my email actually authenticates?
No — and it's important to be clear about that. This checker only reads the SPF and DMARC records you publish in DNS and parses them. It never sends or receives mail, so it cannot confirm that DKIM is signing your outgoing messages, that SPF or DKIM alignment passes at delivery time, or that a specific mail provider is set up correctly. To verify real delivery-time results, send a message to a DMARC/mailbox test address or read the aggregate (rua) reports your domain receives.
Where does DKIM fit in, and why isn't it checked here?
DKIM adds a cryptographic signature to each outgoing message, using a private key held by your mail sender; the matching public key is published in DNS under a selector you choose (for example selector._domainkey.yourdomain). Because the selector name is chosen per sender and isn't discoverable from the domain alone, a domain-only lookup can't reliably find it. DMARC passes when SPF or DKIM authenticates and aligns, so DKIM matters a great deal — this tool simply can't enumerate it without knowing your selectors.
What does the 10 DNS-lookup limit on SPF mean?
SPF evaluation is capped at 10 DNS lookups, counting mechanisms like include, a, mx, ptr, exists, and redirect — including those inside records you include. Exceed it and SPF returns a permerror, which can cause legitimate mail to fail. This tool counts the lookup-causing mechanisms in the record itself; it does not recurse into your includes, so the real total can be higher than shown.
Why should I have both SPF and DMARC?
SPF on its own tells receivers which servers are allowed to send, but without DMARC there is no instruction on what to do when a check fails, and no reporting. DMARC without SPF (or DKIM) has nothing to authenticate against. Together — SPF ending in -all or ~all, plus DMARC at quarantine or reject — they let receivers confidently reject mail that spoofs your domain, and give you visibility through reports.
Do you store the domains I check?
No. The lookups run entirely in your browser and go directly to a public DNS-over-HTTPS resolver. We don't proxy them through our servers and we don't log the domains you check.