Inputs
Example
Check one SPF record, _dmarc policy tags, and selector._domainkey ownership before publishing changes.
SPF/DMARC/DKIM Checker
Parse SPF, DMARC, and DKIM TXT records, highlight policy issues, and run DNS lookup only when needed.
Use it to read mail-auth records before changing DNS or comparing them with a delivered message header.
Three records, one authentication story
SPF, DKIM, and DMARC are usually configured at different moments, by different tools, under different amounts of time pressure — and mail authentication only works when the three of them tell one coherent story. SPF names the servers allowed to send for the envelope domain, DKIM proves that a signing domain vouched for the message, and DMARC decides what receivers should do when neither of those aligns with the visible From address. Most real-world delivery incidents live in the seams: a second SPF record pasted in by a well-meaning platform guide, a DKIM selector that quietly rotated, a DMARC policy that promises reject while alignment silently fails.
This checker reads all three record families for a domain and highlights value-level problems: syntax faults, weak or contradictory policy tags, malformed keys, duplicate records, and owner names that do not match the convention. It works from pasted TXT values when you have zone data in front of you, or from live DNS when what matters is what the world currently resolves.
From record inspection to safer publishing
Paste known records first when you are editing a zone: the parser works locally, so a draft SPF or DMARC value can be corrected before publication. For a live review, enter the domain and — if DKIM is part of the question — the selector your sending platform actually uses; the lookup builds the selector._domainkey names from it. Setting the expected DMARC policy makes the report opinionated in the right way: it shows the distance between what you intend and what is published.
Read warnings in order of blast radius. Duplicate SPF records are permerror territory and come first. Then DMARC: policy tag, alignment expectations, reporting addresses. DKIM key shape follows — algorithm, key length, empty or revoked keys. Publish changes one record family at a time and re-run the check after DNS has settled, so a regression stays attributable to the change that caused it.
Lookup paths and what stays local
Pasted records are parsed entirely in the browser. Live lookups start only on the button press and send just the DNS names required — the domain, the _dmarc owner, and selector-derived names — using DNS-over-HTTPS first with the same-origin DNS helper as fallback. The tool inspects published records; it does not send test messages, cannot observe your real sending path, and therefore cannot prove that a delivered mail will pass DMARC alignment.
Frequently asked questions
Can this prove my mail will pass DMARC?
No. It inspects the published records, which is a precondition, not the verdict. A real DMARC pass also depends on the sending path, the envelope domain, the header From domain, the DKIM signature actually applied, and how all of those align.
Why is a second SPF record such a serious warning?
Because the standard requires exactly one SPF record per name, and many receivers respond to duplicates with a permanent evaluation error — which can fail authentication outright. It typically happens when a SaaS platform's setup guide is followed without checking what already exists.
Which DKIM selector should I enter?
The one your sending platform configured — s1, default, or a dated selector are common. The lookup queries selector._domainkey.domain, so a wrong selector proves nothing except that this particular name has no key.
What does alignment actually mean?
That the domain a receiver validated — via SPF's envelope domain or DKIM's signing domain — matches the domain the human sees in From. DMARC only counts authentication that aligns; a valid DKIM signature from an unrelated domain does not help.
Should I go straight to p=reject?
Not by default. Start with p=none and aggregate reports, remediate legitimate senders, then choose enforcement for the domain's purpose and indirect-mail exposure. RFC 9989 warns that p=reject can be unsuitable for general-purpose user-mail domains; tightly controlled sending domains or subdomains are different.
Are my pasted records uploaded anywhere?
No. Pasted values stay in the browser session. Only a live DNS lookup sends anything — namely the queried DNS names — to the resolver path.