RFC 9989: What’s New in the Latest DMARC SpecificationRFC 9989: What’s New in the Latest DMARC Specification<br>On May 20, 2026, DMARC reached an important milestone with the publication of RFC 9989, officially replacing RFC 7489 from 2015. Unlike its predecessor, which was published as an informational RFC, RFC 9989 is now on the Internet Standards Track as a Proposed Standard.<br>That said, this is not a major redesign of DMARC. The protocol itself works largely the same way, DMARC records still begin with v=DMARC1, and most domain owners will not need to change their existing policies. RFC 9989 primarily clarifies terminology, tightens definitions, and standardizes behavior that had previously been implemented inconsistently. Still, there are several notable additions and changes worth understanding.<br>New t Tag Replaces pct for Testing<br>RFC 7489 introduced the pct tag, which allowed domain owners to apply DMARC enforcement to only a percentage of failing messages. In practice, however, values other than 0 and 100 were implemented inconsistently across mail receivers.<br>RFC 9989 replaces this behavior with the simpler t tag, which supports only two values:<br>t=y: Indicates that the domain owner is testing DMARC enforcement. If the DMARC policy is set to quarantine, failing messages are treated as if the policy were none. If the policy is reject, failing messages are quarantined instead.<br>t=n (default): DMARC policy is enforced normally according to the p, sp, or np tags.<br>This removes ambiguity and makes testing behavior more predictable across implementations.<br>New np Tag Sets Policy for Non-Existent Domains<br>The new np tag allows domain owners to define a DMARC policy specifically for non-existent subdomains.<br>Under RFC 7489, the sp tag applied only to existing subdomains, leaving non-existent subdomains without explicit policy coverage. This gap could be abused by attackers spoofing addresses from randomly generated subdomains.<br>The np tag follows the same syntax as p and sp:<br>np=none: No enforcement for non-existent subdomains.<br>np=quarantine: Messages from non-existent subdomains are treated as suspicious.<br>np=reject: Messages from non-existent subdomains should be rejected.<br>If the np tag is absent, receivers fall back to sp, or to p if sp is also missing.<br>New psd Tag Identifies Public Suffix Domains<br>RFC 9989 introduces the psd tag, which allows a domain owner to indicate whether a domain is a public suffix domain (PSD).<br>A PSD is a domain under which third parties can register subdomains, such as .com or .co.uk. Distinguishing PSDs from organizational domains is important because DMARC policy discovery depends on identifying the correct organizational boundary.<br>The psd tag supports three values:<br>psd=y: The domain is a public suffix domain.<br>psd=n: The domain is an organizational domain controlled by a single entity.<br>psd=u (default): PSD status is unspecified.<br>This tag plays a key role in the new DNS Tree Walk algorithm described later in the RFC.<br>Removal of rf and ri Tags<br>RFC 9989 removes the rf and ri tags from DMARC policy records and marks them as historic.<br>rf (report format) previously allowed domain owners to specify the format of failure reports. In practice, the only widely used value was afrf.<br>ri (report interval) allowed domain owners to request a reporting interval in seconds for aggregate reports. Most receivers ignored this value and used their own schedules instead.<br>Because these tags were either effectively fixed or widely ignored, they were removed from the standard.<br>Removal of the Maximum Report Size Parameter<br>RFC 9989 also removes the ability to specify a maximum report size using the ! modifier in reporting URIs.<br>For example, older DMARC records could include:<br>rua=mailto:reports@example.com!5mThis requested a maximum aggregate report size of 5 MB. In practice, however, most receivers enforced their own limits and ignored the parameter.<br>DMARC Reporting Moved to Separate RFCs<br>Aggregate and failure reporting are no longer defined directly within the core DMARC specification.<br>Instead, RFC 9989 references two separate RFCs:<br>RFC 9990 – DMARC Aggregate Reporting<br>RFC 9991 – DMARC Failure Reporting<br>Separating reporting from core policy enforcement allows the reporting formats and schemas to evolve independently without requiring updates to the main DMARC specification.<br>DNS Tree Walk Replaces the Public Suffix List<br>One of the most important changes in RFC 9989 is the replacement of the Public Suffix List (PSL) approach with a DNS Tree Walk algorithm.<br>Determining the organizational domain is essential for two parts of DMARC:<br>DMARC policy discovery: If a domain does not publish a DMARC record, receivers look for a policy at the organizational domain.<br>Identifier alignment: Under relaxed alignment, DMARC verifies that the From domain shares the same organizational domain as the SPF or DKIM-authenticated domain.<br>Under RFC 7489, implementations were expected to use a Public Suffix List to determine the organizational...