What RFC 9989 changes for your DMARC record

DMARC policy lives at the organizational domain, and alignment is judged against it. So before a receiver can do anything with a message from mail.example.co.uk, it has to decide whether the organizational domain is example.co.uk or co.uk. RFC 7489 answered that with the Public Suffix List: find the longest public suffix, add one label, and that is your organizational domain. The list began as a Mozilla project in 2007 for scoping browser cookies, and DMARC borrowed it because nothing better existed.

It worked, and it worked because volunteers kept it current through every new TLD and every private suffix for more than a decade. But it was a dependency the protocol did not own: an external file that every receiver had to download, cache, and refresh, with no standard saying how often. Two receivers holding copies of different ages could reach different organizational domains for the same message, and neither would know.

DMARC was never a standard until now

RFC 7489, the document everyone deployed, was Informational. It was published in 2015 on the Independent Submission stream, so it never went through IETF working group consensus, and vendors had room to interpret it, which some of them used. Operators deployed it anyway. They compared notes in forums and in groups like the Messaging, Malware and Mobile Anti-Abuse Working Group, built tooling, and worked out from aggregate reports what each alignment failure meant. An aggregate report, requested with the rua tag, is a daily summary from receivers of who sent mail as you and whether it passed. By the time Gmail and Yahoo required DMARC from bulk senders in 2024, the practice was mature; the mandate made it compulsory.

The revision went by the working group name DMARCbis for years. In May 2026 the IETF published it as three Standards Track documents: RFC 9989 for the protocol, RFC 9990 for aggregate reporting, and RFC 9991 for failure reporting. Together they obsolete RFC 7489. RFC 9989 also retires RFC 9091, the experimental public suffix domain spec, and keeps its np tag, the policy for subdomains that do not exist. Now that it is published, the standard is RFC 9989, and that is the name to use.

The tree walk replaces the list

Under RFC 9989 the receiver asks DNS directly. For the policy, it queries _dmarc at the From domain first and uses that record if one exists. To find the organizational domain, which relaxed alignment needs, it moves up one label at a time, querying _dmarc at each parent, capped at eight queries so a domain with fifty labels cannot tie a receiver up. The walk stops early only at a record carrying psd=y or psd=n. Otherwise it runs to the top, and the record with the fewest labels marks the organizational domain.

A receiver uses the From domain's own record when there is one. When there is not, the same walk supplies the policy from the organizational domain or, failing that, the public suffix.

That removes the download, the cache, and the question of whose copy of the list is current. It also fixes things operators had reported for years: inconsistent handling of the list, the unreliable pct tag, and spoofing of subdomains that do not exist, which the np tag now covers.

Publication is not deployment. Most receivers still evaluate DMARC the RFC 7489 way, and tree walk support will arrive one receiver at a time over a long period. For most domains the record keeps working unchanged. If you publish records at more than one level, or send from a domain on the private part of the Public Suffix List, the old and new methods can disagree. Publishing a record at every From domain removes that risk. There is no deadline and nothing to rush. There are a few edits worth making so the record reads cleanly under both specs.

What to change in your record

Most of the work falls on receivers. On yours, it is five checks, three of them edits, and all fit in one sitting.

1. Remove the retired tags. RFC 9989 removes pct, rf, and ri. Receivers on the new spec ignore them, and they clutter the record. If you were using pct to ramp enforcement in stages, there is no replacement. The new t tag has two values. With t=y, receivers apply one level below your policy, so reject is treated as quarantine and quarantine as none. With t=n, the default, they apply the policy as written. That is less of a loss than it sounds. Receivers applied percentage sampling inconsistently, so pct never gave the control it promised. Stay at p=none until your aggregate reports show every legitimate sender passing with aligned DKIM, not SPF alone, and use sp to enforce on subdomains ahead of the organizational domain if you want a staged path.
2. Drop the report size suffix. If a rua or ruf address carries a size limit such as mailto:[email protected]!10m, remove the !10m. RFC 9989 Appendix C.4 removes that syntax, and receivers on the new spec ignore it. The address itself is unchanged.
3. Leave psd alone unless you run a public suffix. The tag has three values: y for a public suffix domain, n for an organizational domain, and u for unknown, which is also the default when the tag is absent and lets the tree walk decide. Registries and public suffix operators declare psd=y. Everyone else can omit it.
4. Consider np=reject while you are still below full enforcement. Under RFC 9989 a subdomain that does not exist inherits sp if you publish it, otherwise p, so a domain at p=reject already covers them. If you are still working through your senders at p=none or p=quarantine, np=reject tells receivers that support it to reject mail from subdomains that are not in DNS, at no risk to real mail, because no real mail comes from a subdomain that does not exist.
5. Check external reporting authorization. If rua points at a domain you do not control, that domain has to publish a TXT record at yourdomain.example._report._dmarc.thirdparty.example containing v=DMARC1, which says it accepts your reports. The rule moved from RFC 7489 into RFC 9990, Section 4, and the record is unchanged. Most report processors publish it for you. Confirm it anyway, because without it receivers drop the reports and nothing tells you.