Before approving DKIM delegation, ask for the exact DNS change and the signing identity it will enable. “Add our DNS records” is too broad an instruction for a security review. A selector CNAME, an NS delegation and access to the entire DNS account grant different forms of control.
Draw the boundary before approving it
A CNAME at one selector owner name directs resolution through its target. A provider controlling that target can change the verification data reached through the alias. It does not, by itself, grant permission to edit arbitrary names in your zone. An NS delegation establishes a zone boundary and gives the delegated authoritative servers responsibility for names beneath it, subject to the DNS hierarchy. Whole-account administrative access can be much broader still. RFC 1034 §3.6.2 and RFC 1034 §4.2 describe these DNS mechanisms.
Write the owner name and affected subtree into the approval. A request for service1._domainkey.example.com is different from control of the entire _domainkey.example.com subtree. Do not replace a narrow provider-supported record with a broad delegation just because it appears simpler to automate.
Distinguish DNS scope from signing impact
DKIM verification obtains a key using the signature's selector and signing domain. Control over a usable selector's verification data, together with the matching private signing key, can enable valid signatures for that signing domain. The apparent narrowness of one DNS name therefore does not mean the email trust consequence is negligible.
A synthetic example illustrates the distinction. A provider receives a CNAME at invoices._domainkey.example.com and operates the matching signer for d=example.com. Its DNS access is confined to the alias target, but that signer can produce signatures claiming responsibility from example.com. A selector named invoices does not itself restrict signatures to invoices, particular recipients or an approved campaign. Application and account controls must impose those limits.
If you use a dedicated sending subdomain, assess the applicable DMARC alignment rules too. Subdomain separation does not automatically isolate relaxed alignment. RFC 9989 §4.4 describes how authenticated identifiers are compared with the Author Domain; the policy and organizational-domain determination matter.
Collect evidence that answers the approval question
Request the provider's current instructions, generated names, account identifier, supported signing domain and rotation model. Verify who can change those values inside the provider account and whether role separation is available. Ask about account closure and stale-DNS handling, without assuming contractual guarantees that have not been supplied.
Build a compact register: DNS owner, record type, destination or nameservers, service owner, intended d= identity, privileged provider users, renewal date and retirement procedure. For a proposed NS delegation, inspect the entire affected subtree for existing selectors before approving it. For an account-access request, challenge why per-record instructions or a narrower supported role are insufficient.
Test onboarding and plan termination
After an approved change, compare authoritative and recursive DNS observations and send through the intended service. Inspect a trusted receiver's DKIM result and alignment. The test should demonstrate the granted identity, not merely show that some signature passes.
At termination, stop application access, remove obsolete sending credentials and coordinate selector retirement with delivery queues and the provider's process. If the provider is suspected of compromise, invoke incident response rather than preserving a routine overlap automatically. A service marked inactive in procurement records can still represent a live technical dependency.
Document the residual trust explicitly: what the provider can sign, who can administer it and how quickly the organisation can remove the dependency. That record makes later renewals a review of actual authority rather than a repeat of the original DNS ticket.
Compare three hypothetical approval requests
Use the scope and consequence together:
- One selector CNAME: review its exact owner and target, intended d identity and provider-account controls. It does not grant arbitrary zone-editing access, but its key mapping can enable signing for that identity.
- NS delegation below _domainkey.example.com: inventory the selectors under that delegated zone and who controls its authoritative servers. Existing or future selectors there may be affected, subject to further zone cuts.
- Full DNS account access: require an explicit need and inspect the account’s actual permissions. It may reach unrelated mail and web records; this is not equivalent to publishing one selector alias.
These are review scenarios, not authorizations or changes made to a real zone. If exact scope or ownership is unknown, resolve that gap before approval.
Related reading
DKIM TXT and CNAME publishing: follow the provider's key-management model · Revoke a DKIM key and distinguish revocation from a missing DNS record.