DMARC tags are the configuration parameters inside a DMARC TXT record, separated by semicolons. Examples include v (version), p (enforcement policy), rua (where to send aggregate reports), and adkim/aspf (alignment modes). The v and p tags are required; the rest are optional with defaults.

What does adkim mean in DMARC?

adkim sets DKIM alignment mode. Value r (relaxed, the default) lets subdomains align with the organizational domain — mail.acme.com aligns with acme.com. Value s (strict) requires exact domain match. Most senders should use adkim=r unless they have a specific reason for strict.

What does aspf mean in DMARC?

aspf sets SPF alignment mode. Value r (relaxed, the default) lets the Return-Path domain align organizationally with the From: domain. Value s (strict) requires exact match between Return-Path domain and From: domain. Use aspf=r for most senders; strict breaks legitimate forwarding patterns.

What does pct mean in DMARC?

pct sets what percentage of failing mail gets the policy applied — quarantined or rejected. pct=10 means only 10% of failing mail is rejected; the rest is treated as p=none. Used during staged rollout when moving from p=none to p=reject. Gmail and Yahoo recently changed how they interpret pct, so it's less reliable than it used to be.

Which DMARC tags are required?

Only two are required: v (version, must be v=DMARC1) and p (policy: none, quarantine, or reject). Everything else has a default. A minimal valid DMARC record is: v=DMARC1; p=none. For production use, add rua= to receive aggregate reports — without it, you're flying blind.

Every DMARC Tag Explained: A Complete Reference

A DMARC record is a single TXT record at _dmarc.yourdomain.com containing semicolon-separated tag=value pairs. Eleven tags are defined in RFC 7489, but most senders only ever touch four or five. This reference covers all of them, with the actual operational defaults I use on production domains.

The complete tag list

Tag	Required	Default	Purpose
`v`	Yes	—	Version. Must be `DMARC1`.
`p`	Yes	—	Policy: `none`, `quarantine`, or `reject`.
`sp`	No	Inherits `p`	Subdomain policy.
`rua`	No	None	Aggregate report URI (mailto).
`ruf`	No	None	Forensic report URI (mailto).
`pct`	No	100	Percentage of failing mail to apply policy to.
`adkim`	No	`r`	DKIM alignment mode: relaxed or strict.
`aspf`	No	`r`	SPF alignment mode: relaxed or strict.
`fo`	No	`0`	Failure reporting options.
`rf`	No	`afrf`	Report format.
`ri`	No	86400	Aggregate report interval (seconds).

A real-world DMARC record using the common tags:

v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100; adkim=r; aspf=r; sp=reject; fo=1

Tag-by-tag detail

v (version)

Required. The only valid value today is DMARC1. Any other value, the record is ignored.

v=DMARC1;

p (policy)

Required. The enforcement action receivers should apply to mail that fails DMARC alignment:

Value	Meaning
`none`	No action. Receivers still send reports if rua= is set. Use for monitoring only.
`quarantine`	Treat failing mail as suspicious — typically moves to spam folder.
`reject`	Refuse failing mail at SMTP transaction. Highest enforcement.

Production senders should target p=reject. Use p=none only during initial rollout for monitoring. See DMARC none to reject for the staged rollout.

sp (subdomain policy)

Optional. The policy receivers apply to mail from subdomains of your domain. If omitted, subdomains inherit the p= value.

sp=reject;

Use sp= when you want different enforcement for the root vs subdomains — for example, root at p=reject and a marketing subdomain still at sp=quarantine during rollout.

rua (aggregate report URI)

Optional but operationally essential. The mailbox(es) to receive daily aggregate XML reports from reporting receivers.

rua=mailto:[email protected];

Multiple addresses are allowed, comma-separated:

rua=mailto:[email protected],mailto:[email protected];

If rua is missing or invalid, you'll publish DMARC and never see what's hitting your domain. Always set rua even for p=none.

ruf (forensic report URI)

Optional. Where individual message-level failure reports go. Privacy-sensitive — many receivers stop sending forensic reports because they include user-identifying headers.

ruf=mailto:[email protected];

In 2026, forensic reports are sparse — Google and Yahoo have largely stopped sending them. Skip ruf unless you have a specific forensic vendor pipeline configured.

pct (percentage)

Optional. The percentage of failing mail to apply the policy to. Range 0-100, default 100.

pct=50;

Originally designed for staged rollout — set pct=10 to apply rejection to only 10% of failures while you monitor impact. In practice, Gmail and Yahoo have shifted to honor p= directly without consistently respecting pct, so it's less reliable than it was. I still use it during rollout but treat it as advisory.

adkim (DKIM alignment mode)

Optional. r (relaxed, default) or s (strict). See DKIM alignment explained for the full mechanics.

adkim=r;

Use relaxed unless you have a specific reason for strict.

aspf (SPF alignment mode)

Optional. r (relaxed, default) or s (strict). Same logic as adkim but for SPF. The Return-Path domain must match (relaxed: organizationally; strict: exactly) the From: domain.

aspf=r;

Use relaxed. Strict frequently breaks legitimate forwarding and shared infrastructure.

fo (failure reporting options)

Optional. Controls when forensic reports are generated. Only meaningful if ruf= is set.

Value	Meaning
`0` (default)	Generate report if all underlying authentication mechanisms fail
`1`	Generate if any underlying mechanism fails (most useful)
`d`	Generate on DKIM failure (signature didn't verify)
`s`	Generate on SPF failure

For diagnostic richness, use fo=1. With fo=0, you only get reports on full DMARC failure.

rf (report format)

Optional. Report format for forensic reports. Default afrf (Authentication Failure Reporting Format). No real alternatives in production.

rf=afrf;

Generally don't set this — the default is fine.

ri (report interval)

Optional. Aggregate report interval in seconds. Default 86400 (24 hours). Receivers may ignore non-default values.

ri=86400;

Don't bother setting this. Receivers send daily regardless.

Operational defaults I use

For a new domain rolling out DMARC, my starting record:

v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; fo=1; sp=none;

After 4 to 8 weeks of clean monitoring, move to:

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]; adkim=r; aspf=r; fo=1; sp=quarantine;

Then over another 4 to 8 weeks, increase pct to 100, then move to p=reject. Final production state:

v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=r; aspf=r; fo=1; sp=reject;

Practitioner note: The most common DMARC record mistake I see is omitting sp=. If you set p=reject for the root domain without sp=reject, subdomains inherit reject — but only because of the default behavior. If you explicitly want different subdomain enforcement, set sp= rather than relying on inheritance.

Tag-related troubleshooting

Records that won't parse. Common causes: missing required tags, extra spaces inside values, semicolons inside mailto: URIs without proper escaping.

rua not receiving reports. External RUA destinations (different domain than the DMARC record's domain) require a verification record. To accept reports for example.com at dmarc-vendor.com, publish example.com._report._dmarc.dmarc-vendor.com TXT "v=DMARC1".

Inherited subdomain policy not working as expected. Receivers do inherit p= to subdomains by default, but if you've set sp= explicitly, that wins. Double-check.

pct not being honored. Receivers have varying respect for pct. Don't rely on pct=50 to mean "exactly 50%" — it's an advisory hint.

See DMARC authentication failed for diagnostic flow when you're seeing failures in reports.

Practitioner note: Always send your DMARC record through MXToolbox's DMARC Lookup or Mailhardener's analyzer after publishing. The parsers catch malformed tags more reliably than a visual review.

Quick reference for ESPs and senders

When configuring DMARC at major ESPs:

Context	Recommended starting record
New domain, single ESP	`v=DMARC1; p=none; rua=mailto:[email protected]; fo=1;`
Established sender, low risk	`v=DMARC1; p=quarantine; rua=mailto:[email protected];`
Production, full enforcement	`v=DMARC1; p=reject; rua=mailto:[email protected]; sp=reject; fo=1;`
Subdomain only (root protected separately)	Set `sp=` to your subdomain enforcement

If you're rolling out DMARC and want help moving safely from p=none to p=reject without breaking legitimate senders, book a consultation. I run DMARC rollouts for organizations from 10K to 50M sends per month.

Sources

v1.0 · May 2026