DMARCbis is Coming. What’s Changing?

The Domain-based Message Authentication, Reporting and Conformance protocol (DMARC) has long guarded our email servers and authenticated our messages, ensuring that emails worldwide reach their intended inboxes undoctored and without embedded threats. First published as RFC 7489, it’s been a necessary aspect of email security for what is still the most effective and popular forms of communication, and now it’s seeing one of the most significant updates in its history in the form of DMARCbis.  

DMARCbis is no replacement, but instead a streamlined and simplified update that is one track to be published as a proposed standard as the industry evolves and becomes more aware of email-based threats and the need for authentication. If your organization is already using DMARC, the good news is that your security will remain intact; DMARC is just as effective as it’s always been. Yet if you’re just getting started, DMARCbis will serve as a means to clarify the standard overall.

In this article, we’ll discuss what’s changing, what it means for your organization, and how you can prepare for potential changes to DMARC in the near future. If you’re just getting started with DMARC, EasyDMARC is a leading provider of DMARC solutions for business.

DMARCbis vs DMARC Key Takeaways

• General restructuring for the purposes of clarity and accessibility, with more guidelines and easier definitions. 
• A new section has been added called “conformance requirements for full DMARC participation.” This is designed to help domain owners and email receivers follow best DMARC practices. 
• Some tags removed from DMARC policy record, including pct, rf, and ri. Some tags added, including np, psd, and t. These are not considered breaking changes, and will not result in DMARC2; Records will continue to start with v=DMARC1.
• The Public Suffix List mechanism will be replaced with the DNS Tree Walk algorithm. 
• Aggregate reporting is more strict and the XML report format will now incorporate new record tags. They will also acknowledge real-world practices. 
• The indirect email flows issue remains unsolved. DMARCbis discourages a reject policy in the event of mailing lists being used as recipients. 

DMARCbis Structuring, Definition, and Requirements

The DMARCbis draft builds on the original RFC 7489 version, but has been reorganized for better clarity. It includes improved examples, clearer explanations, and more practical implementation guidance.

The updated specification is now divided into three separate documents, each published as its own RFC:

• The main DMARC specification
• The aggregate reporting specification
• The failure reporting specification

Several definitions have also been refined or newly introduced. For example:

• The “DMARC policy” is now formally referred to as the Domain Owner Assessment Policy.
• A policy of “none” is now described as Monitoring Mode, while active policies are referred to as Enforcement Mode.
• The term Report Receiver has been replaced with Report Consumer.

Conformance Requirements for Full DMARC Participation

Newly added section 8 defines how domain owners and mail receivers authenticate and process email messages. While both parties have flexibility in how they apply the mechanism, full participation requires meeting specific technical requirements.

For Domain Owners, full participation means:

• Sending messages that produce an SPF-authenticated identifier aligned with the Author Domain.
• Signing messages with a DKIM domain that generates a DKIM-authenticated identifier aligned with the Author Domain.
• Setting up and maintaining a mailbox to receive aggregate reports, and reviewing those reports regularly to track authentication results.
• Publishing a DMARC policy record for the Author Domain and, if applicable, for the Organizational Domain when they differ.
• Avoiding reliance on SPF alone for a DMARC pass when the policy for the Author Domain is set to “p=reject.”

For Mail Receivers, full participation means:

• Checking for a DMARC policy record on each inbound message’s Author Domain to determine whether DMARC validation applies.
• Verifying the presence of authenticated identifiers (SPF and DKIM) and preserving the results for use in reporting.
• Performing identifier alignment checks when applicable to determine whether authentication aligns with the Author Domain.
• Using the results of these checks to determine whether the message passes or fails DMARC validation.
• Supporting the “mailto:” URI scheme to send requested reports.
• Sending aggregate reports at least once per day.
• Avoiding rejection of messages solely because the Author Domain’s policy is set to “p=reject.”

DMARC Tag Removals, Changes, and Additions

Several tags have been added, replaced, or removed to help with consistency, patch security for modern attack vectors, and streamline deployment. 

np Added

The proposed np tag works similarly to the existing p and sp tags, but it specifically applies to non-existent subdomains.

Cybercriminals often attempt to bypass DMARC protections by sending emails from subdomains that don’t actually exist under a legitimate domain. By setting the np tag to an enforcement value such as quarantine or reject, domain owners can block these fraudulent messages before they reach recipients. This ensures that even fake or unused subdomains are protected under the organization’s DMARC policy. 

pct Replaced With t

The pct tag in DMARC controls message sampling and lets receivers apply policy enforcement to a portion of messages. However, it often caused confusion about how percentages were calculated and was rarely used correctly. In most cases, administrators set pct=0 or pct=100, treating it as an on-or-off setting instead of a gradual control.

Because of these inconsistencies, the DMARCbis draft removes pct and introduces a simpler t tag with two values:

• t=y means testing mode, equal to pct=0
• t=n means full enforcement, equal to pct=100

This change has sparked discussion within the community. Some experts, including Wei Chuang from Gmail, questioned whether removing pct is worth the confusion it might create, since it is already widely used. For now, both tags are expected to coexist until the new approach becomes standard practice.

rf and ri Removed

The rf and ri tags are being removed in the DMARCbis draft. According to RFC 7489, rf defines the format used for failure reports, with afrf as the only supported option. The ri tag specifies the reporting interval in seconds for generating aggregate reports.

If these changes are approved, the impact will be minimal. Since afrf is already the standard format and most domains receive daily aggregate reports by default, reporting behavior will remain the same for the vast majority of implementations.

psd Has More Control of Discovery Algorithm

A known limitation of DMARC is that it does not allow Public Suffix Domain (psd) owners to fully benefit from the protocol unless they use experimental extensions.

An example of this limitation can be found in gov.uk, which functions both as the UK Government’s domain and as a type of Top-Level Domain, since subdomains can be registered upon request. Because it appears in public suffix lists, DMARC cannot apply policies to its subdomains. A Public Suffix Domain cannot be treated as an Organizational Domain, which limits protection.

DMARCbis updates the algorithm used to determine the Organizational Domain. It now partly depends on a new psd tag, which can have the following values:

• y – the domain is a Public Suffix Domain, and its subdomains are considered Organizational Domains.
• n – the domain is not a Public Suffix Domain but acts as the Organizational Domain for itself and its subdomains.
• u – the default. The Organizational Domain is determined using the DNS Tree Walk method.

DNS Tree Walk in, Public Suffix List out

Determining the Organizational Domain is a key part of DMARC. It serves two main purposes:

1. Finding the DMARC policy record when the From domain does not publish one.
2. Checking whether SPF or DKIM domains are aligned in relaxed mode.

Under RFC 7489, this process relied on public suffix lists to identify the highest registrable domain in the hierarchy, but these lists are community-maintained and not always reliable, which limited their accuracy.

DMARCbis replaces that system with a new approach called the DNS Tree Walk. This algorithm queries parent domains step by step until it finds a DMARC record, with a maximum of eight queries to reduce DNS load. Some intermediate domains may be skipped.

The Organizational Domain is determined as follows:

1. If a DMARC record with psd=n is found, that domain is the Organizational Domain and the process stops.
2. If a record with psd=y is found, the domain is a Public Suffix Domain, and the Organizational Domain is the level directly below it.
3. If neither condition applies, the shortest domain with a valid DMARC record is selected.
   

This mechanism is more flexible than the public suffix approach and allows organizations with complex DNS structures to manage DMARC policies more effectively through the psd tag. In most cases, adding the tag will not be necessary. When relaxed alignment is used, the same algorithm applies to each domain involved in SPF and DKIM alignment checks.

Because the DNS Tree Walk can produce different results than the public suffix method, inconsistencies may occur across implementations. The DMARCbis draft addresses this concern, saying that “this issue is entirely avoided by the use of Strict Alignment and publishing explicit DMARC Policy Records for all Author Domains used in an organization’s email.”

While strict alignment may not work for every setup, it remains a strong recommendation for consistent DMARC performance across all domains.

DMARCbis Adoption: Should you Avoid p=reject?

One of the main goals of the DMARCbis working group was to address the long-standing problem of indirect email flows, particularly forwarding and mailing lists.

When an email is forwarded, SPF and DKIM checks often fail. SPF fails if the forwarder is not listed in the sender’s SPF record. Even with the Sender Rewrite Scheme (SRS), alignment breaks and DMARC fails. DKIM can fail when mailing lists modify the message, for example by adding a footer or changing the subject.

If the message remains unchanged, DKIM can still pass, which is why DMARCbis emphasizes that “domains publishing p=reject must not rely only on SPF and must apply valid DKIM signatures to their messages.”

However, when mailing lists are involved, both SPF and DKIM often fail. This can cause messages from domains with a p=reject policy to be rejected entirely, sometimes leading to users being automatically unsubscribed from lists that see the rejections as delivery failures.

Attempts to solve this problem have included Authenticated Received Chain (ARC), which preserves authentication results during forwarding, and the upcoming DKIM2 standard, which aims to recover signatures altered in transit. Both remain experimental, and no universal solution exists yet. 

Because of this, the working group debated whether to discourage the use of p=reject for general-purpose domains. Some experts argued that strict enforcement can harm mailing list interoperability, while others pointed out that major providers such as Yahoo and Gmail already use p=reject to protect billions of inboxes.

The final consensus recognizes both perspectives. DMARCbis warns that p=reject can cause interoperability issues and provides guidance to help organizations minimize disruption.

Domains whose users post to mailing lists should not publish p=reject. Before enforcing rejection, domains should analyze aggregate report data, first testing with p=none for about a month, then p=quarantine, and comparing message outcomes. Domains that still choose p=reject should either prevent users from posting to mailing lists or warn them that list participation may be affected.

To reduce false rejections, DMARCbis recommends that mail receivers not reject a message solely because the sending domain uses p=reject. They should consider additional context, such as sending patterns and content analysis. If there is no clear evidence, the message should be treated as if the policy were p=quarantine instead.

This balanced approach aims to preserve both security and deliverability, giving senders and receivers clearer guidance for handling complex forwarding and mailing list scenarios.

DMARCbis Adoption: Changes in Aggregate Reporting

DMARC aggregate reporting has undergone several small adjustments in DMARCbis. The reporting mechanism itself remains unchanged, and the format stays backward compatible, but it is now documented in a dedicated specification with clearer definitions and formatting improvements.

Key Aggregate Reporting Updates Under DMARCbis

• The rua tag can still contain multiple URIs, but the requirement that receivers must support sending to at least two addresses has been removed.
• With the ri tag removed, reports are now sent daily or more frequently, and the reporting interval can no longer be customized.
• The option to set a size limit for reports in the rua tag has been removed.
• The XML schema has been updated:
  • Reporters must use the media types application/gzip or text/xml for attachments.
  • Reporters must construct attachment filenames and email subjects using the specified formats.
  • External destination validation is now mandatory, ensuring that third-party report recipients are properly verified.
• In report_metadata, a new optional generator field identifies the reporting software, and the error field is now limited to one entry.
• In policy_published, new optional fields include testing (y or n), discovery_method (psl or treewalk), and np. The sp field is now optional.
• The policy override reason can now include policy_test_mode, while forwarded and sampled_out have been removed.
• In policy_evaluated, pass is now an accepted value for disposition.
• Within authentication results:
  • envelope_from is now optional.
  • SPF results and scope are optional and limited to one occurrence.
  • The SPF result can take the value policy, as defined in RFC 8601.
  • A new human_result field has been added for SPF, with an optional lang attribute (defaulting to English).
• A recommended limit of 100 DKIM signatures per row has been added, and the selector field is now mandatory.
• The version field is optional, though versioning discussions are ongoing.
• The schema now supports extensions.
• The XML root element includes new targetNamespace and xmlns attributes.
• A new security consideration addresses potential feedback leakage caused by the updated policy discovery algorithm.
• Reports that do not conform to the schema should be discarded by receivers, although partial data recovery is permitted.

These refinements are designed to improve clarity, interoperability, and validation across reporting implementations while maintaining compatibility with existing DMARC reporting systems.

Failure Reporting Stays the Same

The failure reporting mechanism in DMARC remains the same in the DMARCbis draft. However, the document now notes that failure reports are rarely used due to privacy concerns and clearly explains the risks involved, such as potential exposure of message content or personal data within the reports.

DMARC Adoption: Clarity, Not Revolution

The arrival of DMARCbis marks an important milestone in the evolution of email authentication. Rather than replacing the existing DMARC standard, it refines and modernizes it, ensuring that policies are clearer, definitions are consistent, and the framework aligns better with today’s email infrastructure.

For most organizations, this change will not require rebuilding existing DMARC setups. Instead, it provides a stronger foundation for improving visibility, reporting accuracy, and interoperability across domains.

As DMARCbis moves closer to finalization, the best next step is preparation. Review your current DMARC configuration, check your records with a DMARC Lookup tool, and make sure your policies and reporting workflows are functioning correctly.

DMARCbis represents clarity, not disruption. It helps domain owners and receivers alike work from the same playbook to strengthen global email security.

Frequently Asked Questions