Organizational domain in DMARC alignment explained

The organizational domain is the domain actually registered with a registrar, the root that owns everything beneath it: for mail.eu.example.com, it is example.com. Email authentication leans on this concept constantly, because policies published at the root govern subdomains, and DMARC's relaxed alignment asks whether two names share an organizational domain rather than whether they match exactly. Getting the boundary right is what makes bounce.mail.example.com count as you while example.org does not.

Why the boundary is not obvious

Chopping to the last two labels fails immediately: example.co.uk is a registered domain, while co.uk is a public suffix under which thousands of unrelated parties register. The boundary between suffix and registration cannot be computed from the name alone, which is why email software historically consulted the Public Suffix List, a community-maintained inventory of suffixes, to find where registration begins. One label below the suffix is the organizational domain.

Where authentication uses it

DMARC uses it twice. Policy discovery: mail from a subdomain without its own DMARC record falls under the organizational domain's record, with the sp and np tags steering subdomain policy from the root. And relaxed alignment: an SPF or DKIM pass counts when its domain shares the From: header's organizational domain, which is exactly what lets bounce subdomains and ESP signing subdomains authenticate mail displayed from the root. Strict alignment ignores the concept and demands exact matches, which is why it breaks standard subdomain patterns.

From the PSL to the tree walk

DMARCbis, the 2025 Standards Track revision, replaced the Public Suffix List dependency with a DNS tree walk: receivers query for DMARC records up the name hierarchy, and tags in discovered records (psd=y marking a public suffix boundary) express the structure in DNS itself. For ordinary corporate domains both methods agree, so the change is invisible; it matters for public suffix operators and unusually deep multinational domain trees, who can now declare their own boundaries instead of depending on a text file's maintenance.

Frequently asked questions

Is www.example.com an organizational domain?

No, it is a subdomain of the organizational domain example.com. Registration happens at example.com; everything deeper is created freely by the owner.

Does relaxed alignment mean any subdomain can authenticate for any other?

Within the same organizational domain, an aligned pass on one subdomain covers mail displayed from another, yes. Where subdomains are separate trust boundaries (different teams, different risk), strict alignment or separate DMARC records restore the walls.

How do I check what the organizational domain of a name is?

Consult the Public Suffix List (publicsuffix.org) or any PSL-aware library: strip the public suffix, keep one more label. Under DMARCbis, receivers derive it from the tree walk, with the same answer for normal domains.

Key takeaways

The organizational domain is the registered root, one label below the public suffix
DMARC discovers subdomain policy at it and measures relaxed alignment against it
The boundary cannot be computed from the name alone: the PSL supplied it historically, the DMARCbis tree walk supplies it now
Subdomains separate reputation while staying inside the alignment boundary; separately registered domains are strangers