Validate your DMARC records instantly to spot syntax errors, check enforcement policies, and verify reporting URIs.
A misconfigured DMARC (Domain-based Message Authentication, Reporting, and Conformance) record can cause your legitimate emails to be rejected, or leave your domain vulnerable to impersonation. Enter your domain above to instantly parse and validate your DMARC string. This tool checks for missing tags, malformed URIs, and policy enforcement levels.
_dmarc.yourdomain.com. If you put it on your root domain, this check will fail.p=none, DMARC is in monitoring mode. It will not stop spoofed emails. To actively block spam and spoofing, you must gradually move to p=quarantine or p=reject.rua tag must use the correct format. A common mistake is forgetting the prefix. It must be rua=mailto:reports@example.com.What exactly is SPF/DKIM alignment? How do the pct, sp, and adkim tags change receiver behavior? Read our comprehensive DMARC guide.
Read the DMARC Record WikiDMARC (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 SPF/DMARC record generator DNS lookup.
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.