Contents
Why rotate DKIM keys
A DKIM private key signs every outgoing message a domain sends, and like any long-lived cryptographic signing key, it should not be left in place forever. Rotating DKIM keys periodically is standard security hygiene, and the reason to learn the rotation procedure properly is that DKIM rotation, done wrong, causes DKIM verification failures, which cause DMARC failures and rejected mail. Done right, it is completely seamless, no signing gap, no failures.
This guide exists to make the seamless rotation procedure clear. The structure of this guide: why rotate DKIM keys, why the selector mechanism is what makes a gap-free rotation possible, the step-by-step rotation procedure, the DNS propagation wait that must come before the signing switch, why the old selector must be retained in DNS for a period after the switch, how often to rotate, emergency rotation, and the diagnostic workflow when a rotation causes DKIM failures.
The reasons to rotate:
- Limiting the compromise exposure window. If a DKIM private key were ever compromised, an attacker could forge the domain's DKIM signatures. Rotating the key bounds the lifetime of any undetected compromise, the compromised key stops being valid once rotated out.
- Limiting the value of a cracked key. Cryptographic keys become more vulnerable the longer they exist and as computing power advances. Rotation replaces the key before it ages too far.
- Operational hygiene. Periodic rotation is good practice, and some senders rotate on a policy schedule.
- Keeping the procedure practiced. Routine rotation keeps the procedure familiar, so an emergency rotation is a known process, not an unfamiliar one under pressure.
The selector mechanism makes it seamless
The reason a DKIM rotation can be done with no downtime is the selector mechanism, and understanding why is the key to the whole procedure.
A DKIM signature names both the signing domain and a selector, and the public key for verifying the signature is published in DNS at a location derived from the selector, at selector._domainkey.domain. Because each selector has its own DNS location and its own key, a domain can publish multiple selectors simultaneously, each with a different key, and signatures made with any of those selectors will verify, because each selector's public key is independently available in DNS.
This is what makes rotation seamless. The principle:
- The operator generates a new key with a new selector name and publishes the new selector's public key in DNS while the old selector's public key is still published.
- For a period, both selectors are valid in DNS.
- The operator switches PowerMTA's signing from the old selector to the new one.
- Mail signed before the switch carries the old selector, and its signature still verifies because the old selector's key is still in DNS. Mail signed after the switch carries the new selector, and its signature verifies because the new selector's key is in DNS.
There is no moment at which a signature cannot be verified, because at every moment the selector that signed the mail in question has its key published. Without the selector mechanism, a domain could only have one DKIM key, and switching it would inevitably create a window where mail signed with one key is checked against another, causing failures. The selector mechanism removes that window. The entire rotation procedure is essentially a careful sequencing of publishing the new selector, switching, and retiring the old selector, designed around this principle.
The rotation procedure step by step
The seamless DKIM rotation procedure:
Step 1: generate the new key pair. Generate a new DKIM key pair, a new 2048-bit RSA key, the same way the original key was generated. This produces a new private key and a new public key.
# Generate the new DKIM key pair
openssl genrsa -out dkim_new.pem 2048
openssl rsa -in dkim_new.pem -pubout -out dkim_new_public.pemStep 2: choose a new selector name. Choose a new selector name, distinct from the current one. Operators often encode a date in the selector name, so the selectors are self-documenting, a selector named for the rotation month, for example.
Step 3: publish the new selector's public key in DNS. Publish the new public key as a TXT record at newselector._domainkey.domain. At this point the old selector is still published and still in use; the new selector is published but not yet used.
Step 4: wait for DNS propagation. Wait for the new selector's DNS record to propagate fully, covered in detail in the next section. This wait is essential and must not be skipped.
Step 5: switch PowerMTA's signing to the new selector. Update PowerMTA's domain-key directive to use the new selector and the new private key, then validate and reload the configuration. From this point, PowerMTA signs new mail with the new selector.
# The domain-key directive updated to the new selector and key
domain-key newselector,example.com,/etc/pmta/keys/dkim_new.pemStep 6: verify the new selector is signing correctly. Send a test message and confirm the DKIM-Signature header now names the new selector, that the signature verifies, and that it aligns for DMARC.
Step 7: leave the old selector in DNS for a retention period. Do not remove the old selector from DNS yet. It must remain for a period, covered below, to verify the old-selector mail still in flight.
Step 8: remove the old selector from DNS. After the retention period, once no old-selector mail can still be in flight, remove the old selector's TXT record from DNS, and remove the old private key from the server. The rotation is complete.
The procedure's two waits, the DNS propagation wait before the switch and the retention wait before removing the old selector, are what make it seamless, and they are the two steps an impatient operator is tempted to shorten and must not.
The DNS propagation wait
Step 4, waiting for the new selector's DNS record to propagate before switching signing to it, is essential, and skipping it is a way to break the rotation.
When the new selector's TXT record is published in DNS, it is not instantly visible everywhere. DNS records propagate, and they are cached, governed by the record's TTL and the caching behavior of resolvers around the internet. For a period after publishing, some receiving servers, querying through resolvers that have not yet seen the new record, will not be able to find the new selector's public key.
If the operator switches PowerMTA's signing to the new selector before that selector's DNS record has fully propagated, then mail signed with the new selector goes out, reaches receivers, and those receivers try to look up the new selector's public key, but for receivers whose resolvers have not yet seen the new record, the lookup fails. The signature cannot be verified, the mail fails DKIM, and it can fail DMARC and be rejected. The fix is simply patience: after publishing the new selector's DNS record, wait long enough for it to propagate fully before switching signing to it. The wait should comfortably exceed the propagation and caching times involved, which means waiting a generous period, hours at least, and a wait of a day is a safe, simple choice that removes all doubt. The new selector must be reliably resolvable everywhere before any mail is signed with it.
The practical guidance: publish the new selector's DNS record, then wait an ample period, a day is a safe choice, and ideally verify that the new selector's record is resolvable, by querying it from a few different vantage points, before proceeding to switch the signing. Only when the new selector is reliably available in DNS is it safe to begin signing with it.
Retaining the old selector after the switch
The mirror-image wait is step 7, retaining the old selector in DNS for a period after switching signing away from it.
When the operator switches PowerMTA to the new selector, PowerMTA stops signing new mail with the old selector. But that does not mean all the mail signed with the old selector has already been delivered and verified. Some old-selector messages may still be:
- In transit to recipients.
- In PowerMTA's retry queues after deferrals, waiting to be retried.
- Sitting in intermediary systems that will relay them onward later.
Every one of those in-flight messages carries an old-selector signature, and when it finally reaches a receiving server, that server looks up the old selector's public key in DNS to verify it. If the old selector has already been removed, the lookup fails, the signature cannot be verified, and the mail fails DKIM.
So the old selector must stay in DNS long enough for all the mail signed with it to have cleared the system. The relevant duration is the maximum time a message might still be in PowerMTA's queues, the bounce-after window, which is typically a few days, plus a safety margin for mail in transit or in intermediaries. Waiting a generous period, on the order of a week or more, before removing the old selector covers all of this comfortably.
Only once the operator is confident no old-selector mail can still be in flight is it safe to remove the old selector's DNS record and delete the old private key. Removing the old selector too soon is one of the few ways a rotation goes wrong, and an ample retention wait is the simple way to avoid it.
How often to rotate
How often to rotate DKIM keys is a matter of the sender's security policy, and there is a range of reasonable practice.
A common recommendation is to rotate DKIM keys a couple of times a year, perhaps every six months, as a routine schedule. Some senders rotate more often, quarterly; some less, annually. The exact cadence is less important than rotating periodically rather than never. A DKIM key that has been in place for many years without rotation is the situation rotation policy exists to avoid.
The factors that push toward more frequent rotation: a higher security posture, regulatory or policy requirements, and the value of keeping the procedure well-practiced. The factor pushing toward less frequent rotation is simply that each rotation is a procedure with waits and a DNS change, and there is modest operational effort each time.
A reasonable default for most senders is a scheduled rotation perhaps twice a year, performed as a routine, planned operation. Scheduling it, rather than rotating only when someone remembers, ensures it actually happens, and performing it routinely keeps the procedure familiar.
Whatever cadence is chosen, the rotation should be a planned, scheduled activity with the full procedure, including both waits, followed each time. A rushed rotation that skips the waits is worse than a slightly less frequent but correct one.
Emergency rotation
There is one situation where rotation is not routine and not scheduled: an emergency rotation when a DKIM private key is suspected of being compromised.
If a private key may have been exposed, a server compromise, a key file leaked, the key must be rotated out urgently, because while the compromised key is still valid in DNS, an attacker could use it to forge the domain's DKIM signatures.
The emergency rotation uses the same procedure, generate a new key and selector, publish, propagate, switch, but with a difference in the handling of the old selector. In a routine rotation, the old selector is retained for a generous period so in-flight legitimate mail verifies. In an emergency, that retention is a tension: keeping the compromised selector in DNS keeps the forgery risk alive, but removing it immediately fails the legitimate in-flight mail signed with it. The operator has to weigh the urgency of cutting off the compromised key against the in-flight legitimate mail, and may choose a shorter retention than routine, accepting some failures of in-flight mail as the cost of closing the compromise faster.
This tension is itself a reason routine rotation matters: if rotations are performed routinely and the procedure is familiar, an emergency rotation is a known process executed quickly and correctly. An operator who has never rotated a DKIM key, attempting it for the first time during a security incident, is far more likely to make a mistake.
When a rotation causes DKIM failures
When a DKIM rotation causes DKIM verification failures, the diagnostic workflow:
Step 1: identify which selector the failing mail used. Examine the failing mail's DKIM-Signature header to see which selector signed it, the old or the new. This points at where in the rotation the problem is.
Step 2: for new-selector failures, check propagation. If mail signed with the new selector is failing, the new selector's DNS record may not have propagated when signing was switched. Verify the new selector's TXT record is now resolvable everywhere. If the switch was made too early, the failures should resolve as propagation completes; confirm the record is correct.
Step 3: for old-selector failures, check the old selector is still in DNS. If mail signed with the old selector is failing, the old selector may have been removed from DNS too soon, while old-selector mail was still in flight. If the old selector's record was removed, re-publishing it temporarily allows the in-flight old-selector mail to verify.
Step 4: verify the new selector's record is correct. Confirm the new selector's published public key actually corresponds to the new private key PowerMTA is signing with. A mismatch, the wrong public key published, causes verification failures regardless of propagation.
Step 5: confirm PowerMTA switched cleanly. Verify PowerMTA's domain-key directive was updated correctly to the new selector and key, and that the configuration was validated and reloaded.
Step 6: verify alignment. Confirm the new selector's signing still uses the sender's own domain, so DKIM still aligns for DMARC. The rotation changes the selector and key, not the domain, the domain must remain the sender's From domain.
Step 7: test and confirm. Send a test message and confirm the DKIM-Signature names the new selector, the signature verifies, and DMARC alignment holds.
An operator we worked with performed a DKIM key rotation, and they did most of it correctly. They generated a new key, gave it a new selector, published the new selector in DNS, waited for it to propagate, switched PowerMTA's signing to the new selector, and verified that new mail was being signed with the new selector and verifying correctly. Up to that point the rotation was textbook. But then, with the new selector working and the switch confirmed, they considered the rotation finished, and as a tidy-up they immediately removed the old selector's TXT record from DNS. They reasoned that PowerMTA was no longer signing with the old selector, so the old selector's DNS record was no longer needed, and leaving it would just be clutter. A day or two later they noticed a small but real stream of DKIM failures, and DMARC failures, for some of their mail. The failures were puzzling because all their new mail was signing fine with the new selector. The diagnosis was in the failing mail's DKIM-Signature headers: the mail that was failing had been signed with the old selector. It was old-selector mail that had still been in flight when they removed the old selector's DNS record, messages that had been signed with the old selector before the switch and were still in PowerMTA's retry queues after deferrals, or still in transit, or held in intermediaries. When those in-flight old-selector messages finally reached receiving servers, the servers tried to look up the old selector's public key to verify the signatures, and the record was gone, so the lookups failed, the signatures could not be verified, and the mail failed DKIM and DMARC. The operator had removed the old selector while mail signed with it was still on its way. The fix was immediate: re-publish the old selector's TXT record in DNS, which allowed the remaining in-flight old-selector mail to verify again. Then they left the old selector in place for a proper retention period, well over a week, long enough to be certain that no mail signed with the old selector could still be in flight, before finally removing it. The lesson is that a DKIM rotation is not finished at the moment signing switches to the new selector. The old selector must remain in DNS for a retention period after the switch, long enough to cover the maximum time, the bounce-after window plus a margin, that a message signed with the old selector might still be in the system. Removing the old selector promptly feels like completing the rotation cleanly, but it strands the in-flight old-selector mail. The rotation is only truly complete after the retention wait, and the old selector is removed last, not as a tidy-up right after the switch.
DKIM key rotation is standard security hygiene, bounding the exposure of a long-lived signing key, and the reason to learn it properly is that done wrong it causes DKIM and DMARC failures while done right it is completely seamless. The seamless rotation rests on the selector mechanism, which lets a domain have multiple DKIM keys valid in DNS at once, so there is never a moment when the selector that signed a given message lacks a published key. The procedure is a careful sequence: generate a new key with a new selector, publish the new selector in DNS, wait for it to propagate fully before switching signing to it, switch PowerMTA's domain-key directive and verify, and then, crucially, retain the old selector in DNS for a generous retention period, a week or more, before removing it, so that mail signed with the old selector and still in flight can still verify. The two waits, propagation before the switch and retention before removal, are what make the rotation gap-free, and they are exactly what an impatient operator must not skip. Operators who follow the full procedure with both waits rotate their DKIM keys with no downtime and no failures; operators who switch before propagation or remove the old selector too soon, as the case shows, strand mail and cause the failures the procedure exists to prevent.