KoltrixDMARCbis is now RFC 9989: what changes for your record
DMARC moved to the standards track as RFCs 9989, 9990 and 9991. Here is what changed: pct is gone, np and psd arrive, and a DNS tree walk replaces the PSL.
On this page(7 sections)
- The three new documents
- What changes in your DNS record
- Tags removed: pct, rf and ri
- Tag added: np
- Tag added: psd
- Tag added: t (testing)
- What changes in how receivers find your policy
- The DNS tree walk replaces the Public Suffix List
- SPF alignment uses only MAIL FROM
- Reporting changes worth knowing
- What you should do now
- What has not changed
- Bottom line
For more than a decade, the DMARC specification most people pointed to was RFC 7489, an Informational document from 2015. On May 20, 2026, the RFC Editor published its replacement as three Standards Track documents.
If you publish a DMARC record, a few of the changes affect you directly.
The three new documents
The update, long known as DMARCbis, is split across:
- RFC 9989: the core DMARC protocol, including policy discovery, alignment and record syntax.
- RFC 9990: aggregate reporting, the daily XML reports sent to
ruaaddresses. - RFC 9991: failure reporting, the per-message reports sent to
rufaddresses.
Together they obsolete RFC 7489. The move to Proposed Standard matters more than it sounds. RFC 7489 was published as Informational because DMARC was already widely deployed before the IETF worked on it. The new documents are the product of years of working group review, and they are what implementers and auditors will cite from now on.
What changes in your DNS record
Tags removed: pct, rf and ri
pctlet you apply the policy to a percentage of failing messages. In practice receivers implemented it inconsistently, and values other than 0 and 100 did not behave the way many people assumed. It is gone from the new specification.rfselected the failure report format. Only one format (AFRF) was ever used.rirequested a reporting interval. Receivers largely ignored it and sent daily reports regardless.
Receivers are likely to keep tolerating these tags in existing records for a long time, and an unknown tag does not invalidate a DMARC record. But there is no reason to include them in new records, and you should not build processes, such as gradual rollouts, around pct.
Tag added: np
The new np tag sets the policy for non-existent subdomains, meaning names under your domain that do not exist in DNS at all.
_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=quarantine; np=reject; rua=mailto:[email protected]"Attackers like to spoof plausible-looking subdomains that you never created, such as billing.example.com or secure-login.example.com. Before np, those were covered by sp, which also applies to real subdomains you might still be cleaning up. np lets you reject mail from names that do not exist while taking a gentler approach to subdomains that do.
Tag added: psd
The psd tag comes from RFC 9091, an experimental extension for public suffix domains. It lets operators of domains like country-code registries indicate that they are a public suffix domain. Ordinary companies do not need to set it.
Tag added: t (testing)
RFC 9989 also defines a testing flag. t=y asks receivers not to apply the published policy while still evaluating and reporting as normal; t=n, the default, means apply it. It covers the role pct=0 was sometimes used for during rollouts. As with any new tag, check that your receivers and reporting tools understand it before relying on it.
What changes in how receivers find your policy
The DNS tree walk replaces the Public Suffix List
Under RFC 7489, receivers determined your "organizational domain," the domain that alignment is measured against, using the Public Suffix List, an externally maintained list of suffixes such as .co.uk. That dependency was always awkward: the list is not part of DNS, implementations used different versions, and errors produced inconsistent alignment results.
RFC 9989 replaces it with a DNS tree walk. Starting from the From domain, the receiver queries _dmarc records at successively shorter names, with a cap on the number of queries, until it finds a policy. Domain owners and public suffix operators can use DMARC records themselves to mark where an organization's boundary lies.
For most domains, the outcome is the same as before: mail.example.com and example.com are still considered the same organization. The edge cases are domains with many labels and unusual registry structures.
SPF alignment uses only MAIL FROM
RFC 7489 allowed receivers to fall back to the SMTP HELO identity for SPF when the envelope sender was empty (as in bounce messages). The new specification drops that fallback: for DMARC purposes, SPF is evaluated against the MAIL FROM domain only. Mail with an empty envelope sender therefore relies on DKIM to pass DMARC.
Reporting changes worth knowing
- Aggregate reports gain a revised XML schema in RFC 9990. Report processors will need updates, and reports from different receivers may use old and new schemas for a while.
- Failure reports get much more explicit guidance on privacy risks. RFC 9991 is candid that per-message reports can expose personal data, which is consistent with how few large receivers send them.
What you should do now
- Audit your record. Remove
pct,rfandrifrom new or edited records. Leaving them in place on an otherwise working record is harmless in the short term. - Consider
np=reject. If your organizational policy is alreadyrejectorquarantine, addingnp=rejecthardens non-existent subdomains at no cost. - Update rollout plans. Replace any percentage-based ramp with stage durations and subdomain policies.
- Update report tooling. Make sure your processor handles the RFC 9990 schema.
- Check senders with empty envelope senders. Bounce and auto-reply traffic needs aligned DKIM to pass.
- Re-read your documentation. Internal runbooks citing RFC 7489 should now point to RFC 9989.
What has not changed
The fundamentals are the same: DMARC still passes when SPF or DKIM produces an aligned pass, p=none, quarantine and reject still mean what they meant, relaxed alignment is still the default, and the rua mechanism still delivers aggregate reports. A correct RFC 7489 record without pct is still a correct record.
Bottom line
DMARCbis is a cleanup and a promotion, not a revolution. RFCs 9989, 9990 and 9991 put DMARC on the standards track, remove tags that never worked well, add np for non-existent subdomains, and replace the Public Suffix List with a DNS tree walk. Trim obsolete tags, consider np=reject, and update your report tooling; the rest of your setup carries over.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
