DMARC checker
Reads your DMARC record, resolves the policy that actually applies, and reports what conforming receivers will do with it.
What this checks
- Policy discovery. If no record exists at the name you enter, we perform the DNS tree walk defined in RFC 9989 §4.6 to find the policy that actually applies, and tell you which domain it came from.
- Record validity. The
v=DMARC1tag must be first and is compared exactly, case-sensitively. If it is not, the whole record must be ignored, so a record with a subtle version typo provides no protection at all. - Duplicate records. When more than one DMARC record is returned for a name, all of them are discarded. The domain has no policy in force. Not the stricter one, and not the first one.
- Policy strength across
p,spandnp. - Reporting. Whether
ruais present, and where the destination is on another domain, whether that domain published the authorisation record RFC 9990 requires. - Obsolete tags.
pct,riandrfare marked historic in the IANA registry.
What DMARC actually does
SPF and DKIM each validate a domain, but not necessarily the domain your recipient sees in the From header. DMARC ties them together: it requires that a passing SPF or DKIM result aligns with the visible From domain, and it tells receivers what to do when neither does. It also asks receivers to send you aggregate reports, which is the only practical way to discover who is sending mail as your domain.
Reading your policy
| Tag | Meaning | Notes |
|---|---|---|
p=none | Take no action on failures | Monitoring only. Correct starting point, common permanent resting place. |
p=quarantine | Treat failures as suspicious | First enforcing policy. |
p=reject | Reject failures | Strictest. |
sp= | Policy for subdomains | Defaults to p. A weaker sp is a common oversight. |
np= | Policy for non-existent subdomains | Added in RFC 9989. No legitimate mail can originate from a subdomain that does not exist. |
t=y | Policy is under test | Replaces the role pct played previously. |
pct= | None | Historic. Removed in RFC 9989 and ignored by conforming receivers. |
Moving from p=none to enforcement
The reason most domains stall at p=none is that moving further risks blocking legitimate
mail from a service nobody remembers configuring. The route through that is aggregate reports: they
show every source sending as your domain and whether it aligns. Once the list contains no surprises,
p=quarantine and then p=reject become low-risk changes rather than leaps.