DMARCbis Overview

Welcome to the DMARCbis documentation section. Here you'll find an overview of DMARCbis, the most significant update to the DMARC standard since it was first published.

What is DMARCbis?

DMARCbis is a revision of DMARC (Domain-based Message Authentication, Reporting, and Conformance). The "bis" designation follows standard naming conventions for protocol revisions.

The original DMARC specification (RFC 7489) was published in 2015 as an "Informational" document, whereas DMARCbis has been released as a "Proposed Standard." This raises DMARC's formal status to that of a proven, widely-adopted email authentication protocol, building on more than a decade of deployment experience.

DMARCbis strengthens the original standard by:

• Splitting the specification into clearer, more detailed drafts with additional examples
• Improving how organizational domain boundaries are determined, using DNS-native lookups instead of a manually maintained list
• Simplifying policy tags by removing inconsistent legacy elements
• Increasing reporting requirements for better visibility and security

Critically, DMARCbis maintains backward compatibility. It continues to use v=DMARC1 as the version identifier, so existing DMARC records remain valid without any immediate changes. Organizations can adopt the new features progressively.

Key Changes in DMARCbis

Restructured Specification

The updated standard is split into three separate drafts:

• Core protocol: defines the DMARC fundamentals
• Aggregate reporting: describes how daily reports are generated and formatted
• Forensic reporting: details how authentication failure information is reported

This split makes the standard easier to understand, implement, and maintain over time.

DNS Tree Walk Algorithm

The most significant technical change replaces the Public Suffix List (PSL) with a DNS Tree Walk algorithm for finding a domain's organizational boundary.

Instead of relying on a manually maintained public list, a receiver queries successive levels of the domain hierarchy, moving up one label at a time, until it finds a DNS record marked psd=y (a public suffix domain) or psd=n (an organizational boundary).

• The walk is capped at eight levels to prevent excessive DNS queries.
• For domains with eight or more labels, the leftmost labels are removed until seven remain before the walk begins.
• The walk stops as soon as it finds a valid DMARC record with an explicit psd value.

This DNS-native approach removes the dependency on a third-party list, making it more likely that boundary changes are picked up consistently and improving the accuracy of domain boundary detection overall.

Note: During the transition, some receivers may still use the PSL while others use the Tree Walk, which can occasionally produce different results for the same domain. Publishing an explicit DMARC record on every domain and subdomain, including a psd tag where relevant, avoids ambiguity.

New Policy Tags

DMARCbis introduces three new tags for finer-grained control:

Tag	Purpose
psd (Public Suffix Domain)	y marks the domain as a public suffix domain, n marks it as an organizational domain. The default, u, leaves it to the Tree Walk to determine.
np (Non-Existent Subdomain Policy)	Sets the policy applied to email claiming to come from a subdomain that doesn't exist in DNS, closing a spoofing gap where attackers use fabricated subdomains such as ceo.example.com.
t (Testing Mode)	Signals that a policy is being trialled and not yet enforced (y), or applied as normal (n, the default).

Deprecated Legacy Tags

Three tags have been discontinued because they produced inconsistent results across receivers:

• pct (percentage): superseded by the clearer t (Testing Mode) tag
• rf (report format)
• ri (report interval): reporting cadence is now uniformly defined instead of being configurable

These tags are still published where set, for backwards compatibility, but DMARCbis-aware receivers will increasingly rely on their replacements instead.

Enhanced Reporting

Aggregate and forensic reporting now each have their own specification draft, with stricter requirements for consistency and security:

• Mandatory validation of external reporting addresses (the rua=/ruf= recipient must authorize reports sent outside the sending domain)
• Standardized attachment formatting and naming conventions
• Stricter enforcement of XML structure and gzip compression

Guidance on Mailing Lists

DMARCbis provides explicit guidance on mailing lists and forwarded mail. It discourages publishing a p=reject policy where mailing lists are part of the normal mail flow, since list software frequently breaks both SPF and DKIM alignment, which can cause legitimate messages to be rejected.

At the same time, DMARCbis continues to encourage domain owners to work toward a p=reject policy wherever feasible, since it's the only policy that fully protects a domain against unauthorized use. The recommendation is to evaluate your mail ecosystem, including any mailing lists, before moving to strict enforcement.

Key Benefits

• More accurate organizational domain detection via the DNS Tree Walk algorithm
• Simpler, clearer policy tags with unambiguous testing signals
• Stronger protection against spoofing of non-existent subdomains
• Better support for complex domain structures and public suffix domains
• Improved reporting consistency and security
• No forced migration: existing records stay valid while you adopt new features at your own pace

FAQs

Do I need to change my current DMARC record for DMARCbis?

No immediate changes are required. DMARCbis keeps the same version identifier (v=DMARC1), so existing records remain valid. You can adopt the new tags progressively to strengthen your email authentication over time.

How does the DNS Tree Walk improve on the Public Suffix List?

Instead of relying on a manually maintained list of public suffixes, the Tree Walk queries DNS directly, moving up through the domain hierarchy to identify the correct organizational boundary. This is more consistent, since it doesn't depend on a third party keeping a list up to date.

Should I set a p=reject policy now that DMARCbis discourages it for mailing lists?

DMARCbis doesn't discourage p=reject outright: it advises caution specifically where mailing lists are part of your mail flow, since they can break SPF/DKIM alignment. Review how your domain's mail is actually sent and forwarded before moving to strict enforcement.

Related Topics

• DMARC Overview: Introduction to DMARC and its purpose
• DMARC Syntax: Detailed information about DMARC DNS record fields
• DMARC Settings: Configure DMARCbis tags such as Testing Mode and Non-Existent Subdomain Policy