Sign inMonitor a domain
Email

DMARC under RFC 9989: what changed (pct removed, t= and np= added)

The DMARC record you published years ago still works. A few tags changed meaning or went away, and how receivers find your policy changed underneath.

By peekip editorialLast checked 5 Oct 20263 min read4 sources
On this page
Short answer

RFC 9989 (May 2026) obsoletes RFC 7489 and RFC 9091. It removes pct and adds t (test mode: apply one level lower), np (policy for non-existent subdomains) and psd (public suffix flag). Receivers now find the policy and organisational domain by walking up DNS labels, not by consulting the Public Suffix List. Reporting moved to RFC 9990 (aggregate) and RFC 9991 (failure), so rf and ri are gone.

The short version

RFC 9989, “Domain-based Message Authentication, Reporting, and Conformance (DMARC)”, was published in May 2026 and obsoletes RFC 7489 and RFC 9091.[1] Reporting was split out into RFC 9990 (aggregate reports) and RFC 9991 (failure reports).[1][2]

TagBefore (RFC 7489)Now (RFC 9989)
p, spPolicy for the domain and its subdomainsUnchanged in purpose
pctApply the policy to a percentage of failing mailRemoved; t replaces it (Appendix A.6)[1]
t—New: test mode. With t=y, quarantine is applied as none and reject as quarantine[1]
np— (experimental in RFC 9091)New: policy for non-existent subdomains[1]
psd—New: says whether the domain is a public suffix domain (y, n or u)[1]
rf, riReport format and intervalRemoved; reporting is defined in RFC 9990 and 9991[1]
rua, ruf, adkim, aspf, foReports and alignmentStill defined[1]

Why pct went and t arrived

pct asked receivers to apply your policy to a random share of failing messages. RFC 9989 drops it and adds a simpler switch: t=y tells the receiver whether you want the declared policy “to actually be applied”.[1] Concretely:

  • p=quarantine; t=y → failing mail is treated as none.
  • p=reject; t=y → failing mail is quarantined instead of rejected.

Vendor guides published before or alongside the new standard still use pct in their rollout examples (Microsoft’s and Google’s both do).[3][4] A receiver that follows the old standard ignores t, and one that follows the new standard ignores pct. If you have pct=100, removing it changes nothing; if you have pct=10, expect receivers on RFC 9989 to apply your policy to all failing mail.

The DNS Tree Walk

To find the policy for mail.shop.example.co.uk, RFC 7489 receivers needed to know where the “organisational domain” starts, which in practice meant consulting the Public Suffix List. RFC 9989 replaces that with a DNS Tree Walk (section 4.10): the receiver queries _dmarc records at the author domain and then at shorter names above it, using what it finds (including the psd tag) to determine the policy and the organisational domain. A shortcut keeps it to at most eight queries even for very long names.[1]

For most domains the answer is the same as before. It matters for organisations with deep naming, and for operators of public suffixes, who can now say so with psd=y.

Alignment is unchanged in spirit

Relaxed alignment still means the From domain and the authenticated domain share an organisational domain: “When the Author Domain has the same Organizational Domain as an Authenticated Identifier, the two are said to be in relaxed alignment.”[1] Strict alignment still requires an exact match.

Reporting

Aggregate reports now have their own document, RFC 9990, with a new XML namespace, urn:ietf:params:xml:ns:dmarc-2.0.[2] The rule for sending reports to another domain is restated there: the receiving domain confirms it accepts reports with a TXT record at yourdomain._report._dmarc.theirdomain whose first tag is v=DMARC1.[2]

Run it on yours

Grade your record against RFC 9989

The domain report reads legacy tags, explains them and suggests the current equivalent.

What to edit today

  1. Remove pct if it is 100. If it is lower, decide whether you want full enforcement or test mode, and use t=y for the latter.
  2. Remove rf and ri; they have no effect under the new standard.
  3. Add np=reject if you never send from subdomains that don’t exist (most organisations don’t).
  4. Leave psd out unless you operate a public suffix.

Sources

  1. RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC) (May 2026) · IETF / RFC EditorChecked 5 Oct 2026
  2. RFC 9990: DMARC Aggregate Reporting (May 2026) · IETF / RFC EditorChecked 5 Oct 2026
  3. Set up DMARC to validate email in Microsoft 365 · Microsoft LearnChecked 5 Oct 2026
  4. Set up DMARC · Google Workspace Admin HelpChecked 5 Oct 2026