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 — which means the same private key sits on mail servers for years, signing everything, waiting to leak. 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. If any of this is new, the SPF, DKIM and DMARC explainer covers how DKIM fits into the bigger authentication picture.

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 entire 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 — s2026a, 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 sets the floor — verifiers must handle keys from 1024 to 4096 bits, and 1024-bit RSA is widely regarded as too weak a margin for keys that live in DNS for years. 2048 is the compatibility sweet spot: 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 elegantly short, 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 industry guidance is to rotate roughly every six to twelve months, and immediately after any suspected compromise or departure of someone with key access. One clarification: if Google Workspace or Microsoft 365 signs your mail with keys they manage, rotation of those is their job. Your job is every key you generated yourself — on Postfix/OpenDKIM boxes, appliances, and any provider that had you generate the 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 use 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 declare victory on the DNS record alone — 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 sign 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 continuously monitors your DKIM selectors alongside SPF and DMARC, alerting when a record changes, disappears, or your email authentication weakens — in the same dashboard as your uptime, SSL and DNS monitoring.

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