What DMARCbis Changes, and What It Leaves Unsolved

DMARCbis, the next version of the DMARC specification (essentially DMARC 2.0), has completed IETF Last Call and is in the RFC Editor queue. Publication as a Proposed Standard is expected in 2026, and it will make the current RFC 7489 specification obsolete. If you operate a DMARC record, most of what changes is quiet. One change is not.

DMARCbis removes the pct tag, which was DMARC's only in-protocol mechanism for staged rollout. Our proprietary data shows that the tag was rarely used correctly and almost never used at all. Its removal formalizes a gap the protocol already had, and it sharpens a question DMARC still cannot answer: how do you cross from monitoring to enforcement without breaking legitimate mail?

Where DMARCbis Stands Right Now

The current draft is draft-ietf-dmarc-dmarcbis-41, last updated 13 January 2026. IETF Last Call review completed on version 36 in late 2024. The document is now in the RFC Editor queue, which is the last administrative step before a Proposed Standard is assigned an RFC number and published.

Three practical points up front.

1. Existing DMARC records keep working. The version tag stays as v=DMARC1. Receivers that implement DMARCbis will accept records formatted under RFC 7489.
2. Most changes are quiet. Tag renames and the replacement of the Public Suffix List with a DNS-based mechanism happen inside receiver implementations. Domain owners do not need to do anything for their records to remain valid.
3. One change affects the crossing from monitoring to enforcement: The removal of pct. Combined with the redesigned testing semantics, this changes how staged rollout is supposed to work. It's the change worth understanding even if you do not read the rest of the spec.

The Changes at a Glance

The headline differences between RFC 7489 (current DMARC) and DMARCbis:

• Tags removed: pct (percentage-based policy application), rf (forensic report format), ri (report interval).
• Tags added: psd (public suffix domain flag, for PSOs opting into DMARC), np (policy for non-existent subdomains), t (binary testing mode).
• Organizational Domain: the Public Suffix List (PSL) is out. A DNS Tree Walk replaces it, using DMARC records at successive ancestor domains to determine the boundary.
• Mailing list guidance: the spec now explicitly advises against p=reject for domains with active mailing list traffic, to reduce collateral damage to subscribers.
• Going obsolete: RFC 7489 (DMARC) and RFC 9091 (PSD DMARC).

The rest of this post focuses on the changes that actually affect how a team operates DMARC in production.

The pct Tag Is Gone

The pct tag was DMARC's attempt to let operators ramp enforcement gradually. Setting pct=10 on a p=quarantine record was supposed to tell receivers: apply the quarantine policy to 10% of failing messages, and let the other 90% through. The idea was to let teams discover what would break under full enforcement without actually breaking it.

In practice, it did not work. The IETF's own rationale for removing the tag notes that receivers applied pct values inconsistently, and that behaviors at values other than 0 or 100 were unreliable across the receiver ecosystem. Staged rollout via pct was a lottery: the percentage you published and the percentage actually applied to your mail were rarely the same number.

DMARCbis replaces the mechanism with the t tag. t=y puts the record in testing mode, which downgrades the effective policy one step: a p=reject record with t=y is treated as p=quarantine. t=n (the default) is full enforcement. There is no percentage. There is no gradient.

Read that directly: the new spec does not replace pct with something that staged rollout actually works on. It removes the failed mechanism and leaves the staged-rollout problem to the operator.

From Public Suffix List to DNS Tree Walk

Under RFC 7489, when a receiver processes mail from a subdomain like invoices.example.com, it consults the Public Suffix List, an externally maintained registry, to figure out where the organizational domain boundary sits. That boundary determines which DMARC policy applies and how alignment is evaluated.

DMARCbis replaces the PSL with a DNS Tree Walk. Instead of consulting an external list, the receiver queries DNS directly: it looks for a DMARC record at the From domain, then at each parent domain, walking up one label at a time (invoices.example.com → example.com → com) and stopping at the first valid DMARC record it finds. The new psd tag on that record tells the receiver whether the record belongs to an organization or a public suffix operator, which shapes what the receiver does next.

For typical domains with a single organizational record, the Tree Walk and the PSL reach the same result. What changes is the edge cases. Three situations are worth checking in your own setup:

• You publish DMARC records on subdomains (common for separating transactional mail from marketing, or isolating third-party senders). Under the Tree Walk, a subdomain's DMARC record always wins over the org policy for mail from that subdomain. If any of those subdomain records were set up years ago and never revisited, they may be silently overriding your current org policy. Audit them.
• You operate a public suffix (a hosting platform issuing customer-branded domains under your zone, a ccTLD or gTLD registry, a BaaS or CMS that assigns subdomains to tenants). The new psd=y tag is built into DMARCbis for exactly this case. Under RFC 7489 this was layered on via the separate RFC 9091; DMARCbis folds it into the main spec. Review whether your zone should publish a psd=y record.
• You have a sender using an uncommon TLD, ccTLD, or multi-label public suffix (e.g., something under co.uk, github.io, s3.amazonaws.com). The PSL entry for that suffix may or may not match the Tree Walk behavior exactly. Check that your DMARC record actually resolves the way you expect by looking up the record at your domain and at each parent label up to the public suffix.

Everyone else: nothing to do. Your existing DMARC record keeps working under the Tree Walk the same way it did under the PSL.

New Guidance on Mailing Lists

The revised spec adds explicit guidance against publishing p=reject on domains that have active mailing list traffic. The reasoning is the same operational pain point DMARC operators have hit for years: mailing lists rewrite headers in ways that break DMARC alignment, and a reject policy punishes subscribers who did nothing wrong.

If your domain has substantial mailing list participation (open-source project lists, industry forums, and association newsletters), the new guidance is worth taking seriously. The Complete DMARC Implementation Guide covers the subdomain-and-ARC patterns most teams use to keep list participation compatible with a strong organizational policy.

What DMARCbis Does Not Fix

The spec revision acknowledges that staged rollout never worked. It does not fix staged rollout. It removes it.

For organizations moving from monitoring to enforcement, this formalizes a structural gap that our own data has been showing for months. Across a Q1 2026 snapshot of actively monitored domains in the DMARCeye platform:

• 39.9% of domains with a valid DMARC policy remain permanently at p=none, providing zero protection against spoofing despite being engaged enough to run a monitoring tool.
• Of the domains that do enforce, 93.8% apply their policy to 100% of traffic with no staged rollout. Only 6.2% use pct<100.

Two outcomes, one cause. DMARC provides no working middle ground between monitoring and enforcement. The mechanism that was supposed to bridge the gap (the pct tag) was a lottery, and after DMARCbis it is gone. The new binary testing flag does not replace what staged rollout should have done.

Preparing Without Panicking

For most domain owners, DMARCbis is not a fire drill. Existing records work as-is, and receivers are not going to change their alignment behavior overnight. A few practical notes are worth keeping in mind as adoption spreads.

• If you currently use pct for staged rollout: your records remain syntactically valid, but a DMARCbis-compliant receiver will effectively treat pct<100 as pct=100. If you were relying on the percentage, plan your transition now. The closest in-spec replacement is t=y for testing mode, but it downgrades the policy by one level rather than applying it probabilistically.
• If you have complex subdomain structure: review your DMARC records under the Tree Walk model. The practical result is usually the same as under the PSL, but edge cases exist.
• If you operate with active mailing list traffic: the new guidance against p=reject for those domains is worth taking seriously. A subdomain carve-out is the usual pattern.
• If you are at p=none and have been for a while: DMARCbis does not change your posture. The structural problem is not in the spec. It is in the lack of a safe crossing, which DMARCbis formalizes but does not solve.

Our guide to reading DMARC aggregate reports and the Complete DMARC Implementation Guide both apply unchanged under DMARCbis. What changes after the spec lands is what you can set in your record, not how you read what comes back.

What the Transition Actually Asks of You

Nothing urgent. DMARC is still DMARC after DMARCbis, and the record you publish today will still be accepted the day the new spec is RFC-stamped. What the transition asks is a posture shift: treat the crossing from monitoring to enforcement as a problem the protocol will not help you solve, and plan accordingly.

Tools that watch your aggregate reports, flag unknown senders before enforcement, and tell you in plain language what would break under a tighter policy become more valuable as the protocol becomes stricter. DMARCeye is built around exactly that role, and our free online tools (DMARC configurator, SPF, DKIM, and BIMI checkers) cover the configuration side in under ten minutes.

Try DMARCeye free today and see what your domain's DMARC reports actually say before the spec shifts.