DMARC Checker

About the DMARC Checker

This DMARC checker resolves the _dmarc TXT record for a domain and breaks the policy down tag by tag: p (the policy itself), rua and ruf (where reports go), pct (what share of mail the policy applies to), and any other published tag such as sp, adkim, aspf or fo. It flags the three weak spots that show up in almost every incomplete deployment: a p=none policy that only monitors without ever blocking anything, a missing rua address that means aggregate reports go nowhere, and a pct value under 100 that leaves part of your mail outside the policy entirely.

Use it to verify a DMARC rollout after publishing the record, to see exactly how strict a domain's current policy is before you trust its From address, or to plan the move from monitoring (p=none) to real enforcement (p=quarantine or p=reject) using the aggregate reports as evidence first. DMARC does not authenticate anything on its own, it sits on top of SPF and DKIM, checks that they align with the visible From address, and tells receivers what to do when that alignment fails plus where to send reports about it.

The lookup runs server-side against public resolvers and reads only the _dmarc TXT record the domain already publishes, which is public by design. Nothing is stored beyond returning that result. Run the SPF and DKIM checkers first if either is missing, since a DMARC policy with nothing underneath it to align has little to check against, and consider the composite mail-deliverability checker for a single pass across all three.

How to use it

1. Enter the domain whose DMARC policy you want to check.
2. Submit to resolve and parse the _dmarc TXT record.
3. Read the policy tag (p) first to see whether mail is only monitored or actually enforced.
4. Check that a rua address is present so aggregate reports actually reach an inbox you read.
5. Confirm pct is 100 so the policy applies to all matching mail, not a partial rollout.
6. Review any other published tags (sp, adkim, aspf, ruf) shown in the parsed table.
7. Work toward p=quarantine or p=reject once reports confirm no legitimate mail is failing alignment.

Examples

• v=DMARC1; p=none; rua=mailto:dmarc@example.com -> valid and reporting works, but flagged as monitor-only since nothing is actually blocked yet.
• v=DMARC1; p=reject; rua=mailto:reports@example.com; pct=100 -> full enforcement with reporting enabled, the target end state.
• v=DMARC1; p=quarantine; pct=50 -> flagged because only half of failing mail is quarantined, the rest passes through unaffected.
• v=DMARC1; p=reject; sp=none -> the domain itself is fully enforced but its subdomains are not covered by that policy.
• No _dmarc.example.com record at all -> flagged, meaning receivers have no instructions if SPF or DKIM fail on mail claiming to be from this domain.
• v=DMARC1; p=reject; adkim=s; aspf=r -> strict DKIM alignment paired with relaxed SPF alignment, shown as separate tags in the parsed output.

Every tag this checker parses

• p: the policy applied to the domain itself. None, quarantine or reject.
• sp: the policy applied to subdomains, if different from p.
• rua: mailto address(es) for daily aggregate XML reports, the main way to see who is sending as your domain.
• ruf: mailto address(es) for forensic (per-message) failure reports, less commonly supported by receivers.
• pct: the percentage of mail the policy applies to, used to ramp up enforcement gradually.
• adkim / aspf: alignment mode for DKIM and SPF, s (strict, exact domain match) or r (relaxed, organizational-domain match).
• fo: forensic report options controlling when a ruf report is generated.

The p=none to p=reject path, and why to not skip steps

Publishing p=reject on day one, before you know every legitimate source sending as your domain, will silently drop your own newsletter platform, CRM, or support-desk mail the moment one of them fails SPF or DKIM alignment. The standard rollout is p=none with rua set, reading the aggregate reports for a few weeks to build a complete list of legitimate senders and fix any that fail alignment, then moving to p=quarantine at a low pct, raising pct toward 100, and finally switching to p=reject once quarantine has run clean.

• Step 1: p=none, rua set, no enforcement, just visibility
• Step 2: p=quarantine, pct=10 to 25, catch remaining misconfigurations at low blast radius
• Step 3: raise pct toward 100 as reports stay clean
• Step 4: p=reject, pct=100, full enforcement

DMARC alignment versus SPF and DKIM passing on their own

SPF and DKIM can each pass individually while DMARC still fails, and this trips people up constantly. SPF passing only means the sending IP is authorized for the envelope-from domain, which after a forward or a mailing list often differs from the visible From address a recipient sees. DKIM passing only means the signature is valid for whatever d= domain it was signed with, not necessarily the From domain. DMARC requires that at least one of SPF or DKIM not only pass but align, meaning its domain matches the visible From header (exactly under strict alignment, or same organizational domain under relaxed). A message can fail DMARC with both SPF and DKIM technically passing, just against the wrong domain.

Frequently asked questions