Introduction
Most of DMARC's day-to-day behaviour is easy to reason about: a receiver reads the From domain, looks up a policy, checks alignment, and applies the result. The part that quietly causes the most confusion sits underneath all of that — the question of which domain actually owns the policy. When someone sends from billing.emea.shop.example.co.uk, which name does the receiver treat as the boundary of the organization, and where does it look for a DMARC record? That question is organizational domain discovery, and DMARCbis, published in May 2026 as RFC 9989, is where the current answer lives.
This article is written for engineers who build or operate DMARC tooling and for the MSP technical staff who have to explain the edge cases. It covers what an organizational domain is, why public-suffix handling matters, how RFC 9989 absorbed the old PSD extension, and why accurate domain-boundary logic becomes unavoidable once you manage domains at scale. For the wider picture, see the core DMARC standard explained and the DMARC for MSPs pillar.
Why this topic matters
A single organization managing one domain almost never notices discovery subtleties. The From domain is example.com, the policy is at _dmarc.example.com, and everything lines up. The trouble appears at scale and at the margins: country-code domains with multi-label suffixes, hosting platforms that hand out subdomains to unrelated tenants, delegated marketing domains, and registry-level names that want to protect everything beneath them. An MSP with hundreds or thousands of domains in its portfolio will, statistically, hold examples of all of these. Getting the boundary wrong means a receiver looks for a policy in the wrong place, and a domain you believe is protected is quietly unprotected — or a report you are reading is attributed to the wrong owner.
What "organizational domain" means
The organizational domain is the level of a name that represents the actual owner, as opposed to the registry infrastructure above it or the operational subdomains below it. For mail.example.com, the organizational domain is example.com. The subtlety is that you cannot find that boundary just by counting labels, because the registry structure varies by top-level domain. In example.com, the owner's name is the second label from the right. In example.co.uk, it is the third, because co.uk is a registry suffix that many unrelated organizations register beneath. DMARC needs the organizational domain for two jobs: to decide where to look for a policy when the exact From domain has none, and to evaluate relaxed alignment, where a signing or envelope domain is considered aligned if it shares the organizational domain with the From header.
Why public-suffix handling matters
The list of registry suffixes — .com, .co.uk, .gov.uk, .com.au, and thousands more — is what tells a receiver where the ownership boundary sits. If a receiver misjudges that boundary, two failure modes follow. If it treats the boundary as too high, it may consider two unrelated organizations that happen to share a registry suffix as aligned, which is a security problem. If it treats the boundary as too low, it fails to discover a legitimate organizational policy, and mail that should be protected is evaluated as if no policy existed. Public-suffix handling is therefore not a cosmetic detail; it is load-bearing for both the security and the correctness of every evaluation. Historically this was driven by the community-maintained Public Suffix List, and differences in how up to date each receiver's copy was could produce subtly different results for the same domain.
How RFC 9989 folds in PSD handling
Public Suffix Domains — registry-level names such as co.uk or gov.uk whose operators may want to publish protective policy for the whole family beneath them — were originally addressed by RFC 9091, a separate experimental extension. DMARCbis obsoletes RFC 9091 and folds PSD handling directly into the core RFC 9989, so there is now one specification that describes both ordinary organizational discovery and the public-suffix case. The psd tag, covered in new DMARC tags explained, is how a record declares that it sits at a public-suffix level. The practical benefit of consolidation is that implementers no longer reason about an add-on bolted onto the base protocol; the boundary rules, the discovery walk and the PSD case are defined together, which reduces the room for two conformant implementations to disagree.
Edge cases that bite at scale
The general rule is simple; the edge cases are where engineering time goes. A few categories recur across large portfolios.
- Multi-label country-code suffixes such as
co.uk,com.auandgov.uk, where the organizational boundary is one label deeper than the naive "second from the right" assumption, and where a stale suffix list produces the wrong answer. - Delegated platform subdomains, where a SaaS provider gives a client a name beneath the provider's own domain, so the name that appears organizational to a receiver is not owned by the client at all.
- Hosting and website builders that place many unrelated tenants under a single parent domain, so relaxed alignment must not treat two tenants as sharing an organization.
- Newer and less common top-level domains whose registry structure may not be reflected identically in every receiver's suffix data, which is precisely the kind of drift the DMARCbis boundary rules aim to reduce.
- Registry and government operators publishing PSD-level policy, where a client domain beneath such a suffix may see that policy referenced in reports even though the client did not publish it.
None of these is exotic on its own. What makes them an operational concern is volume: across enough domains, at least a handful will land on each of these edges, and a platform that assumes the simple case will misattribute or mis-evaluate them.
Why MSP platforms need accurate domain-boundary logic
For a one-domain administrator, a discovery bug is invisible because their domain never exercises the edge cases. For an MSP platform, the boundary logic is a core correctness feature, because the portfolio guarantees the edge cases will show up. If your platform computes the organizational domain incorrectly, several things go wrong at once: alignment can be judged wrongly, a policy lookup can land on the wrong name, and aggregate reports can be attributed to the wrong client. Each of those undermines the confidence a client places in your reporting. This is why boundary logic deserves real test coverage — a fixture set of co.uk-style suffixes, delegated subdomains, PSD parents and wildcard cases, exercised against the RFC 9989 rules — rather than being assumed to work because it works for the common case. When you are investigating a specific domain's structure by hand, a DNS lookup is the fastest way to see exactly what records exist at each level and where the real boundary sits.
A note on subdomains and non-existent names
Discovery and subdomain policy are closely related, because once a receiver knows the organizational boundary it also has to decide how to treat names below it — including names that do not exist in DNS at all. That is where the np tag comes in, giving owners a clean way to reject mail from non-existent subdomains without affecting real ones. The interaction between discovery, sp and np is worth understanding as a set; the non-existent subdomains and the DMARC np tag article picks up that thread in detail.
Related articles
- DMARC for MSPs — complete guide
- RFC 9989 explained: the core DMARC standard for MSPs
- New DMARC tags explained: np, psd and t
- Non-existent subdomains and the DMARC np tag
Authoritative references
- RFC 9989 — core DMARC protocol, including organizational domain discovery and PSD handling
- RFC 7489 — the obsoleted 2015 specification
- Public Suffix List — the community-maintained suffix boundary list
Author: DMARC AI editorial team Last updated: August 2026