DKIM key rotation: how to automate it

Why rotate DKIM keys at all?

DKIM signs each outgoing message with a private key, and receivers check the signature against a public key published in your DNS.^[1] Anyone who holds that private key can sign mail that verifies as yours. A key can be cracked if it is short, or stolen from the system that stores it.

Rotation limits that exposure. M3AAWG, the messaging anti-abuse working group, says regular rotation reduces "the risk of active keys being compromised", and that a practiced process means people know what to do when an emergency rotation is needed.^[4] DKIM still matters after DMARC arrives: under the current DMARC standard, RFC 9989, a DKIM pass only counts when its domain aligns with the visible From domain.^[7]

How often should keys change?

M3AAWG recommends rotating DKIM keys "at least every six months".^[4] Its 2019 revision moved from quarterly to twice a year, a balance between the risk of a compromised key and the effort of coordinating many senders. It adds that less complex mail flows can rotate more often, and suggests picking dates that avoid your busiest sending periods.^[4]

Rotate outside the schedule straight away if you suspect a key has leaked, a vendor reports a breach, or someone with access to private keys leaves on bad terms.

What key strength should you use?

RFC 8301 updated DKIM's cryptography. Signers "MUST use RSA keys of at least 1024 bits" and "SHOULD use RSA keys of at least 2048 bits", and rsa-sha1 must not be used at all.^[2] Defaults vary by platform: in Microsoft 365, 1024 is the default key size when you create a DKIM configuration in PowerShell, with 2048 as an option.^[5] Google Workspace offers 2048-bit keys where your DNS host supports them and says "Longer keys are more secure than shorter keys."^[6]

RFC 8463 added Ed25519 as a second signing algorithm. Because each selector holds one key, a sender that wants both uses two selectors and adds two signatures, so receivers that only understand RSA still have one they can check.^[3] A scheduled rotation is a sensible moment to move to 2048-bit RSA.

How do selectors prevent failed signatures?

RFC 6376 subdivides the key namespace into selectors "to support multiple concurrent public keys per signing domain".^[1] That lets the next key sit in DNS before anything signs with it. M3AAWG's workflow runs like this:^[4]

1. Publish the next public key under a new selector and wait for DNS to propagate.
2. Switch signing to the new private key.
3. Keep the old public key unchanged for at least seven days, and up to 30, so mail in transit still verifies.
4. Retire it by setting its p= value to empty instead of deleting the record.
5. Publish the following key in advance, ready for the next cycle or an emergency.

RFC 6376 defines an empty p= value as a revoked key,^[1] and its operational advice says the old public key "should be retained for a reasonable validation interval" before removal.^[1] M3AAWG also discourages reusing selector names, because old messages would then fail any later check against the new key.^[4]

How do email hosts handle rotation?

Many handle the mechanics for you, so check before building anything. Microsoft 365 publishes two selectors per custom domain, keeps one inactive and offers a "Rotate DKIM keys" action. After a rotation it takes "four days (96 hours)" before the new key starts signing.^[5] Microsoft also notes there is currently no automatic rotation for the onmicrosoft.com domain.^[5]

Marketing platforms, CRMs and billing tools that send as you are the harder part. M3AAWG describes three patterns for third parties: you generate the key and pass the private key securely, the vendor generates it and gives you the public key, or you delegate through CNAME records that point to keys the vendor rotates.^[4] It warns never to send a private key by unencrypted email.^[4]

Which steps should you automate?

The steps that repeat and are easy to get wrong by hand:

• Key generation and storage. Generate keys in a secrets manager or your email platform, not on a laptop, and restrict who can read private keys.
• DNS publishing. Use your DNS provider's API or infrastructure-as-code templates so records are generated from one validated template.
• Propagation checks. Query several public resolvers for the new selector before switching signing.
• Schedules and reminders. Track each selector's planned active dates so retirements happen on time.
• Halt on failure. If a check fails, stop and alert rather than rotating into a broken state.

M3AAWG recommends scripts for exactly these steps, noting that even simple automation "helps to reduce mistakes and save time".^[4] Keep a person in the loop for the switch itself on senders you do not control.

How do you confirm a rotation worked?

Use DMARC aggregate reports. RFC 9990 says they expose the outcome of SPF and DKIM validation, and each DKIM result carries the selector that signed the message.^[8] After a rotation, every legitimate stream should show the new selector passing. A stream still on the old selector, or a rise in DKIM failures, points to a sender that missed the change.

M3AAWG suggests an audit about a week after each rotation, comparing the domain and selector in real messages against your inventory.^[4] That inventory, with each stream, its owner and its selectors, is the backbone of the whole process.

Where should a team start?

1. List every service that sends mail as your domain, and the selector each one uses.
2. Move any key below 2048 bits at its next rotation.
3. Write a policy: rotation interval, retention window and emergency triggers.
4. Automate one domain end to end, then extend it.

Our guide to corporate DNS security explains how DKIM fits with SPF and DMARC. Pair it with a registry lock, which guards the domain's registration and name servers, though not the records inside the zone, and with a typosquatting audit, since DKIM does nothing for lookalike domains. Executive fraud often starts there, as our guide to executive impersonation shows. Our domain security service reviews email authentication as part of our digital asset security work.