RFC 9989: What Changed From RFC 7489 for DMARC

RFC 9989, published in May 2026, replaces RFC 7489 as the DMARC standard. For most domain owners nothing is urgent: a normal record keeps its meaning. What changed: pct is gone, a DNS tree walk replaces the Public Suffix List, np, psd and t are new, and reporting moved into RFC 9990 and RFC 9991.

Everything below comes from the RFC text itself, mainly Appendix C ("Changes from RFC 7489") and section 4.7 (the tag list). Where we say how many domains are affected, the number is from our own scan of the Tranco top 1,000 on 19 October 2026.

One document became three

The status line matters more than it looks. RFC 7489 "was not the product of any IETF work stream"; the Independent Submissions Editor published it as Informational. RFC 9989 is an IETF standard. RFC 9091, the experimental spec for public suffix domains, is folded in and retired.

pct is removed, and t takes its useful half

RFC 7489 let you apply a policy to a percentage of failing mail. Appendix A.6 of RFC 9989 explains why that went: "Operational experience showed that the 'pct' tag was usually not accurately applied, unless the value specified was either 0 or 100." A pct=25 meant different things at different receivers.

pct=0 had picked up a second job. Some mailing lists and mailbox providers read it as a cue to rewrite the From header instead of applying the policy, and owners used that to measure how much of their mail passed through intermediaries. RFC 9989 keeps that behaviour under a new name:

• t=y asks receivers not to apply the policy as written but one level below it. Reject is handled as quarantine, quarantine as none.
• t=n is the default and means apply the policy as written.
• t has no effect on a policy of none.

The IANA registry now lists pct as "historic". In our October scan, 10 of the 722 DMARC records in the top 1,000 still set pct below 100, including one p=reject; pct=5.

The tree walk replaces the Public Suffix List

Under RFC 7489, a receiver found your organizational domain with a public suffix list, and the RFC did not say which list or how often to refresh it. Two receivers could disagree about where your domain ends.

RFC 9989 section 4.10 drops the list. The receiver asks for _dmarc at the From domain. If nothing is there, it strips labels from the left and asks again, up to the top-level domain. Names longer than eight labels are shortened first, so a lookup never takes more than eight queries. For a.b.c.d.e.f.g.h.i.j.mail.example.com the RFC's own example queries _dmarc.a.b.c.d.e.f.g.h.i.j.mail.example.com, then jumps to _dmarc.g.h.i.j.mail.example.com and works up to _dmarc.com.

A record with psd=y or psd=n stops the walk. psd=y is for public suffix operators such as a registry. psd=n says "this is an organizational domain". Section 5.1.8 describes it for large organisations that hand parts of their DNS to departments, with a warning: a record placed deeper than the eight-query walk reaches is never found.

Receivers still running RFC 7489 code with a public suffix list may land on a different answer. Appendix C.3 gives the fix: the problem "is entirely avoided by the use of strict alignment and publishing explicit DMARC Policy Records for all Author Domains used in an organization's email."

Tags added and removed

p also changed status. RFC 7489 made it required in a policy record. RFC 9989 calls it recommended: a record without a valid p but with a valid rua is handled as p=none, and one with neither gets no DMARC processing at all.

Adoption of the new tags is thin so far. Only two domains in our scan publish np (both np=reject) and three publish psd.

Reporting moved into its own documents

Aggregate reports now live in RFC 9990. For a domain owner the differences are small:

• A report "SHOULD be sent to each listed URI" in rua. RFC 7489 only required receivers to support two.
• The size suffix on report addresses, such as mailto:[email protected]!50m, is gone.
• Reports can say how the policy was found (discovery_method is psl or treewalk) and carry the t value as testing.
• A DKIM result in a report must now include the selector, which makes it easier to tell two signing services apart.

Failure reports moved to RFC 9991. RFC 9989 section 5.3.9 now says plainly that receivers "MAY choose to send them" and that privacy-minded receivers either redact them heavily "or not send them at all." If your ruf mailbox is empty, that is why. Our FAQ on missing ruf reports has the details.

The advice on p=reject got sharper

Section 7.4 is the part most likely to change a decision. It says domains that publish p=reject "MUST NOT rely solely on SPF" and "MUST apply valid DKIM signatures", because forwarding breaks SPF but usually leaves DKIM intact.

It goes further for domains whose users post to mailing lists. Those domains "SHOULD NOT" publish p=reject. A domain that wants to anyway should first run p=none for at least a month, then p=quarantine for as long, and compare the results in its aggregate reports. On the receiving side, receivers "MUST NOT reject incoming messages solely on the basis of a 'p=reject' policy." The RFC admits in the same section that few receivers behave this way in practice.

What a domain owner needs to change

Nothing has a deadline. Work through this list when you next touch the record:

1. Delete pct. At 100 it was the default and removing it changes nothing. If you used pct=0 to soften a new policy, use t=y instead. Receivers that still run RFC 7489 ignore t, so expect the full policy from them.
2. Delete rf, ri and any !size suffix in rua or ruf. They no longer mean anything.
3. Publish a record on every domain you send From, not only the parent. That sidesteps any difference between the tree walk and a public suffix list.
4. Consider np=reject. It blocks mail from invented subdomains without touching the real ones.
5. Before p=reject, check DKIM on every sender. Section 7.4 makes it a MUST. Your aggregate reports show which sources pass on SPF alone.

The DMARC record generator now follows RFC 9989 and never writes pct, and the DMARC checker explains np, psd and t when it finds them. Once reports arrive, the report analyzer reads both the RFC 7489 and RFC 9990 formats in your browser.

Frequently asked questions

Sources

• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), May 2026
• RFC 9990: DMARC Aggregate Reporting, May 2026
• RFC 9991: DMARC Failure Reporting, May 2026
• RFC 7489: DMARC (Informational, 2015, now obsolete)
• DMARC adoption in the Tranco top 1,000, 19 October 2026 (our scan)