DMARCbis: What the RFC Update Means and When to Adopt

What Is DMARCbis?

DMARCbis is the informal name for the updated RFC that revises DMARC (Domain-based Message Authentication, Reporting, and Conformance), originally defined in RFC 7489. The update has been in development for several years and addresses specific gaps that practitioners have encountered since DMARC was deployed at scale.

The most visible change is a new policy tag called "np", which stands for none-permissive. This article breaks down what it actually does, which parts are already live in receivers, and what you should do today versus what can wait.

The "np" Tag: None Permissive

The headline addition in DMARCbis is the np tag. It sits alongside the existing p tag in a DMARC record and specifies what happens to mail from servers that are not aligned with the sending domain.

The current p=none tells receivers to take no action on mail that fails DMARC. The new p=np tells receivers to reject mail from servers that are not explicitly authorized, even when that mail passes SPF on the third party's own infrastructure.

This distinction matters in one specific scenario: when a third-party sender is legitimately passing SPF on their own infrastructure but is not authorized to send on your domain's behalf.

Under p=none, that mail appears in your aggregate reports as a DMARC failure but no action is taken at the receiving server.

Under p=np, the same mail gets rejected. The policy tells receiving servers: any server that is not explicitly authorized for this domain should be rejected, not silently accepted.

The use case is stricter subdomain control. If you only want mail to come from your own mail servers and explicitly authorized third parties, p=np enforces that. It is a more surgical version of p=reject for organizations that need to block specific relay paths without blanket rejection.

The DNSSEC Problem Nobody Talks About Yet

Here is where DMARCbis gets complicated before it even ships at scale.

When a domain has DNSSEC enabled, DNS lookups for non-existent DMARC records return NOERROR with NODATA rather than NXDOMAIN. DMARC processors need to handle this distinction correctly to determine whether a DMARC record actually exists.

The np tag creates a known edge case: if a subdomain has no DMARC record at all and DNSSEC is enabled, some DMARC processors have been found to misinterpret the NODATA response as an affirmative policy instruction rather than a signal that no policy exists. The result is unexpected rejections of mail that should not be subject to DMARC enforcement at all.

This is not theoretical. It has been documented in DMARC working group discussions and is one reason practitioners recommend testing np tag behavior against your specific receiver set before broad deployment.

Receiver Support: Not There Yet

The honest answer to "should I adopt DMARCbis now?" is: your record can include DMARCbis syntax, but most major receivers have not fully updated their DMARC processing engines yet.

Google and Yahoo updated their DMARC processors for their bulk sender requirements in 2024, but those updates were focused on aggregate report formats and SPF/DKIM requirements. Microsoft Exchange Online processes p=reject and p=none correctly but np tag handling is a separate code path that has not been broadly tested across all receiver scenarios.

Your DMARC record will not break if you add np today. Receivers that do not recognize it will ignore it. But you will not get the enforcement behavior either.

The risk is asymmetric: adding np to a record that is otherwise p=none gives you nothing from uncooperative receivers, but may create unexpected rejections if a receiver interprets the tag incorrectly and applies strict policy when it should not.

What to Do Today

Here is a practical checklist for where you actually stand.

First, check your current DMARC record. If you are at p=none and using it as a monitoring step before moving to p=reject, DMARCbis does not change that process. Your record is already doing what you need it to do.

Second, if you are considering np for new subdomains, test it against a small volume first. Send test messages from the specific third-party senders you are trying to block and verify that receivers treat them as expected before rolling it out domain-wide.

Third, watch your aggregate reports. The DMARCbis np tag does not change report formats, so your existing reporting pipeline continues to work. Any new rejection patterns in your aggregate reports after adding np are worth investigating before you expand usage.

Fourth, do not rush. The standards process exists to catch edge cases. The DNSSEC interaction issue alone is enough reason to wait for receiver implementations to catch up rather than pioneering the np tag in production.

How DMARCFlow Tracks Your DMARC Readiness

This is where monitoring earns its place.

DMARCbis adoption readiness is not a one-time configuration decision. It is an ongoing process of checking whether your receivers are processing your DMARC record the way you expect, whether new rejection patterns appear in your aggregate reports after you change your policy, and whether the third-party senders you rely on are still passing DMARC alignment as their infrastructure evolves.

DMARCFlow monitors your DMARC records continuously and surfaces changes in your aggregate report data. If you move to np and third-party mail starts failing that was previously passing, DMARCFlow flags the pattern before your users start reporting bounces. That is the practical value: not a configuration wizard, but the signal that something has changed in how your domain is being evaluated.

For organizations that want to prepare for DMARCbis without running blind, that visibility is the actual benefit.

FAQ

Is my current DMARC record still valid under DMARCbis?
Yes. Existing p=none, p=quarantine, and p=reject records continue to work exactly as before. DMARCbis adds new syntax; it does not deprecate the existing p tag values.

Does DMARCbis affect SPF or DKIM?
No. SPF and DKIM are separate RFCs. DMARCbis changes only how DMARC-aligned authentication results are interpreted and enforced.

When will Google and Yahoo require DMARCbis?
There is no announced deadline. The bulk sender requirements introduced in 2024 did not reference DMARCbis. Any future requirement would likely be announced with a transition period.

Can I use the np tag today?
Yes, syntactically. Your DNS provider must allow the tag in your record. Whether receivers enforce it depends on their DMARCbis implementation. Start with low-volume testing before broad deployment.

What is the difference between p=none and p=np?
p=none tells receivers to accept unauthenticated mail and include it in reports. p=np tells receivers to reject mail from servers that are not explicitly aligned, treating unaligned mail as a policy violation rather than a reporting event.

Does the np tag replace p=reject?
No. p=reject is still the strongest policy for domains that want all unauthenticated mail blocked. np is a more targeted option for domains that want to enforce alignment strictly without moving to full reject, often used during a migration or for subdomains with specific third-party senders.