A boundary tag is not an ownership certificate
The psd tag tells the current DMARC discovery algorithm how to interpret a policy record's position in the DNS hierarchy. It does not transfer domain ownership, authorize a hosted service or prove that a public-suffix operator controls every sender beneath it. Its operational importance is narrower and substantial: the tag can terminate tree walking and influence the organizational domain used for relaxed alignment, as well as the policy available when a tenant publishes none.
RFC 9989 section 4.7 defines y, n and the default u. A y record identifies a Public Suffix Domain. An n record explicitly identifies the organizational boundary for that domain and its subdomains. A u record, including an omitted tag, does not settle whether the domain is organizational; discovery must resolve that question. A missing psd tag is therefore not equivalent to psd=n.
Start with the operator's role
A Public Suffix Operator occupies a different role from an ordinary registrant or tenant. Under section 5.2, a participating PSO must publish psd=y. This is a statement within the DMARC protocol, not a general-purpose list of registry boundaries. Review who controls the relevant DNS zone, which independent organizations exist below it, and whether the proposed deployment actually has the PSO role described by the specification.
An organization that operates subdomains for its own teams should not set y merely because the domain has children. Conversely, n can make an intended organizational boundary explicit instead of relying on defaults. That change can alter relaxed-alignment calculations for subordinate identities, so its effect deserves a controlled comparison with existing records and actual sending paths. A syntactically valid tag is not proof that the chosen boundary matches the organization's security model.
Follow a fictional public-suffix case
Assume registry.example is a fictional public suffix and tenant.registry.example belongs to one fictional tenant. The Author Domain is alerts.tenant.registry.example. Neither that name nor tenant.registry.example publishes a DMARC policy in this fixture. The record at _dmarc.registry.example is v=DMARC1;p=reject;psd=y. No lookup has been executed; these facts are stipulated for the worked example.
The walk ascends from the Author Domain, reaches registry.example and stops on y. Because this is not the starting domain, section 4.10.2 identifies the domain one label below it, tenant.registry.example, as the organizational domain. With no tenant or Author Domain policy, the PSD record supplies the policy under section 4.10.1. In this particular record there is no sp or np override, so p supplies the requested assessment.
Do not generalize that example to y at the starting domain. The one-label-below rule explicitly excludes the starting record. The generic stopping rule and the organizational-domain selection rule are separate steps. A conformance fixture should exercise this edge rather than manufacturing a child organizational domain that was never part of the lookup path.
Compare explicit n with default u
Change the fictional tenant record to v=DMARC1;p=quarantine;psd=n. Now the walk stops at tenant.registry.example. That domain is organizational, its policy takes precedence over the PSD fallback, and the lookup need not ascend to registry.example. The higher operator's reject preference does not override this tenant record merely because it sounds stricter.
For a separate default-discovery example, begin at alerts.team.tenant.registry.example. Let team.tenant.registry.example and tenant.registry.example each have valid records with psd omitted or set to u. Assume no valid records at registry.example or example. The walk does not stop at the first u record; the valid record with the fewest labels identifies tenant.registry.example as organizational. This is a default result derived from the whole relevant candidate set, not a promise that every u-bearing domain is an organizational boundary.
The same algorithm also contains a fallback to the initial target when it cannot determine an organizational domain. Keep “no boundary determined,” “no applicable policy” and “DNS error” distinct in the review output. They do not justify inventing a suffix boundary from intuition or silently substituting an old public-suffix-list result.
Keep tenant reporting separate from suffix reporting
Policy precedence has a privacy consequence. Section 4.10.1 says PSD policy is not used for an organizational domain that publishes its own DMARC policy. The suffix operator cannot use its record to fill in reporting addresses a tenant omitted. A trace that merges the tenant's policy with the PSD's rua or ruf values is not the described mechanism.
Failure reports are especially sensitive in multi-organization suffixes. Section 10.2 prohibits ruf in DMARC records published by PSDs encompassing multiple organizations. This is not solved by calling the recipient a central security team. Aggregate reporting has its own privacy considerations, and organizational approval is still needed before real reporting destinations or datasets are changed.
Verify protocol meaning and deployment independently
The exact commission is: Show a suffix, organisational-domain and default discovery example with current RFC references. The three fictional examples above provide documentary expected outcomes, with complete assumptions retained before drafting. They are not real DNS fixtures, a tenant inventory or observed receiver behavior. Those operational and applicability gates remain open, alongside current errata verification and specialist acceptance.
For a future authorized evaluation, retain the full policy set and the receiver's discovered organizational domains for both the Author Domain and authenticated identities. Compare present and proposed boundaries without assuming every receiver has adopted RFC 9989. Escalate conflicting tenant control or unexpected relaxed alignment before publication. The desired result is an agreed boundary with evidence, not a tag added solely because it appears in a new registry.