Validate DMARC policy, alignment, and reporting tags for a domain.
DMARC (Domain‑based Message Authentication, Reporting, and Conformance) builds on SPF and DKIM to let domain owners publish a policy for handling unauthenticated mail. A correct DMARC record improves inbox placement, provides feedback reports, and reduces spoofing. This DMARC checker validates the record at _dmarc.<domain>, confirms that required tags are present, and highlights common policy mistakes.
DMARC policies often fail because the record is published at the wrong hostname, the p= tag is missing or invalid, or the reporting URIs are malformed. Another common issue is leaving p=none for too long, which provides visibility but no enforcement. This page summarizes policy, alignment, and reporting in a friendly view so you can see what receivers will apply.
You should run a DMARC check whenever you onboard a new mail provider, adjust SPF/DKIM alignment, or move from monitoring to enforcement. A single typo can turn a DMARC record into a no‑op, so validation is critical. If multiple DMARC records are published, receivers can treat the policy as invalid, which is why a single record is required.
If you need related checks, try TXT record validator and Check SPF check online.
DMARC is published as a TXT record at _dmarc.yourdomain. Publishing at the apex will not work.
v=DMARC1 and p= (none, quarantine, or reject) are required. Missing or invalid values should be treated as failures.
p=none is a monitoring policy. It generates reports but does not enforce rejection or quarantine. It is useful during rollout but should not be the final state for most domains.
rua is for aggregate report URIs and ruf is for forensic report URIs. They must be valid mailto: addresses.
Alignment controls whether the SPF/DKIM domains must exactly match (s) or can be a relaxed subdomain match (r). Defaults are relaxed if not specified.
pct defines the percentage of mail to which the policy applies. It should be between 0 and 100. Missing pct defaults to 100.
DMARC requires a single policy record. Multiple records can invalidate the policy, causing receivers to ignore it.
Check after any mail system change, during provider migrations, and before tightening enforcement from none to quarantine or reject.