DMARC
_dmarc.<domain> · TXT
Not checked yetThe DMARC policy that applies to the domain, tag by tag, with the report addresses and whether outside receivers have agreed to them.
DMARC · RFC 9989
DMARC checker: the policy that applies, tag by tag
Type a domain to read the DMARC record that applies to it. Every tag is explained, the report addresses are checked, and when the domain has no record of its own the DNS tree is walked to find the one that covers it.
The DMARC checker
What a DMARC record is
DMARC lets the owner of a domain say what it would like receivers to do with mail that uses the domain in its From address and cannot be validated, and ask for reports about such mail. The record is a TXT record at _dmarc.<domain> that begins with v=DMARC1 (RFC 9989 §4.5). A message passes DMARC when SPF or DKIM passes for a domain that is aligned with the From domain: the same domain, or under relaxed alignment one that shares its Organizational Domain (RFC 9989 §4.4).
DMARC was first published as RFC 7489 in March 2015, an Informational document. In May 2026 it was republished on the standards track as RFC 9989, which obsoletes it. This page reads records against the new text and points out where the old one differs.
DMARC record examples
v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com
Monitoring: nothing is asked of receivers, reports are collected. The record of RFC 9989 Appendix B.2.1.
v=DMARC1; p=quarantine; rua=mailto:dmarc-feedback@example.com,mailto:tld-test@thirdparty.example.net; t=y
A policy under test, with reports to two addresses. The record of RFC 9989 Appendix B.2.5.
v=DMARC1; p=reject; aspf=r; rua=mailto:dmarc-feedback@example.com
Enforcement: failures are a clear sign that the use of the name is not valid. From RFC 9989 Appendix B.3.1.
How to read the tags
| Tag | Meaning | Default |
|---|---|---|
| v | Version. Required, first, and exactly DMARC1; otherwise the whole record is ignored. | — |
| p | The policy for mail that fails: none, quarantine or reject. | none, if a usable rua is present |
| sp | The policy for existing subdomains that publish no record of their own. | the value of p |
| np | The policy for subdomains that do not exist in the DNS. | sp, then p |
| rua | Where aggregate reports go. Without it receivers must not send any. | none |
| ruf | Where reports about single failed messages go. | none |
| adkim | DKIM alignment: r relaxed, s strict. | r |
| aspf | SPF alignment: r relaxed, s strict. | r |
| fo | When to send failure reports: 0, 1, d, s. Ignored without ruf. | 0 |
| t | Test mode: y asks receivers to apply one level less than the policy says. | n |
| psd | Whether the domain is a public suffix (y), is its own Organizational Domain (n), or either (u). | u |
| pct | Historic. In RFC 7489, the share of failing mail the policy applied to. | 100 |
Tags and defaults from RFC 9989 §4.7; the status of pct, rf and ri from the registry in RFC 9989 §9.3.
What happened to pct
RFC 7489 let a domain apply its policy to a percentage of failing mail. RFC 9989 removed the tag: experience showed it "was usually not accurately applied" unless the value was 0 or 100, and pct=0 had taken on a meaning of its own as a signal to intermediaries. The new t=y replaces pct=0, and t=n, the default, replaces pct=100 (RFC 9989 Appendix A.6). A record that still carries pct is not broken. The checker reports the tag and says what each generation of receiver does with it.
Which record applies to a subdomain
A receiver first asks for a record at the exact domain in the From address. If there is none it walks up the DNS tree, one label at a time and at most eight queries in all, looking for the Organizational Domain, and applies that domain's record with its sp or np tag (RFC 9989 §4.10). This DNS Tree Walk replaces the public suffix list that RFC 7489 relied on. Receivers that have not moved to RFC 9989 still use a public suffix list, which this page does not carry; the checker shows every name it asked so that the walk can be followed.
The common mistakes
- Two DMARC records. When more than one is returned they are all discarded (RFC 9989 §4.10).
- v=DMARC1 not first, or in lower case. The record is ignored.
- The record at the wrong name. It belongs at
_dmarc.example.com, not atexample.com. - Reports sent to another domain that never agreed. When the report address is outside the domain, the receiving domain has to publish a record at
<your domain>._report._dmarc.<their domain>; without it the address is ignored (RFC 9990 §4). The checker looks for that record. - p=none forever. It asks for nothing to be done. It is the setting for reading reports before moving on.
- No rua. The domain then learns nothing about who sends in its name.
- A misspelled policy. With no valid p and no usable rua, receivers apply no DMARC processing at all (RFC 9989 §4.10.1).
What this checker does not tell you
It reads the policy; it does not know whether the domain's own mail passes. Moving to quarantine or reject while a legitimate sender still fails SPF and DKIM alignment will affect that sender's mail. The aggregate reports are where a domain finds that out. What a receiver finally does with a message is the receiver's decision; the record states the domain owner's preference.