DMARCbis Unveiled Featuring a New DNS Tree Walk Algorithm and More

The Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol stands as a cornerstone of modern email security, essential for protecting organizations against phishing, spoofing, and other email-borne threats. Now, this vital protocol is undergoing its most significant evolution yet with the introduction of DMARCbis. This next-generation revision builds upon the robust foundation of the original protocol, introducing enhancements designed to improve clarity, bolster security, and offer greater flexibility for domain owners.

At the heart of DMARCbis’s transformative changes is the replacement of the rigid **Public Suffix List (PSL)** with an innovative, dynamic, and DNS-native discovery mechanism: the **DNS Tree Walk Algorithm**. This fundamental shift redefines how the “Organizational Domain” is determined, a critical component for both DMARC policy discovery and accurate identifier alignment. This article will delve into the intricacies of DMARCbis, focusing on the revolutionary DNS Tree Walk Algorithm and the new tags that empower domain owners with unprecedented control over their email authentication policies.

---

Understanding the Shift: Why the DNS Tree Walk Algorithm is Essential

For years, the current DMARC standard (RFC 7489) has relied on the **Public Suffix List (PSL)** to identify the **Organizational Domain**. The Organizational Domain is essentially the highest-level domain an organization owns and controls, such as example.com when an email originates from mail.example.com or alerts.example.com. The PSL is a community-maintained list of domain suffixes (like `.com`, `.co.uk`, `.org`, `.app`, etc.) used to prevent malicious actors from registering subdomains of public suffixes and claiming them as their “organizational domain.”

While the PSL served its purpose, it presented several inherent challenges:

• Inconsistency and Latency: As a manually maintained list, the PSL often lagged behind new TLDs (Top-Level Domains) or unique domain structures. Updates required manual intervention and distribution, leading to potential inconsistencies across different DMARC implementations.
• Complexity for Edge Cases: Determining the organizational boundary for complex or non-standard domain structures could be ambiguous, leading to configuration headaches and potential policy misinterpretations.
• External Dependency: Relying on an external list introduced an additional point of failure and removed some control from domain owners over how their organizational boundaries were defined.

DMARCbis addresses these limitations head-on with the **DNS Tree Walk Algorithm**. This innovative algorithm offers a flexible, real-time, and decentralized method to determine the organizational boundary directly through DNS records. By making this process native to DNS, DMARCbis significantly enhances the reliability and accuracy of DMARC policy enforcement.

---

How the DNS Tree Walk Algorithm Functions

The DNS Tree Walk Algorithm introduces a hierarchical, iterative process for discovering the applicable DMARC policy. This process ensures that the most specific and authoritative DMARC record is found, preventing misapplication of policies and enhancing email security. Here’s a detailed breakdown of how it works:

When a receiving mail server processes an incoming email, say from alerts.mail.example.com, and needs to retrieve the DMARC policy, the Tree Walk algorithm initiates a series of DNS lookups:

1. Initial Query (Most Specific): The algorithm begins by querying the exact, full domain level from which the email purports to originate. For our example, it would first look for a DMARC record at: _dmarc.alerts.mail.example.com. This ensures that any specific policy set for this exact subdomain is discovered first.
2. Progressive Traversal (Walking Up the Tree): If no valid DMARC record is found at the initial, most specific level, the algorithm “walks up” the domain hierarchy. It progressively removes the leftmost label of the domain and queries the parent domain for a DMARC record. This process continues iteratively:
   • It would next query for: _dmarc.mail.example.com
   • Followed by: _dmarc.example.com
   • …and so on, until a DMARC record is found or a boundary is detected.
3. Boundary Detection and Query Limit: The upward traversal stops under one of two conditions:
   • Explicit Boundary: A DMARC record is found that explicitly defines an organizational boundary using the new psd tag (which will be explained in detail below). This tag allows domain owners to precisely dictate where their organizational domain ends.
   • Predefined Query Limit: To prevent potential DNS amplification attacks and ensure efficiency, the algorithm has a maximum query limit (typically 8 queries). If no DMARC record or explicit boundary is found after this many lookups, the process ceases, and the DMARC check might fail or default to a safe policy.

This DNS-native method ensures greater consistency, eliminates the reliance on an external list, and empowers domain owners to control their domain boundaries more effectively and in real-time. It’s a significant step towards a more robust and self-managed email authentication ecosystem.

---

Impact on Your DMARC Record: New Tags in DMARCbis

While DMARCbis is designed with backward compatibility in mind – meaning your existing v=DMARC1 record will still function – the new specification introduces several key tags that directly interact with the DNS Tree Walk algorithm and enhance policy definition capabilities. Understanding these new tags is crucial for optimizing your DMARC implementation and maximizing its security benefits.

Important Note: Not all tags are relevant to every domain owner. For many organizations, particularly those with straightforward domain setups, the transition to DMARCbis will be a seamless process requiring minimal new tag definitions. The default Tree Walk logic often suffices.

1. The Organizational Boundary Tag: psd

The psd (Public Suffix Domain) tag is perhaps the most critical new addition, directly replacing the PSL’s function by allowing domain owners to explicitly define organizational boundaries within their DMARC record. This tag instructs the Tree Walk algorithm precisely where to stop its upward search.

Tag Value	Meaning	Implication for the Tree Walk
psd=y	Public Suffix Domain. This DMARC record is published on a Public Suffix (e.g., a country code TLD like .co.uk, or a shared service suffix like .github.io).	The organizational domain is considered one level below the domain where this record is found. This value is primarily for Public Suffix Operators.
psd=n	Organizational Domain. This DMARC record is published on the actual Organizational Domain itself (the root domain you own, e.g., example.com).	This domain is explicitly declared as the organizational boundary for itself and all its subdomains. The Tree Walk stops here.
psd=u	Undefined/Default. The DMARC policy is on a non-PSD domain, and its boundary status is not explicitly declared. This is the default if `psd` is omitted.	The Tree Walk will continue its default logic, searching further up the hierarchy for an explicit boundary or another DMARC record.

What this means for most domain owners: If you are not a Public Suffix Operator (i.e., you don’t manage a TLD like .com or .org), you should focus on publishing a valid DMARC record at your base domain (e.g., example.com). For most straightforward setups, omitting the psd tag entirely will allow the default Tree Walk logic to function correctly by relying on the presence of a valid DMARC record at the highest level. However, if you have a particularly complex domain structure or need to explicitly declare your base domain as the definitive organizational boundary for policy enforcement, using psd=n can provide added clarity and certainty.

2. Policy for Non-Existent Subdomains: np

A significant security enhancement in DMARCbis is the introduction of the np (Non-existent Policy) tag. This powerful tag allows a domain owner to specify a DMARC policy that applies specifically to messages purporting to be from a subdomain that does **not actually exist** in DNS. This closes a common and often exploited loophole for spoofing attacks (e.g., a spammer attempting to spoof nonexistent.example.com).

Tag Example	Description
np=reject	Instructs receiving mail servers to apply a reject policy to emails from subdomains that do not exist in DNS. These emails should be discarded.
np=quarantine	Instructs receiving mail servers to apply a quarantine policy to emails from non-existent subdomains. These emails should be moved to spam or held for review.
np=none	Instructs receiving mail servers to apply a none policy to emails from non-existent subdomains, allowing them to be delivered without special handling. (Not recommended for security).

If the np tag is omitted, the policy for non-existent subdomains will default to the existing subdomain policy (sp), or if sp is also absent, it will fall back to the organizational domain policy (p). Explicitly defining np with an enforcement policy like reject or quarantine is a highly effective way to proactively shut down a prevalent type of spoofing and phishing attack, significantly enhancing your domain’s security posture.

3. Simplified Testing: t (Replacing pct)

The original DMARC specification included the pct (percentage) tag, which aimed to allow partial enforcement of a DMARC policy (e.g., pct=10 for 10% enforcement). However, this tag often led to complexity, inconsistent implementation across different mail receivers, and sometimes confusing results. DMARCbis addresses this by removing pct and replacing it with a simpler, binary t (Testing Mode) tag:

• t=y: Indicates that the domain owner is in testing mode. When a receiver encounters a DMARC-failing email, they should treat the policy as if it were set to p=none. This is functionally equivalent to the old pct=0. This is invaluable for safely testing policy changes without impacting legitimate email deliverability.
• t=n: Indicates that full enforcement is desired. This is the default behavior if the t tag is omitted, and it is equivalent to the old pct=100. This means any DMARC-failing emails will be subject to the specified p or sp policy (e.g., quarantine or reject).

This simplification of the testing mechanism makes DMARC policy deployment and adjustments far more straightforward and predictable for domain owners, reducing the chances of unintended consequences during a rollout.

---

Key Action Items for Domain Owners in the DMARCbis Era

The transition to DMARCbis is meticulously designed to be smooth and largely seamless for the majority of organizations, especially those with an existing, well-configured DMARC record at their base domain. However, to fully leverage the enhanced security, flexibility, and clarity offered by DMARCbis, we highly recommend conducting a proactive review and making strategic adjustments to your DMARC implementation:

1. Audit and Streamline Your Current DMARC Record: Begin by reviewing your existing DMARC record. Identify and remove any tags that are now deprecated in DMARCbis, such as pct (percentage), rf (Report Format), and ri (Report Interval). While receivers might still process them, DMARCbis-compliant receivers will simply ignore them, and their removal can clean up your record and prevent potential confusion. Focus on the core policy tags (`p`, `sp`, `rua`, `ruf`).
2. Familiarize Yourself with Subdomain Policy Inheritance: If your organization utilizes complex subdomain structures, it is crucial to thoroughly understand the new DNS Tree Walk logic. This understanding will help you ensure that your DMARC policies are inherited and applied as intended across all your subdomains, preventing both over-enforcement and under-protection. Consider mapping out your domain hierarchy and how the Tree Walk will interact with it.
3. Implement the New Security Tags for Robust Protection: Proactively implement the np (Non-existent Policy) tag with an enforcement policy (reject or quarantine). This is a vital step to protect your brand from spoofing attempts targeting non-existent subdomains, which are a common attack vector. For example, add np=reject to your DMARC record.
4. Define Explicit Boundaries for Complex Setups: For organizations with intricate domain structures, or those operating as public suffix operators (though less common for standard businesses), consider explicitly using psd=n in your base domain’s DMARC record. This explicitly declares your primary domain as the organizational boundary, providing unequivocal clarity to mail receivers and ensuring consistent policy application, especially useful in large enterprise environments.
5. Embrace Simplified Testing with the `t` Tag: When making policy changes or initially deploying DMARC, utilize the new t=y tag to safely test your DMARC policies without risking the legitimate deliverability of your emails. This clear testing mode simplifies the rollout process and allows for confident adjustments.
6. Maintain Vigilant DMARC Reporting and Monitoring: Even with simplified tags, continuous monitoring of your DMARC aggregate (RUA) and forensic (RUF) reports remains paramount. These reports provide invaluable insights into your email ecosystem, identifying legitimate senders that might need DMARC alignment and exposing ongoing spoofing attempts. Leverage DMARC monitoring tools to interpret these reports effectively.

DMARCbis represents a significant leap forward, offering a more refined, robust, and user-friendly future for email authentication. By actively understanding the mechanics of the DNS Tree Walk Algorithm and strategically updating your DMARC records to incorporate these new, powerful tags, you can ensure your domain is optimally protected against the ever-evolving landscape of phishing, spoofing, and other email-based threats for years to come. Proactive engagement with DMARCbis will safeguard your brand, maintain email deliverability, and enhance trust in your communications.