> On Jun 15, 2026, at 9:02 PM, John Levine <[email protected]> wrote: > > It appears that Dan Mahoney via mailop <[email protected]> said: >> All, >> >> A little background: >> >> In prior versions of DMARC, one was encouraged to use a "public suffix list" >> to determine where the apex of an >> organizational domain was (thus assuming that the highest a search could go >> was at the public suffix). >> >> DMARCbis changed this, saying basically that you should traverse upward >> through the DNS until you encounter a tag with >> psd=n (indicating that you're an apex of an organization), or psd=y >> (indicating that you're the "public suffix" (e.g. >> .com, .org, etc). This then requires that every public suffix domain should >> insert a new _dmarc TXT record. Because >> many cctlds are bureaucratic and complicate, adoption for this will be >> somewhat unpredictable. > > No, that's not what RFC 9989 says. The psd=y/n tags are expected to be rare. > In the > usual case where the tree walk doesn't find either, the Organizational domain > is > the highest level in the tree that has a _dmarc record, which in nearly every > case will produce the same result as the former PSL check. You can publish > psd=n > to say "this is an org domain" or psd=y to say "the org domain is one level > down > from here", but again, those will be rare. > > See section 4.10 and particularly 4.10.2 of RFC 9989.
I was imprecise here, and I apologize. My use of the word "requires" is overloaded there and doesn't mean any kind of actual RFC-2119 "must" requirement, just that that would be what would stop an upward search in cases where one does actually happen (i.e. where no author domain DMARC record is present), per my reading of how the tree walk operates (steps 5-7). The listed example even includes polling for _dmarc.com TXT in cases where the search occurs. Some TLD's already have this style of record. Others may never. That said: The short version of what I was trying to share is that DMARCbis utilizes tags in existing records that are new (and others that are now deprecated) and that I thought it was useful to survey as best I can how widely deployed these affected tags are -- this data (as well as the over-time adoption rates) may be of interest not only to other implementers, but also other operators. This feels as useful as tracking DNSSEC deployment, or root zone propagation. I am attempting to be open with both my data and tools. This was not either a gripe about DMARCbis nor any judgement of the authors. Thanks for the work you've done here, John. -Dan _______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
