The Public Suffix List has retired from DMARC

Here is a fact about DMARC that surprises most people I tell it to. For roughly the last decade, the question “what is the organizational domain for news.example.co.uk?” was answered with help from a flat text file maintained by volunteers and hosted by Mozilla. Not by DNS. Not by the IETF. By a file called the Public Suffix List.

That file was load-bearing. DNS still held the DMARC records, but the list helped receivers decide where the organizational boundary sat when a subdomain had no record of its own. If the list was wrong, or stale, or your domain was simply not in it, DMARC alignment and policy inheritance could read your domain differently than you expected.

DMARCbis, published as RFC 9989 in May 2026, retires that dependency. In its place is a DNS tree walk: a small, bounded climb through the DNS hierarchy that finds the organizational domain using DNS itself. If you run email for any domain with subdomains, this is worth ten minutes of your attention.

What the Public Suffix List was doing for DMARC

DMARC is evaluated against the domain in the From: header. If that domain publishes a _dmarc record, simple enough. The interesting case is the one where it does not.

Say you send marketing mail as news.example.com but you only published a record at _dmarc.example.com. The subdomain has no record of its own. A receiver needs to decide: does the parent policy apply here, and which domain counts as “the organization” for alignment purposes?

Under RFC 7489, the original DMARC spec, the answer came from the Public Suffix List. The receiver counted labels from the right, found the longest matching public suffix, and added one more label. For news.example.co.uk, the matching public suffix is co.uk, so the organizational domain is example.co.uk, not example.com-style guesswork and not co.uk itself. That boundary is what let example.co.uk and news.example.co.uk align under relaxed mode and share an inherited policy.

The mechanism worked. The problem was where the truth lived.

Why a flat file was always an odd dependency

The Public Suffix List is a community resource. Domain operators and registries submit entries, volunteers review them, and Mozilla publishes the result. It is genuinely useful, and browsers, email libraries, and TLS tooling all lean on it.

For a normative internet standard, though, it was an uncomfortable thing to depend on.

The list is not part of DNS. It ships embedded inside software, which means every program carries its own copy and that copy ages. A registry that adds a new public suffix today does not change the list inside the mail server you deployed two years ago. The boundary a receiver computes is only as fresh as the copy it happens to hold. And a domain that is not on the list at all gets handled by a fallback rule rather than a published fact.

When the authority for “where does this organization’s domain begin” sits in a file outside DNS and outside the standards process, two receivers can read your domain differently, and you cannot see or fix the disagreement from your own zone. That is the gap DMARCbis set out to close.

The tree walk, in plain terms

RFC 9989 §4.10 replaces the list lookup with a DNS query loop. The receiver walks up the tree, one label at a time, asking DNS the question directly.

To find the policy for a sender like [email protected], a receiver first checks the exact Author Domain. If there is no valid record there, it walks upward through parent domains:

_dmarc.api.eu.mail.example.com   → no record
_dmarc.eu.mail.example.com       → no record
_dmarc.mail.example.com          → no record
_dmarc.example.com               → v=DMARC1; p=reject
_dmarc.com                       → no record

In this ordinary case, example.com is the shortest name in the walk with a valid DMARC record, so it becomes the organizational domain and the policy source for the subdomain. There is no list to consult and no embedded copy to go stale.

The selection rule is worth stating precisely, because it is the part most easy to oversimplify. A record with psd=n says “this name is the organizational domain.” A record with psd=y, found above the starting domain, says “this name is a public suffix, so the organizational domain is one label below it.” If neither flag settles the boundary, the valid record with the fewest labels wins.

Two details matter in practice.

First, the walk is bounded. A malicious sender could otherwise craft a name with hundreds of labels and force a receiver into hundreds of lookups per message. To prevent that, RFC 9989 §4.10 caps the walk at eight DNS queries, even for names with more than eight labels. For the vast majority of real domains, the record sits one or two hops up and the cap never comes near.

Second, public-suffix operators get an explicit say. A hosting provider or registry that wants customer domains underneath a shared suffix treated as separate organizations can publish a record with psd=y. During the walk, that flag marks the public-suffix boundary, so the domain one label below it becomes the organizational domain. Large organizations can also use psd=n to pin an intermediate node as the organizational domain for itself and its subdomains. This folds in the job that the experimental PSD DMARC of RFC 9091 used to do. RFC 9091 is now obsoleted by RFC 9989, and the tree walk absorbs its role.

For an ordinary flat domain, the tree walk and the old list lookup reach the same answer. mail.example.com resolves to example.com either way. The difference is that the new answer comes from DNS, under your control, rather than from a file you do not maintain.

What this changes for you in practice

If you publish one DMARC record at your organizational domain and your mail flows from subdomains under it, your day-to-day behavior does not change. The walk lands where the list landed. You do not need to do anything.

The places to pay attention are the ones where you were relying on assumptions:

• Subdomain policy now resolves through the walk. Your sp tag, the subdomain policy, and np, the policy for non-existent subdomains, are applied to whatever domain the walk identifies as yours. If you want subdomains handled differently from the root, set sp and np explicitly rather than trusting an inherited default to mean what you remember it meaning. Our DMARC record tags guide breaks down how sp and np differ.
• Public-suffix operators have a new control. If you run a platform where customer namespaces live under a shared parent, psd=y is how you mark that parent as a public suffix and keep customer domains separate below it. If you are a customer on such a platform, this is why your domain may be treated as standalone.
• Alignment uses the same boundary. Relaxed alignment passes when the From domain and the authenticated domain share an organizational domain. Since the tree walk defines that boundary, your alignment results follow it too. If you want a refresher on how alignment reads those domains, see our post on how SPF, DKIM, and DMARC alignment work together.

The surprises, when they happen, are usually a subdomain inheriting a stricter policy than its owner realized, or a platform domain that no longer inherits where someone expected it to. Both are visible in your reports before they become a delivery problem, which brings me to the useful part.

How to see who has already switched

This is the part I find genuinely interesting as an operator, because the migration is observable in your own data.

When a receiver sends you an aggregate report, the report’s policy block can state which method the receiver used to discover your organizational domain. RFC 9990 added a discovery_method field for exactly this, and its value is either psl for the old Public Suffix List or treewalk for the new algorithm.

DMARCTrust reads that field and shows it on the report page, next to your published p, sp, np, and alignment settings. So you do not have to take anyone’s word for which receivers have moved. You can open a recent report and read it. As the large mailbox providers migrate, you watch psl give way to treewalk in your own reporting, receiver by receiver.

One honest aside, because I would rather you hear it from me. DMARCbis retires the Public Suffix List for policy discovery, but the list is not gone from the world, and it is still the right tool for some jobs. Our own Email Header Analyzer still uses the PSL to judge alignment between two domains in a parsed header, because that is a static comparison with no receiver doing a live DNS walk on your behalf. Dropping the list from DMARC’s discovery step does not make it useless everywhere else.

What to do now

A short checklist, in priority order:

1. Confirm your root record is discoverable. Run your sending domain through the free DMARC checker and verify the _dmarc record resolves. The tree walk only finds what DNS serves.
2. Set sp and np deliberately. If your subdomains and your root should behave differently, say so in the record instead of relying on inherited defaults. If they should behave the same, you can leave both unset and let the walk inherit.
3. If you run a shared-suffix platform or registry, evaluate psd=y. Decide whether customer domains under your suffix should be separate organizations, and publish accordingly.
4. Read your aggregate reports and watch discovery_method. It is the cleanest signal you have for which receivers are evaluating you with the new algorithm.

None of this is urgent for a well-configured flat domain. All of it is worth knowing before a subdomain inherits a policy you forgot you wrote.

If you want the full standards picture behind this change, including the renumbering of the DMARC specs, I wrote a longer piece on what DMARCbis actually changed. And if you would rather just see the new algorithm reflected in your own mail, the fastest path is to check your domain, publish a monitoring policy, and watch the reports come in.

Marc

FAQ

Do I need to change anything right now?

For a standard domain with a _dmarc record at the organizational level, no. The tree walk lands on the same organizational domain the Public Suffix List did, so your policy and alignment behave as before. The change is worth understanding mainly so that sp, np, and platform psd=y boundaries do not surprise you later.

Will the tree walk break my subdomains?

It should not. A subdomain with no record of its own still inherits the organizational policy, just discovered through DNS instead of a list. The one thing to verify is that your subdomain policy is what you intend: set sp explicitly if subdomains should differ from the root, rather than relying on a default to mean something specific.

Is the Public Suffix List gone everywhere?

No. RFC 9989 removes it from the DMARC organizational-domain discovery algorithm. The list itself still exists and is still appropriate for static alignment comparisons, browser cookie boundaries, and similar uses where no live DNS walk is happening. This change is specific to how receivers discover your DMARC policy.

How many DNS queries does the walk make?

At most eight, per RFC 9989 §4.10. The receiver climbs label by label, collecting valid DMARC records and stopping early only when a valid record contains psd=n or psd=y. The eight-query cap exists to stop an attacker from forcing excessive lookups with a deeply nested name, not to limit legitimate domains.