RFC 9989 and DMARC: What the Public Suffix List Change Means

What is the Public Suffix List in email authentication?

RFC 9989 is an IETF informational RFC that removes a long-standing dependency in how DMARC validates multi-level domains. At the center of that change is the Public Suffix List (PSL) - a registry maintained by Mozilla that lists every top-level domain and public suffix. A public suffix is the part of a domain that is publicly registered, as opposed to a private subdomain. Examples include .com, .co.uk, .org.uk, and gov.pl. The PSL exists so that browsers and email systems can distinguish between a domain owned by an organization and a domain that is itself a public registration point.

When you set a DMARC policy on example.com, the receiving mail server needs to determine the Organizational Domain - the registered entity that owns the domain. It does this by checking the PSL. If you own mail.example.co.uk, the server strips subdomains until it reaches co.uk, which it finds in the PSL, and then treats example.co.uk as the Organizational Domain.

This logic has worked reliably for years. It is also the mechanism that makes DMARC work correctly on multi-level domains like github.io or wordpress.com, where thousands of unrelated organizations share a common parent domain.

How DMARC uses the Public Suffix List today

DMARC uses the PSL today in its Organizational Domain calculation. The process is deterministic but has a problem: it relies on the PSL being accurate and up to date. The PSL is maintained manually. New public suffixes are added slowly. Some multi-level domain structures are not in the PSL at all, which means a receiving server may calculate a different Organizational Domain than the one you intended.

This creates edge cases. A company running DMARC on a subsidiary domain might find that alignment fails not because their SPF or DKIM is broken, but because the PSL does not recognize their domain hierarchy correctly. Similarly, DMARC reporting tools that try to summarize domain posture often struggle with multi-level domains where the PSL lookup produces unexpected results.

The underlying issue is not a flaw in DMARC itself. It is a dependency on an external registry that moves independently of email authentication standards.

What RFC 9989 changes

RFC 9989 removes DMARC's hard dependency on the PSL for Organizational Domain determination. Instead of relying on a manually maintained external list, the RFC introduces a different approach to domain alignment that does not require looking up whether a suffix is in the PSL.

Specifically, RFC 9989 changes the DMARC alignment algorithm so that it no longer needs to ask "is this suffix in the Public Suffix List?" It uses domain-based heuristics instead. This means the validation result for a domain like co.uk or example.com is no longer dependent on whether the PSL has been updated to reflect the latest domain structure.

RFC 9989 is an informational RFC, not a standards-track update to DMARC itself. It describes a change in how DMARC implementations can handle domain alignment when PSL data is unavailable, inconsistent, or when the organizational boundary cannot be determined cleanly from the suffix list.

For most practitioners, the practical effect is narrow but real: email receivers that implement RFC 9989 logic will validate DMARC alignment for multi-level domains without consulting the PSL. This makes DMARC behavior more predictable on complex domain hierarchies.

Who is affected by the RFC 9989 change

RFC 9989 primarily affects three groups:

1. Operators of multi-level domains

If you run DNS for a domain that itself acts as a parent for other registered domains - for example, a university that runs .university.edu as a TLD for its subdomains, or a country-code domain structure where registration rules create unusual hierarchies - RFC 9989 changes how receiving servers validate your DMARC records. Your alignment checks no longer depend on whether your TLD is correctly listed in the PSL.

2. Organizations using shared hosting or cloud email on multi-level domains

If your email is hosted on a platform like github.io, wordpress.com, or a similar multi-level structure, RFC 9989 may change how your DMARC policy is evaluated. Previously, the PSL determined your Organizational Domain. Now, receiving servers that support RFC 9989 may use a different method.

This does not necessarily break anything. Most DMARC policies on shared platforms continue to work because SPF and DKIM alignment still function. But if your policy was tuned specifically to work around PSL-related edge cases, test it after RFC 9989 is deployed by major receivers.

3. DMARC monitoring and reporting tool operators

If you build or operate DMARC aggregation or analytics tools, RFC 9989 affects how you calculate Organizational Domains when summarizing reports. Tools that rely on PSL lookups to normalize DMARC data may need to update their logic to match how RFC 9989-capable receivers actually evaluate alignment.

Do you need to update your DMARC policy?

For most domains, no. If you run DMARC on a standard second-level domain like example.com or example.co.uk, and your SPF and DKIM are configured correctly, RFC 9989 does not require you to change your DMARC record.

You may need to act if:

You run DMARC on a multi-level domain where the PSL lookup was producing unexpected Organizational Domain results.
Your email service provider specifically notified you of PSL-related alignment failures.
You operate a DNS service or email platform that publishes DMARC records for thousands of third-level or fourth-level domains.

In those cases, verify that your DMARC policy still produces the intended alignment results after RFC 9989 adoption by major receiving mail servers. This is a gradual rollout - not all receivers have implemented RFC 9989 logic yet.

If you manage DMARC across many domains, use a monitoring tool to catch alignment failures automatically. DMARCFlow tracks DMARC records across your domain portfolio and can surface when PSL-related issues cause unexpected failures.

FAQ

Does RFC 9989 require a new DMARC record?

No. RFC 9989 changes how receivers validate your existing DMARC record. It does not introduce new tags or change the syntax of p=reject, p=quarantine, or p=none.

Which email receivers support RFC 9989?

RFC 9989 is a recent informational RFC. Deployment is gradual. Major receivers like Google, Microsoft, and Fastmail typically adopt new standards over months or years. Check your DMARC aggregate reports for changes in alignment failure rates as RFC 9989 rolls out.

Does RFC 9989 affect BIMI?

No. BIMI operates independently of DMARC's PSL dependency. RFC 9989 does not change how BIMI validates logo ownership or selects certificates.

My DMARC policy is p=none. Should I upgrade it now that RFC 9989 exists?

That depends on your overall email authentication maturity, not on RFC 9989 specifically. If your SPF and DKIM are aligned and your domain sends no spoofed email, moving to p=quarantine or p=reject is still the right long-term goal. RFC 9989 does not change that recommendation.

Where can I read RFC 9989?

RFC 9989 is published by the IETF. Search "RFC 9989 DMARC Public Suffix List" at ietf.org.