How to Rotate DKIM Keys Without Breaking Delivery

Rotating DKIM keys without disrupting email delivery requires running a dual-key staging process. Generating a new key and immediately replacing your existing DNS TXT record causes in-flight emails, deferred delivery queues, and cached MTA sessions to fail DKIM checks. By publishing the new public key under a new selector first, switching your outbound signing mechanism second, and retiring the retired key third, you maintain full cryptographic continuity.

Quick Guide: Zero-Downtime DKIM Rotation

To rotate DKIM keys safely, create a new cryptographic pair under a distinct selector name (e.g., google2026). Publish the new public key to your DNS. Once DNS propagation finishes (typically 24–48 hours), update your mail server to begin signing outbound messages with the new selector. Wait another 48 hours for in-transit mail to clear before removing the old DNS key.

Why Immediate Key Replacement Fails

A common administrative error during DKIM key rotation is editing the existing selector’s DNS record directly (e.g., swapping the p= string inside google._domainkey.example.com).

This causes immediate delivery problems:

1. DNS Caching / TTL Discrepancies: Receiving MTAs cache DNS answers based on the record’s TTL. If an email is signed with the new private key, but the receiving MTA relies on a cached copy of the old public key, signature validation fails with an invalid signature error.
2. In-Flight Mail Delivery: Emails transmitted right before the change can be delayed in recipient queues or greylisted. By the time the destination server performs the public key query, the key has changed, triggering a permanent DKIM validation error.
3. Replay and Spooling Latency: High-volume senders, marketing platforms, and transactional relays often hold messages in outbound spoolers. A sudden key replacement invalidates all pre-signed, un-sent messages.

The solution is selector-based rotation. Because the selector name forms part of the DNS lookup path, you can run multiple valid public keys simultaneously on the same domain without conflict.

The Zero-Downtime 4-Phase Rotation Workflow

Phase 1: Publish New Key
  DNS: [selector1 (active)] + [selector2 (staged)]
  Outbound Signing: selector1

Phase 2: Propagation Window (24-48 Hours)
  Allow all global DNS resolvers to cache the new selector2 record

Phase 3: Switch Active Signer
  DNS: [selector1 (old)] + [selector2 (active)]
  Outbound Signing: selector2

Phase 4: Retire Old Key (48 Hours Later)
  DNS: Remove selector1 TXT record

Phase 1: Generate and Publish the New Selector Key

Never overwrite your existing selector. Instead, generate a new key pair using a descriptive, timestamped selector name (such as 2026a or gsuite2).

For organizations upgrading to stronger keys, follow How to Generate 2048-bit DKIM Key in Admin Console.

Once generated:

1. Log in to your DNS provider.
2. Create a new TXT record using the new selector:
   • Host: [new-selector]._domainkey.example.com
   • Value: v=DKIM1; k=rsa; p=[NewPublicKeyData]
   • TTL: 3600 (1 hour)
3. Do not modify or delete the old DNS TXT record.

Phase 2: Wait for DNS Propagation

Before pointing your outbound mail system to the new selector, verify that external DNS resolvers can see the new record.

Run a query against public DNS resolvers:

dig txt new-selector._domainkey.example.com @8.8.8.8 +short
dig txt new-selector._domainkey.example.com @1.1.1.1 +short

Wait at least 24 hours (or the duration of your record’s previous TTL) to ensure the new public key is cached and discoverable worldwide.

Phase 3: Switch Outbound Signing to the New Selector

Once the new DNS record resolves reliably:

1. In your mail server or provider dashboard (Google Workspace, Microsoft 365, or local MTA like Postfix/Exim), update the active DKIM selector to the new value.
2. Start DKIM signing with the new selector.
3. Send a test email to an external account (such as a personal Gmail account or a header analysis tool) and inspect the authentication headers to confirm:
   • s=[new-selector] appears in the DKIM-Signature header.
   • dkim=pass is confirmed by the receiving MTA.

If migrating platforms or keys leads to signature errors, refer to Troubleshooting “Invalid DKIM Signature” after Migration.

Phase 4: Revoke and Clean Up the Retired Key

Do not remove the old DNS record immediately after updating the outbound signer. Mail that was sent right before the switch might still be queued on intermediate MTAs, awaiting delivery.

1. Wait a minimum of 48 to 72 hours after updating the outbound signer.
2. Review your DMARC aggregate reports (RUA) to ensure that no legitimate traffic is failing under the old selector.
3. Once reports show 100% of signatures using the new selector, delete the old TXT record ([old-selector]._domainkey.example.com) from your DNS zone.

Operational Best Practices

• Rotation Cadence: Rotate organizational DKIM keys every six to twelve months to reduce risk from compromised private keys.
• Key Length: Use 2048-bit RSA keys. Only drop to 1024-bit keys if your DNS registrar cannot support 2048-bit strings (more than 255 characters in a single string, which requires string concatenation).
• Third-Party Alignment: If you send email through transactional or marketing providers, review How to Align SPF/DKIM for Third-Party Apps to manage multiple signing services without conflicting with your primary domain policies.