DKIM Key Rotation: Selectors, 2048-Bit Keys and Zero-Downtime Swaps

DKIM key rotation is the piece of email security everyone agrees on in theory and almost nobody schedules in practice. Teams publish a DKIM key once, watch the green checkmark appear, and never touch it again, so the same private key sits on mail servers for years, signing everything. A stolen DKIM private key is a phishing kit with perfect credentials: mail signed with it passes authentication as your domain. This guide covers how DKIM signing actually works, how selectors make rotation possible, 1024 vs 2048-bit keys, and a dual-selector rotation procedure that never drops a signature.

How a DKIM signature actually works

Your mail server holds a private key. For each outgoing message it computes a hash of the body and selected headers, signs it, and attaches a DKIM-Signature header:

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=s2026a;
    c=relaxed/relaxed; h=from:to:subject:date:mime-version;
    bh=g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs=;
    b=KxTAbSp+ZKXlLw0uVL8QYm...

Two tags matter for rotation. d= is the signing domain; s= is the selector. Together they tell the receiver where to fetch your public key: a TXT record at {selector}._domainkey.{domain}, here s2026a._domainkey.yourdomain.com:

s2026a._domainkey.yourdomain.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEF...IDAQAB"

The receiver verifies b= (the signature) against that public key and bh= (the body hash) against the body. Pass means the message provably came from infrastructure holding your private key and wasn't modified in transit.

Selectors are the rotation mechanism

Notice what the selector buys you: a domain can publish many DKIM keys simultaneously, each under its own selector, and every message names the selector that verifies it. That's the whole trick behind zero-downtime rotation: old and new keys coexist in DNS while you switch signing over.

Two selector strategies worth adopting:

• Date-based names such as s2026a and s2026b make key age self-documenting. A selector named default that's been live since 2019 is a finding in itself.
• One selector per sending service. Your own mail server, your transactional provider and your marketing platform should each sign with distinct selectors (providers typically assign their own, like selector1/selector2 for Microsoft 365). Separate selectors mean you can rotate or revoke one service's key without touching the others.

1024 vs 2048-bit keys

Short version: use 2048. RFC 8301 says signers must use at least 1024 bits and should use at least 2048, and verifiers must handle keys from 1024 to 4096 bits. 1024-bit RSA is too thin a margin for a key that may live in DNS for years; 2048 is universally verifiable and comfortably strong.

The practical wrinkle: a 2048-bit public key is longer than 255 characters, the maximum size of a single TXT character-string. The record must be split into multiple quoted strings, which resolvers concatenate:

s2026a._domainkey.yourdomain.com. IN TXT ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0Fs8Z2..."
    "...4Xw1QIDAQAB" )

Most DNS providers handle the splitting automatically when you paste a long value; a few older control panels choke, which is the usual reason people retreat to 1024. Don't; fix the DNS tooling instead. (Ed25519 DKIM keys also exist and are much shorter, but verifier support remains limited as of mid-2026, so RSA-2048 stays the safe default.)

Why rotate at all

• The private key is exposed surface. It lives on every box that signs mail: app servers, SMTP relays, third-party providers. A compromised host, a leaked backup, or an ex-employee's laptop can all walk away with it, and there's no certificate transparency log or expiry date to save you. Rotation puts a hard bound on how long a stolen key stays useful.
• Compromise is invisible. Unlike a breached password, a leaked signing key produces no login alerts. Attackers can sign spoofed mail that sails through DMARC. You'd likely never know.
• Old keys are weak keys. Long-lived deployments still run 1024-bit keys from a decade ago; rotation is the natural moment to upgrade to 2048.

There's no RFC-mandated schedule, but common guidance is to rotate roughly every six to twelve months, and immediately after any suspected compromise or departure of someone with key access. With hosted providers such as Google Workspace or Microsoft 365, the provider holds the private key and rotation happens in their admin console (or, for some setups, automatically), so follow their procedure. The dual-selector process below is for keys you generated yourself: Postfix/OpenDKIM boxes, appliances, and any service that had you create the key pair.

Dual-selector rotation, step by step

The wrong way is to overwrite the existing key in place: mail signed moments before the DNS change now fails verification. The right way never has a signed message without a resolvable key:

1. Generate a new key pair with a new selector. If the live key is s2026a, create s2026b. Keep the private key with the same care as a TLS key.
2. Publish the new public key at s2026b._domainkey.yourdomain.com before touching anything else. Verify it resolves (dig TXT s2026b._domainkey.yourdomain.com +short, or the free DNS lookup tool) and wait out your DNS TTL so every resolver can see it.
3. Switch signing to s2026b in your mail server or provider dashboard. From this moment, new mail references the new selector; old mail still verifies against s2026a, which is still published.
4. Leave s2026a in DNS for at least a week. Mail can sit in retry queues and forwarding chains for days; the old record must stay resolvable until every message signed with it has been delivered and verified.
5. Revoke the old key. Publish it with an empty p= tag (v=DKIM1; k=rsa; p=), the explicit "this key is revoked" signal, and delete the record after a further grace period. Destroy the old private key.

Total downtime: zero. At no point does any message reference a selector that doesn't resolve.

Verifying after rotation

Don't stop at the DNS record; verify the signing switched too:

• Send a test message to a Gmail account, open Show original, and confirm dkim=pass with header.d=yourdomain.com and header.s=s2026b in the Authentication-Results.
• Check your DMARC aggregate reports over the following days for any rise in DKIM failures, the early warning that some sender is still signing with the retired key. (If you're mid-way through moving DMARC to p=reject, pause the ramp until the rotation proves clean.)
• Confirm every selector you expect to exist still resolves, and the revoked one shows the empty p=.

Make key age impossible to forget

Rotation fails as a policy because nothing reminds you: a DKIM key has no expiry date, so "we'll rotate in Q3" quietly becomes never. CompleteStatus's email authentication monitor checks your DKIM selectors alongside SPF and DMARC and flags a selector that stops resolving, in the same dashboard as your uptime and SSL monitoring.

See what your domain publishes right now with the free DMARC / SPF / DKIM checker, then start monitoring free so a missing selector shows up before it hurts deliverability. The free tier allows commercial use.