Does your _dmarc TXT record still contain a pct=50 tag? It has served no purpose since May 20, 2026. On that date, the IETF published DMARCbis as three RFCs: RFC 9989 for the protocol’s core, joined by RFC 9990 and RFC 9991 for reporting, which officially replace RFC 7489 from 2015 (dmarc.org, May 2026). The pct tag disappears, two new tags arrive, and the mechanism for discovering the organizational domain changes. Losing 30% of delivery in three months with no change to content, while your email SaaS still shows a green status, often traces back to a DNS configuration that was never revisited rather than to campaign content. For the fundamentals of the protocol, particularly what it doesn’t cover, DMARC: 5 things it can’t do remains the reference. Here, the focus is the transition itself and what needs fixing before the major mailbox providers (Google, Microsoft, Yahoo) align their parsers with it.
What does DMARCbis actually change compared to RFC 7489?
RFC 7489 held “Informational” status since its 2015 publication: DMARC had never become an Internet standard in the strict IETF sense. RFC 9989 fixes that. The protocol advances to Proposed Standard, the first normative rung of the IETF, rendering both RFC 7489 and RFC 9091 (the PSD DMARC extension, which stayed experimental) obsolete. RFC 9990 now governs aggregate XML reports; RFC 9991 covers message-by-message failure reports. All of this stems from draft-ietf-dmarc-dmarcbis-41, published April 4, 2025, capping work that began in 2019 following the finalization of the ARC protocol.
One thing should reassure administrators short on time. The v=DMARC1 value doesn’t change. A record published in 2019 still resolves correctly in 2026, with no service interruption on the day of the switch.
The tags DMARCbis removes
Three tags leave the spec, pct leading the pack. Meant to apply the policy to a percentage of traffic, it carried a flaw documented for years: in practice, only the 0 and 100 values were applied reliably, with intermediate values producing inconsistent behavior from one receiver to another (dmarcian, 2025). It’s replaced by a binary tag, t, with just two values: t=y for test mode, equivalent to the old pct=0, and t=n for full enforcement, equivalent to pct=100. Alongside it go rf, the aggregate report format, and ri, the reporting interval, both moved into the reporting documents RFC 9990 and RFC 9991. A record that still contains one of these three tags keeps working. It simply becomes obsolete.
The tags DMARCbis adds
The np tag targets a real blind spot in RFC 7489: subdomains that don’t exist in DNS. An attacker could previously send from fake.payment.example.com without any DMARC policy applying, since the subdomain simply had no record to query (dmarcian, 2025). With np=reject or np=quarantine, the domain owner closes that door without having to harden the rest of their legitimate traffic. Alongside it, the psd tag carries over the content of the former RFC 9091: it marks a domain as a public suffix (psd=y), information that feeds the discovery mechanism described below. A domain aiming for BIMI display in Gmail will still need p=quarantine or p=reject either way. The clarification np brings doesn’t change that existing prerequisite.
DNS tree-walk discovery replaces the Public Suffix List
Take mail.marketing.example.com. Under RFC 7489, determining this address’s organizational domain depended on the Public Suffix List, a list maintained manually by Mozilla, updated out of band, never formally standardized. A forgotten registry or a new TLD missing from the list produced a silent false negative. RFC 9989 replaces this mechanism with a DNS Tree Walk: the receiver queries mail.marketing.example.com, then marketing.example.com, then example.com, then the TLD, in sequence, stopping as soon as it finds a record carrying psd=n (organizational domain) or psd=y (public suffix). The algorithm is capped at 8 DNS queries, a figure set in section 4.10 of the RFC itself. RFC 9990’s aggregate reports add two fields that weren’t there before: discovery_method and testing, which indicate how the policy was found and whether the domain is running in t=y mode. An administrator who reads their XML reports without ever checking these two fields will need to add them to their dashboard.
The impact on SPF and DKIM alignment
Alignment still works the same way: comparing the domain authenticated by SPF or DKIM to the organizational domain of the From domain. What changes is how that organizational domain is calculated: no longer pulled from an external list, but resolved deterministically via DNS. On a domain with a standard structure, like example.com with no exotic sub-level, nothing changes. On a deep DNS structure, with several levels of subdomains managed by different entities, the tree walk’s result can differ from what the PSL returned, especially when an intermediate level now publishes a psd record. RFC 9989 also clarifies a point that was already true in practice but rarely spelled out: SPF alignment only applies to the MAIL FROM identity of the SMTP command, never to the HELO identity. A domain relying on HELO alignment was never covered in the first place; the clarification just makes it explicit. For the structural friction points of the SPF protocol itself, the 10 DNS lookup limit and the consequences of a missing SPF record remain just as relevant. DMARCbis doesn’t remove them.
One limit remains. Past eight DNS queries, the tree walk resolves nothing. The RFC sets this cap to prevent loops and amplification attacks, but a deep-delegation architecture, with one DNS subcontractor stacked on another, can hit it before even reaching the actual organizational domain.
Which _dmarc DNS TXT tags need fixing before the transition?
IETF documentation doesn’t specify a timeline for when the major mailbox providers (Google, Microsoft, Yahoo) will migrate their receiving parsers to DMARCbis. The three RFCs are published; adoption on the receiver side remains gradual, with no fixed calendar at this stage. Fixing the record now avoids falling behind the day one of the three switches its default reading.
- Remove any pct= tag from the _dmarc TXT record, regardless of its current value.
- Delete rf= and ri= if present: two parameters a receiver compliant with RFC 9989 no longer reads.
- Add np=quarantine or np=reject as soon as the main policy, p=, is already enforced, to close the door on nonexistent subdomains.
- Check the structure of subdomains managed by external providers (registrar, subsidiary, secondary brand) and assess whether a psd=y or psd=n tag needs publishing at an intermediate level.
- Document the chosen t= mode, t=y for test or t=n for enforcement, instead of letting a legacy pct value stand in as the record of intent.
None of these fixes requires canceling or reconfiguring an existing SPF or DKIM record. The work stays confined to the DMARC field, even though it touches the same DNS zone as the CNAME records already in place for other purposes.
“The changes and improvements known as DMARCbis are now official: the protocol moves onto the IETF’s normative track” (dmarc.org, May 2026).
What the transition means for sender reputation
Cleaning up the DMARC record only solves part of the problem. A perfectly aligned domain sending to a degraded list keeps generating rejections, for a different reason: the hard bounce rate climbs, sender reputation deteriorates with Gmail’s postmaster, and a DMARC reject on an otherwise clean domain ends up read as a spam signal rather than a one-off anomaly. This is the usual objection: verifying a list before sending has a cost, so why not just filter afterward? Except a post-authentication DMARC rejection can’t be caught downstream like an ordinary soft bounce. It damages IP reputation before any filtering even happens. ISP feedback loops and complaint rate typically spike before Microsoft’s SNDS flags anything unusual. A poorly prepared DMARCbis transition, combined with a list that’s never been cleaned, stacks both causes of rejection instead of isolating just one. To understand why SMTP rejections rise and how to bring them down, the topic connects directly to the DNS record issue covered here. The only way to know which of the two causes weighs more is to run the list through a check before the next campaign, separately from the DNS record work.
Protocols update themselves. DNS records never do.
