emailmarketing.net
EnglishFrançais

DMARC Standard Reference (RFC 9989 / DMARCbis)

The standards-track DMARC spec that obsoletes RFC 7489 — full record tag registry, the DNS Tree Walk replacing the Public Suffix List, alignment rules, policy discovery, and what changed.

Reference4 min read

Who it is for ESP operators, Senders

Applies to senders on any platform

ContentsOn this page — 6 sections

When you write a DMARC record, or need to know exactly how a receiver will find and apply it, the rules now come from DMARCbis. Below are its tags, its alignment rules, how a receiver discovers the policy for a message, and what changed from the earlier specification.

RFC 9989 (Standards Track, May 2026) is the current DMARC specification, and obsoletes RFC 7489 and RFC 9091. It splits DMARC into three documents: RFC 9989 (core protocol), RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting). For an introduction to what DMARC does, the basics of alignment and rollout strategy, see DMARC.

Complete tag registry

The record is published as a TXT record at _dmarc.<domain>. Tags are key=value pairs separated by semicolons, and v= must come first.

Tag Values Default Meaning
v DMARC1 required, first tag Version.
p none | quarantine | reject none if absent Requested handling for messages from the domain that fail DMARC.
sp same as p inherits p Policy for existing subdomains of the record's domain.
np same as p inherits sp, then p New in 9989. Policy for non-existent subdomains (no A, AAAA or MX records). For example, you can set p=none; np=reject to stop spoofing of invented subdomains while you are still moving the main domain toward enforcement.
adkim r | s r DKIM alignment mode: relaxed (same Organizational Domain) or strict (identical domain).
aspf r | s r SPF alignment mode.
rua comma-separated mailto: URIs none Destinations for aggregate reports.
ruf comma-separated mailto: URIs none Destinations for failure reports.
fo 0 | 1 | d | s (combinations separated by colons) 0 When to send failure reports: 0 means report only if all mechanisms fail to produce an aligned pass; 1 means report if any mechanism fails; d means report DKIM failures whatever the alignment; s means report SPF failures whatever the alignment.
psd y | n | u u New in 9989. Whether this domain is a Public Suffix Domain (y), definitely not one (n), or unknown (u). Used by the Tree Walk.
t y | n n New in 9989. Test mode: t=y asks receivers to treat the policy as advisory (evaluate and report, but do not enforce the disposition). Replaces pct.

Removed from RFC 7489: pct (percentage sampling, replaced by the t tag, which applies to all messages or none) and ri (report interval). Receivers that still find old records simply ignore tags that are unknown or retired.

If a record has no valid p tag but has a valid rua, receivers treat it as p=none (monitoring only) instead of discarding it.

Alignment

An Authenticated Identifier is the DKIM d= domain of a passing signature, or the RFC5321.MailFrom domain validated by SPF.

  • Relaxed (default): the From: domain and the Authenticated Identifier have the same Organizational Domain.
  • Strict: the domains must be identical.
  • The comparison is not case-sensitive. An aligned pass from either DKIM or SPF gives a DMARC pass.

The DNS Tree Walk (replaces the Public Suffix List)

RFC 7489 relied on the Public Suffix List, a list maintained for web browsers, to find a domain's Organizational Domain. RFC 9989 replaces it with a Tree Walk within DNS, limited to 8 queries per walk:

  1. Query _dmarc.<domain> for the exact domain. Discard anything that does not start with v=DMARC1.
  2. If the name has more than 8 labels, go straight to its last (rightmost) 7 labels for the following steps.
  3. Remove the leftmost label, and query _dmarc. at each shorter name in turn.
  4. Stop early when a record with psd=n or psd=y is found. These records mark the boundary between the organization and the public suffix.
  5. The walk ends when a suitable record is found or no labels are left.

The Organizational Domain is determined from the results of the walk: it is the domain just below the point where psd=y appears, or the longest name that has a record or psd=n. This changes the behavior in edge cases compared with the PSL, for deeply delegated zones. For typical setups such as example.com and mail.example.com, the outcome is the same.

Policy discovery for a message

  1. Query _dmarc.<RFC5322.From domain>. If a valid DMARC record exists, use it.
  2. Otherwise, perform the Tree Walk upward. The first valid record found applies.
  3. When the record that applies was found above the From: domain (that is, the From: domain is a subdomain), use sp if the subdomain exists in DNS, and np if it does not. Otherwise, fall back to p.
  4. If there is no valid record anywhere, DMARC does not apply to the message (disposition none, result "none" in Authentication-Results).

Operational implications

  • Publish psd=n in the record of an organizational domain if you delegate deep trees of subdomains. It fixes the point where the Tree Walk stops, and prevents mail from being attributed to the wrong domain.
  • Use np= to protect against spoofing of non-existent subdomains, even while the main policy is still p=none during rollout.
  • t=y replaces raising pct= in steps. Under RFC 7489, pct=25 gave partial enforcement. Under 9989, you either enforce or test. Plan rollouts in stages, first p=none, then t=y with p=quarantine/reject, then enforcement, guided by the data in aggregate reports as described in DMARC.
  • Receivers adopt DMARCbis gradually. Expect a long period in which both the semantics of RFC 7489 (PSL, pct) and those of RFC 9989 (Tree Walk, t, np, psd) are in use. Records that contain only the tags common to both (v, p, sp, adkim, aspf, rua, ruf, fo) behave identically under both.

Check your own record

The free check reads what your domain publishes in DNS.

In this topic

All 13 in Authentication →