DMARC RFC 9989, 9990 and 9991

After years of work inside the IETF DMARC working group, the long-anticipated update to the DMARC standard has been published. Three documents, RFC 9989, RFC 9990, and RFC 9991, now formally replace the original RFC 7489 from 2015. Although not an official term, the RFCs were together known in the community as DMARCbis, and are now published as the updated DMARC specification with the same version number.

The new specifications were published in May 2026 and moved DMARC from its earlier Informational status to a Proposed Standard on the IETF Standards Track. This is a meaningful jump, since it gives DMARC a stronger and more formal place in the Internet standards stack.

Key Changes to DMARC

1. DNS Tree Walk Replaces the Public Suffix List

The Public Suffix List (PSL) is replaced by a DNS-native Tree Walk method for determining the Organizational Domain.

When a receiver cannot find a DMARC record at the message's domain directly, it performs a Tree Walk, querying for a DMARC record at successively higher levels of the DNS hierarchy until it locates the policy that applies. This lets domain boundaries be determined natively in DNS and removes the dependence on a third-party suffix list. The psd tag (psd=y for a Public Suffix Domain, psd=n for an organizational domain) helps the receiver identify where the organizational boundary sits during this process.

The walk is bounded to keep lookups manageable. For typical domains the starting point is the immediate parent of the Author Domain, and for unusually deep names (more than eight labels) the algorithm shortens the name before walking, which caps the number of queries a receiver will make.

2. Removed Tags

The following tags were moved to historic status to streamline the protocol:

pct (percentage-based policy application)
rf (report format)
ri (report interval)

Existing records that still contain these tags keep working, because receivers ignore tags they do not recognise, but they should be left out of new records.

3. New and Updated Tags

The new psd tag declares whether a domain is a Public Suffix Domain, helping domain owners and PSD operators control policy inheritance during Tree Walks.

The t tag signals to the receiver that the domain owner is in a testing phase and may not want full enforcement of the policy (p, sp, np). Setting t=y asks receivers to apply the next-lower enforcement level while testing. It does not change how DMARC reports are generated and does not affect a policy already set to none.

The new np tag specifies the DMARC policy to apply to non-existent subdomains (names that do not resolve in DNS). It closes a gap that sp did not cover, since sp applies only to existing subdomains.

4. Reversed Guidance on p=reject

One of the most consequential changes is a shift in policy guidance. After more than a decade of deployment, the spec recognises that indirect mail flows such as forwarding and mailing lists routinely break alignment for domains with human users. As a result, p=reject is no longer presented as the universal goal. For domains that host general user mailboxes, the spec discourages p=reject and points toward p=quarantine as the practical end state, and receivers may treat p=reject more conservatively in these cases. p=reject remains appropriate for domains that send only transactional or automated mail with no human posting.

5. "Full Participation" Requirements

A new conformance section defines what it means for domain owners and receivers to fully support DMARC, setting clearer expectations and improving interoperability.

6. Improved Specification Format

The document has been restructured with better examples, clarified terminology, and a cleaner layout, making implementation easier for all stakeholders.

What Stays the Same?

1. Existing DMARC records using v=DMARC1 remain valid.
2. The core DMARC mechanisms for SPF, DKIM, and alignment still apply.
3. The central policy and reporting tags (p, sp, rua, ruf) remain in place.

Impact on Existing DMARC Deployments

The update is backward compatible and does not break existing RFC 7489 deployments. The new tags are optional, so current setups remain functional. Auditing your records is recommended for cleaner authentication, but no immediate action is required if your DMARC is correctly configured.

What Domain Owners Should Do

Domain owners do not need to panic-edit their DNS, but it is a good moment to review their setup. Check whether your records still rely on pct, rf, or ri, and plan to clean them up. If you operate subdomains, the new np tag is worth exploring as a defence against spoofing of non-existent subdomains. PSD operators should look at how the Tree Walk and psd tag affect their domains.

Make Sure Your DMARC Platform Is Ready

Not every tool on the market has caught up with the new standards yet, and that gap matters. If your platform cannot read the new tags or process reports in the updated format, you lose visibility right when the protocol is evolving.

PowerDMARC is already aligned with the new specifications and supports:

1. RFC 9989, 9990, and 9991 compatible record generation
2. Parsing of the new np, psd, and t tags
3. RFC 9990 aggregate report ingestion and reporting
4. DNS Tree Walk based organizational domain handling
5. Updated processing behaviour that reflects the new conformance rules

If you want to see how your current record holds up against the new standard, run it through our free DMARC checker and review what needs cleaning up.

Summing Up

The updated RFCs are not a new protocol. It is the same DMARC, rewritten more clearly and lifted to Standards Track status. After more than a decade of real-world deployment, the spec now reflects how email actually works, including its messy parts like forwarding and mailing lists.

For anyone responsible for domain security, the publication of RFCs 9989, 9990, and 9991 is a good prompt to audit your records and make sure your tooling is ready for the new tags and the DNS Tree Walk approach.