Reference

DMARC record tags and examples: every tag, what it does, and which ones RFC 9989 retired

Every DMARC tag with its values and defaults, example records for monitoring, quarantine and reject, strict vs relaxed alignment, and what RFC 9989 changed.

By Updated Last verified

On this page
  1. A DMARC record example for each stage
  2. Every DMARC tag
  3. Strict vs relaxed alignment (adkim and aspf)
  4. pct, ri, fo and rf: what they did and what RFC 9989 changed
  5. Sending reports to another domain: external destination verification
  6. Syntax rules that break records
  7. Build and check your record
  8. Sources

A DMARC record is a TXT record published at _dmarc.example.com, as Google's DMARC setup page (opens in a new tab) and RFC 9989 section 4.5 (opens in a new tab) describe, made of tag=value pairs separated by semicolons under the grammar in RFC 9989 section 4.8 (opens in a new tab). RFC 7489 (opens in a new tab) requires the v tag, with the value DMARC1, first, and a p tag after it; the table below covers the rest. A complete monitoring record from the DMARC generator is v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com. RFC 9989 section 4.7 (opens in a new tab) adds np, psd and t to the tag list, and its IANA registry update (opens in a new tab) marks pct, ri and rf historic, so a record written today should not rely on them.

A DMARC record example for each stage

The three records below come from the DMARC generator, which builds a record one step at a time, starting with monitoring. Each is published as a TXT record; Google's DMARC setup page (opens in a new tab) gives the record type as TXT, the name as _dmarc.example.com with your own domain, and recommends starting with p set to none.

Monitoring. Delivery does not change; receivers send daily aggregate reports to the address in rua, which shows you every service that sends email as your domain.

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Quarantine. Once your real senders pass SPF or DKIM, failing email goes to spam instead of the inbox.

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com

Reject. Failing email is refused, so others cannot send as your domain.

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

A subdomain policy or strict alignment adds sp, adkim or aspf, for example v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc-reports@example.com; adkim=s. RFC 7489 (opens in a new tab) defines the three p values: none requests no specific action, quarantine asks receivers to treat failing mail as suspicious, which can mean the spam folder or extra scrutiny, and reject asks them to refuse it, preferably during the SMTP transaction.

Check your domain now

See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.

Create a free account

Every DMARC tag

The table reads RFC 7489 (opens in a new tab) for each tag's meaning and default, RFC 9989 (opens in a new tab) for its definition today, RFC 9989's registry update (opens in a new tab) for the historic markings and its change log (opens in a new tab) for what was added and removed. Under RFC 7489's grammar (opens in a new tab) tags other than v and p may appear in any order, and unknown tags are ignored.

Tag Meaning Values and default RFC 9989
v Marks the record as DMARC DMARC1, required, first tag, exact match; otherwise the whole record is ignored Unchanged
p Policy for the domain none, quarantine, reject; required under RFC 7489 Recommended rather than required: a valid record without p is treated as p=none
sp Policy for subdomains same values as p; absent means subdomains follow p Unchanged
np Policy for non-existent subdomains optional New, imported from RFC 9091
rua Where aggregate reports go mailto: addresses; absent means receivers must not send aggregate reports Unchanged
ruf Where failure reports go mailto: addresses; absent means receivers must not send failure reports Unchanged
adkim DKIM alignment mode r relaxed (default) or s strict Unchanged
aspf SPF alignment mode r relaxed (default) or s strict Unchanged
fo Failure report options 0 (default), 1, d, s; ignored without ruf Unchanged; 0 and 1 are mutually exclusive
pct Share of the domain's mail stream the policy applies to integer 0 to 100, default 100 Historic
ri Requested interval between aggregate reports seconds, default 86400 Historic
rf Failure report format afrf only Historic
psd Flags whether the domain is a PSD default u New
t Test mode y or n (default) New, replaces some of what pct did

Two details from RFC 7489 catch people out. sp applies only to subdomains, never to the domain itself, and it is ignored on records published at subdomains of the organizational domain, an effect of the policy discovery mechanism. And fo does nothing unless ruf is also present. RFC 9989 adds that the t tag downgrades the policy one step while set to y: quarantine is applied as none, and reject as quarantine.

Strict vs relaxed alignment (adkim and aspf)

RFC 7489 (opens in a new tab) authenticates the From domain by requiring it to match, or align with, an identifier that SPF or DKIM authenticated; strict mode limits that to an exact match, relaxed mode also covers subdomains of the verified domain. RFC 7489 section 3.1.1 (opens in a new tab) gives the DKIM case: in relaxed mode a signature with d=example.com aligns with a From address of alerts@news.example.com, because both share the organizational domain; in strict mode that fails, because the d= domain does not exactly match. RFC 9989 (opens in a new tab) defines the two modes the same way: relaxed alignment is a shared organizational domain, strict alignment is an identical domain. For SPF the same test applies to the domain of the return-path address, so under relaxed alignment a bounce address at cbg.bounces.example.com aligns with payments@example.com, as RFC 7489's SPF example (opens in a new tab) shows, and under strict alignment it does not.

Both modes default to r under RFC 9989's tag definitions (opens in a new tab), and RFC 9989 section 4.4 (opens in a new tab) records that nearly all domain owners have found relaxed alignment sufficient. Google's DMARC setup page (opens in a new tab) adds that relaxed alignment typically provides sufficient spoofing protection, while strict alignment can send mail from associated subdomains to spam or rejection. Choose s only when every service that sends as your domain signs or bounces with the exact From domain. Note that these modes are unrelated to DKIM's own simple and relaxed canonicalization.

pct, ri, fo and rf: what they did and what RFC 9989 changed

RFC 7489 (opens in a new tab) added pct so a domain owner could roll enforcement out slowly, applying the policy to a percentage of failing mail; ri to request aggregate reports more often than daily, with receivers required to manage daily reports and expected to manage hourly ones; fo to choose when failure reports are generated; and rf to name the failure report format, with afrf the only option.

RFC 9989 (opens in a new tab) explains why pct went. In practice receivers applied it accurately only at 0 or 100, and other values behaved differently from one implementation to another, so a tag with two meaningful values made no sense. The t tag replaces that part of it: t=y corresponds to pct=0 and t=n, the default under RFC 9989's tag definitions (opens in a new tab), to pct=100. RFC 9989's IANA update (opens in a new tab) lists pct, ri and rf as historic, meaning deprecated and not expected to be in use in any current implementation, and appendix C.4 (opens in a new tab) removes the ability to cap report size in a reporting URI. Google's DMARC setup page (opens in a new tab) still documents pct, with a missing tag meaning 100 percent, and Microsoft's DMARC page (opens in a new tab) still shows pct=100 as the default; a staged rollout should not depend on a tag that receivers are no longer expected to implement. Google also notes that Gmail does not support ruf, so expect few failure reports whatever fo asks for; the DMARC reports guide covers what does arrive.

Sending reports to another domain: external destination verification

When rua points at a mailbox on a different domain, for example rua=mailto:reports@red.example.net in the record for blue.example.com, receivers check that the receiving domain agreed to it. RFC 7489 (opens in a new tab) explains why: without the check, anyone could publish a record naming a victim's address and flood it with reports. The receiver queries a TXT record at blue.example.com._report._dmarc.red.example.net; a reply containing the v tag with the value DMARC1 confirms the arrangement, and if nothing confirms it the reporting address is ignored. The report receiver publishes that record, and a wildcard at *._report._dmarc.red.example.net with that same v tag says it accepts reports for any domain. Google's DMARC setup page (opens in a new tab) states the same requirement from the sender's side: a reporting address on another domain needs a DNS record at that other domain. Reporting services, including the DMARC generator's private reporting address, set this record up for you.

Syntax rules that break records

The record lives at _dmarc under your domain, as a TXT record, and RFC 9989 (opens in a new tab) adds that a TXT record split into several strings is joined in order and parsed as one. Tags are separated by ; with optional spaces around it, as RFC 7489's grammar (opens in a new tab) shows, and after v and p the order is free. A v value other than exactly DMARC1, or a v tag that is not first, makes receivers ignore the whole record. Two or more DMARC records at the same name are discarded together, so a second record switches DMARC off rather than adding to it; RFC 7489's discovery rules (opens in a new tab) and RFC 9989 (opens in a new tab) agree on that. Under RFC 9989 section 4.8 (opens in a new tab), syntax errors in later tags are dropped in favour of defaults or ignored, and unknown tags are ignored. Google's DMARC setup page (opens in a new tab) adds the practical trap: some hosts append the domain name automatically, so check the record name after saving. If a checker cannot find the record at all, see No DMARC record found.

Build and check your record

The DMARC generator builds the record one step at a time, starting at p=none with a reporting address, and saves nothing you enter. The free SPF, DKIM and DMARC check reads the public DNS records of a domain and flags a missing record, a policy of none, no reporting address, a policy that covers only part of your mail, and subdomains left at none. For what the p=none warning means and the safe order to move to quarantine and reject, see DMARC policy not enabled; for what dmarc=fail in a message header means, see DMARC fail.

Sources

Tools for this

Frequently asked questions

Can I leave out rua?

Yes, the record is still valid, but receivers then send no aggregate reports, and without reports you cannot see which services send as your domain. Publish a reporting address from the start.

Does pct=50 still do anything?

Under RFC 7489 it asked receivers to apply the policy to half of failing mail. RFC 9989 marks pct historic because receivers applied it inconsistently for values other than 0 and 100, and introduces the t tag instead. Treat pct as a tag receivers may ignore.

Why does a DMARC check say my record is invalid when every tag looks right?

The usual causes are two DMARC records at the same name, which receivers discard together, a v tag that is not first or not exactly DMARC1, or a record published at the wrong name. The record must be a TXT record at _dmarc.yourdomain.

Check your domain now

See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.

Create a free account