DMARCbis and RFC 9989: what changed in DMARC, and what should you do?

DMARC has a new specification. In May 2026 the IETF published RFC 9989, long known as "DMARCbis", and it obsoletes the 2015 RFC 7489 that every DMARC guide used to cite. Most domains don't have to touch anything, but a few changes matter, and one of them changes the advice about p=reject.

What is DMARCbis?

DMARCbis is the IETF's revision of DMARC. "bis" is IETF shorthand for a second version of a document. The work produced three RFCs, all published in May 2026:

The status change is a big part of the story. Appendix C.1 notes that RFC 7489 "was not the product of any IETF work stream" and was published by the Independent Submissions Editor as an Informational RFC. RFC 9989 is an Internet Standards Track document, which means it has IETF consensus behind it.

If you're new to DMARC itself, start with what DMARC is and how it works. This guide assumes you already have a record.

What changed in the DMARC record?

The record format is the same: a TXT record at _dmarc.yourdomain, starting with v=DMARC1. Section 4.7 says receivers must ignore unknown tags, so new tags didn't need a new version number. Appendix C.5 lists the tag changes:

The DMARC record examples guide documents every current tag with copy-paste records. Here's why each change happened.

pct is gone; t replaces it

RFC 7489 let you apply your policy to, say, 25% of failing mail. Appendix A.6 explains that in practice the tag "was usually not accurately applied, unless the value specified was either 0 or 100", and that the errors "varied widely from one implementation to another."

Meanwhile pct=0 had picked up a second meaning. Mailing lists and some mailbox providers treated it as a signal to rewrite the From header, and domain owners used that to see how much of their mail passed through intermediaries. The authors kept that behavior and gave it a clearer name: t=y is meant to be analogous to pct=0, and t=n (the default) to pct=100.

Under t=y, a receiver applies one level below your policy: p=quarantine is treated as none, and p=reject as quarantine. It doesn't affect reporting, and it does nothing when the policy is already none.

np becomes standard

np sets the policy for subdomains that return NXDOMAIN, meaning they don't exist at all. It was introduced in experimental RFC 9091; RFC 9989 makes it part of the standard. If np is absent, the sp policy applies, and if sp is absent too, p applies. Our subdomain policy guide covers sp and np in detail.

rf and ri are gone

rf only ever had one supported value (afrf). ri asked for a reporting interval, but RFC 7489 itself said anything other than a daily report was handled "on a best-effort basis." Neither tag has a replacement. RFC 9990 describes aggregate reports as "daily (or more frequent)," whatever you ask for.

How does the DNS tree walk replace the Public Suffix List?

This is the biggest technical change, though most domain owners won't notice it.

DMARC needs your organizational domain for two jobs: finding a policy when the From domain has no record of its own, and deciding whether two domains align under relaxed alignment. RFC 7489 found it with a Public Suffix List (PSL), a published list of suffixes like .com and .co.uk. Section 4.10 points out that RFC 7489 never said which list to use or how often to refresh it, so receivers could reach different answers.

RFC 9989 replaces the list with a DNS tree walk. The receiver queries _dmarc at the domain, then removes the left-most label and queries again, up the tree. Without a psd tag in play, the organizational domain is the name with the fewest labels that has a valid DMARC record. To stop abuse, names with more than eight labels are shortened first, so a walk never takes more than eight queries.

Two practical effects:

1. Your organizational domain is now the highest name with a DMARC record, not "whatever the registrar sold you". For almost every business those are the same thing.
2. Records on deep subdomains may be skipped. Section 5.1.8 warns that because of the eight-query shortcut, when a From domain has more than eight labels, a record published on one of its parent names that is eight or more labels long is never queried. If you need a specific policy on such a long name, publish the record at that exact name.

What is the psd tag for?

psd=y is for public suffix operators, such as registries, that want to publish DMARC for names under their suffix. Section 5.2 says a public suffix operator that publishes a DMARC record MUST include psd=y. Ordinary businesses should leave it out.

psd=n says "this name is an organizational domain for itself and its subdomains". Section 5.1.8 describes it as a tool for large organizations whose departments manage their own DNS. It also changes alignment, so don't add it casually.

Appendix C.3 admits the change can cause disagreements between receivers that use the tree walk and receivers still using a PSL. It says the issue is "entirely avoided" by using strict alignment and publishing explicit DMARC records for every From domain you use. For a typical business with one domain and a record at _dmarc.example.com, both methods give the same answer.

What changed for receivers and p=reject?

RFC 9989 is far more explicit about p=reject than RFC 7489 was. This is the change most likely to affect your plans.

Advice to domain owners

Section 7.4 says that "domains that host users who might post messages to mailing lists SHOULD NOT publish Domain Owner Assessment Policies of 'p=reject'." Those that want to anyway SHOULD first publish p=none "for at least a month," then p=quarantine "for an equally long period of time," and compare the results.

It also says domains that publish p=reject "MUST NOT rely solely on SPF to secure a DMARC pass and MUST apply valid DKIM signatures to their messages." The reason is forwarding. Forwarded mail "will most likely fail SPF checks," while "DKIM signatures will generally remain valid." Our guide to forwarding, SPF and ARC explains the mechanics.

Advice to receivers

Section 7.4 also says receivers "MUST NOT reject incoming messages solely on the basis of a 'p=reject' policy." Without other evidence, they "MUST treat such failing mail as if the policy were 'p=quarantine'." The RFC is candid that this may not change much: it says that "in practice, despite this advice, few Mail Receivers apply any mitigation techniques" for indirect mail.

So p=reject remains a request. Some receivers will reject, some will junk, and some will deliver with a warning.

What else changed?

• Missing p tag. Section 4.10.1 says a record without a valid p is treated as p=none only if it has at least one valid rua address. Otherwise the receiver applies no DMARC processing.
• Duplicate records. If a name returns more than one DMARC record, all of them are discarded. That was already the effect in practice; the tree walk spells it out.
• Every report address gets reports. RFC 7489 required receivers to support at least two report addresses. RFC 9989 says a report "SHOULD be sent to each listed URI."
• No report size limit. The !10m size suffix on report addresses is obsolete, and Appendix C.4 notes it was removed. Receivers should ignore it.
• A Domain Owner checklist. Section 5.1 now walks through the steps: aligned SPF, aligned DKIM, a report mailbox, monitoring, then a decision about enforcement. Section 8 says full participation means sending mail that aligns through both SPF and DKIM.
• New terms. "Monitoring Mode" means p=none; "Enforcement" means quarantine or reject. "Report Receiver" is now "Report Consumer".

What do you actually need to do?

For most domains, very little. Work through this list once:

1. Check your record. Run the DMARC Checker. It flags duplicate records, pct below 100 and unauthorized outside report addresses.
2. Replace partial pct values. If you have pct=25 or similar, updated receivers apply your full policy to everything. Use t=y while you test, then remove it. pct=100 is harmless and can stay or go.
3. Decide about pct=0. Older receivers still read it, and Microsoft's DMARC guide still showed pct examples when we checked in October 2026. Adding pct=0 next to t=y keeps both kinds of receiver in test mode.
4. Remove rf and ri. They do nothing now. Leaving them is harmless, but removing them avoids confusion.
5. Confirm aligned DKIM on every sender, especially before p=reject. The DKIM Checker shows whether a selector's key is published, and why DMARC fails covers alignment problems.
6. Add np=reject if your main policy isn't at reject yet. It blocks mail from invented subdomains without touching real ones.
7. Think about mailing lists. If your staff post to outside mailing lists, read section 7.4 before choosing reject over quarantine for your main domain.

You don't need to change v=DMARC1, your report addresses, adkim, aspf or fo.

What didn't change?

DMARC still asks the same question: did SPF or DKIM pass for a domain that aligns with the visible From address? The policies are still none, quarantine and reject. Relaxed alignment is still the default, and the RFC still notes that "nearly all Domain Owners have found relaxed alignment sufficient." Our guide to relaxed vs strict alignment covers when strict makes sense.

Reports still arrive as gzipped XML by email. If an address is on another domain, that domain still has to authorize it with a _report._dmarc record; DMARC rua and ruf reporting addresses shows how.

Adoption also hasn't changed overnight. In our scan of the Tranco top 1,000 domains in October 2026, 38.3% of these large sites still didn't enforce DMARC. The new RFC changes the fine print, not that gap.

Next steps

• Check your record with the DMARC Checker, and rebuild it with the DMARC Record Generator if it still uses pct, rf or ri.
• Upload a week of reports to the DMARC Report Analyzer and confirm every legitimate sender passes with aligned DKIM.
• Plan your enforcement stages with moving DMARC from p=none to p=reject.
• Watch for unplanned changes. iBlockSpam's domain monitoring alerts you when your MX, SPF or DMARC record changes.

Browse our other SPF, DKIM and DMARC guides.