An organisational domain is a boundary used in DMARC processing. It helps a receiver find policy when a visible From domain has no record of its own, and it helps compare authenticated identities in relaxed alignment. Those are related operations, but they are not the same question.
The shortcut “take the last two labels” is unreliable. A name under a multi-part public suffix, such as co.uk, already shows why counting two labels can select the suffix instead of the organisation. The current specification adds a further reason to avoid shortcuts: RFC 9989 defines DNS tree walking rather than relying on a public suffix list alone.
Write down the three questions separately
Begin with the actual domain in the message's From address, called the Author Domain. Then ask:
- Which DMARC policy record applies to this Author Domain?
- What organisational domain does the applicable discovery process establish for each identity being compared?
- Does the passing SPF or DKIM identity meet the selected alignment mode?
A valid record directly at the Author Domain wins policy selection. That does not automatically prove that the Author Domain is the organisational domain used for relaxed alignment. Treat a DNS checker that displays only one “domain” field as a starting view, and collect the actual names and responses needed to explain its conclusion.
The identity-chain guide helps identify the From, envelope and DKIM domains before discovery begins.
Follow a labelled example
The following is a synthetic DNS snapshot. It illustrates a fictional registry beneath the reserved .example namespace; it is not a live query result or an assertion about any real public suffix.
Assume the existing Author Domain is invoice.harbour.registry.example. Its message has a passing DKIM signature with d=sign.harbour.registry.example. SPF passes for a separate service domain that does not align.
| Query target | Illustrative response | Consequence |
|---|---|---|
| _dmarc.invoice.harbour.registry.example | No DMARC policy record | Continue discovery |
| _dmarc.harbour.registry.example | v=DMARC1; p=none; sp=quarantine; psd=n | Establish this explicit organisational boundary and stop the walk |
| _dmarc.registry.example | Not queried after the stop | No further response is needed for this walk |
The selected policy is the record at harbour.registry.example. Because invoice.harbour.registry.example exists and is a subdomain, its applicable assessment policy is quarantine through sp. The organisational domain is harbour.registry.example because the record explicitly signals psd=n.
For the DKIM identity, the illustrative lookup at _dmarc.sign.harbour.registry.example returns no record, followed by the same psd=n boundary record. The authenticated signing identity and Author Domain therefore share an organisational domain. With relaxed DKIM alignment, that passing DKIM signature supplies an aligned path. Strict alignment would require exact identity equality, which these two different names do not have.
The example deliberately keeps policy selection, boundary discovery, authentication and alignment visible as separate results. Changing the policy value would not turn the unequal domain strings into an exact match.
Understand what stops the walk
RFC 9989 Section 4.10 specifies the queries, record filtering and limits. A valid record with psd=n identifies an organisational boundary. A valid record with psd=y identifies a public suffix boundary, with the organisational-domain selection rules accounting for the domain one label below it when appropriate.
If neither signal resolves the boundary, the specification provides selection and fallback rules. It also bounds long-name discovery to avoid an attacker forcing unlimited lookups. A production implementation needs that complete algorithm, including invalid or multiple records and DNS errors; removing labels until a familiar name appears is not a substitute.
Do not copy psd=y into an ordinary organisation's record. It describes a suffix role. psd=n can support intentional organisational boundaries, including delegated subtrees, but should follow a documented namespace decision rather than a universal checklist.
Investigate differences between tools and receivers
An older implementation may use the public-suffix approach associated with RFC 7489. A newer implementation may follow RFC 9989 tree walking. DNS responses, caches and implementation support can therefore matter when results disagree.
For a useful comparison, retain the complete identity names, query responses with timestamps, discovered policy record, alignment settings and receiver result. Ask the tool vendor which discovery model it implements. Do not infer universal adoption from a publication date or change DNS solely to make two dashboard labels agree.
Separate a genuine boundary disagreement from a raw authentication problem. A missing DKIM signature, failed signature or unapproved sending route will not become valid because the organisational-domain calculation is corrected.
Make the boundary an operational record
For domains with several business units or delegated DNS teams, record who can publish beneath each boundary and which services may authenticate mail there. Revisit that record when an application gains a subdomain, a business unit changes DNS management or a supplier is retired.
Use subdomain policy verification to check which policy applies, and the alignment comparison when deciding what domain relationships are acceptable.
The useful result is a reproducible chain: these were the message identities, these DNS responses established the relevant boundaries, this policy applied, and this passing identity did or did not align. A guessed domain label cannot provide that evidence.
Use a boundary decision card
Use this card for organisational-domain selection, not as a replacement for policy discovery. First check the Author Domain for its own policy. A direct policy can apply even when alignment requires a different boundary calculation.
| Observation during the specified walk | Boundary decision |
|---|---|
| A valid record contains psd=n | Stop; that record's domain is the organisational domain. |
| A valid record contains psd=y away from the starting domain | Stop; choose the domain one label below that public suffix. |
| psd=y is at the starting domain | The walk stops, but the “one label below” rule does not apply to that starting record. Apply the selection rules, rather than inventing a child domain. |
| Valid records exist without a decisive boundary signal | Select the valid record at the name with the fewest labels. Do not automatically select the first ancestor record. |
| No organisational domain is determined | Use the initial target domain as the organisational domain. This fallback does not create a policy record. |
| The subject name has many labels | Apply the eight-query bound: keep the initial query, then shorten as specified. Do not query every ancestor of an arbitrarily long name. |
These rows summarise RFC 9989 Sections 4.10–4.10.2; record filtering and DNS-error handling still apply. No policy found during policy discovery means DMARC does not apply, even though the alignment algorithm has a boundary fallback.
As a second fictional trace, suppose the walk for a.mail.example.com finds valid records at mail.example.com and example.com, neither with psd=n or psd=y, and none elsewhere. The selected organisational domain is example.com. If mail.example.com instead signals psd=n, the walk stops there and that more specific boundary wins. Keep the DNS snapshot with the result so another operator can reproduce the comparison.