DKIM Key Rotation: When to Do It and How to Avoid Breaking Email

Why DKIM Keys Need to Be Rotated

DKIM signs every outgoing message with a private key stored on your mail server or relay. The corresponding public key lives in a DNS TXT record under a subdomain called a selector. Any private key that never changes is a liability: if it's leaked or compromised, an attacker can forge signatures indefinitely. Regular key rotation limits that window of exposure.

There's also a practical reason for rotation that has nothing to do with breaches. RFC 6376 recommends rotating keys at least every six months, and Google's 2024 bulk sender guidelines nudge senders toward 2048-bit keys and regular rotation as hygiene signals. Stale keys—especially 1024-bit ones published years ago—stand out as red flags to security-conscious receiving servers.

How Selectors Make Rotation Safe

The key insight behind safe rotation is that DKIM selectors are named independently. You're not replacing an existing key; you're publishing a new key under a new selector name, then switching your mail server to sign with the new key, and only then retiring the old one. This staging approach means no messages in transit or recently delivered messages lose their valid signature.

A selector is just a label. Common naming conventions:

• s1, s2 — simple sequenced names
• google, sendgrid — named for the sending service
• 2024a, 2025a — year-based rotation markers

The DNS record format is:

{selector}._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p={base64-public-key}"

Step-by-Step: Rotating a DKIM Key Without Breaking Anything

Step 1: Generate a New Key Pair

Use OpenSSL to generate a 2048-bit RSA key pair (or 4096-bit if your mail server supports it):

openssl genrsa -out dkim_new_private.pem 2048
openssl rsa -in dkim_new_private.pem -pubout -out dkim_new_public.pem

Strip the header/footer lines from the public key and base64-encode it into a single line for the DNS record.

Step 2: Publish the New Key in DNS

Add the new selector record to your DNS zone. If your current selector is s1, name the new one s2:

s2._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0B..."

Wait for DNS propagation—typically 5–30 minutes with a low TTL, up to 24 hours with a default one. Verify the record is live before touching your mail server config:

dig TXT s2._domainkey.yourdomain.com

Step 3: Update Your Mail Server to Sign With the New Key

Switch your SMTP server or sending relay to use the new private key and the new selector name. In Postfix with opendkim, this means updating /etc/opendkim/KeyTable and SigningTable and restarting the service. For a managed relay like MailDog's SMTP service, this is handled through the dashboard without touching config files.

Step 4: Verify Signing Is Working

Send a test message to a Gmail address and inspect the headers. Look for:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yourdomain.com; s=s2;

The s= value should match your new selector. Also check the Authentication-Results header in Gmail to confirm it reads dkim=pass.

Step 5: Retire the Old Key

Don't delete the old DNS record immediately. Keep it live for at least 48–72 hours after switching selectors. This gives any messages signed with the old key (still in transit or queued on remote servers) time to be delivered and verified. After that window, remove the old DNS record.

Common Mistakes That Break DKIM During Rotation

• Deleting the old selector before propagation settles. Messages signed under the old key can't be verified if the DNS record is gone.
• Publishing the key with incorrect formatting. Extra spaces, newlines embedded in the base64 string, or a missing p= tag will cause DKIM failures. Validate with a DKIM record checker after publishing.
• Forgetting to update all sending paths. If you send through multiple relays or have separate keys for different subdomains, rotate each one. A missed path means some mail goes out unsigned.
• Using 1024-bit keys. 1024-bit RSA is considered cryptographically weak. If you're rotating, always go to 2048-bit minimum.

How Often Should You Rotate?

Every six months is the commonly cited baseline. In practice, larger senders rotate quarterly. The right interval depends on your threat model—a transactional email service handling financial notifications warrants more frequent rotation than a small newsletter. Set a calendar reminder; key rotation is the kind of task that slips indefinitely without a scheduled date.

If you want to verify whether your current DKIM setup is correctly configured before starting a rotation, the MailDog DNS security tools check your selector, key length, and record syntax against current best practices. For context on how DKIM fits into the broader authentication picture, see our post on why emails land in spam.

A Note on DKIM and Third-Party Senders

If you use an ESP to send marketing or transactional mail, they may handle DKIM signing on your behalf using a subdomain delegation or a CNAME-based setup. In those cases, rotation happens on their side—but you should still verify periodically that the key they're using meets current bit-length standards. Don't assume a configured integration is still using a modern key.