DKIM Key Rotation: Why, How Often, and How to Do It Safely

A DKIM key is a long-lived secret. If it leaks, whoever holds it can sign mail as your domain that passes every check, and nothing in your DNS will look wrong. Rotating the key limits how long a leak stays useful, and moving to a longer key fixes weaknesses in older 1024-bit setups. The trick is doing it without a window where mail in transit fails verification. Here is the safe sequence.

Quick answer

Rotate DKIM keys at least once a year, immediately after any suspected compromise, and whenever you change mail providers. Use a new selector for the new key, publish it alongside the old one, switch signing to the new selector, wait at least a week for in-transit mail and retries to clear, then remove the old record. Never overwrite the old selector's TXT records (short text lines in DNS used for email security) in place.

Why rotation matters even if nothing went wrong

• Private keys sit on the sending server. Every server migration, backup, and support engineer with access is an opportunity for a copy to exist somewhere you did not intend.
• Older setups used 1024-bit keys. 2048-bit is the widely recommended length today, and rotation is the natural moment to upgrade.
• A former provider may still hold a key you published. Leaving its selector in DNS after you migrate means they can still sign as you.
• Regular rotation means your team already knows the procedure when the urgent case arrives.

How DKIM selectors make zero-downtime rotation possible

Every DKIM signature names a selector in the s= tag of the DKIM-Signature header. Receivers fetch the public key from selector._domainkey.yourdomain.com. Because the selector is per message, you can have two keys published at once and choose which one signs. Mail signed with the old key while it sits in a queue can still verify, because its record is still published.

# Old key, still published during the overlap
sel2025._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=… (the exact key is shown in your OquMail dashboard)"

# New key, published before you switch signing
sel2026._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=… (the exact key is shown in your OquMail dashboard)"

Step-by-step rotation

1. Generate or request the new key pair from your mail host. With a hosted service such as OquMail the private key never leaves the server; the dashboard shows you the public TXT value to publish.
2. Publish the new public key at a new selector name. A date-based name like sel2026 or a short random token both work; avoid reusing a selector name you have used before.
3. Confirm the record with a DKIM lookup tool. Long keys are often split into two quoted strings by DNS panels; that is fine as long as the tool reassembles it correctly.
4. Switch signing to the new selector in your mail host. Send a test to a Gmail address and check Show original for DKIM (a digital signature that proves your email was not tampered with)=pass with the new s= value.
5. Wait. Seven days covers queued retries at most receivers; some administrators wait 30 days to be safe.
6. Remove the old selector's TXT records (short text lines in DNS used for email security). Do not just blank its value; delete the record so the selector returns no answer.
7. Record the date and the new selector name in your security notes for the next rotation.

Rotating at third-party tools

Each tool that signs with your domain has its own key and selector, typically something like k1._domainkey or a CNAME pointing to the vendor's key. Rotate those on the same schedule using the vendor's re-verify or regenerate option. Tools that use a CNAME can rotate the underlying key without you touching DNS, which is one advantage of that method.

Mistakes that cause bounces or spam-foldering

• Overwriting the existing selector record with the new key. Every message already signed with the old key fails from that moment.
• Deleting the old record the same day you switch. Retries from greylisting receivers can take hours.
• Publishing a truncated key. Copy the value from your dashboard in one piece and verify with a lookup tool before switching.
• Forgetting subdomains that sign separately, such as a marketing subdomain with its own key.
• Rotating DKIM but not checking DMARC reports afterwards. The reports will show a DKIM fail from your own IPs if something went wrong.

Common questions

What if I think the key was stolen right now?

Skip the overlap. Publish a new selector, switch signing, and delete the old record immediately. A small amount of legitimate in-transit mail may fail DKIM, but with SPF also passing it will still pass DMARC. That is far better than an attacker signing as you.

Should I use 2048 or 4096 bits?

2048 is the sensible default. A 4096-bit key produces a TXT records (short text lines in DNS used for email security) long enough to hit size limits at some DNS providers and adds little practical security for email.

Does OquMail handle rotation for me?

OquMail signs your mail with a key it manages and shows you the selector and public value to publish during guided setup, with live DNS verification. If you migrate away, delete the OquMail selector record after your last message has cleared, exactly as described above.