Step two of the lookup needs an organisational domain, and DNS does not provide one. Nothing in the protocol distinguishes co.uk from example.co.uk — both are just labels. The answer comes from a list maintained by volunteers.
What the list is
The Public Suffix List enumerates every suffix under which anyone may register a name: every TLD, every co.uk-style second level, and — significantly — a large private section contributed by hosting providers.
A domain's organisational domain is: the longest matching public suffix, plus one more label. bbc.co.uk suffix co.uk -> bbc.co.uk mail.bbc.co.uk suffix co.uk -> bbc.co.uk example.com suffix com -> example.com a.b.example.com suffix com -> example.com myapp.github.io suffix github.io -> myapp.github.io
That last line is the interesting one. GitHub added github.io to the private section, so every GitHub Pages site is its own organisational domain — which stops one user’s DMARC policy applying to everybody else’s.
Why it matters for DMARC
| Question | Answered by |
|---|---|
| Which record does step 2 query? | The organisational domain, derived from the list |
| Does a relaxed-alignment subdomain count? | Yes, if both resolve to the same organisational domain |
| Is bbc.co.uk a subdomain of co.uk for DMARC? | No — co.uk is a public suffix, so bbc.co.uk is an organisational domain |
Relaxed alignment is defined in terms of the organisational domain, so the list decides alignment outcomes as well as policy discovery. Two names under the same suffix align; two names under different suffixes do not, regardless of who owns them.
Where it goes wrong
- Receivers carry different snapshots. The list changes weekly and nobody updates in lockstep, so a newly added suffix produces inconsistent behaviour across receivers for a while.
- A new TLD may be missing from an old copy. A receiver with a stale list derives the wrong organisational domain and queries the wrong record — or treats your registrable domain as a public suffix and finds nothing.
- The private section is self-service. A provider can add or remove an entry, changing the alignment and policy-discovery behaviour of every customer under it, with no notice to those customers.
- There is no way to signal your own boundary. If you operate a namespace where customers register names, your only recourse is to submit an entry and wait for the world to pick it up.
This is the reason DMARC failures can appear without a change
Your record is identical, your senders are identical, and a receiver updated its copy of a list you have never heard of. It is rare, it is real, and it is worth knowing about before you spend a day looking for a change you did not make.