DMARC record tags explained

Updated 2026-08-03 · DMARC Fundamentals

A DMARC record is a single line of tag=value pairs, separated by semicolons, published as a TXT record at _dmarc. on your domain. Nine tags cover everything you will ever set — the standard defines two more, ri and rf, which receivers largely ignore in practice — two are required, the rest are optional with sensible defaults. This page is the reference: what each tag means, what happens when you omit it, and which of the optional ones actually deserve your attention.

If you are brand new to DMARC, read What is DMARC? first — this article assumes you know what the record is for.

The full tag table

A few notes that save real-world pain:

• Only v and p are mandatory, but a record without rua is close to pointless — you get the policy with none of the visibility that makes tightening it safe.
• adkim and aspf control how exactly the passing domain must match your From domain; the defaults are right for almost everyone. The details live in DMARC alignment explained.
• ruf is honoured by few receivers and carries privacy baggage — request it deliberately or not at all.
• One more gotcha lives outside the record itself: if your rua address is on a different domain than the one being monitored, the receiving domain must publish a small DNS record authorising those reports. Monitoring services handle this for you.

The tags worth a closer look

Three of the optional tags change behaviour in ways that surprise people. They deserve more than a table row.

sp= — the forgotten subdomain hole

When sp is absent, subdomains inherit your p policy, which is usually what you want. The trouble starts when the two drift apart deliberately — and then get forgotten.

Suppose you reach p=reject on example.com but set sp=none "temporarily" while a subdomain sender gets fixed. From that day, anything.example.com is an open door: spoofers can send as invoices.example.com or hr.example.com with no enforcement at all, while your dashboard shows a proudly enforced apex domain. Attackers probe for exactly this, because subdomain From addresses look every bit as convincing to a human.

The rule of thumb: let sp inherit unless you have a specific, current reason — and if you do set it looser than p, put a date on removing it.

pct= — staged rollout mechanics

pct asks receivers to apply your policy to only a sampled percentage of failing mail. p=quarantine; pct=25 means roughly a quarter of failing messages get quarantined; the rest are treated one notch softer — as none. (Likewise, sampled-out mail under p=reject is treated as quarantine, not delivered untouched.)

That makes pct a genuinely useful stabiliser when stepping up to quarantine or reject on a high-volume domain: move through 25 → 50 → 100 while watching your reports, as described in the policy rollout guide. Two caveats: pct has no effect under p=none (there is nothing to sample), and not every receiver implements the sampling — so treat it as a rollout aid, never a precision instrument.

fo= — failure options

fo fine-tunes when a forensic report should be generated, so it only matters if you have set a ruf address. The values:

• 0 — report only when both SPF and DKIM fail to produce an aligned pass (the default: a full DMARC failure).
• 1 — report when any check fails to produce an aligned pass, even if the message still passes DMARC overall.
• d — report on any DKIM failure, regardless of alignment.
• s — report on any SPF failure, regardless of alignment.

Values combine with colons — fo=1:d:s — and fo=1 is the common choice when debugging, because it surfaces partial failures you would otherwise never see. Just remember the ceiling: however you tune fo, most large providers decline to send forensic reports at all.

Three records from real rollouts

Reference syntax is easier to absorb as complete, realistic records. These three match the natural stages of a DMARC deployment.

Starter — monitoring only. Day one; delivery behaviour unchanged, reports switched on:

_dmarc.example.com.   TXT   "v=DMARC1; p=none; rua=mailto:[email protected]"

Ramping — staged quarantine. Legitimate senders verified via reports; enforcement being introduced gradually, subdomains explicitly included:

_dmarc.example.com.   TXT   "v=DMARC1; p=quarantine; pct=50; sp=quarantine; rua=mailto:[email protected]"

Enforced — the destination. Full rejection for the domain and its subdomains, reporting kept on to catch new senders and new threats:

_dmarc.example.com.   TXT   "v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]"

Note what the enforced record does not include: strict alignment. adkim=s and aspf=s are optional hardening for setups where every legitimate sender uses the exact From domain — tighten them only after your reports prove nothing legitimate relies on subdomain alignment.

Check a record against the reference

The fastest way to apply all of this is to look at a real record with the reference beside it. The free DMARC checker fetches any domain's live record, prints it in full, and explains its policy, reporting and alignment tags — run your own domain through it and see how your current tags map to the table above. If you need to create a fresh record from scratch, the DMARC record generator lets you pick policy, reporting addresses and optional tags through a guided form and outputs a copy-ready TXT value. And since the right values for p, sp and pct depend on what your senders are actually doing, the reports themselves are the final authority: monitoring them is how the reference becomes a plan.