RFC 9989: What the DMARC Public Suffix List Change Means

RFC 9989: What Changes When DMARC Stops Using the Public Suffix List

If you run DMARC on your domain, something important changed in May 2026 that probably did not break your email - but it did change how some mail receivers figure out who owns your domain.

RFC 9989 is the new core DMARC specification. Its most significant change: it removes DMARC's dependency on the Public Suffix List and replaces it with a live DNS-based mechanism. Here is what that means for you.

What Is RFC 9989?

RFC 9989 is the new core Domain-based Message Authentication, Reporting and Conformance (DMARC) standard, published in May 2026 by IETF (Herr & Levine, Standards Track). It formally obsoletes two earlier DMARC specifications: RFC 7489 (the original DMARC RFC) and RFC 9091.

Three companion RFCs arrived together:

RFC 9989: Core DMARC protocol - the authentication and alignment rules

RFC 9990: Aggregate reporting - the XML format for summary reports

RFC 9991: Failure reporting - what to include in per-message failure reports

RFC 9989 is the main one. The key difference from the old standard is how it handles the organizational domain concept - the part of your domain that represents the actual organization, not a parent registry or a shared platform.

What the Public Suffix List Was and Why It Was a Problem

The original DMARC design relied on the Public Suffix List (PSL) to determine the organizational domain. The PSL is a static list maintained by Mozilla at publicsuffix.org. It lists which DNS domains are "public" - shared by many unrelated entities. Examples include .com, .co.uk, .github.io, and .appspot.com.

Mail receivers looked up where your domain fell on this list to figure out which label represented your organization. If you owned department.example.com, the receiver used the PSL to decide whether example.com or department.example.com was the organizational domain.

This caused real problems:

The PSL is static. It is updated manually by Mozilla contributors. New top-level domains, changes to country-code domain structures, and edge cases with complex subdomain hierarchies could all lag behind because the list is not generated automatically from DNS data.

It was one organization making a judgment call. The PSL represents Mozilla's opinion about where domain ownership boundaries lie. That opinion does not always match DNS reality, and it has changed over time in ways that caught domain owners off guard.

It made ccTLDs especially messy. Country-code domains have complex delegation structures. Whether example.co.uk has an organizational domain of co.uk or example.co.uk depends on how the PSL classifies .co.uk. This classification has changed before and will continue to change.

The practical result: two domains with identical DMARC configurations could get different organizational domain assignments depending on which version of the PSL a receiver was using.

The DNS Tree Walk: How RFC 9989 Replaces the PSL

RFC 9989 removes the PSL dependency entirely and replaces it with a live DNS query mechanism called a tree walk.

Instead of looking up a static list, a mail receiver running RFC 9989 walks up the DNS tree from your specific subdomain, checking each level for a _dmarc record, until it finds one.

Here is the exact sequence for user@mail.department.example.com:

1. Receiver checks _dmarc.mail.department.example.com. No record found.
2. Checks _dmarc.department.example.com. No record found.
3. Checks _dmarc.example.com. Record found.

The organizational domain is example.com - determined by live DNS, not a static list.

This is more reliable because:

No list to maintain or update

Works immediately for any new TLD or subdomain structure

No discrepancy between what a static list says and what DNS actually shows

Platforms like GitHub Pages (.github.io) or Google App Engine (.appspot.com) are handled correctly without manual PSL updates

Who Benefits Most from This Change

RFC 9989 is particularly good news for three groups:

Subdomain operators. If you run marketing.example.com or api.example.com and send DMARC-authenticated mail from those subdomains, the tree walk finds your organizational DMARC record without needing the PSL to know that .com is a public suffix. Alignment failures caused by PSL edge cases should decrease.

Organizations on complex ccTLDs. If your domain ends in a country-code TLD where the PSL classification was unclear or incorrect, the DNS tree walk eliminates that uncertainty. Your DMARC policy is found where your DNS says it is, not where a third-party list thinks it should be.

Multi-level domain users on shared platforms. Anyone sending from user.github.io or user.appspot.com benefits from the DNS tree walk correctly identifying the platform boundary without relying on a manually maintained list.

What This Means for Your DMARC Record

Your _dmarc.example.com DNS record does not need to change. The p=, rua, ruf, adkim, and aspf tags work exactly as they did before. RFC 9989 did not introduce new record syntax or tags.

The change is on the receiving side. Mail receivers are what updated their behavior.

However, the tree walk being more accurate can reveal misalignment you did not know you had. If your subdomain was passing alignment under the old PSL rules because of a quirk in how that list classified your TLD, those edge cases may now resolve differently.

What Domain Owners Should Check Now

Run through this checklist:

1. Verify your DMARC record is published correctly. Use a DMARC lookup tool and confirm _dmarc.yourdomain.com returns a valid record.

2. Check your subdomains. If you send from subdomains with their own sending infrastructure, confirm they either publish their own _dmarc record or correctly align with your organizational domain. The DNS tree walk will find whatever record exists at each level.

3. Monitor your aggregate reports. As more receivers adopt RFC 9989, you may see changes in which domains are reported as the organizational domain for your mail. DMARCFlow tracks these shifts in aggregate reports and flags sudden changes in organizational domain assignment - which is one of the first things to watch as the transition unfolds.

4. Test if your previous PSL workarounds are still needed. If you published separate _dmarc records for subdomains specifically because the PSL was not handling your TLD correctly, test those scenarios against a receiver that implements the tree walk. The DNS-based approach may make those workarounds unnecessary.

5. Confirm your rua reporting is working. Aggregate reports remain the best way to see what receivers are actually doing with your mail. RFC 9990 (the updated aggregate report spec) delivers the same data, now with more accurate organizational domain detection per receiver.

Does DMARC Reporting Still Work Under RFC 9989?

Yes. Aggregate reports (rua) and failure reports (ruf) are both unchanged in spirit and format. RFC 9990 defines aggregate reports and RFC 9991 defines failure reports. The DMARC monitoring and reporting ecosystem continues to function.

As receivers adopt RFC 9989, aggregate reports may show more accurate organizational domain assignments. DMARCFlow processes aggregate reports and will update its interpretation as the standard enters wider receiving infrastructure. The practical benefit: fewer spurious alignment failures in your reports due to PSL inaccuracies.

Frequently Asked Questions

Does RFC 9989 require me to change my DMARC record?

No. Your existing _dmarc.example.com record is fully compatible with RFC 9989. The change lives on the receiving side, not in your DNS.

How does the DNS tree walk work in practice?

A mail receiver begins at the most specific label of the From domain and checks for a _dmarc record at each level going up. The first _dmarc record found marks the organizational domain. It is a standard DNS query sequence - no list, no external dependency, just DNS lookups.

I use Google Workspace or Microsoft 365. Does RFC 9989 affect me?

Your provider handles DMARC for their sending infrastructure. Most users will see no change. If you have subdomains with custom DMARC policies, test that alignment still works. The DNS tree walk is more accurate than the PSL was, so correctly configured domains should work better; domains that were relying on PSL quirks may behave differently.

My subdomain was passing DMARC alignment before but failing now. Why?

If your subdomain was relying on the PSL treating your TLD or subdomain structure in a specific way, the DNS tree walk may now determine your organizational domain differently. Check whether your subdomain needs its own _dmarc record, or whether the SPF and DKIM signatures it uses correctly align with the parent domain.

Are aggregate reports still compatible?

Yes. RFC 9990 defines the aggregate report format for the rua tag. The format, delivery mechanism, and content are unchanged in nature. Your DMARC monitoring tool should continue to receive and parse reports normally.

When will mail receivers implement RFC 9989?

Adoption is gradual. As of May 2026, RFC 9989 is very new. Large receivers will update over time. Smaller receivers will take longer. During the transition, some receivers will use the DNS tree walk and others will still use the PSL, so alignment behavior may vary across different mail destinations briefly.

The Short Version

RFC 9989 (May 2026) is the new core DMARC standard. Its headline change is replacing the static Public Suffix List with a live DNS tree walk that finds organizational domains more accurately.

Most domain owners do not need to change their DMARC record. The practical benefit is fewer alignment failures for subdomains and domains on TLDs where the PSL was out of date or incorrect.

Watch your aggregate reports as receivers adopt RFC 9989. If you see sudden changes in which domain is reported as your organizational domain, those reflect the more accurate DNS-based approach - not a problem with your configuration. DMARCFlow helps you track these changes in aggregate reports automatically.