DKIM Key Rotation: When to Rotate Your Signing Keys and How to Do It Safely

DKIM keys are not meant to last forever. Running the same signing key indefinitely is a security risk: if a key is compromised without your knowledge, an attacker could forge valid DKIM signatures for your domain indefinitely. Regular DKIM key rotation limits that exposure — but doing it wrong can break email authentication for everyone you send to until the problem is diagnosed and fixed.

This guide covers when to rotate DKIM keys, how to do it safely without disrupting delivery, and what to verify afterward.

How DKIM Signing Works (Briefly)

When you send a signed email, your mail server adds a DKIM-Signature header to the message. That signature is generated with a private key stored on your sending server. The receiving server retrieves your public key from DNS — published as a TXT record at a selector subdomain — and uses it to verify the signature.

The key pair is asymmetric: the private key signs, the public key verifies. Rotation means replacing both: generating a new key pair, publishing the new public key in DNS, configuring your server to use the new private key, and eventually removing the old public key.

Why You Should Rotate DKIM Keys

• Security hygiene: Cryptographic keys can be compromised through server breaches, backup leaks, or insider access. Shorter key lifetimes limit the window of exposure.
• Key length upgrades: If you're still using 1024-bit RSA keys, rotate to 2048-bit. Major providers including Gmail have signaled that 1024-bit keys offer insufficient security for modern email.
• Auditing and compliance: Some security frameworks require periodic credential rotation. DKIM keys are credentials.

How often should you rotate? At minimum, once a year. Security-conscious organizations rotate every 3–6 months. The exact interval matters less than doing it consistently and correctly.

The Safe Rotation Sequence

The most common mistake with DKIM key rotation is removing the old key before messages signed with it have finished delivering. In-flight messages may be queued or deferred and won't be verified until they arrive — if you've already deleted the old public key, those verifications fail.

Step 1: Generate a new key pair

Generate a new RSA private key (2048-bit minimum) and corresponding public key:

# Generate a 2048-bit RSA private key
openssl genrsa -out dkim-private-new.key 2048

# Extract the public key
openssl rsa -in dkim-private-new.key -pubout -out dkim-public-new.key

Step 2: Publish the new public key under a new selector

A DKIM selector is the subdomain prefix used to look up your public key. If your current selector is mail, create a new one like mail2 or a date-based name like 2026a. Publish the new public key — do not replace the old record yet:

mail2._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=YOUR_PUBLIC_KEY"

Step 3: Wait for DNS propagation

Wait for the new record to fully propagate — typically 24–48 hours depending on your TTL. Verify:

dig TXT mail2._domainkey.example.com

Step 4: Switch your signing configuration to the new key

Update your mail server or sending service to sign with the new private key and the new selector. Send a test email and confirm the new selector appears in the DKIM-Signature header.

Step 5: Keep the old key in DNS for 48–72 hours

After switching, leave the old public key record in DNS for at least 48 hours. Messages signed with the old key may still be queued or deferred. Both keys can coexist in DNS without conflict.

Step 6: Remove the old public key and private key

Once you're confident no messages signed with the old key are still in transit, delete the old selector's DNS record and securely remove the old private key from your server.

Verifying the Rotation Worked

After switching to the new key, send a test message and inspect the headers:

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

The s= value should reflect your new selector. The receiving server's authentication result should confirm the pass:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@example.com header.s=mail2

DKIM Key Rotation for Managed Services

If you're using a managed email platform, the rotation process may happen through a dashboard rather than direct server access. With services like MailDog's SMTP infrastructure, DKIM is configured per domain and keys can be updated through the control panel. The documentation walks through the exact steps.

Some managed services rotate keys automatically. If yours does, verify it's actually happening by checking which selector appears in your sent mail's headers periodically.

A Rotation Checklist

• New key pair generated (2048-bit minimum)
• New public key published in DNS under a new selector
• DNS propagation confirmed before switching
• Mail server updated to sign with new private key and new selector
• Test email confirms new selector in headers and DKIM pass
• Old public key remains in DNS for 48–72 hours post-switchover
• Old private key and old DNS record removed after cutover period

For teams managing the full authentication stack, DKIM rotation is best tracked alongside SPF and DMARC reviews. The MailDog DNS security overview covers all three. Done correctly, rotation is a background maintenance task — done wrong, it's a deliverability incident that can take hours to diagnose. Visit the MailDog blog for more practical authentication guides.