A DKIM private key is authority to create signatures that can verify against the matching public record. Protecting the DNS record alone does not protect that authority. Inventory the signing systems, the accounts that can use them and every operational copy of the secret before deciding the key is controlled.
Identify custody rather than assuming it
Start with the actual provider or signing software. A managed service may generate and retain keys; a self-operated signer may read a file, secret store or supported hardware-backed interface. These models have different access and recovery controls. Do not promise hardware protection, non-exportability or customer-managed rotation unless the chosen product documents and implements it.
RFC 6376 §8.3 explains the consequence of private-key compromise: an intruder can create mail signed by the domain that publishes the corresponding public key. It also describes the value of a controlled outgoing mail server that authenticates submitters and applies sending controls. The specific storage and review steps below are operational recommendations, not universal DKIM protocol requirements.
Build a custody map that exposes hidden copies
For each selector, record the signing domain, service owner, key custodian, active signing nodes, deployment path and supported recovery mechanism. Track the secret's reference or identifier, not the secret itself. Review configuration repositories, container build steps, temporary deployment files, backups and diagnostic bundles for unintended copies through the organisation's approved secret-handling process.
A synthetic example is a billing cluster with two signing nodes and a deployment job. The DNS key is public and expected. The private key is intended to reach only the two nodes, but an old build pipeline also embeds it in an image accessible to unrelated projects. Securing the current node file permissions would not remove that older exposure. Investigate the distribution path and treat a potentially exposed secret according to the incident process.
Never paste a private key into a public DNS field, ticket, chat or public DKIM checker. When support needs evidence, provide the public selector information and suitably controlled diagnostic results. Raw messages may contain sensitive content too; minimise what is shared and use approved channels.
Reduce who can sign and who can retrieve secrets
Use the platform's supported least-privilege controls for both administration and runtime access. An account that can request signatures may be powerful even if it cannot export the key. Review who can change allowed sending identities, submit mail, rotate keys, deploy signer configuration and retrieve backups.
Separate services with different owners or trust levels where the architecture supports independent keys and selectors. Copying one key into every application makes an incident harder to scope and retirement more disruptive. High availability may legitimately require a shared signing identity, but that should be an explicit design with controlled distribution rather than an accidental consequence of a copied configuration file.
Test recovery without distributing the secret
Ask whether an outage is recovered by restoring a protected key, generating a replacement or using the provider's managed recovery path. Test the supported procedure in a controlled environment. Record recovery time, DNS dependencies and whether queued mail still uses the older selector. Do not create additional unprotected backup copies merely to make a drill easier.
Review logs and access events available from the signing platform and secret-management system. The useful question is whether an unauthorised change or use could be detected and investigated, not whether a particular dashboard exists. Document logging gaps instead of inventing an audit trail.
Finish with an actionable lifecycle record
Keep the custody map beside rotation and compromise procedures. Remove obsolete access when staff or vendors leave, and recheck distribution after infrastructure changes. During a suspected exposure, coordinate access containment, a clean replacement and the verification consequences of old-key retirement. A protected current file is only one part of a controlled signing lifecycle.
Use a custody decision worksheet
For each signing identity, record these non-secret fields:
- Use: which service accounts can submit or request signatures, and which d identities they may use.
- Retrieval: which roles can export or restore the private key, and where approved copies reside.
- Change: who can alter signer configuration, allowed identities or deployment artifacts.
- Recovery: whether the supported path restores a protected key or generates a replacement, with DNS and queued-mail dependencies.
- Evidence: available access/signing logs, any coverage gaps and the owner responsible for review.
If an old build artifact contains an exposed key, securing only the live node is insufficient: scope the old exposure and decide on clean replacement under incident procedures. This worksheet is editorial security guidance, not a claim that a particular platform supplies these controls.
Related reading
Revoke a DKIM key and distinguish revocation from a missing DNS record · DKIM key length and algorithms: check current receiver support.