Delegating a business-unit domain can reduce operational delay, but the delegation must be narrower and clearer than a statement that marketing owns the subdomain. A full DNS zone, a single DKIM selector and an application configuration are different authority boundaries. Define what the local team may change, who approves the business use and what the central team can still observe.
Identify the delegated object
Record the DNS owner name, record type, delegation target, service account and operator. Distinguish an NS delegation for a child zone from a CNAME used at a selector or service name. A zone operator can publish records within the delegated zone, while a selector relationship concerns a specific key lookup path. RFC 1034 explains zone delegation, and RFC 6376 describes the DKIM selector and key lookup. DNS delegation; DKIM.
Do not infer business permission from technical capability. Document allowed service purposes, domains and change classes, along with actions requiring central approval. The local team may operate a campaign platform without having authority to create unrelated senders or weaken a policy. Keep access permissions consistent with the agreement and review actual privileges rather than relying on a written boundary alone.
Divide central and local work
A workable arrangement gives the local business owner responsibility for approved service use and vendor lifecycle, the local operator responsibility for scoped configuration, and the central team responsibility for visibility, shared-domain risks and escalation. Adjust those assignments to actual control. Name deputies and an emergency route so a central dependency does not become a silent outage bottleneck.
Maintain a service record containing purpose, owner, criticality, From identity, envelope identity, signing domain, selector, last test and approval. Require local changes to produce an exact diff and a verification artifact. NIST AC-6 and CM-5 support least privilege and restricted change access; the division of central and local roles here is a proposed governance pattern, not a mandatory departmental design. NIST catalogue.
Test visibility independently of local signing
Suppose a local team changes the provider behind one delegated DKIM selector and obtains an authorized sample with a valid signature. The central inventory still names the previous provider and receives no change record. Local signing evidence does not establish central awareness, so the visibility gap remains even if the service sends successfully.
A separate zone delegation requires a broader review: identify which authoritative records the local operator controls, any further delegated children, and the dependent services central teams must continue to observe. Do not copy the narrow selector checklist and assume it covers the entire zone. These are hypothetical governance cases, not discovered DNS objects or executed tests.
For an authorized exercise, retain the exact changed object, service mapping, approval and evidence that the central team received and understood the change. Monitoring access and DNS write access remain distinct capabilities.
Define a safe exit
The delegation agreement should explain how services migrate or retire, who removes records, how keys and credentials are handled and what happens when a local owner leaves. Inventory shared dependencies before revoking access. If central control must be restored, plan the zone or service transition explicitly rather than deleting a delegation and hoping all records reappear elsewhere.
Review the arrangement after reorganisations, vendor replacements and changes in domain use. Record exceptions with a scope, owner and review date. The goal is not to centralize every small operation; it is to ensure that delegated capability, business authorization and monitoring remain connected. A successful design lets the local team move quickly while making the authority boundary inspectable and recoverable.
Match the written boundary to effective access
Compare the named DNS object and service permissions with what the operator can actually modify. An agreement limited to one campaign is not enforced if the account can alter unrelated records. Request the appropriate scoped access change through the authorized process and retain central visibility separately.