How Often Should You Rotate DKIM Keys? A Practical Schedule

How often should you rotate DKIM keys is a scheduling question with a boring, correct answer: on a regular cadence, using two selectors that overlap so no message fails while the switch happens. For most senders that means roughly every six months; for high-volume senders, quarterly; and right away if a private key is ever exposed.

The part people get wrong is not the frequency — it is the changeover. Cut the old key too early and mail already in flight fails verification. This post is the runbook: why rotation matters, a schedule by sender size, the exact overlap steps, and how to revoke a key cleanly.

Why rotate DKIM keys at all?#

DKIM signs your outbound mail with a private key and lets receivers check that signature against a matching public key you publish in DNS. As long as that pair keeps working, nothing forces you to change it. So why rotate DKIM keys at all?

The reason is exposure time. The longer a single private key stays in use, the longer a copy of it — leaked from a backup, a misconfigured server, or a former vendor — stays useful to whoever holds it. Rotation caps that window: an old key that no longer signs anything is worthless to an attacker.

Rotation is also the natural moment to retire a weak key. If you are still on a 1024-bit key, the next rotation is when you publish a 2048-bit one, which is the current recommended minimum. Think of scheduled rotation as hygiene, not emergency response — the emergency version is a compromised key, and that one you rotate the same day.

How often should you rotate DKIM keys?#

There is no single mandated interval. RFC 6376, the DKIM standard, describes how to rotate but sets no fixed clock. M3AAWG's DKIM Key Rotation Best Common Practices recommends rotating on a regular, scheduled basis rather than leaving one key in place indefinitely; the exact interval is a judgement call, and six months is a common baseline. Scale the cadence to how much mail one key signs.

Before you rotate: what you need#

Rotation touches DNS and your signing setup, so line these up before you change anything. A five-minute check here prevents the two failure modes that break mail: a record that never resolves, and a switch made before DNS propagates.

• Access to your domain's DNS, where the selector._domainkey TXT records live — or admin access to the provider that manages them for you.
• Your current selector name. Open a recent message's headers and read the s= tag in the DKIM-Signature line; that is the active selector.
• The DNS TTL on the current record. Lower it a day ahead so your changes propagate in minutes, not hours.
• A way to test after the switch: send to a Gmail or Outlook account and read the Authentication-Results header, or run a DKIM checker.

How to rotate a DKIM selector without breaking mail#

The safe method is overlap: publish the new key beside the old one, switch signing, then remove the old key only after mail signed with it has cleared. RFC 6376 calls this advertising both public keys concurrently for the transition period during which email may be in transit prior to verification.

1. 1

   Generate a new key pair under a new selector

   Create a second key with its own selector name — for example move from selector1 to selector2, or use a dated name like aug2026. Leave the old selector completely untouched for now.

2. 2

   Publish the new public key in DNS

   Add the new selector._domainkey TXT record alongside the existing one. Both public keys are now live at the same time; nothing is signing with the new key yet.

3. 3

   Verify the new record resolves

   Query the new record and confirm it returns the full public key before you sign a single message with it. A typo or a truncated record fails silently and only shows up as failed mail later.

4. 4

   Switch signing to the new selector

   Point your provider or server to sign outbound mail with the new private key. New mail now carries the new selector; messages already in transit still verify against the old one that is still published.

5. 5

   Wait out the overlap window

   Leave both records live for several days. RFC 6376 says the old public key should be retained for a reasonable validation interval, because receivers can defer verification until a message is actually read.

6. 6

   Then retire the old selector

   Only after the overlap window has passed do you remove or revoke the old record. Doing this earlier is the single most common way rotation breaks mail.

How rotation differs by platform#

Where the key is generated and who holds it changes the mechanics, but the overlap principle is the same everywhere. Provider consoles change often, so confirm the exact clicks in your provider's current documentation before you rotate.

The overlap window, in one picture#

During the overlap, your domain is publishing two public keys and receivers verify against whichever selector a given message names. Mail sent before the switch points at the old selector; mail sent after points at the new one. As long as both records resolve, both verify — which is exactly why you do not touch the old record until in-flight mail has cleared.

Revoke or remove the old key safely#

Once new mail has been signing with the new selector for longer than your overlap window, the old key can go. You have two clean ways to end it, and which you pick depends on whether the old key was simply retired or actually compromised.

1. 1

   Confirm the old selector is no longer needed

   Check that you switched signing more than a few days ago, so any message still relying on the old selector has already been delivered and verified.

2. 2

   Decide: remove, or publish a revocation record

   For a routine rotation, deleting the old TXT record is enough. If the old private key was compromised, publish a revocation record instead — a record with an empty p= value, which RFC 6376 defines as meaning the key is revoked so any message still using it fails verification.

3. 3

   Delete or replace the record

   Remove the retired selector's TXT record, or replace its content with the empty-p= revocation record. Keep the new selector exactly as it is.

4. 4

   Re-test end to end

   Send a fresh message and confirm it still passes both DKIM and DMARC in the receiving Authentication-Results header. Rotation is not done until a real message passes.

When rotation breaks mail, and how to fix it#

Most rotation failures trace back to timing or a malformed record. Here is what the symptoms usually mean and how to recover.

A faster way to catch a broken rotation#

None of this happens inside an email client. DKIM keys live in your DNS and are signed by your email provider or sending platform, so rotation is a job for your DNS host, Google Workspace, Microsoft 365 or your ESP — not for the app you read mail in. AI Emaily does not rotate keys or touch your DNS, and any tool claiming to do that for a hosted mailbox is overreaching.

What an AI email assistant can do is shorten the gap between a botched rotation and you noticing it. When a rotation misfires, the evidence arrives as mail: bounce notices, DMARC failure reports, and authentication-failed messages. AI Emaily triages your inbox and surfaces those instead of letting them sink under everything else, so a quiet DKIM failure gets caught in hours rather than weeks. We build AI Emaily.