Delegating a subdomain can make a sending service easier to operate, but it also distributes control over an organizational identity. A useful DKIM design names the DNS owner, the private-key custodian and the business owner separately. It also states exactly what is delegated and how that delegation will end.
Do not begin by publishing restrictive records or assuming the subdomain only sends mail. Establish its current and intended purpose, including receiving, application use and inherited dependencies. DKIM configuration alone does not decide whether a namespace should accept messages, serve a website or remain dormant.
Define the delegation boundary
Distinguish a selector-level CNAME from delegation of an entire DNS zone using NS records. A selector CNAME points a particular lookup toward provider-managed verification data under RFC 1034 §3.6.2. A zone delegation assigns authoritative responsibility for names within that zone, subject to further zone cuts, under RFC 1034 §4.2; the scope can include records unrelated to DKIM. Review that wider authority before treating the two mechanisms as interchangeable.
Record the complete selector lookup name, target or authoritative zone, intended d domain and provider account. RFC 6376 §3.1 describes selector use cases and RFC 6376 §3.6.2.1 defines key lookup. It does not prescribe the permissions in a particular provider's control panel. Obtain the provider's current instructions and an accountable owner for those permissions.
Assign three kinds of ownership
The business owner knows which messages must continue working. The DNS owner can publish or remove the lookup or delegation. The key custodian controls the private signing key, whether that is an internal system or a managed provider. One team can hold several roles, but each responsibility should be explicit.
Ask who can rotate the key, change the signing domain, export evidence and disable the sending account. Public verification data is not a private signing key. Never request a provider's private key simply to prove that a record is correct; use documented controls and received-message verification instead.
Work through a scoped example
Illustrative design: receipts.mail.example is assigned to a billing service, with a supported signature using d=receipts.mail.example and selector bill1. The organization retains its parent DNS, while the provider controls verification material reached by bill1._domainkey.receipts.mail.example. Record the billing owner, DNS change owner and provider key custodian against that exact name.
If the visible From domain is receipts.mail.example, the identities match exactly. If From instead uses mail.example, assess the configured alignment mode under RFC 9989 §3.2.10 and organizational-domain discovery under RFC 9989 §4.10.2; do not assume strict alignment. A passing signature proves the cryptographic relationship for its d domain, not that every address under the parent has the same business authorization. This is a design fixture, not a live tenant result.
Check hidden dependencies before change
Search configuration inventories for scheduled jobs, acquisition-era applications and old campaign systems using the subdomain. Review receiving requirements separately. A DNS delegation change can affect more than DKIM, while removal of a selector can affect delayed messages already signed with that selector.
Prepare representative tests for each known sending route. Capture From, d, s, trusted receiver result and alignment, together with the DNS answer and timestamp. Verify the normal path as well as the recovery route. A dashboard marked verified is useful configuration evidence, but not a substitute for a received-message sample.
Make offboarding part of the initial design
Document how to stop new signing, preserve necessary verification during a planned transition and remove unused delegation after dependencies have ended. Coordinate account access and API credentials separately; deleting one DNS record is not complete provider offboarding. If key compromise is suspected, security containment can take priority over ordinary overlap.
The final register should show the namespace purpose, authority granted, owners, tests and exit conditions. That record lets the next administrator distinguish a necessary dependency from an abandoned pointer without guessing from a provider name in DNS.
Record the next decision
Before approval, compare the exact requested name and record type with the intended authority. One selector CNAME should not be silently replaced with NS delegation for a whole zone. If the provider needs the broader scope, list affected names and dependencies and obtain the responsible owner’s decision. The example grants no actual DNS authority.