For the past couple of years, the email authentication community has been talking about “DMARCbis.” That name is now officially obsolete, as the updates to the DMARC specifications previously encapsulated in the details of DMARCbis have now been published as three new, separate, and official “Request For Comment” (RFC) internet specification documents.
These updated DMARC specifications have formally arrived as three new RFCs:
This is the long-awaited update to RFC 7489, the original DMARC specification published back in 2015. While there are a few changes that we need to discuss, note that overall, these updates to DMARC can be considered relatively minor, and most of what is new is more a case of updating the documentation to reflect how email senders and receivers utilize DMARC out here in the real world.
The biggest change: DNS tree walk support
Historically, DMARC depended on something called the Public Suffix List (PSL) to determine the “organizational domain” during DMARC evaluation. This is how mailbox providers looking for DMARC policy settings in DNS records would make the jump from a subdomain (like email.example.com) to the organizational domain level (like example.com).
The PSL, created by the Mozilla Foundation in 2007, was intended to be utilized by browsers to define domain boundaries related to cookies. It does important work; helping enforce cookie and privacy protection, defining security boundaries for browsers, and it even helps to provide interface clarity, allowing browsers to know where the highest level of any given domain name lies.
It has some quirks that can make it tricky to properly define domain boundaries in email, and occasionally, some PSL entries – intended to help with specific cookie-related issues for various service providers — led to certain edge cases where email authentication was difficult to properly manage or parse for email senders and mailbox providers.
The updated specifications introduce “tree walking” as a method for moving “up” the DNS tree for a domain to look for the highest level of a domain for purposes of applying email authentication policy and confirming authentication “alignment.” Tree walking involves taking a hostname or subdomain, removing one left-most part from the name, and checking DNS at that new, “upper” level. For example, starting with email.industry.example.com and removing the rightmost label (email) so that a mailbox provider can look for a DMARC policy at the “industry.example.com” level instead — that’s an example of DNS tree walking.
The updated specifications also introduce explicit DNS signaling around organizational boundaries through the psd= tag, allowing domains to declare themselves as either organizational domains (by specifying “psd=n” in the DMARC record), or public suffix domains (by specifying “psd=y”).
This makes DMARC behavior more deterministic without relying on an external, manual list to determine domain boundaries.
For most marketing and enterprise senders, this change won’t amount to much. But it does improve support for more complex delegated subdomains and hosting environments, particularly in large enterprises, higher education, government, and managed multi-tenant infrastructures. For those with exceptionally complex infrastructure, note that the DNS tree walk process is limited to eight queries, to prevent denial-of-service-like impact to receivers performing DNS checks for purposes of verifying email authentication.
Valimail will soon be updating our platform to support these changes and ensure compatibility with the updated specifications.
Another change: DMARC tags removed
The updated RFCs also remove several tags that either saw inconsistent adoption or caused confusion in real-world deployment: pct, ri, and rf.
The pct tag was originally intended to support gradual rollout by allowing senders to apply policy to only a percentage of failing mail. In theory, setting “pct=10” meant “only reject 10% of failing messages.” In practice, implementation was inconsistent and often confusing. (The updated RFCs remove pct entirely and replace it with a simpler testing-oriented approach using the new “t=y” testing flag.)
The ri tag allowed senders to request aggregate reporting intervals. The rf tag attempted to specify failure report formatting. Neither tag was broadly supported, and now the updated RFCs acknowledge this by eliminating them entirely.
Failure reporting: Privacy concerns
One of the three new RFCs (RFC 9991) focuses entirely on DMARC failure reporting. These reports can contain portions of message headers and content intended to help diagnose authentication failures. In practice, that also means they can expose personally identifiable information (PII) and other sensitive data.
As privacy concerns increased, particularly post-GDPR, many mailbox providers either heavily redacted these reports or stopped sending them entirely. The updated failure reporting RFC essentially acknowledges this reality directly, formally recognizing how the email ecosystem already operates.
Aggregate reporting remains the core operational mechanism for DMARC visibility and enforcement, and that remains fully intact and unaffected. This update just helps you to make a better understanding of why you rarely received failure reports before, and why that is not likely to change.
DMARC: The core mandate doesn’t change
DMARC’s mission doesn’t change: It is a valuable tool to help protect your email domains against phishing and spoofing. These updated specifications do not change that. We continue on down the path started way back in 2015 with RFC 7489, with adoption boosts driven by Google and Yahoo sender requirements in 2023, Microsoft sender requirements in 2025, and now with these new RFCs documenting the latest evolution of domain protection.
And Valimail is here and ready to help you embark upon your DMARC journey. Reach out to us today for a demo of Valimail Enforce, to learn more about your quick path to automated DMARC enforcement, eliminating lookup limits with Instant SPF, DKIM key monitoring and management, precision sender management, and more.
