A DMARC record is a TXT record at _dmarc.{domain} consisting of semicolon-separated tag=value pairs. Most production records use only 4–5 tags; the rest exist for edge cases.
v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]; sp=reject; aspf=r; adkim=r; fo=1
Required and Near-Required Tags
v=Required
Version
Identifies the record as a DMARC record. The only valid value is DMARC1. Must be the first tag in the record.
Example
v=DMARC1
p=Required
Policy
The action receivers should take on mail that fails DMARC.
Valid values
none — observation only; no enforcementquarantine — mark failing mail as spamreject — refuse delivery of failing mail at SMTP
Recommendation
Start at none, progress to quarantine, then reject. See our policy progression guide.
rua=Strongly Recommended
Aggregate Reporting URI
Where to send aggregate reports. Without this, you have no visibility into what's passing or failing.
Format
One or more comma-separated mailto: URIs.
Example
rua=mailto:[email protected]
rua=mailto:[email protected],mailto:[email protected]
Subdomain and Alignment Control
sp=Optional
Subdomain Policy
Separate enforcement policy for subdomains. Defaults to the value of p= if not specified.
Valid values
Same as p= — none, quarantine, or reject.
When to use
If subdomains have different sender ecosystems than the apex. Common pattern: stricter sp=reject when no legitimate mail comes from subdomains.
aspf=Optional
SPF Alignment Mode
How strictly the SPF-authenticated domain must match the From domain.
Valid values
r (relaxed, default) — subdomain matches count. mail.example.com SPF passing aligns with From example.com.s (strict) — exact match required.
Recommendation
Stick with r unless you have a specific need. Strict alignment breaks more legitimate setups than it stops attacks.
adkim=Optional
DKIM Alignment Mode
How strictly the DKIM signing domain must match the From domain. Same valid values and defaults as aspf=.
Rollout Control
pct=Optional
Percent
Percentage of failing mail to apply the policy to. The remainder gets p=none treatment.
Valid range
0–100 (default 100).
When to use
During the rollout from p=quarantine to p=reject, ramp pct= from 10 to 100 in stages. Once stable, drop the tag (defaults to 100).
Failure Reporting
ruf=Optional
Failure Reporting URI
Where to send per-message failure reports. Most providers don't generate these by default; useful only when paired with fo=.
Format
Same as rua= — one or more mailto: URIs.
fo=Optional
Failure Reporting Options
When to generate failure reports. Each option's behaviour stacks if multiple are specified (colon-separated).
Valid values
0 (default) — both SPF and DKIM must fail1 — either SPF or DKIM failing triggers a reportd — only on DKIM failures — only on SPF failure
Recommendation
fo=1 during early rollout for maximum visibility; drop later.
rf=Optional, rarely changed
Failure Report Format
Format for failure reports. Only valid value in practice is afrf (the default — Authentication Failure Reporting Format).
Reporting Frequency and Length
ri=Optional, rarely changed
Reporting Interval
How often (in seconds) the receiver should send aggregate reports. Default is 86400 (daily). Most receivers ignore values other than 86400 anyway.
A Complete Annotated Example
Production-grade DMARC record
Here's a record covering most production needs:
v=DMARC1; p=reject; sp=reject; pct=100; aspf=r; adkim=r; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; ri=86400
p=reject; sp=reject — full enforcement on apex and subdomainspct=100 — every failing message subject to policy (default but explicit)aspf=r; adkim=r — relaxed alignment (default but explicit)rua + ruf — both reporting endpoints setfo=1 — generate failure reports on either SPF or DKIM failureri=86400 — daily aggregate reports (default)
A Minimal Starting Record
Day-1 record for new DMARC deployment
If you're publishing DMARC for the first time today:
v=DMARC1; p=none; rua=mailto:[email protected]
Three tags. Observation mode. Reports flowing back. That's enough to start. Add complexity only as you progress through the rollout.
Validating Your Record
Once you've published the record, verify it:
- DMARC Dashboard — instant lookup with parsed tag breakdown and validation.
- dig from the command line:
dig +short TXT _dmarc.example.com
- The Authentication-Results header on a test message you send to Gmail or Outlook.
Common mistakes:
- Multiple DMARC records on the same name — receivers treat as permerror.
- Typos in tag names (
policy=reject instead of p=reject) — silently ignored.
- Missing
rua= — no visibility into what's happening.
- Going to
p=reject without first observing at p=none — risks rejecting legitimate mail.