DMARCbis Explained: What Changed in the New DMARC Specification

What Is DMARCbis?

DMARCbis is the updated version of the DMARC email authentication specification, formally known as draft-ietf-dmarc-dmarcbis. It is currently a working IETF draft at version 41, published in April 2025, and will eventually replace RFC 7489 when it reaches full standard track status.

RFC 7489 has been the basis for DMARC email authentication since March 2015. DMARCbis does not introduce radical changes to how DMARC works, but it clarifies ambiguities in the original spec, adds new tags for previously uncovered use cases, and removes tags that caused problems in practice.

If you already run a DMARC record, most of what you are doing today still applies. The update is a refinement, not a rewrite. That said, if you are using the pct tag, you need to remove it. And reviewing your DMARC reports after any record change is good practice whether or not DMARCbis is involved. That is where DMARCFlow fits naturally: keeping your DMARC monitoring active while you make infrastructure changes.

What Is New in DMARCbis

DMARCbis introduces several new tags and clarifications that were not explicitly covered in RFC 7489.

The np tag (none-permanent) is the most notable addition. It allows domain owners to specify a policy for messages that fail DMARC authentication where the failure is considered non-permanent in nature. This gives receivers more nuanced guidance about how to handle specific failure types, rather than applying the same rejection or quarantine rule to all failures.

The specification also formalizes concepts that were previously described only in implementation notes. Domain Owner Assessment Policy replaces the vague concept of a published DMARC policy as simply "what to do with failing mail." The updated spec makes clearer that this is an explicit policy choice by the domain owner, not just a technical configuration.

PSO (Public Suffix Operator) actions are now more explicitly defined. When a Public Suffix Operator publishes a DMARC policy, the updated spec clarifies how that policy interacts with subdomain owners beneath it. This matters for large hosting providers, government domains, and other multi-tenant domain structures where the public suffix operator and the domain owner below it may have different authentication postures.

Reporting has been updated with clearer guidance on aggregate report formats and failure report handling. Report generators are now expected to include more consistent data fields, which should make cross-vendor DMARC reporting more usable in practice. DMARCFlow has tracked these evolving reporting standards over time and updates its report parsing as receiver implementations change.

What Was Removed: The pct Tag

The pct tag (percentage tag) has been removed from DMARCbis. This was a tag in the original RFC 7489 that allowed domain owners to specify that a policy should only apply to a percentage of messages, for gradual rollout of strict DMARC enforcement.

RFC 7489 included pct as a way to test DMARC policies without immediately affecting all mail flow. In practice, it created problems. Receivers had to selectively apply policy based on a random percentage calculation, which meant the same message might be treated differently depending on which receiver processed it. It also made DMARC compliance unpredictable for senders who thought they were testing with 10 percent of traffic but were actually rejecting a much larger portion due to how receivers handled the calculation.

Appendix A.6 of DMARCbis explicitly documents the removal of pct, citing these interoperability and predictability issues. If you currently have a pct tag in your DMARC record, DMARCbis-compliant receivers will ignore it. For testing purposes, the recommended approach now is to use monitoring mode (v=DMARC1; p=none) and gradually move to quarantine or reject across your entire mail stream, not a percentage of it.

DKIM2 and What It Means for Email Signers

DKIM2 is a separate specification from DMARCbis, but the two are often discussed together because they both update how email authentication works.

DKIM (DomainKeys Identified Mail) is the underlying signing mechanism that DMARC validates. The original DKIM spec (RFC 6376) used 1024-bit RSA keys, which were considered secure in 2011 when the standard was written. DMARCbis does not directly update DKIM, but the broader email authentication community has moved toward longer key sizes as computational attacks on 1024-bit RSA have become more practical.

DKIM2 updates key size requirements and signing practices. The main practical change for email senders is that DKIM2 expects or requires keys longer than the original 1024-bit minimum. Longer keys are more secure but also increase DNS record size and processing overhead. Email systems that generate DKIM signatures need to be updated to produce DKIM2-compliant signatures.

For DMARC purposes, DKIM2 signatures are compatible with existing DMARC processing. A DMARC pass still means the message had a valid DKIM signature from an aligned domain. The difference is in what the signing system produces. If you run your own DKIM signing infrastructure, you need to verify that your DKIM generator supports DKIM2 key sizes and signing algorithms. If you use a third-party sending platform, check whether they have announced DKIM2 support timelines.

How to Audit Your DMARC Record for DMARCbis Compliance

Auditing your record for DMARCbis compliance means checking what you currently publish and comparing it to what the new spec expects.

Start by fetching your DMARC record:

dig TXT _dmarc.yourdomain.com +short

Or use an online DMARC checker. Your current record probably looks something like:

v=DMARC1; p=reject; rua=mailto:reports@example.com; ruf=mailto:failures@example.com; pct=100

Check each tag in your record against the DMARCbis specification. The pct tag, if present, will be ignored by DMARCbis-compliant receivers. The recommended action is to remove it entirely rather than leaving it in the record.

Verify that your rua and ruf email addresses are correctly formatted and actively monitored. DMARCbis places more explicit requirements on report generators, which means you may receive reports in a slightly different format than before. This is one area where using a DMARC reporting tool like DMARCFlow avoids the need to update your own parsing logic every time the spec changes.

If you are using third-party email senders, verify that they are DKIM signing with aligned domains. DMARCbis does not change alignment requirements, but clearer terminology around aligned domains in the new spec makes it easier to diagnose alignment failures when they occur.

Step-by-Step DMARC Record Migration

Here is a practical sequence for updating your DMARC record to DMARCbis compliance.

Step 1: Document your current record. Before changing anything, capture your existing DMARC record and the last set of aggregate reports. You want a baseline. DMARCFlow stores your historical reports, so you can compare before and after any change.

Step 2: Remove the pct tag. If your record has pct=X, remove that tag entirely. DMARCbis-compliant receivers will ignore percentage-based policies. If you need to test enforcement, move to p=none, monitor for a period, then switch to p=quarantine or p=reject for all traffic.

Step 3: Verify DKIM alignment. Check that every legitimate sending source DKIM-signs with a selector domain that matches your organizational domain. Third-party ESPs, marketing platforms, and cloud productivity suites should all be signing with your domain, not their own. DMARCFlow flags misaligned sending sources automatically, which is faster than cross-referencing manually.

Step 4: Review your policy. If you are still at p=none (monitoring), set a calendar reminder to move to p=quarantine after you have resolved any DKIM or SPF alignment issues shown in your aggregate reports. Staying at p=none indefinitely means you are not actually using DMARC to protect your domain from impersonation.

Step 5: Update report destinations. Make sure your rua and ruf addresses are current and that someone reviews the aggregate reports regularly. DMARCFlow processes these reports automatically and surfaces alignment failures and policy issues in a dashboard, which removes the need to parse raw XML reports by hand.

Step 6: Publish and monitor. Push your updated record and watch your aggregate reports for the first two weeks. Look for legitimate mail sources that are suddenly failing DMARC. These are usually sending systems that were not properly DKIM-aligned. DMARCFlow alerts on new failure patterns so you catch problems before they become email delivery incidents.

DMARCbis Adoption Timeline

DMARCbis is currently an IETF draft at version 41. It has been in development since at least 2020 and has gone through substantial revision. The timeline for reaching full standard track status depends on IETF working group consensus and a final vote.

Major email receivers (Google, Microsoft, Yahoo) have already updated their DMARC processing to handle aspects of the new specification, particularly around reporting formats and PSO policy handling. If you run a receiving MTA, now is the time to audit your DMARC processing against the current draft.

For senders, the practical recommendation is to audit your record now. There is no need to wait for the final RFC to be published. Removing pct and verifying DKIM alignment are changes that improve your security posture regardless of whether DMARCbis is final.

Frequently Asked Questions

Is DMARCbis backward compatible?
Yes. DMARCbis-compliant receivers will process records that follow RFC 7489 without issues. The main incompatibility is the pct tag, which DMARCbis-compliant receivers will ignore rather than honor.

Do I need to change my DKIM keys for DMARCbis?
If you are asking about DMARCbis specifically, no. DMARCbis does not mandate new DKIM key sizes. However, if you want your DKIM implementation to be current with DKIM2, you should plan for longer key sizes. Check with your email platform or DKIM signing software for DKIM2 support timelines.

What happens to mail from domains that still use pct?
Receivers implementing DMARCbis will ignore the pct tag. This means if you have pct=10, the receiver will apply your full policy (p=reject, for example) to all messages, not just 10 percent. If you rely on pct for gradual rollout, you need to change your approach.

When will DMARCbis be final?
It is not final yet. The current draft expires October 2025. The specification could advance to standard track in the next revision cycle, but exact timing depends on IETF process. Watch the IETF datatracker for current status.

Is DMARCFlow compatible with DMARCbis?
Yes. DMARCFlow processes DMARC aggregate and failure reports according to current standards. As DMARCbis is finalized, DMARCFlow will be updated to support the new reporting formats and tags. Existing DMARCFlow users do not need to change their DMARC records specifically for DMARCFlow compatibility, and DMARCFlow will continue to flag alignment issues and policy changes regardless of which RFC their receiver is using.

Bottom Line

DMARCbis refines DMARC rather than replacing it. The most important practical change for most domain owners is removing the pct tag. If your DMARC record has pct in it, take it out now. Beyond that, verify your DKIM alignment, make sure your aggregate reports are being reviewed, and keep an eye on the IETF draft progress for any changes that affect your specific setup.

Monitoring your DMARC reports is the part that most people skip, and it is also the part that catches problems before they become email delivery incidents. DMARCFlow handles the report parsing and alerting so you can focus on the actual DNS changes.