DMARC syntax checker

Understand the structure of a DMARC record

Domain-based Message Authentication, Reporting and Conformance (DMARC) links SPF and DKIM results to an enforcement policy published as a TXT record on _dmarc.<domain>. This page explains which tags the validator inspects and how to interpret the diagnostics returned by the API.

Example DMARC record

A DMARC record is a list of semicolon-separated tag/value pairs. Each tag contains a short name, an equals sign and a value. Extra whitespace is tolerated, but tag names must remain ASCII and unique.

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:forensics@example.com; adkim=s; aspf=s; pct=100

Mandatory tags to publish

• v — the version. DMARC1 is currently the only accepted value.
• p — the enforcement policy applied to non-aligned messages (none, quarantine or reject).

Without these tags the record is treated as invalid and recipients will ignore the policy.

Optional tags that matter

• rua — aggregate report destinations (mailto URIs). Strongly recommended to monitor how the policy behaves.
• ruf — forensic report recipients. Reserve for monitored, secured mailboxes.
• sp — policy applied to subdomains when different from p.
• adkim / aspf — alignment modes for DKIM and SPF (r for relaxed, s for strict).
• pct — percentage of traffic subject to the policy (defaults to 100).
• fo — failure reporting options (such as 1, d, s).
• ri — desired interval between aggregate reports in seconds (defaults to 86400).
• rf — report formats that recipients may use (afrf, iodef).

The validator displays every detected tag so you can preview exactly what DNS will serve.

Common issues detected by the tool

1. Unknown or duplicated tags. Tag names must be unique; duplicates are flagged.
2. Invalid report URIs. rua and ruf values must resolve to valid mailto: or https: URIs.
3. Missing or empty policy. Without p the policy never applies.
4. Out-of-range percentage. pct must be between 1 and 100.
5. Unsupported alignment or options. Values other than r/s for adkim or aspf, or unsupported fo options, trigger errors.

Best practices before deploying

• Start with p=none and a valid rua destination to observe traffic without impacting delivery.
• Analyse the reports and progressively move to p=quarantine then p=reject once SPF and DKIM are consistently aligned.
• Use sp only when subdomains require a different policy.
• Document rua/ruf mailboxes, owners and retention so reports are actually processed.
• Test the final record with this validator, then query _dmarc.<domain> to confirm publication and propagation.

A systematic validation prevents syntax mistakes, secures the DMARC rollout and gives deliverability teams actionable diagnostics.