DMARC record tags explained: p, rua, ruf, pct, adkim, aspf, and more
A DMARC record is a semicolon-separated list of tags published as TXT at _dmarc.yourdomain.com. Only v and p are required, but reporting, subdomain, percentage, and alignment tags control how useful and how strict the policy becomes. Most domains need fewer custom tags than online generators suggest.
Updated July 14, 2026
A minimal, useful DMARC record
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comPublish this at _dmarc.example.com. v=DMARC1 must appear first, p=none requests monitoring-only treatment, and rua= provides the destination for aggregate reports. When the reports show all legitimate senders aligned, change the policy deliberately.
Core policy and reporting tags
| Tag | Purpose | Practical guidance |
|---|---|---|
v | Protocol version | Required; use DMARC1 and place it first |
p | Policy for the organizational domain | Required; none, quarantine, or reject |
rua | Aggregate-report destination(s) | Strongly recommended; use a mailbox or DMARC processor built for XML volume |
ruf | Forensic/failure-report destination(s) | Optional and inconsistently supported; consider privacy implications |
sp | Policy for subdomains | Optional; defaults to p when omitted |
pct | Percentage of failing messages subject to policy | Defaults to 100; use staged values only with a clear rollout plan |
Alignment and report-behavior tags
| Tag | Values | Default and effect |
|---|---|---|
adkim | r or s | Relaxed by default; controls DKIM domain alignment |
aspf | r or s | Relaxed by default; controls SPF domain alignment |
fo | 0, 1, d, s combinations | Controls when failure reports are requested; useful only where ruf is supported |
ri | Seconds | Requested aggregate-report interval; receivers may ignore it, default 86400 |
Relaxed alignment is the correct default for most organizations: mail.example.com can align with example.com. Strict alignment is not automatically more secure in a meaningful way, but it is easier to break when subdomains are intentionally used for sending.
Safe records for each rollout stage
# Observe
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
# Enforce cautiously
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com
# Full enforcement
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.comA pct= rollout can reduce policy application during transition, but it also leaves part of the spoofed stream untreated and is not a substitute for analyzing reports. Many teams prefer a clean policy progression from none to quarantine to reject after fixing known sources.
Mistakes that invalidate or weaken a record
- Publishing DMARC at the root instead of
_dmarc. - Publishing more than one DMARC record at the same name.
- Misspelling
DMARC1, placing another tag beforev, or using an unsupported policy value. - Sending reports to an external domain without the authorization record that receivers may require.
- Using
p=noneindefinitely and assuming it blocks spoofing. - Adding strict alignment without checking legitimate subdomain senders.
- Sending reports to an ordinary personal inbox that cannot process XML volume safely.
Use the DMARC generator to avoid syntax mistakes, then verify the public record with the DMARC checker. For the rollout itself, follow how to set up DMARC.
Sources and further reading
- RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC) — The DMARC policy, alignment, reporting, and record-format specification.