How DMARC tree-walk policy discovery changes Organizational Domain and public-suffix handling

For years, DMARC implementations usually answered the question "what is this domain's Organizational Domain?" by consulting a copy of the Public Suffix List (PSL). That approach was useful, but it left the receiver dependent on a separately maintained heuristic list.

RFC 9989, which obsoletes RFC 7489 and RFC 9091, changes the model. DMARC now defines a DNS tree walk that discovers valid DMARC Policy Records as it moves up the namespace. The result affects both policy discovery and relaxed SPF or DKIM alignment.

The practical change is not simply “replace one list with DNS.” A receiver now needs to understand policy records at several levels, the psd tag, the eight-label query limit, and the difference between the domain where policy was found and the Organizational Domain used for alignment.

The old public-suffix model

Under the original DMARC algorithm, the receiver used a public suffix list to find the registration boundary. For example:

• news.example.com had example.com as its Organizational Domain.
• billing.example.co.uk had example.co.uk as its Organizational Domain.

The receiver then looked for a DMARC record at the Author Domain and, if necessary, at that Organizational Domain. The public suffix itself, such as com or co.uk, was normally not an Organizational Domain.

The weakness was operational rather than conceptual. RFC 7489 did not require one particular list or specify how often a receiver should refresh it. Two receivers could therefore classify the same domain differently after a suffix change or because their list copies differed.

The Public Suffix List remains useful for many DNS and web applications. It is no longer the authority that a DMARC receiver must use to discover the Organizational Domain under RFC 9989.

The new tree-walk idea

The receiver starts with the Author Domain from the message's From: field and queries for a DMARC record at that exact name:

_dmarc.mail.news.example.com

If a single valid DMARC record is found there, it is the policy record for the message. If not, the receiver removes the left-most label and tries the parent:

_dmarc.news.example.com
_dmarc.example.com
_dmarc.com

Each query is for a DMARC TXT record. Records with the wrong version are discarded. Multiple DMARC records at one location are discarded rather than combined. A single valid record containing psd=n or psd=y ends the walk because it explicitly identifies the boundary.

This produces two related but separate answers:

• DMARC Policy Domain: the domain where the applicable policy record was found.
• Organizational Domain: the domain used when comparing the Author Domain with SPF and DKIM identifiers in relaxed alignment.

They are often the same, but tree-walk processing means they do not have to be.

Why psd matters

RFC 9989 adds the psd tag to make the boundary discoverable through DNS:

A normal domain owner can use psd=n when it wants to make the Organizational Domain explicit. A public-suffix operator publishing policy at a suffix must use psd=y.

Consider a receiver evaluating a.mail.example.com:

1. It finds no usable record at a.mail.example.com.
2. It finds a record at mail.example.com with no explicit boundary.
3. It finds a record at example.com with psd=n.

The Organizational Domain is example.com. If the record at mail.example.com had psd=n, the Organizational Domain would instead be mail.example.com. This allows a large organization to establish deliberate policy boundaries below its usual domain apex.

How public-suffix policy is discovered

A PSD policy is the lowest-preference policy location, after the Author Domain and its Organizational Domain. It does not automatically override a domain owner's record.

For example, imagine a public suffix operator publishes this record:

_dmarc.bank.example. TXT "v=DMARC1; psd=y; p=reject; np=reject"

For mail from giant.bank.example, a tree walk can find the policy at giant.bank.example and then the PSD record at bank.example. The psd=y marker says that bank.example is the public suffix, so the Organizational Domain is the label immediately below it: giant.bank.example.

For mail from unknown.bank.example where no record exists at the Author Domain or its Organizational Domain, the PSD record can be the applicable policy. The receiver uses the sp policy for an existing subdomain and np for a non-existent Author Domain when those tags apply. If neither is present, the p value supplies the subdomain policy.

This folds the useful PSD DMARC behavior into the main DMARC standard. RFC 9091 described an experimental PSD registry; RFC 9989 obsoletes that approach and uses DNS-discovered psd=y records instead.

Existing and non-existent subdomains

The policy record's location and the DNS state of the Author Domain determine which policy value applies:

The np distinction is especially useful for namespace protection. A real subdomain may be a legitimate sender that is still being brought under policy. A name that returns NXDOMAIN is a different operational case. See How to use the DMARC np tag for the rollout implications.

Why there is an eight-label limit

Walking all the way up an arbitrary domain would let a sender force a receiver to perform a large number of DNS queries simply by putting many labels in the From: domain.

RFC 9989 therefore limits the walk. If the Author Domain has eight or fewer labels, the receiver begins with its immediate parent. If it has more than eight labels, the first tree-walk target is shortened so that seven labels remain. The walk then proceeds upward, with no more than eight queries for the search.

There is an important deployment consequence: a DMARC record below the first shortened target will not be discovered by the tree walk. If an organization uses an Author Domain deeper than eight labels and needs a policy specifically for it, it should publish a DMARC record at the exact Author Domain. The exact-domain lookup happens before the tree walk.

What changes for relaxed alignment

Policy discovery and alignment are connected, but they are not the same lookup.

For relaxed alignment, the receiver may need tree walks for:

• the Author Domain
• the SPF-authenticated MAIL FROM domain, when SPF passes
• each DKIM signing domain with a passing signature

The receiver compares the Organizational Domains selected for those names. If they match, the identifiers are aligned. Strict alignment still uses a direct domain comparison and does not need a shared Organizational Domain.

This can change a result compared with a stale PSL-based implementation. A receiver using RFC 9989 may discover an explicit psd=n boundary or a psd=y public suffix record where an older implementation would infer a different boundary. A domain owner should not assume that every receiver will transition at the same time.

Operational advice for domain owners

Most organizations do not need to redesign their DMARC records immediately. The safest practices are:

1. Publish a valid DMARC record at every Author Domain that needs an unambiguous policy.
2. Publish the intended Organizational Domain policy, rather than relying on a receiver to infer it from a suffix list.
3. Use psd=n when the record is deliberately defining the Organizational Domain boundary.
4. Keep SPF and DKIM identifiers aligned under both the old PSL-based behavior and the RFC 9989 tree-walk behavior during the transition.
5. Test long or unusually delegated names against the eight-query limit.
6. Review aggregate reports for the policy domain and disposition a receiver reports after changing DNS.

Publishing explicit records is particularly important when interoperability with older receivers matters. An older implementation may still use RFC 7489-style PSL discovery, while a newer one uses RFC 9989 tree walking.

Operational advice for receivers and report processors

Receiver and authentication-tool maintainers have more work to do:

• implement the tree-walk query order and the eight-label limit
• reject multiple valid-looking DMARC records at one location instead of merging them
• preserve both the policy domain and the discovered Organizational Domain
• interpret psd=n, psd=y, and the default psd=u correctly
• distinguish existing subdomains from NXDOMAIN names when applying sp and np
• expose the discovery method in diagnostics or aggregate-report data when possible

RFC 9990's aggregate-report schema includes an optional discovery_method field. It can be psl or treewalk, which helps a report consumer understand why two receivers may have selected different policy domains during a transition.

The boundary is now published where it is used

The key change in RFC 9989 is that the Organizational Domain is no longer only an external-list calculation. DMARC policy records can participate in defining the namespace boundary, and a public-suffix operator can identify its own policy with psd=y.

For senders, explicit records and aligned identifiers remain the best interoperability strategy. For receivers and tooling, the important distinction is to record what was discovered, where it was discovered, and which domain boundary was used for alignment. That makes a tree-walk result explainable instead of looking like a mysterious SPF or DKIM mismatch.

In summary

DMARC tree-walk discovery changes three assumptions:

• the PSL is no longer the only way to determine an Organizational Domain
• the domain where policy is found can differ from the Organizational Domain used for alignment
• public-suffix policy is discovered through psd=y, while psd=n lets an organization declare its own boundary

The algorithm gives domain owners more control and gives receivers a standards-defined fallback path, but it also introduces a transition period. Explicit DMARC records, careful handling of sp and np, and diagnostics that preserve the discovery method will prevent most surprises.