DMARC Checker

About the dmarc checker

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 9989, which obsoleted RFC 7489 in May 2026) is a DNS TXT record at _dmarc.yourdomain.com that tells receiving servers what to do with mail claiming to be from your domain that fails authentication, and where to send reports about it. It builds on top of SPF and DKIM rather than replacing them. A message passes DMARC if either SPF or DKIM passes and, critically, is aligned: the domain that authentication actually validated must match the visible From address, either exactly (strict alignment) or as a related subdomain (relaxed alignment, the default). Passing SPF alone for an unrelated domain does not satisfy DMARC.

This tool decodes every tag in the record: p sets the policy for the domain itself (none, quarantine or reject), sp optionally sets a different policy for subdomains, and rua and ruf give the addresses that receive aggregate and forensic reports. RFC 9989 removed the pct tag, which used to ask receivers to apply the policy to only a fraction of failing mail; a record still carrying one is honoured by some receivers and ignored by others, so the fix is to delete it rather than to set it to 100. Reading a record tells you what you have asked receivers to do, which is not the same as knowing what they did: only the aggregate reports show whether your mail authenticates in alignment, and this tool does not ingest them. p=none does not stop spoofed mail; it only asks receivers to report on what they see while taking no enforcement action, which is why it is meant as a monitoring phase rather than an end state. Moving to quarantine and eventually reject, once the aggregate reports confirm all legitimate mail is authenticating correctly, is what actually blocks impersonation.

Reading a DMARC record is only half the picture; the aggregate reports it requests are where the real information lives, showing which sending sources pass or fail authentication for the domain. Reviewing those reports before tightening the policy is what separates a safe rollout from one that risks blocking mail from a legitimate but forgotten sending source. A single reporting domain often turns up sending sources nobody remembered, such as a helpdesk platform or an old marketing tool, which is exactly the kind of surprise a rollout plan needs to catch before enforcement, not after.

Common questions

What does p=none mean?

Monitoring only: receivers send you reports on what they observed but take no action against mail that fails DMARC. It is meant as a first step, not a lasting configuration.

Do I need SPF and DKIM before DMARC?

Yes. DMARC only passes if SPF or DKIM passes and the authenticated domain aligns with the visible From address, so at least one of them has to already be correctly configured.

What are rua and ruf?

Addresses that receive aggregate (rua) and forensic (ruf) reports. Aggregate reports are the useful, widely-supported ones; forensic reports are rarely sent by major providers today.

How do I move from p=none to p=reject safely?

Review aggregate reports until every legitimate sending source authenticates cleanly, move to quarantine, and switch to reject after a couple of clean weeks. Do not ramp with pct: the 2026 revision of DMARC removed the tag, so some receivers sample on it and others ignore it entirely.