Email authentication
DMARC checker
Read a DMARC record in plain words, and see exactly what a receiver does with mail that fails.
Free, no accountLive check
Result
The verdict and the record appear here once you press Check DMARC record.
What this is
This DMARC checker reads the DMARC record a domain publishes at "_dmarc.<domain>" and explains every tag in it - most importantly what a receiver actually does with mail that fails, which is the one thing the record itself does not spell out.
DMARC (Domain-based Message Authentication, Reporting and Conformance) does not check a message itself; it tells a receiver what to do with the result SPF and DKIM already produced, and where to send a report about it. One TXT record at "_dmarc.<domain>" covers the whole domain.
The policy tag, "p", is the part with teeth: "none" only watches, "quarantine" sends failing mail to spam, and "reject" refuses it outright. Everything else in the record - percentage, report addresses, alignment mode - adjusts how that policy is applied rather than replacing it.
How to read the result
The table below explains every tag actually published, not a generic list - "sp" and "ruf" only appear if the record sets them. The one line that matters most is spelled out directly in the summary: what a receiver does with a message that fails, in plain words rather than a tag name.
A fail here means the record itself is broken - unparsable, duplicated, or pointing reports somewhere not authorised to receive them. A warn means the record works but is not protecting much yet: monitoring only, a partial rollout, or nobody actually receiving the reports.
Common mistakes
What goes wrong most often, and how to tell.
- Publishing "p=reject" on day oneWithout first reading the aggregate reports, there is no way to know which of your own legitimate senders would be rejected along with the forged mail. Start at "p=none" to watch, then move up once the reports show nothing real is failing.
- Setting a policy with nowhere for the reports to goWithout a "rua" address, the receivers enforcing this policy never tell you what they are catching - you are enforcing blind, with no way to notice a legitimate sender being blocked.
- Pointing "rua" at an address on a different domain without authorising itRFC 7489 §7.1 requires the receiving domain to explicitly agree to receive reports about a domain that is not its own, via a record at "<your-domain>._report._dmarc.<their-domain>". Without it, a receiver is required to skip that address, silently.
- Leaving "pct" below 100 indefinitelyA partial percentage is for the ramp-up period, not a permanent setting - it means a share of failing mail is let through one level lighter than the policy says, by design, for as long as it stays below 100.
Questions
What people ask about this tool.
- It means DMARC is only watching: RFC 7489 §6.3 defines "none" as taking no action, so mail that fails SPF or DKIM is delivered exactly as if it had passed. It is the right first step, used to see what the aggregate reports show before enforcing anything.
- Without one, nobody receives the aggregate reports receivers send about mail claiming to be from your domain, so there is no way to see what is passing, what is failing, or who is sending it - including a forger you would otherwise never hear about.
- Only if that domain explicitly authorises it. RFC 7489 §7.1 requires a record at "<your-domain>._report._dmarc.<their-domain>" containing "v=DMARC1" before a receiver will send reports there; without it, that address is silently skipped.
- RFC 7489 §6.6.3 requires a receiver to ignore both and treat the domain as if it had no DMARC record at all, which is worse than either record on its own - merge them into one.
Use it from the API
The same check, as one request.
This example uses a name RFC 2606 reserves for documentation, ending in .example, .test, .invalid or .localhost. None of them is a real domain, and nobody can register one.