DKIM Selector Rotation: Complete Operational Guide

DKIM key rotation — replacing the current signing key pair with a new one — is a security hygiene practice recommended annually and required whenever there is any possibility the private key has been exposed. Done correctly with a proper transition period, DKIM rotation is invisible to recipients and causes zero delivery disruption. Done incorrectly, it causes immediate DKIM failures that persist for hours or days. This guide documents the correct rotation sequence with the transition period protocol that makes rotation delivery-safe.

Why Rotate DKIM Keys

DKIM private keys that are never rotated accumulate exposure risk over time. The private key file on the sending server is a high-value target — anyone who obtains it can forge email that passes DKIM verification from the affected domain. Annual rotation limits the exposure window: even if a key was compromised at some point, it becomes useless to an attacker within the rotation cycle.

Additionally, DKIM key rotation is the mechanism for upgrading key strength. The 1024-bit DKIM keys that were standard before 2018 are now considered insufficient — modern standards recommend 2048-bit minimum, with 4096-bit for highest-security applications. Any legacy 1024-bit keys should be rotated to 2048-bit as a priority, regardless of the normal rotation schedule.

Additional rotation triggers beyond the annual schedule: any suspicion that the private key file has been accessed by unauthorized parties, any server security incident, any change in the server environment that may have exposed the key file (misconfigured backup including private key files in a public location), or any credential leak associated with the server's administrative accounts.

When to Rotate: Schedule and Triggers

The annual rotation schedule should be documented and calendar-tracked. The best time for planned rotation: during a low-volume period. Avoid rotating during Q4 peak sending, before a major campaign deployment, or on a Monday when weekend queued messages may still be processing. Midweek, mid-morning in the programme's primary timezone, with the deliverability team available to monitor — these conditions make rotation lowest-risk.

The rotation should be on the calendar 4-6 weeks in advance, with reminders at 2 weeks and 1 week. The pre-rotation checklist: generate the new key pair in advance, prepare the DNS TXT record content, identify who has access to publish DNS records, and confirm the MTA configuration change process. Having all of this prepared before the rotation date means the actual rotation is a 30-minute execution rather than a 3-hour discovery-and-execution session under time pressure.

Generating New Keys: Commands and Parameters

Use a year-based selector naming convention so key age is visible from the selector name — mail2026 clearly indicates when the key was generated. Generate with opendkim-genkey or OpenSSL:

# Using opendkim-genkey — generates key pair and DNS record format
opendkim-genkey -b 2048 -d brand.com -s mail2026 -D /etc/pmta/dkim/brand.com/
# Creates: mail2026.private (keep secret) and mail2026.txt (DNS record content)

# Verify 2048-bit key size
openssl rsa -in /etc/pmta/dkim/brand.com/mail2026.private -text -noout | grep "Private-Key"
# Expected: Private-Key: (2048 bit)

# Set restrictive permissions immediately
chmod 600 /etc/pmta/dkim/brand.com/mail2026.private
chown pmta:pmta /etc/pmta/dkim/brand.com/mail2026.private

The mail2026.txt file contains the DNS TXT record in the format: mail2026._domainkey IN TXT "v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY". This is the content to publish in DNS.

DNS Publication: The Safe Rotation Sequence

The critical principle: publish the new DNS record BEFORE changing the MTA signing configuration. This ensures the public key is available in DNS before any messages are signed with the new private key.

Updating MTA Configuration

After the DNS record is confirmed published and propagated, update the PowerMTA signing configuration. The new configuration line uses the new selector name and new private key path. Remove or comment out the old signing line after the transition period:

# In PowerMTA config — during transition period, both lines may exist:
# dkim-sign domain=brand.com selector=mail key=/etc/pmta/dkim/brand.com/mail.private  # OLD — remove after transition
dkim-sign domain=brand.com selector=mail2026 key=/etc/pmta/dkim/brand.com/mail2026.private  # NEW

# After transition period — only new line remains:
dkim-sign domain=brand.com selector=mail2026 key=/etc/pmta/dkim/brand.com/mail2026.private

For multi-domain PowerMTA setups, repeat the rotation for each domain's DKIM configuration. Update each domain's signing line independently, verify each one separately, and complete the transition period for each before retiring the old keys. Rotating all domains simultaneously increases the blast radius if anything goes wrong — stagger the rotations by domain if managing many domains.

Post-Rotation Verification

After switching the MTA to the new selector, perform end-to-end verification before retiring the old key. The Authentication-Results header from a test message is the definitive verification:

# Expected Authentication-Results after successful rotation:
Authentication-Results: mx.google.com;
   dkim=pass header.i=@brand.com header.s=mail2026 header.b=SIGNATURE_DATA;
   spf=pass ...;
   dmarc=pass ...

If the DKIM-Signature still shows the old selector after MTA configuration update, the configuration change did not take effect — check for syntax errors in the config file and re-run pmta reload. Check the Postmaster Tools authentication dashboard over the next 24 hours — DKIM pass rate should remain at 100% if the rotation was successful. Any drop in DKIM pass rate indicates some sending path is still using the old key or a signing misconfiguration occurred.

Old Key Retirement Timeline

The old DKIM DNS record must remain published for a minimum of 48-72 hours after switching the MTA to the new selector. This allows any messages signed with the old key before the configuration change — including messages in ISP retry queues with retry periods up to 72 hours — to complete DKIM verification successfully.

Before removing the old DNS record: query the accounting log to confirm no messages with the old selector are still processing. If the accounting log shows zero delivery events with s=mail (old selector) for the past 4 hours, the old selector is safe to retire. Remove the old DNS TXT record from DNS, then securely delete (shred) the old private key file from the server. The private key of the retired selector provides no security value after the DNS record is removed — retaining it only creates unnecessary exposure risk.

Archive the old public key (from the DNS record) in the infrastructure documentation, along with the rotation date and the new selector name. This documentation provides the audit trail that confirms annual rotation has been performed and records the rotation history for each domain.

Automating DKIM Rotation

For programmes managing multiple domains each requiring annual rotation, a rotation automation script using a DNS provider API (Cloudflare, Route53, DNSimple all provide REST APIs) can handle key generation, DNS publication, and cleanup automatically. The automation workflow:

1. Generate new key pair for each domain requiring rotation.
2. Publish new DNS records via DNS provider API. Verify propagation via API lookup.
3. Update PowerMTA configuration files with new selector and key paths.
4. Run pmta reload and send verification test message per domain.
5. Wait 72 hours (transition period).
6. Remove old DNS records via DNS provider API.
7. Archive old private keys to encrypted long-term storage, delete from server.
8. Send completion report to infrastructure team with rotation summary.

Even with automation, the verification step (step 4) should involve human review of the Authentication-Results header from a live test message — automated testing can miss edge cases that manual header review catches. Automate the mechanical steps; keep human verification for the correctness confirmation that determines whether the rotation proceeds safely. Annual DKIM rotation, executed correctly and on schedule, is the security maintenance that keeps authentication providing its full value — and the operational discipline this guide documents is what makes the rotation consistently safe.

DKIM Rotation for ESP-Managed Sending

For programmes using a managed ESP (Postmark, Mailgun, SendGrid, Amazon SES) rather than a self-managed MTA, DKIM key rotation works differently. These platforms manage the DKIM signing internally — the sender configures a custom signing domain by publishing DKIM and CNAME records provided by the ESP, and the ESP handles the actual key management and rotation on their side. The sender's responsibility: keep the DNS records the ESP requires published and up-to-date, and verify that DKIM continues passing after any ESP-side changes.

Some ESPs rotate their underlying signing keys automatically on a schedule and notify customers via dashboard notifications or email. When the ESP rotates, the corresponding DNS records may need to be updated by the sender. Check the ESP's documentation for their key rotation process and ensure alerts are configured to notify the infrastructure team when DNS record updates are required.

For ESPs that use CNAME-based DKIM setup (where the sender publishes a CNAME record pointing to the ESP's DNS, and the ESP serves the actual DKIM public key through the CNAME chain), key rotation is fully transparent to the sender — the ESP updates the key at their end and the CNAME automatically resolves to the new public key without any DNS change by the sender. This architecture makes DKIM rotation completely automatic for the sender but requires verifying that the CNAME chain is working correctly whenever authentication problems are reported.

DKIM key rotation is the email authentication equivalent of certificate renewal — a routine security maintenance task that, done correctly on schedule, ensures the authentication infrastructure continues providing its security value indefinitely. Build it into the annual security maintenance calendar; document the process; verify the result; and DKIM will remain a reliable, current security mechanism for the programme's full operational lifetime. The key that was generated today is securing email that will be sent years from now — rotate it annually to keep that security current and relevant.

The DKIM key is the digital signature that authenticates every message the programme sends. Rotate it annually; verify the rotation thoroughly; and it will continue authenticating reliably for as long as the programme sends email. The 30-minute rotation investment protects years of sending reputation — the asymmetry that makes DKIM key rotation one of the highest-security-ROI maintenance tasks available to commercial email senders.

Security without maintenance degrades. DKIM key rotation is the maintenance that keeps DKIM signing providing its full security value year after year. Schedule it, execute it correctly, verify it thoroughly, and it will be the invisible security layer that authenticates every message the programme ever sends — reliably, correctly, and with the current cryptographic strength the protocol deserves.

Annual DKIM rotation is the operational standard for professional email infrastructure. Programmes that rotate annually demonstrate the security maturity that enterprise recipients and corporate IT security teams increasingly require from their email vendors. That operational maturity — visible in the current, strong DKIM keys the programme uses — is a commercial differentiator as much as a security requirement. Rotate annually. Verify thoroughly. And let the current, strong DKIM signature on every message confirm the programme's commitment to email security for every recipient who checks.

The final word on DKIM rotation: do it annually, document the process, verify the result end-to-end, and keep both old and new keys active for the full transition period. These four practices make DKIM rotation a reliable, zero-disruption security maintenance task. Skip any of them and the rotation becomes the source of the authentication failure that this guide documents how to fix. Follow them consistently and DKIM will authenticate every message the programme sends with current, strong cryptographic keys — indefinitely.

Rotate the key. Verify the signature. Retire the old record after the transition window. That is the complete DKIM rotation in one sentence. The detail in this guide exists to make that simple sequence fail-proof in production environments where the cost of getting it wrong — immediate authentication failures across all sending — justifies the careful, documented, verified approach this guide describes.