DKIM key rotation: a safe, zero-downtime playbook

DKIM keys are like passwords: long-lived ones rot. The longer a key sits in DNS, the more chances it has to leak — from old backups, decommissioned servers, or that one developer laptop that never came back. Rotating annually is the conservative baseline; quarterly is what mature programs do.

Why rotate at all?

• Key compromise reduction. Even without a known leak, time-bounded keys limit the blast radius if one happens.
• Algorithm upgrades. Rotation is the natural moment to move from 1024-bit to 2048-bit RSA.
• Compliance. SOC 2, ISO 27001 and most enterprise security questionnaires expect a documented rotation schedule.
• Hygiene. Forces you to verify that your signer still has access to the private key — surprisingly often it doesn't.

Selector naming

A DKIM selector is a label that lets you publish multiple keys under the same domain. The DNS name is <selector>._domainkey.<domain>. Pick a scheme that encodes the rotation date so you can read history at a glance.

The five-step rotation

What the published record looks like

Key size: 1024 vs 2048 vs 4096

Verifying the rotation

1. Send a test message through WillItInbox. The DKIM check shows the signing selector and verification result.
2. Inspect raw headers — look for DKIM-Signature: ... s=s2026q2 ... confirming the new selector.
3. Read DMARC aggregate reports for the next two weeks. A spike in DKIM failures means a sender wasn't switched over.

Additional guidance: DKIM Key Rotation: How Often, How To, and How Not to Break Alignment

DKIM key rotation means replacing the RSA keypair your mail server signs with, by publishing a fresh public key under a new selector in DNS, signing with both keys during an overlap window, then retiring the old one. Rotate every 6–12 months, use 2048-bit keys where your platform supports them, and never delete the old key until the new selector is live and verified.

Most domains set up DKIM once and never touch it again. The key that was generated during onboarding in 2021 is still signing every message in 2026. That's not a scandal — RSA doesn't expire on a schedule — but it is a gap. Keys leak. Vendors change. Employees with DNS access leave. And unlike TLS certificates, nothing forces you to rotate, so nobody does. This post is the process: what a selector actually is, how often to rotate, and the exact rollover sequence that gets you to a new key with zero signing gaps.

What is a DKIM selector, actually?

A selector is the s= tag in the DKIM-Signature header. It's a label that tells the receiving server where in DNS to find the public key. The lookup is always:

<selector>._domainkey.<signing-domain>

So a signature with s=s1; d=example.com triggers a TXT lookup at s1._domainkey.example.com. A typical record looks like this:

s1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

That record has three parts that matter:

• v=DKIM1 — version tag. Optional but conventional.
• k=rsa — key type. RSA is effectively the only type in production; Ed25519 exists in the spec but support is thin.
• p= — the base64-encoded public key. This is the whole point of the record.

The selector is just a name you choose. s1, google, mail, 20260801, k1 — all valid. ESPs (email service providers) pick their own conventions: SendGrid uses s1/s2, Mailchimp uses k1/k2/k3, Google Workspace uses google. You can run as many selectors in parallel as you want. That fact is what makes zero-downtime rotation possible: you add a second key, you don't swap one out.

One more thing selectors do that people miss: they namespace keys per sending platform. Your transactional ESP signs with s1, your marketing platform with mkt, Google Workspace with google — all under the same domain, all coexisting. Rotation has to account for every one of them.

1024 vs 2048-bit keys in 2026

Use 2048 bits. Full stop, unless your platform genuinely can't.

The argument for 1024-bit keys was always DNS packet size: a 1024-bit RSA public key fits in a single UDP DNS response without truncation, while 2048-bit keys push responses past 512 bytes and rely on EDNS0 or TCP fallback. That was a real concern in 2010. In 2026, every resolver that matters handles large TXT responses fine, and Google, Microsoft, and Yahoo all accept and recommend 2048-bit keys.

The risk case: 1024-bit RSA is not broken, but it's within sight of well-resourced adversaries. If a state-level actor or a large criminal operation wanted to forge signatures from your domain — and DKIM signatures are exactly what lend credibility to phishing — 1024-bit is the weak link. 2048-bit pushes factoring out of practical reach for the foreseeable future. There's also a documented history of researchers factoring weak 512-bit DKIM keys found in the wild and demonstrating forged mail from major domains; the lesson stuck, and 1024 became the floor. Floors get raised. Don't build on the floor.

Practical notes:

• Most ESPs now generate 2048-bit keys by default. If your ESP's DNS instructions give you a short p= value, check their settings — many let you choose key length.
• If you self-host with OpenDKIM, specify -b 2048 when generating.
• Some older platforms hardcode 1024. If you can't change it, that platform becomes your highest-priority rotation candidate, and a line item for your next vendor review.

Why rotate at all?

Four reasons, in descending order of how often they actually bite:

1. Key compromise. If the private key leaks — a breached mail server, a misconfigured backup, a former vendor that still has it — the attacker can send DKIM-valid mail as your domain until you rotate. Valid DKIM is a reputation loan, and someone else is spending it. This also connects to DKIM replay attacks, where legitimately signed messages get re-injected at scale; shorter key lifetimes shrink the replay window.
2. Personnel and vendor changes. Everyone who ever had access to the private key or the signing infrastructure is a potential leak. Employee offboarding and ESP migrations are natural rotation triggers.
3. Crypto hygiene. Long-lived keys are long-lived targets. The same logic that rotates TLS certs and SSH keys applies here — the industry just hasn't built the automation yet.
4. Compliance frameworks. SOC 2 and ISO 27001 auditors increasingly ask about email signing key management. "We rotate annually" is a much better answer than "we set it up in 2021."

How often should you rotate DKIM keys?

There's no RFC-mandated cadence, so here's practitioner guidance: every 6–12 months for most senders. Annually is a reasonable default if your infrastructure is stable and access-controlled. Go to 6 months if you're high-volume, high-value (finance, healthcare), or you've had any security incident touching mail infrastructure. Going beyond 12 months means you're relying on nothing having gone wrong — which you can't verify, because key compromise is silent until forged mail shows up.

The trigger-based rotations matter as much as the calendar ones. Rotate immediately when: an employee with DNS or mail-server access leaves; you migrate off an ESP (their copy of the private key should become worthless the day you leave); any server in the signing path is breached or decommissioned sloppily; or you discover a selector you can't account for. Scheduled rotation is hygiene. Triggered rotation is incident response.

The cost of rotation is low once you've done it once: one DNS record, one config change, one verification pass. The cost of not rotating is unbounded and invisible.

The zero-downtime rollover sequence

This is the part people get wrong. The naive approach — generate a new key, overwrite the DNS record — creates a window where in-flight mail fails verification and where any cached DNS still serves the old key. Do it this way instead:

Step 1: Inventory every selector in use

Before you touch anything, list every platform that signs mail for your domain and which selector each uses. Check your outbound mail streams: marketing ESP, transactional ESP, Google Workspace or Microsoft 365, helpdesk, CRM, that WordPress plugin someone installed. Pull a real message from each stream and read the DKIM-Signature header, or use the free DKIM checker to test each selector you find. Write the list down. Rotation that misses one platform is how you end up with a stream failing DMARC alignment — and in a world of Gmail 550 5.7.26 rejections, alignment failures are delivery failures.

Step 2: Generate the new keypair

Generate the new RSA keypair on the signing side (or have your ESP do it). Use a new selector name — the convention that saves you from ambiguity is date-based selectors: 202608, 2026q3, aug2026. Never reuse an old selector name; you'll never be sure which key a given signature was made with.

Step 3: Publish the new public key in DNS

Add the new record alongside the existing one:

202608._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx7k..."
s1._domainkey.example.com.     3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw2m..."

Both records coexist. Nothing breaks, because nothing is signing with the new selector yet.

Step 4: Verify the published key

Query the record and confirm it resolves and parses:

dig TXT 202608._domainkey.example.com +short

Then validate it with the DKIM checker tool — it catches truncated keys, stray whitespace, and split-string formatting errors that dig output can hide. Long 2048-bit keys in zone files often need to be split into quoted strings; that's normal and valid, but a bad split silently corrupts the key.

Step 5: Switch signing to the new selector

Configure your mail server or ESP to sign with the new selector. This is the cutover. Mail sent from this point carries s=202608 and verifies against the new key.

Step 6: The overlap window

Keep the old public key in DNS for at least 7 days after cutover — longer if you send to lists with long retry tails. Messages signed just before cutover are still in queues, in transit, and in greylisting retries; receivers will still look up the old selector. Deleting the old key early turns those messages into DKIM failures. Some practitioners run dual-signing (both signatures on every message) during this window; it's not required for a clean rotation, but it's harmless insurance on high-volume streams.

Step 7: Retire the old key

After the overlap, delete the old selector's DNS record. Don't zero out the p= value (p=) as a soft-retire — it works per spec (it declares the key revoked), but deleting the record is cleaner and equally unambiguous to verifiers.

The timeline at a glance

Automating the checks

Rotation isn't done when the DNS record is deleted — it's done when you've confirmed every stream verifies with the new key. Two checks worth automating:

1. Weekly DNS drift scans. Confirm your expected selectors exist and match the expected public keys. ESPs occasionally rotate their own selectors and update their CNAME targets without telling you. DMARC/domain monitoring that tracks DKIM record drift catches this. WillItInbox's DMARC monitoring watches SPF, DKIM, and DMARC records continuously and alerts when something changes — which turns "did the rotation work?" from a manual dig session into an alert you don't receive.
2. DMARC aggregate report review. Your rua reports show DKIM pass/fail per sending source. After a rotation, watch the reports for the old selector's sources: they should show DKIM passing under the new selector within a day or two. A source still failing a week later is a missed platform from your Step 1 inventory. If you're not already reading these, our guide on reading DMARC aggregate reports walks through the XML. And if your DMARC policy is still at p=none, rotation season is a fine time to revisit the path from none to reject — DKIM health is half of what makes p=reject safe.

One subdomain note: if you send from subdomains, their DKIM keys live under the subdomain (s1._domainkey.mail.example.com), and they're separate rotation items. DMARC policy inheritance for subdomains is its own topic — see the DMARC sp= tag guide — but DKIM keys never inherit. Each signing domain's selectors are their own inventory line.