DMARC Record Tags Explained (v, p, rua, pct...)

24 June 2026 · DMARC Engine · 7 min read

A DMARC record is a single TXT entry published at _dmarc.yourdomain.com, made up of semicolon-separated tags such as v, p and rua. Each tag controls one piece of behaviour: the policy you ask mailbox providers to apply, where reports are sent, how strictly alignment is checked, and so on. This article explains every tag you are likely to meet, the values each accepts, the defaults that apply when a tag is omitted, and how the tags fit together in a real record.

The short answer: only two tags are required, v=DMARC1 and p=. Everything else is optional and falls back to a sensible default. But getting the optional tags right is what turns a record from "technically valid" into "actually protecting your domain".

The two required tags

v: version

v identifies the record as DMARC and must come first.

Valid value: DMARC1 (exactly).
Default: none. It is mandatory.
Notes: If v is missing or is not literally DMARC1, the record is ignored entirely. This is also how receivers tell a DMARC TXT record apart from any other TXT records at the same host.

p: policy

p tells receiving mail servers what to do with messages that fail DMARC (i.e. mail that is neither SPF-aligned nor DKIM-aligned).

Valid values: none, quarantine, reject.
Default: none. It is mandatory and must be the second tag.
What each does:
none: take no action; just send reports. This is monitor-only mode.
quarantine: treat failing mail as suspicious (typically routed to spam/junk).
reject: refuse failing mail outright at SMTP time.

p=reject is the goal: it is the only policy that actually stops exact-domain spoofing, and it is what Google and Yahoo's bulk-sender rules nudge senders toward. You should not jump straight to it, though, so see the enforcement journey.

Reporting tags

rua: aggregate report address

rua is where aggregate (RUA) reports are sent. These XML summaries (one per source IP per day, roughly) are the single most useful thing DMARC gives you, because they show every system sending on your behalf.

Valid value: one or more mailto: URIs, comma-separated.
Default: none. Omit it and you receive no aggregate reports (the most common reason a record "does nothing").
Example: rua=mailto:dmarc@yourdomain.com
Notes: To send reports to a domain you do not control (such as a monitoring service), that domain must publish an authorisation record. You can also cap report size with the ! syntax, e.g. rua=mailto:dmarc@yourdomain.com!10m.

ruf: forensic/failure report address

ruf is where forensic (RUF) reports go: these are redacted copies of individual messages that failed.

Valid value: one or more mailto: URIs, comma-separated.
Default: none.
Notes: Very few mailbox providers send RUF reports today, largely for privacy reasons, so do not be surprised if you set this and never receive anything. Aggregate (rua) data is where you should focus.

fo: failure reporting options

fo controls when a failure report is generated. It only has an effect if you have also set ruf.

Valid values: 0, 1, d, s (combine multiple with :).
Default: 0.
What each means:
0: report only when both SPF and DKIM fail to produce an aligned pass (the default).
1: report when either SPF or DKIM fails to produce an aligned pass. This is the most useful setting if you want visibility.
d: report on any DKIM signature that fails to verify, regardless of alignment.
s: report on any SPF check that fails, regardless of alignment.
Example: fo=1

Alignment tags

DMARC passes when SPF or DKIM both authenticates and aligns: the authenticated domain matches the domain in the visible From: header. The alignment tags decide how exact that match must be.

adkim: DKIM alignment mode

Valid values: r (relaxed) or s (strict).
Default: r.
What each means:
r (relaxed): the DKIM d= domain only needs to share the organisational domain with the From: domain. So a signature from mail.yourdomain.com aligns with a From: of yourdomain.com.
s (strict): the DKIM d= domain must match the From: domain exactly.

aspf: SPF alignment mode

Valid values: r (relaxed) or s (strict).
Default: r.
What each means:
r (relaxed): the SPF-authenticated MAIL FROM (envelope/return-path) domain only needs to share the organisational domain with the From: domain.
s (strict): the envelope domain must match the From: domain exactly.

Leave both at relaxed unless you have a specific reason to tighten them. Strict alignment frequently breaks legitimate mail sent through providers that use their own bounce domains. If your SPF itself is the problem (too many includes, permerror from the 10-lookup limit), our SPF checker will flag it.

Rollout and rate-control tags

pct: percentage

pct applies your policy to only a sampled percentage of failing mail. It is a ramp-control dial: the rest of the failing mail is treated as if the next-lowest policy applied.

Valid values: an integer 0-100.
Default: 100.
Example: p=quarantine; pct=25 quarantines a quarter of failing mail and applies none (monitor) to the other three quarters.
Notes: pct lets you step into enforcement gradually (e.g. 10, then 50, then 100), watching reports at each stage. (Be aware the revised DMARC standard, DMARCbis, removes pct; for now every deployed receiver still honours it, and it remains the safest way to ramp.)

sp: subdomain policy

sp sets a separate policy for subdomains, overriding p for them.

Valid values: none, quarantine, reject.
Default: if sp is absent, subdomains inherit whatever p is.
Example: p=reject; sp=quarantine rejects failing mail from the exact domain but only quarantines failing mail from subdomains.
Notes: A subdomain that publishes its own _dmarc record uses that record instead. sp on the parent does not apply. See subdomain DMARC records.

ri: reporting interval

ri requests how often, in seconds, aggregate reports should be generated.

Valid value: an unsigned integer (seconds).
Default: 86400 (24 hours).
Notes: This is only a request. In practice nearly all providers send aggregate reports once per day regardless, so changing ri rarely makes a difference.

Worked examples

A monitor-only record to start safely (collect data, change nothing for recipients):

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1

A mid-rollout record, quarantining a sample while you confirm your legitimate senders are aligned:

v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@yourdomain.com; fo=1

A fully enforced record, the destination, with a slightly softer subdomain policy:

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=r; fo=1

How to read and verify your own record

Look up the TXT record at _dmarc.yourdomain.com (not the root of the domain). On macOS or Linux: dig +short TXT _dmarc.yourdomain.com.
Confirm there is exactly one DMARC TXT record. Two or more is a configuration error and most receivers will treat the policy as undefined.
Check v=DMARC1 is first and p= is present.
Confirm rua= points at a mailbox you can actually read, or you will collect nothing.
Read remaining tags against the defaults above: anything you have not set is using its default value.

Our free DMARC checker parses each tag for you and flags duplicates, missing rua, and policies that are not yet at enforcement.

Common problems

Record published at the wrong host. It must live at _dmarc.yourdomain.com, not at the domain apex. A DMARC record at the root does nothing.
No rua tag. The record is valid but you will never see a report, and without reports you can never safely move past p=none. If you set rua but still get nothing, see empty DMARC reports.
Tags out of order. v must be first and p second; receivers may reject records where they are not.
Strict alignment set too early. adkim=s or aspf=s often breaks mail relayed through third-party providers. Stay relaxed unless you have verified every sender.
Stuck at p=none. A monitor-only policy never blocks spoofing. The whole point is to reach p=reject once your reports are clean, so read is it safe to move to p=reject?.
Smart quotes or trailing semicolons copied from a document can silently invalidate the record. Use plain ASCII.

Next steps

Once you can read every tag, the workflow is straightforward: publish v=DMARC1; p=none with a working rua, watch the aggregate reports until all of your legitimate senders pass aligned, then ramp through quarantine (optionally using pct) to p=reject. Hosted DMARC from DMARC Engine automates that ramp: it parses your inbound reports, identifies every sender, and guides each policy change so you reach enforcement without dropping a single legitimate message. Start by running your current record through the DMARC checker to see exactly which tags are set and which defaults you are relying on.

What do the DMARC record tags mean?