Email authentication underpins the identity relationship between senders and subscribers. It validates that emails genuinely came from the domains they claim to represent, protecting recipients from spoofing and safeguarding senders’ reputations. So, when DMARC—the part of authentication that tells receiving servers what to do when emails fail verification—announces major updates, email marketers need to pay attention. 

What is DMARC? 

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a technical standard designed to reduce email fraud. It builds on two other email authentication technologies—SPF and DKIM—which help receivers verify whether emails genuinely come from the domains they claim to represent, and whether they have been tampered with. When these checks fail, DMARC tells receiving mail servers what to do with those emails (quarantine or reject them), in line with the instructions published by the domain owner. Domain owners also may receive reporting that provides visibility into their authentication performance at mailbox providers, identifying any issues with their own mail streams, and identifying spoofing and who else may be sending email on their behalf. 

SPF, DKIM, and DMARC are all DNS-based protocols. The Domain Name System is effectively the internet’s phone directory, helping senders verify their identity and ensure email messages are correctly routed to recipients’ inboxes. Domain owners publish records to their DNS that specify the exact IP addresses and domains authorized to send email on their behalf (SPF), as well as the cryptographic digital public key used for validating their signed emails (DKIM). The resulting signature is carried in the message headers. These security elements are now mandatory requirements for major providers like Gmail, Microsoft, and Yahoo to assist in delivery and placement and to prevent domain spoofing and phishing.  

Why the need for an update? 

Originally published as Informational RFC 7489 in 2015, DMARC has become a cornerstone of email transmission, mandated by major mailbox providers like Gmail, Yahoo, and Microsoft.  Its original Informational status reflected the need for real-world deployment, experimentation, and feedback before the protocol could be refined and advanced through the formal IETF standards process. 

Who is behind the updates? 

This work took place with the Internet Engineering Task Force (IETF)— the main global standards organization for the internet, responsible for developing and maintaining the technical standards and protocols that keep the internet running. The IETF’s DMARC working group led the effort to expand the original informational standard (RFC 7489) into three new Proposed Standards: 

• RFC9989 (the core DMARC protocol document) 

• RFC9990 (covering aggregate reporting) 

• RFC9991 (covering failure reporting) 

What has changed? 

The specifications defined by the new RFCs are authoritative, reflecting how modern email authentication actually operates today and formalizing the use of features like SPF and DKIM alignment. Expanding one RFC into three also brings additional clarity, allowing the reporting framework to be maintained and extended without disturbing the core protocol. 

At a more granular level, the key developments include: 

• Introduction of the DNS Tree Walk: Previously, DMARC relied on the Public Suffix List (PSL) mechanism to determine where an organizational domain began. In practice, receivers commonly used the community-maintained Public Suffix List, but differences in list sources, update timing, and local implementation could create inconsistent results. The new DMARC specification replaces that with a “DNS Tree Walk” allowing receivers to discover the applicable DMARC policy directly through structured DNS queries. This makes policy discovery less dependent on external lists and more consistent with how domains publish and delegate authority in DNS. 

• Greater support for large organizations: Businesses with complex, decentralized DNS structures previously had no reliable way to declare distinct organizational domains at different points in their namespace. Previously, DMARC relied on Public Suffix List logic to infer where the Organizational Domain began. The updated standard introduces the psd= tag (explained below), allowing domain owners and Public Suffix Operators to declare whether a domain is a public suffix, an organizational boundary, or unknown. Combined with the DNS Tree Walk, this gives receivers a more explicit way to determine which DMARC policy applies, while allowing delegated parts of a namespace to publish their own policies where appropriate. 

• New DMARC policy record parameters: Under RFC 9989, the following tags (parameters) are now available: v, p, sp, np, psd, t, adkim, aspf, rua, ruf, and fo. A full description of their functions is available here. The new parameters are: 

• “np=” (non-existent subdomain policy) 

• “psd=” (public suffix domain indicator) 

• “t=” (test mode) 

The following parameters have been retired: 

• “pct=” (percentage) 

• “ri=” (reporting interval) 

It’s also worth noting that use of the “p=” parameter (the primary policy) is now recommended rather than mandatory, defaulting to “p=none” — though the behavior also depends on how domain owners configure their “sp=” (subdomain policy) and “np=” (non-existent subdomain policy) parameters. More on what this means for senders in the next section. 

• Reporting changes: Email senders should be aware of the following: 

• RFC 9990 (Aggregate Reporting) introduces an updated XML schema that provides flexibility for future data fields without breaking existing parsers. Core data remains consistent with the current format, but domain owners should validate their report processing to confirm compatibility with the updated schema. 

• RFC 9991 (Failure Reporting) updates the specification for per-message failure reports, which use Abuse Reporting Format (ARF) and contain message headers and authentication failure details. The updated spec addresses privacy considerations more explicitly and clarifies that receivers generating failure reports should redact sensitive user data. 

Do email senders need to change their published DMARC records?  

Here’s a summary of the changes email senders should consider making to get the most out of these updates:  

• Add an “np=” tag. This specifies how to handle email sent from a subdomain that doesn’t exist in DNS. Like the “p=” tag, options are “none,” “quarantine,” or “reject.” Without this tag, the “sp=” policy applies to non-existent subdomains (or “p=” if “sp=” is also absent). If you currently rely on “p=” or “sp=” to cover non-existent subdomains, “np=” lets you apply a stricter policy to phantom subdomains that should never be sending legitimate mail. 

• Add a “psd=” tag, where appropriate. This is especially relevant for large enterprises with decentralized DNS management. The tag flags whether the domain publishing the record is a Public Suffix Domain—which is essential for the DNS Tree Walk mechanism to work correctly. Values are “y” (this is a PSD), “n” (this is an organizational domain), or “u” (undefined, the default). 

• Adopt “t=y” for staged rollouts. This signals that the domain owner is testing their policy and asks receivers to apply one level of leniency—for example, “reject” is treated as “quarantine,” and “quarantine” is treated as “none.” Note that this tag has no effect on a “none” policy and does not suppress report generation. 

• Remove the “pct” tag if you currently have it in place. This parameter has been widely misunderstood and inconsistently implemented. The new “t=” tag provides a cleaner replacement.  

• Remove the “ri=” (reporting interval) tag. This is now addressed by RFC 9990. In practice, mail receivers have already been sending reports on their own schedules (typically daily), and this is now the explicitly recommended approach. Including “ri=” serves no practical purpose under the new framework 

• Ensure your reporting (“rua=”) is correctly configured in line with RFC 9990’s updated aggregate reporting XML schema and RFC 9991’s failure reporting guidance. Note that this also forms part of Validity’s Sender Certification requirements. 

Finally, domain owners using third-party services for email sending or DMARC reporting should confirm that their providers have updated their implementations to support the new RFCs. 

How will email senders benefit from these changes? 

• These updates deliver real, practical advantages for email senders: 

• Greater consistency. Senders can have higher confidence that their published DMARC policies will be interpreted and enforced uniformly across all mail receivers. 

• Sharper anti-spoofing tools. Domain owners now have better instruments to lock down their brands against spoofing and phishing — directly reducing the risk of impersonation fraud. 

• More autonomy for large organizations. Businesses with subsidiaries and departments can now protect their own sending domains without depending on a central IT function. 

• A lower barrier to full enforcement. Senders can now progress from monitoring to active protection without the operational risks that previously made enforcement feel out of reach. 

Email senders now have an opportunity to further build and maintain trust with their subscribers. The ability of subscribers and mail receivers to reliably verify emails genuinely came from the claimed brand translates into improved sender reputations, better deliverability, and reduced damage to brand credibility. 

Where can senders learn more? 

• The new Proposed Standards RFCs can all be found on the IETF’s website: 

• • RFC 9989

• • RFC 9990

• • RFC 9991

• Check out M3AAWG Board Chair Tom Bartel’s LinkedIn post (here). 

• And there are more great DMARC resources on the M3AAWG website (here). 

Looking for more context behind these changes? Validity’s SVP of Data Services and M3AAWG Chairperson Tom Bartel and I sat down to chat all things DMARC on a recent episode of the Email After Hours Podcast.