Free account

Keep your requests in reach

Create an account in under 30 seconds to keep 6 months of history, share saved requests, and trigger email or webhook alerts on every diff.

  • 6-month searchable history
  • Diff alerts via email & webhook
  • Latency spike monitoring
Create account

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.

What the validator checks

  • Record envelope — empty strings, trailing quotes or records without v=DMARC1/p= are marked invalid (empty_record, record_trailing_quote, not_dmarc_record).
  • Tag syntax — duplicate or unknown tags, invalid separators and empty names generate invalid_tag_syntax, empty_tag_name or duplicate_tag diagnostics.
  • Policy and alignment — missing or empty policy tags, unsupported values for p, sp, adkim or aspf and percentages outside 1–100 are surfaced explicitly.
  • Reporting endpoints — malformed rua/ruf URIs, report intervals or formats raise dedicated diagnostics so you can correct mailto/HTTPS destinations before production.
  • DNS resolution — missing TXT answers, missing DMARC records or multiple conflicting policies appear as lookup_no_txt, lookup_no_dmarc or lookup_multiple_dmarc to distinguish publication issues from syntax 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.