DMARC Tree Walk vs the Public Suffix List (and psd=)

Under RFC 7489, a receiver found your organizational domain by checking the From domain against a Public Suffix List. RFC 9989 replaces that with a DNS tree walk: the receiver queries _dmarc.<name> TXT records from the From domain upward, at most eight times, and a new psd tag lets registries and other public suffix operators mark where the walk should stop. If you run ordinary domains, you don't set psd, and your records keep working.

The organizational domain matters in two places: it's where the receiver finds a policy when your exact From domain has no record, and it defines relaxed alignment. RFC 9989 §3.2.10.1: "When the Author Domain ... has the same Organizational Domain ... as an Authenticated Identifier ..., the two are said to be in relaxed alignment."

Why the PSL was dropped

RFC 9989 §4.10 gives the history. RFC 7489 "mandated no requirement for a specific PSL for Mail Receivers to use (though it did suggest the one found at https://publicsuffix.org/) nor did it provide any guidance for the frequency of regular retrieval of the PSL". It "acknowledged the possibility of interoperability issues caused by Mail Receivers choosing different PSLs and even suggested that if a more reliable and secure method for determining the Organizational Domain could be created, that method should replace reliance on a PSL."

The tree walk is that method. It uses data the domain owners publish in DNS themselves, so every receiver sees the same inputs, and there's no third-party list to fetch or let go stale.

How the walk works

The generic procedure is seven steps in §4.10. Condensed:

1. Query the TXT record at _dmarc. plus the starting name.
2. Discard records that don't start with the DMARC version tag. If more than one record remains, discard them all. "If a single record remains and it contains a "psd=n" or "psd=y" tag, stop."
3. Count the labels in the name (x).
4. Shorten the name: "If x < 8, remove the left-most (highest-numbered) label from the subject domain. If x >= 8, remove the left-most (highest-numbered) labels from the subject domain until 7 labels remain."

Steps 5 to 7 query the shorter name, apply the same discard and stop rules, drop one more label, and repeat until the walk stops or no labels remain.

The shortcut in step 4 is there for abuse, not tidiness. §4.10: without it, "an ill-intentioned Domain Owner" could send mail from names with "tens or even hundreds of labels" to make receivers do DNS work. With it, "Author Domains with more than eight labels do not result in more than eight DNS queries."

The RFC's own example is a.b.c.d.e.f.g.h.i.j.mail.example.com, 13 labels. The walk queries:

_dmarc.a.b.c.d.e.f.g.h.i.j.mail.example.com   (13 labels, the starting name)
_dmarc.g.h.i.j.mail.example.com               (cut to 7)
_dmarc.h.i.j.mail.example.com
_dmarc.i.j.mail.example.com
_dmarc.j.mail.example.com
_dmarc.mail.example.com
_dmarc.example.com
_dmarc.com

That's eight queries. No name starting with b through f is ever queried.

From records to an organizational domain

The walk collects records. §4.10.2 then picks the organizational domain with three rules:

1. "If a valid DMARC Policy Record contains the "psd" tag set to "n" ("psd=n"), this is the Organizational Domain, and the selection process is complete."
2. "If a valid DMARC Policy Record, other than the one for the domain where the Tree Walk started, contains the "psd" tag set to "y" ("psd=y"), the Organizational Domain is the domain one label below this one in the DNS hierarchy, and the selection process is complete."
3. "Otherwise, select the DMARC Policy Record found at the name with the fewest number of labels."

Worked example

Take a fictional suffix, example, whose operator publishes a record, and a company registered under it:

_dmarc.example        "v=DMARC1; p=reject; psd=y"
_dmarc.shop.example   "v=DMARC1; p=quarantine; sp=reject; rua=mailto:dmarc@shop.example"

Mail arrives From news.shop.example, a real host with no DMARC record of its own.

• Query 1: _dmarc.news.shop.example. Nothing.
• Query 2: _dmarc.shop.example. One valid record, no psd tag, so keep walking.
• Query 3: _dmarc.example. One valid record with psd=y, so stop.

Selection: no record has psd=n. The record at example has psd=y and isn't the starting name, so the organizational domain is one label below it: shop.example. Policy discovery (§4.10.1) then takes sp from that record because the Author Domain exists, and news.shop.example gets reject. §4.10.1 also rules out a fallback to the suffix operator's policy here: "PSD policy is not used for Organizational Domains that have published a DMARC Policy Record."

Now remove psd=y from _dmarc.example. The walk no longer stops early, rule 3 applies, and the record with the fewest labels wins, so example itself becomes the organizational domain. Every company under the suffix would then share one organizational domain, and relaxed alignment would treat them as the same organization. That's why §5.2 says: "if a PSO ... publishes a DMARC Policy Record, it MUST include the "psd" tag ... with a value of "y" ("psd=y")."

Who should set psd

The three values, from §4.7:

• psd=y: "PSOs include this tag with a value of "y" to indicate that the domain is a PSD." Registries and anyone else operating a public suffix.
• psd=n: "The DMARC Policy Record is published for a domain that is not a PSD, but it is the Organizational Domain for itself and its subdomains." This one is for organizations that deliberately split DNS management, where a subdomain such as eu.example.com should stand on its own. It stops the walk at that name, so eu.example.com stops being relaxed-aligned with example.com. Only set it if you want that. §5.1.8 adds a caveat: because of the label shortening, a psd=n record deep in a long name can be skipped by the walk and never discovered.
• psd=u: the default, meaning the domain is not a PSD "and may or may not be an Organizational Domain for itself and its subdomains."

If you run a SaaS on yourapp.com with a sending subdomain or two, leave psd out. In the normal case, send.yourapp.com still resolves to yourapp.com as its organizational domain under the tree walk, the same answer the PSL gave.

The one exception is defensive. §11.8 says that if a public suffix above you "publishes a DMARC Policy Record without the appropriate "psd=y" tag, Organizational Domain owners can add "psd=n" to their Organizational Domain's DMARC Policy Record" so the walk stops at your domain. The same section suggests checking the records of the suffixes above you periodically, "perhaps weekly".

Seeing it in your reports

RFC 9990 adds an optional discovery_method element to policy_published in aggregate reports. Its values are psl and treewalk (the DiscoveryType enumeration in RFC 9990 Appendix A), and §3.1.1.5 describes it as "The method used to discover the DMARC Policy Record used during evaluation."

For most domains both methods give the same answer. If two receivers show different policy_published domains for the same mail, check this field first. It's optional, so its absence tells you nothing.

To see what your domain publishes at each level, run the DMARC Record Checker. To see discovery_method in a report you've received, paste it into the DMARC XML Analyzer. For the other RFC 9990 report fields, see what's new in DMARCbis aggregate reports.