PSL entries publish MX/SPF/DMARC (potential DMARC/RFC 7489 “public suffix” alignment concern)

[groundcat]

I did a non-rigorous exploratory scan of PSL entries against DNS to get a high-level sense of how often public suffixes appear to publish mail-related DNS records (MX, SPF, DMARC). This is not a comprehensive measurement study, and it has important limitations (see below), but I’m sharing the aggregated results in case it’s useful context for PSL users/operators.

As outlined at https://datatracker.ietf.org/doc/html/rfc7489#section-3.2 and mentioned by #2709 #2292
#1418 and #632, DMARC’s concept of “Organizational Domain” relies on a public suffix list. A public suffix itself is not an organizational domain for DMARC alignment purposes, so publishing MX/SPF/DMARC directly on a public suffix can create ambiguity and downstream confusion for receivers and tooling.

Dataset and method (high-level)

• Input: PSL entries with per-domain DNS checks for MX, SPF (TXT), and DMARC (_dmarc TXT).
• “Violation” definition used here: any PSL domain with MX or SPF or DMARC present.
• Deduplication key: psl_domain (this dataset ended up being 1 row per domain).
• DNS outcomes were taken from a single point-in-time query run (records can change).

Datasets

CSV files:
https://github.com/groundcat/PSL-Sandbox/tree/main/exploratory_stuff/rfc7489/datasets

Findings

1) Overall metrics

• Total PSL entries checked: 10,064 (unique)
• Violations (MX/SPF/DMARC present): 2,196
• Overall “violation” rate: 21.82%

2) Breakdown by PSL section

ICANN

• Total: 6,930
• Violations: 920
• Rate: 13.28%

Private

• Total: 3,134
• Violations: 1,276
• Rate: 40.71%

3) Violation types (MX/SPF/DMARC combinations)

ICANN (counts)

• MX Only: 81
• SPF Only: 30
• DMARC Only: 9
• MX + SPF: 52
• MX + DMARC: 13
• SPF + DMARC: 651
• MX + SPF + DMARC: 84

Private (counts)

• MX Only: 166
• SPF Only: 55
• DMARC Only: 302
• MX + SPF: 295
• MX + DMARC: 122
• SPF + DMARC: 111
• MX + SPF + DMARC: 225

Overall most common type: SPF + DMARC (762 total)

4) Examples

I used a simple “severity” sort: 3 records > 2 records > 1 record, then alphabetical. Also looked at domain age where present.

Top ICANN examples (20)

kharkov.ua, crimea.ua, cherkassy.ua, huissier-justice.fr, cci.fr, net.ua, ms.gov.br, rj.gov.br, pr.gov.br, df.gov.br, …

Top Private examples (20)

it.com, africa.com, cistron.nl, avocat.fr, us.org, demon.nl, eu.org, tche.br, ru.com, uk.com, …

5) MX provider distribution (heuristic)

Parsed MX hostnames and bucketed them by very simple pattern matching (this is approximate).

Broad categories observed among violating domains:

• Self-hosted / org-specific: 1,313
• Google Workspace: 329
• Microsoft 365: 37
• Other email providers: 55

Most common parsed “providers” (top few, detailed parsing):

• Google Workspace: 250
• no-ip.com: 93
• googlemail.com: 79
• registrar-servers.com: 55
• Microsoft 365: 37
• cloudflare.net: 33
• …

6) SPF patterns

Top SPF signature:

• v=spf1 -all : 829

Common include/redirect targets (top few):

• no-ip.com : 81
• _spf.google.com : 37
• spf.protection.outlook.com : 33
• amazonses.com : 21
• mail.zendesk.com : 20

7) DNS error / completeness notes

Across all lookups (MX + SPF + DMARC): 30,192 total queries (10,064 domains × 3).

• Successful (error = null): 7,233 (24.0%)
• NoAnswer: 14,468
• NXDOMAIN: 8,244
• NoNameservers: 158
• LifetimeTimeout: 89

Interpretation note: for “presence of record” detection, NXDOMAIN and NoAnswer were treated as compliant outcomes (no record), but I’m calling out these totals for transparency.

8) Trend by creation year (limited)

Creation dates were available for ~60.6% of entries. With that caveat, I generated a basic “violation rate by creation year” line chart for the subset with a known year. I’m not drawing strong conclusions from it, but can share the underlying table if helpful.

Limitations

• Point-in-time DNS: records can change frequently.
• Not a rigorous classification: “violation” here just means record exists (not whether it’s “bad” operationally).
• Private section context: higher rates may reflect platform/service behavior and could be expected/intentional.
• Provider inference is heuristic and will misclassify some MX setups.

Questions for the PSL community

Is this a known/expected phenomenon that PSL consumers already handle?

Would it be useful to document guidance for operators that public suffixes generally should not publish mail auth records (MX/SPF/DMARC), even if PSL itself can’t enforce it?

[dnsguru]

Wow. Nice datascience. Really good work.

There has never been any directive, suggestion or other guidance related to MX etc, so this is more about what evolved outside the project. I typically am more vocal about not changing what we do on the PSL due to these types things that depend upon the PSL evolving outside the project and our need to consider them when we are thinking of changes.

I am forming some more thoughts beyond these comments, and will reply once I have a chance to talk with some peers in the M3AAWG and SSAC about this.

I know there is a spectrum of attitudes about the way to configure SPF/DMARC/MX generally (as well as sophisitication levels), and very likely some temporal (pre-DMARC) or interop factors (some from regions or orgs or providers that are not up to the latest standards and they need their shit to work).

So far, I could see a need to alter our intake process a little to introduce asking the requestor to indicate if they intend to operate email at the string(s) (ie if they are adding chewbacca.wookie to the PSL, will they operate email addresses like falcon@chewbacca.wookie) and mention there may be affectation.

Implementation in the wild of SPF/DMARC is absolutely not 100%, and I would estimate the actual to perhaps 10-20%. If it were 100%, my educated guess is that your statistics would indicate a much higher degree of overlap than you see in the exploratory scan.

PSL has been used by DMARC as a means to overcome doing a tree walk of domains, and I have seen SPF and MX put in place to null route email as opposed to being something actually handling service, so I think there's likely some false positives in the mix.

I also think that in the real world of humans and their tendancies, people configure email MX first typically, and then maybe later add SPF or DKIM later (typically triggered by some provider forcing it and then the domain admin has to react and put something in place).

In summary, my initial 2 cents here is that we have been rather agnostic typically about being prescriptive on use cases of listed items. I don't know what we could put in place here at the PSL other than an increased set of automated checks at the onset to scan for DMARC/SPF/MX when looking for the _PSL leaf TXT record, and I struggle with if that is appropriate or not.

[groundcat]

Appreciate the thoughtful take @dnsguru ! I’m broadly in agreement, and I’m not sure PSL can (or should) try to enforce a “no MX/SPF/DMARC on PSL labels” rule as a formal requirement given how legacy/defensive real-world configs can be; the most I can see is the kind of gentle, situational nudge sometimes @simon-friedberger mentioned during PR review (e.g., if a requestor implicitly signals they plan to run mail at the suffix itself by including an address like falcon@chewbacca.wookie for chewbacca.wookie that is/will be a public suffix, it’s probably worth a heads-up about potential downstream effects).

On the “expectation vs. scan results” question, I dug into the overlap patterns and I think the biggest driver is that this dataset is PSL labels (not normal org domains), and a large share of the “violations” look like defensive/parked-domain posture rather than mail rollout: the single most common combo is SPF+DMARC with no MX (762/2196), and among DMARC-without-MX cases the DMARC policy is overwhelmingly p=reject (1036) and the SPF qualifier is overwhelmingly -all (748/762) which lines up with industry guidance for “non-sending/parked” domains to publish DMARC reject + SPF -all even when they don’t run mail service: https://www.m3aawg.org/M3AAWG-Protecting-Parked-Domains-BCP-update-2022-06 plus, in the write-up some of the high % impressions may come from conditioned breakdowns on the violations-only subset rather than the full population.

Full CSVs are uploaded here (expect both FP/FN in a one-run snapshot):
https://github.com/groundcat/PSL-Sandbox/tree/main/exploratory_stuff/rfc7489/datasets