The transition of DMARC from its long-standing RFC 7489 informational status to a formal IETF Internet Standard through the DMARCbis draft marks the end of ambiguous organisational domain discovery and the beginning of stricter enforcement requirements for Mail Transfer Agents (MTAs).
This shift is prompted by the 2024 mandates from major mailbox providers including Google and Yahoo, which now require valid DMARC records for any bulk sender reaching more than 5,000 recipients per day. While the original protocol served as a critical defence against exact domain spoofing, its reliance on the Public Suffix List (PSL) and its inability to handle complex subdomain structures led to significant authentication gaps in enterprise environments.
DMARCbis addresses these architectural flaws by refining the Tree Walk algorithm and introducing new tags that provide granular control over non-existent subdomains. For security teams, this update is not a simple rebranding, but a fundamental change in how the DNS query flow operates during the SMTP transaction.
The Structural Failure of RFC 7489
The original specification suffered from a lack of clarity regarding how a receiving server should locate a DMARC policy for a subdomain that does not have its own record. This process, often called Organisational Domain discovery, relied heavily on the Public Suffix List, which is a community-maintained file listing all TLDs and effective TLDs like co.uk or github.io.
The dependency on an external, third-party list introduced a latency risk and a potential point of failure for email gateways. If the Public Suffix List was outdated or inaccessible, the MTA might fail to identify the correct Organisational Domain, leading to incorrect policy application or the total bypass of authentication checks.
RFC 7489 did not provide a standardised method for handling Public Suffix Domains (PSDs) themselves, such as government TLDs or academic hierarchies. If a malicious actor sent an email from a non-existent subdomain of a TLD that lacked a DMARC record, the receiver had no authoritative way to verify the sender identity. DMARCbis solves this by formalising the Tree Walk, a recursive DNS lookup process that moves from the leaf node up to the TLD-minus-one level to find the policy.
Technical Mechanics of the Tree Walk Algorithm
The DMARCbis Tree Walk is a specific sequence of DNS queries designed to eliminate the ambiguity of policy inheritance. When an email arrives, the receiving MTA extracts the domain from the RFC 5322.From header. If a DMARC record is not found at that specific host, the MTA begins a step-by-step climb up the domain hierarchy.
- The Old Model: The MTA would query the Organisational Domain directly.
- The DMARCbis Model: The MTA performs a series of lookups at each level of the domain tree.
This process stops only when a DMARC record is found or when the query reaches a domain that is known to be a Public Suffix. This change ensures that policies published at a high level are consistently applied to all descendants, even in massive, multi-layered corporate structures where subdomains may be nested four or five levels deep.
This recursive approach prevents the common “subdomain shadowing” attack, where an attacker identifies a deeply nested subdomain that has been forgotten by the IT department and uses it to bypass the primary domain’s p=reject policy. By ensuring the Tree Walk always terminates at a verified policy or a PSD, the new standard closes the loop on unauthorized sender discovery.
The NP Tag and Protection Against Non-existent Subdomains
One of the most significant additions in the DMARCbis specification is the np tag, which stands for Non-existent Subdomain Policy. Previously, the sp tag was used to define policies for all subdomains, but it lacked the nuance to distinguish between a legitimate subdomain that simply lacked a record and a completely fake subdomain used in a phishing campaign.
The np tag allows a domain owner to specify a different policy for subdomains that do not exist in the DNS. For example, a corporation might set its primary policy to p=reject and its subdomain policy to sp=reject, but if an attacker attempts to spoof hr-portal.example.com and that host does not actually have an A or AAAA record, the np=reject tag tells the receiver to drop the message immediately without even considering the alignment of SPF or DKIM.
This is a critical defence against “Ghost Subdomain” attacks, where attackers generate thousands of unique, random subdomains to overwhelm spam filters and bypass reputation-based blocking.
Addressing the Public Suffix Domain Gap
DMARCbis introduces the psd tag to handle the unique requirements of Public Suffix Domains. This is particularly relevant for operators of TLDs or large-scale infrastructure providers who want to protect their entire namespace. The psd=y or psd=n tag indicates whether a domain is acting as a Public Suffix.
If a domain is marked with psd=y, it informs the receiving MTA that this domain should be treated as a boundary for the Tree Walk. This prevents the algorithm from incorrectly looking up policies at a level where no unified policy should exist, such as trying to find a DMARC record for .com or .org. This refinement reduces unnecessary DNS traffic and prevents “Over-Discovery,” where a policy might be accidentally applied to unrelated entities sharing a common suffix.
Tag Refinements and the Deprecation of Percentage-Based Rollout
The pct tag, which allowed for a graduated rollout of DMARC policies by applying them to only a percentage of failing messages, has seen a shift in usage within the DMARCbis framework. In the original protocol, pct=100 was the default, but many implementations handled lower values inconsistently. Some receivers would treat a message that fell outside the percentage as if no DMARC policy existed, while others would default back to p=none.
DMARCbis clarifies that the pct tag is a transitional tool and encourages receivers to move toward a binary application of policy. The industry consensus, reflected in the draft, is that percentage-based filtering creates an unpredictable security posture. If an attacker knows a domain is only rejecting 50% of unauthorized mail, they simply increase their volume to ensure half of their payloads reach the target. DMARCbis shifts the focus away from this probabilistic model, pushing organisations toward a 100% enforcement state as the only valid security outcome.
External Reporting Authorization and Destination Verification
The mechanism for sending Aggregate (RUA) and Failure (RUF) reports to a third-party domain is significantly more rigorous under DMARCbis. To prevent DMARC reports from being used in DNS-based DDoS attacks, the protocol requires a specific verification step.
When a domain owner specifies an RUA address that belongs to a different domain, such as rua=mailto:reports@thirdparty.com, the receiving MTA must verify that thirdparty.com has actually agreed to receive these reports. This is done by querying a specific DNS record at the destination:
example.com._report._dmarc.thirdparty.com
DMARCbis tightens the requirements for this External Reporting Authorization (ERA). If the verification record is missing, or if the DNS response is anything other than v=DMARC1, the receiver must not send the report. This prevents attackers from “pointing” the massive volume of global DMARC reports at a victim’s email server by simply publishing a spoofed DMARC record with the victim’s email in the RUA tag.
Refining the RUF and Privacy Considerations
Failure reports (RUF) have long been a point of contention due to the amount of PII (Personally Identifiable Information) they contain. An RUF report often includes the full email header and parts of the message body, which can leak sensitive data if the email was legitimate but failed authentication due to a technical error.
DMARCbis moves closer to deprecating traditional RUF in favour of more privacy-conscious reporting mechanisms. The standard encourages the use of redacted reports or aggregate data that provides enough forensic information to fix configuration issues without exposing the content of the communications. For engineering leads, this means that relying on RUF for troubleshooting will become increasingly difficult, necessitating a shift toward better internal logging and ARC (Authenticated Received Chain) analysis.
Logic for Indirect Mail Flows and ARC Integration
One of the primary reasons organisations hesitate to move to p=reject is the fear of breaking legitimate mail sent through mailing lists or forwarders. When an email passes through a mailing list, the “envelope sender” is rewritten, which breaks SPF. If the mailing list also modifies the message by adding a footer or changing the subject line, the DKIM signature is invalidated.
DMARCbis acknowledges these “indirect mail flows” and provides a clearer path for the use of ARC (RFC 8617). While ARC is technically a separate protocol, DMARCbis is designed to work in tandem with it.
- ARC allows intermediary servers to “vouch” for the authentication status of a message before they modified it.
- An MTA receiving a message that fails DMARC can look at the ARC chain to see if the message passed DMARC at its first hop.
- If the ARC chain is valid and trusted, the MTA may choose to override the DMARC failure.
DMARCbis provides the policy framework that makes this trust decision possible. It defines how receivers should evaluate these “local policy overrides” and how they should be reflected in the aggregate reports, giving domain owners visibility into how often their mail is being rescued by ARC.
Implementation Requirements for the Modern Enterprise
Adopting DMARCbis requires a technical audit of the existing DNS infrastructure to ensure compliance with the refined Tree Walk and tag logic.
Key Technical Steps:
- Version Tag: Engineers must ensure that the v=DMARC1 version tag remains the first component of the record. DMARCbis does not change the version prefix to maintain backwards compatibility with legacy MTAs.
- Subdomain Logic: The internal logic of the record should be updated to include the np tag if the organisation uses a complex subdomain hierarchy.
- Alignment Tags: Configuring the aspf and adkim tags is critical. These tags determine whether “relaxed” or “strict” alignment is required.
- Relaxed: The organisational domain must match.
- Strict: Requires an exact match of the FQDN (Fully Qualified Domain Name).
DMARCbis reinforces that relaxed alignment is the safer default for most organisations, but strict alignment should be used for high-value domains where even subdomain spoofing is unacceptable.
Security Risks of Misconfiguration During Transition
The most significant risk during the transition to DMARCbis is the “Lookup Limit” imposed by SPF. While DMARC itself does not have a lookup limit, it relies on SPF, which is capped at 10 DNS lookups. Many organisations, in an attempt to be thorough with their DMARCbis implementation, add too many third-party senders to their SPF records, causing a “PermError”.
When an SPF PermError occurs, DMARCbis treats this as an authentication failure. If the policy is set to p=reject, legitimate mail from services like Salesforce, ServiceNow, or Marketo will be blocked. Engineering teams must use SPF macros or subdomaining to keep the lookup count under control while maintaining the integrity of the DMARC policy.
Another risk involves the use of wildcards in DNS. If a wildcard CNAME or A record exists at a higher level in the domain tree, it can interfere with the Tree Walk algorithm’s ability to determine if a subdomain exists. This can lead to the incorrect application of the np tag, potentially blocking legitimate mail from dynamically generated subdomains used in cloud environments.
DMARCbis Technical Verification Checklist
Before declaring a domain compliant with the new standard, the following technical requirements must be verified at the DNS and MTA level:
- Validate Tree Walk: Test lookups at multiple subdomain depths to ensure policy inheritance functions as expected.
- Define np Tag: Explicitly define the np tag in the primary Organisational Domain record to prevent ghost subdomain attacks, even if sp is already set.
- Review RUA Destinations: Confirm the _report._dmarc verification record is present at the receiving domain.
- Audit PSL Dependency: Ensure the MTA is capable of performing the formal DMARCbis Tree Walk without relying solely on static files.
- Standardise pct: Set the pct tag to 100 explicitly or remove it entirely to align with binary policy enforcement.
- Verify DKIM Signing: Ensure all third-party senders are using DKIM, as SPF will inevitably fail in indirect mail flows.
- Monitor psd Tags: Check for conflicts if the organisation operates in a shared namespace or provides vanity subdomains.
The move to DMARCbis is a mandatory evolution for any organisation that views email as a trusted communication channel. By closing the loopholes in subdomain discovery and formalising the reporting structure, this standard provides the technical foundation needed to reach a global “Reject” posture. Failure to adapt to these refined lookup mechanisms will result in decreased deliverability as receiving MTAs adopt the stricter IETF Standard logic.
