Free DMARC Record Checker
Look up and validate the DMARC record for any domain. The checker finds the record that receiving mail servers actually apply, following the RFC 9989 tree walk, then reports the domain, subdomain and non-existent subdomain policies, testing mode, deprecated tags and reporting setup with actionable recommendations in plain language.
Need DMARC, SPF and TLS together? Run the free domain security check, or check SPF or TLS on their own.
What the DMARC checker tests
- Record discovery. The checker looks for a TXT record at
_dmarc.your domain. If there is none, it walks up to the organisational domain the way RFC 9989 receivers do and tells you which record applies and every domain it queried. Multiple records at one name are flagged, because receivers ignore all of them. - Syntax and tags. Each tag is parsed. Duplicate tags, empty values, malformed tokens, invalid optional values and unknown tags are called out, along with what receivers do in each case.
- Policy details. The Domain Policy, Subdomain Policy and Non-existent Subdomain Policy are shown side by side with what receivers will do with failing mail, including any policy the domain inherits from its parent.
- Testing mode. A record with
t=yis highlighted, because receivers apply the policy one level below the one published until the flag is removed. - Deprecated tags. Tags removed in RFC 9989 such as
pct=,rf=,ri=and report size limits are listed with a recommendation for each. - Reporting. A missing
rua=address is flagged, and reporting URIs that receivers cannot use are explained. - Domain status. If the domain appears unregistered, or DNS cannot be reached, the checker says so rather than reporting a missing record.
How to read the policy details
The result opens with an overall status and the messages behind it, then a Policy Details table with three rows. Domain Policy is what receivers do with failing mail from the domain itself. Subdomain Policy covers subdomains that exist in DNS but publish no record of their own. Non-existent Subdomain Policy covers subdomains that do not exist at all, a common target for spoofing.
A policy shown as Monitor (none) means receivers take no action and the domain can be spoofed. Enforce (quarantine) sends failing mail to junk. Enforce (reject) refuses it. The checker reports a valid record with an enforcement policy as ok, and warns whenever any of the three policies leaves a gap.
If the record was found at a parent domain, a tag above the table says so, and the messages explain which policy receivers apply to the domain you entered.
Common DMARC problems and how to fix them
- No record at all. Add a TXT record at
_dmarc.yourdomainstarting withv=DMARC1; p=none;and arua=mailto:address, then use the reports to find every legitimate sender before tightening the policy. - Stuck at p=none. Monitoring alone stops nothing. Once your reports show legitimate mail passing, move to
p=quarantineand thenp=reject. Then make sure you stay there. - No rua= address. Without aggregate reports you are flying blind. Add a reporting address, or use a reporting service so the XML reports are collected and analysed for you.
- Weak subdomain policy. An explicit
sp=noneornp=noneleaves subdomains spoofable even when the domain itself is atp=reject. Left out, both tags inherit the domain policy, so only add them when a subdomain genuinely needs a different policy. - Old pct= tag. RFC 9989 receivers ignore
pct=and apply the full policy. Replace it witht=yif you still need a testing phase, or remove it. - Multiple records. Receivers ignore every DMARC record when more than one is published at the same name. Delete the extras so exactly one remains.
Move to p=reject and stay there
A one-off check tells you where you stand today. The VerifyDMARC dashboard collects and analyses your DMARC reports, shows which senders pass and fail alignment, checks every domain's record hourly, and sends regression alerts if a policy is downgraded. It sits alongside SPF and TLS reporting for every domain you manage.
Start Free TrialDMARC checker FAQ
What is a DMARC record?
DMARC (Domain-based Message Authentication, Reporting and Conformance) is a TXT record published at _dmarc.yourdomain. It tells receiving mail servers what to do with email that claims to come from your domain but fails SPF and DKIM alignment, and where to send reports about that mail.
The record starts with v=DMARC1, sets a policy with p=, and usually includes a rua= address for aggregate reports. Read about DMARC and why it is fundamental.
What do p=none, p=quarantine and p=reject mean?
p=none (Monitor) asks receivers to take no action against failing mail and only send reports. It is the right starting point while you discover every service that sends as your domain, but it provides no protection against spoofing.
p=quarantine asks receivers to treat failing mail as suspicious, typically by delivering it to the junk folder. p=reject asks them to refuse it outright, which is the only policy that stops spoofed mail reaching inboxes. See how to move to p=reject safely.
Why does the checker say my policy is inherited from a parent domain?
When a subdomain has no DMARC record of its own, receiving mail servers look for one at its organisational domain and apply that record's subdomain policy (sp=), or its np= policy if the subdomain does not exist in DNS. RFC 9989 defines this as a tree walk up the domain hierarchy.
The checker follows the same walk, lists every domain it queried, and shows which record and policy actually applies. Learn how DMARC treats subdomains.
Why do I need reports if my policy is p=none?
Reports are the only way to see which services send email as your domain and whether they pass SPF and DKIM alignment. Without a rua= address you cannot tell what would break if you moved to an enforcement policy, so most domains stay at p=none forever and remain spoofable.
Read why reporting matters at p=none, or learn the difference between RUA and RUF reports.
What changed in RFC 9989 (DMARCbis)?
RFC 9989 replaces RFC 7489. It defines the tree walk for finding the applicable record, adds the np= policy for non-existent subdomains and the t=y testing flag, and removes the pct=, rf= and ri= tags along with report size limits.
Records written for RFC 7489 keep working, but the checker flags the removed tags with a recommendation so you can bring the record up to date. Read what DMARCbis means for you.