DKIM key rotation and management best practices

A DKIM key pair is a credential, and credentials need lifecycle management: a strength decision at creation, rotation on a schedule and on incident, and an inventory of who holds which private key. Most DKIM outages and most DKIM security findings trace back to one of those three being neglected. This entry covers the practice.

Key size: 2048 is the answer

1024-bit RSA keys are the compatibility floor and no longer a defensible choice: they are within reach of well-resourced factoring efforts, and the provider requirements that mandate DKIM recommend 2048-bit. 2048-bit RSA verifies everywhere and is the production standard. Larger RSA keys buy little and can exceed DNS handling in some resolvers, and ed25519 remains ahead of receiver support. Choose 2048, revisit when the ecosystem moves.

Zero-downtime rotation

Rotation never edits a live key in place. The selector mechanism exists precisely so that a new key can be introduced alongside the old one, with no window in which mail verifies against nothing. The pattern is additive at every step, which also makes it reversible at every step.

The rotation sequence

1
Generate the new pair, publish under a new selector
Create the key, publish it at s2026b._domainkey.example.com, and verify resolution externally. Nothing signs with it yet; publishing early costs nothing.
2
Let DNS settle
Wait out propagation (a day is comfortable). The new record exists everywhere before any signature references it.
3
Switch signing to the new selector
Reconfigure the signer (MTA filter or vendor dashboard) to sign with s2026b. New mail references the new key; mail already in transit still references the old one.
4
Verify in the wild
Send test mail, confirm dkim=pass with the new selector in Authentication-Results, and watch DMARC aggregate reports for any source still failing.
5
Retire the old key after a grace period
After enough time for all in-flight and queued mail to deliver (a week is generous), revoke the old selector with an empty p= or remove the record.

Cadence: scheduled and triggered

Quarterly rotation is a reasonable baseline for keys you operate; annual is the outer bound of acceptable. More important than the exact interval is having triggered rotation rehearsed: immediately on suspected private key exposure, on departure of personnel with key access, and as containment during a replay incident, where retiring the abused selector kills captured signatures. An unrehearsed rotation performed for the first time during an incident is how a security event becomes a delivery outage.

Vendor-held keys

For most senders, most private keys live with vendors: the ESP generates and holds the key, you publish the CNAME delegation, and rotation is the vendor's automated concern. That is a sane arrangement with two obligations on your side. First, insist on custom-domain signing so d= is your domain; a vendor rotating keys for a signature that does not align helps their infrastructure and not your DMARC. Second, keep the inventory: which vendors sign for your domains, under which selectors or delegations, so that offboarding a vendor includes deleting the delegation the same day.

For keys you do operate (self-hosted MTAs with OpenDKIM or Rspamd), the private key is a file on infrastructure you secure: readable by the signing process only, absent from repositories and backups with broad access, and generated on the host rather than transported. Nothing exotic, the same discipline as any TLS private key, applied consistently.

The inventory that makes it manageable

DKIM key inventory, per domain

Every active selector, with signer (vendor or system), key size, and creation date
Every CNAME delegation, resolved end to end quarterly, deleted when vendors are offboarded
Rotation owner and schedule, with the triggered-rotation runbook written down
Custom-domain signing (aligned d=) confirmed for every vendor stream
Old selectors revoked with empty p= rather than left resolving forever

Frequently asked questions

Does rotating keys hurt deliverability?

Done additively via new selectors, no: reputation attaches to the d= domain, not to the key, and receivers simply fetch the new record. The damage comes from in-place edits that leave a propagation window where signatures verify against nothing.

How fast do vendors rotate the keys they hold?

Practice varies from regular automated rotation to never. It is a fair due-diligence question, and one of the genuine advantages of CNAME delegation is that vendor rotation requires nothing from you when it does happen.

Should each sending stream have its own key?

Each signer inherently has its own key, and separating streams across subdomains with their own keys and selectors contains incidents: a compromised or replay-abused marketing key never touches transactional mail. The subdomain strategy and signing segmentation reinforce each other.

Is there any reason to keep a 1024-bit key?

Only a legacy system that cannot handle 2048-bit records, which in 2026 is a system to replace rather than accommodate. Provider guidance recommends 2048, and short keys are the finding every security review flags first.

Key takeaways

2048-bit RSA is the production standard; 1024 is no longer defensible and ed25519 is not yet broadly verified
Rotation is additive: new selector, propagate, switch signing, verify, then retire the old key
Quarterly rotation is a sound baseline, and triggered rotation must be rehearsed before the incident that needs it
Vendor-held keys are fine when d= aligns with your domain and delegations are inventoried and cleaned up
Keep a per-domain inventory of selectors, signers, and delegations; unmanaged keys are the ones that end up in findings