Blog · Dmarc
DMARCbis vs RFC 7489: What the Update Actually Changes
What Is DMARCbis and How Does It Differ From RFC 7489?
RFC 7489 has been the DMARC standard since 2015. DMARCbis is its planned replacement. The IETF draft (draft-ietf-dmarc-dmarcbis-41, April 2025) is in active development and will, when finalized, obsoletes RFC 7489.
The question practitioners ask most is simple: what actually changes? This post answers that directly. It compares the two specifications section by section, names the specific technical changes, and identifies what stays exactly the same.
Standards Track vs Informational
RFC 7489 was published as an Informational RFC. It described how DMARC works in practice but did not mandate specific behavior for mail receivers. DMARCbis is being developed as a Standards Track RFC, which defines normative requirements that conforming mail receivers should follow.
This matters for adoption. An Informational RFC describes a useful practice. A Standards Track RFC defines a protocol requirement. When DMARCbis becomes an RFC, mail receivers that ignore DMARC policies will be out of step with a standard, not just operating off a suggestion. That does not mean all receivers will enforce immediately -- email standards adoption is always gradual -- but the floor for DMARC enforcement rises.
New Terminology: PSD, PSO, and Domain Owner Assessment Policy
DMARCbis introduces three terms that RFC 7489 left undefined or only implied.
Public Suffix Domain (PSD): A domain name that exists at the top of the DNS tree before any registrant-controlled suffix. Common public suffixes include .com, .net, .org, and country-code TLDs. The concept was used in RFC 7489 but never formally defined as a named term.
Public Suffix Operator (PSO): The organization that manages a public suffix. For .com that is VeriSign. For a country-code TLD it is the relevant national registry. DMARCbis formalizes the relationship between domain owners and PSOs in the policy discovery process.
Domain Owner Assessment Policy: This is the new formal name for what RFC 7489 simply called the "policy." The mechanism is unchanged. Domain owners specify how receivers should handle mail that fails DMARC validation. The name in DMARCbis is more precise and shows up consistently in the specification.
The np Tag: When None-Permissive Replaces p=none
RFC 7489 defines three policy tags: p=none, p=quarantine, and p=reject. DMARCbis adds a fourth: np, for "none-permissive."
The np tag behaves identically to p=none in terms of the signal it sends -- neither instructs receivers to take action against failing mail. The difference is in how receivers interpret the signal.
Under p=none, receivers may handle failing mail in any way they choose. Under np, receivers are told that the domain owner has made an explicit, deliberate choice not to enforce at this time. The practical difference is that np eliminates the ambiguity of p=none, which can look like an accidental or unconfigured record rather than an intentional monitoring setting.
If you are currently using p=none to monitor while preparing for enforcement, np gives you a more precise way to communicate that intent to receivers.
The pct Tag Is Gone
RFC 7489 introduced the pct tag to support gradual DMARC enforcement. A record like this:
v=DMARC1; p=none; pct=50; rua=mailto:reports@example.com
would apply DMARC policy to 50% of incoming mail. DMARCbis removes pct entirely. The reasoning is that selective percentage-based enforcement created unpredictable behavior and did not meaningfully improve deployment safety compared to simply running p=none.
If you have pct in any current DMARC records, DMARCbis-aware receivers will ignore the pct tag. The rest of the record continues to work. Any partial-rollout strategy built on pct should be treated as complete and the pct tag removed when you are ready.
How PSD and PSO Change Subdomain Policy Discovery
RFC 7489 describes a process for finding the applicable DMARC policy when a receiver checks an incoming message. The receiver walks up the DNS tree from the sender's domain looking for a DMARC record until it hits a public suffix.
DMARCbis formalizes this process and adds explicit PSO-controlled domain concepts. For most domain owners, subdomain inheritance behavior works the same way under both specifications. Where DMARCbis changes things is at the registry level. A public suffix operator can now publish a DMARC policy for its TLD that affects all second-level domains beneath it, in a way that RFC 7489 left ambiguous.
For the vast majority of commercial domain owners, this change will not affect your setup. If you manage a large TLD or operate at the registry level, DMARCbis gives you new tools to set policy for your entire namespace.
What DMARCbis Changes in Your Aggregate Reports
The DMARCbis draft updates the aggregate report format and adds guidance for report generators. The core data that aggregate reports carry stays the same: authentication results, policy decisions, and timing information. The changes are in how that data is formatted and what metadata is included.
DMARCFlow processes aggregate reports automatically and absorbs these format changes without manual reconfiguration. When DMARCbis finalizes and receivers begin emitting the updated report format, DMARCFlow handles the parsing in the background. That is the practical benefit of using a dedicated report consumer: the infrastructure tracks the standard as it evolves, and your monitoring does not interrupt.
What Does NOT Change in DMARCbis
The core DMARC mechanism is unchanged from RFC 7489:
- p=none, p=quarantine, and p=reject behave identically
- DKIM and SPF alignment checks work the same way
- The rua (aggregate report) and ruf (failure report) mechanisms are unchanged
- Relaxed vs strict alignment is unchanged
If you have a working DMARC record that uses p=quarantine or p=reject, that record continues to work under DMARCbis without modification.
DMARC Record Example: Before and After DMARCbis Adoption
Here is a typical RFC 7489 record:
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-failures@example.com; fo=1
Under DMARCbis, that record is still valid. If you want to adopt the np tag during your migration:
v=DMARC1; p=none; np=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-failures@example.com; fo=1
This tells receivers that you are in monitoring mode but have made an explicit choice, not an accidental p=none.
If you were using pct for gradual rollout and are now ready to enforce fully, drop pct and go straight to:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com
DMARCbis FAQ
When should I migrate to DMARCbis?
When your current RFC 7489 record is working reliably and you understand which new tags apply to your situation. If you are using pct, plan to remove it. If you are using p=none for monitoring, consider whether np=none communicates your intent more precisely to receivers.
Will my current DMARC record stop working?
No. All p=none, p=quarantine, and p=reject records continue to work under DMARCbis. The pct tag will be ignored by DMARCbis-aware receivers, so any partial-rollout strategy built on pct should be resolved before treating that migration as complete.
Does DMARCbis require DKIM2?
No. DKIM2 is a separate standards effort. DMARCbis does not mandate DKIM2 adoption.
Is DMARCbis final?
No. It is an IETF draft (draft-ietf-dmarc-dmarcbis-41, April 2025). Treat it as a working document. The specific tag changes described in this post are stable features of the current draft, but the specification itself may still change before publication.
Will receivers enforce DMARCbis immediately?
No. Like any email authentication standard, receiver adoption is gradual. Monitor your aggregate reports for changes in how receivers handle your mail during the transition period. DMARCFlow will show any shifts in authentication result patterns that may indicate receiver-side updates.
Does DMARCFlow support DMARCbis?
DMARCFlow processes aggregate reports and continues working without changes to your DMARC record. As receivers update to handle DMARCbis format reports, DMARCFlow parses the updated format automatically.