You set up DKIM once during the initial SPF/DKIM/DMARC checklist. The key has been signing every outbound message since. It works. You moved on to the next fire.
Months later the same key is still the only one. If it leaks, if the laptop it was generated on disappears, or if you simply want a repeatable hygiene habit, you have nothing. Most indie founders never rotate DKIM keys. They treat the initial setup as a one-time event.
This post fixes that. It assumes you already have working SPF, DKIM, and DMARC records. The goal is a 15-minute zero-downtime rotation using two selectors, a short TTL window, and one monitoring step that catches the gotcha almost everyone misses.
The dual-selector trick
The usual approach is dangerous: generate a new key, replace the old DNS record, update the MTA config, and pray nothing is in flight. A message signed during the cutover can fail DKIM and bounce or land in spam.
Instead, keep two selectors active for a brief, controlled window. Name them by year and letter so they are obviously temporary: s2026a and s2026b.
The sequence is simple.
- Generate the new key pair. Publish only the public key under the new selector (
s2026b._domainkey). Leave the old selector (s2026a._domainkey) exactly as it is. - Set a short TTL on both TXT records (300 or 600 seconds) for the duration of the rotation.
- Wait one full TTL so the new record has propagated everywhere.
- Update your mail server configuration to sign with the new selector (
s2026b). - Wait another short buffer (one TTL plus five minutes).
- Remove the old selector DNS record.
At no point is mail signed with a selector whose public key is not published. No message is lost. The overlap window is measured in minutes, not days.
Most people who try to rotate without this pattern either cause a brief outage or leave the old selector in DNS “just in case” for months. The dual-selector method removes both problems.
ed25519 vs 2048-bit RSA in 2026
Use ed25519 unless you have a documented reason not to.
RFC 8463 added Ed25519-SHA256 support to DKIM. The resulting TXT records are roughly one-third the size of a 2048-bit RSA record. Signing and verification are faster. Every major mailbox provider (Google, Microsoft, Yahoo, Cloudflare, Amazon SES, Postmark, etc.) has supported it for years.
2048-bit RSA remains the safe fallback when you are dealing with ancient internal mail servers or a very old recipient MTA that has never been updated. In 2026 that situation is rare for normal SaaS and transactional mail.
Generate the new key with your normal tool and specify ed25519:
opendkim-genkey -t ed25519 -s s2026b -d yourdomain.com
Or the equivalent one-liner in rspamd or whatever you use. The rest of the rotation process is identical regardless of algorithm.
The stale-selector gotcha
This is the part that quietly breaks deliverability weeks after you think you are done.
Gmail and Outlook cache DKIM public keys by selector. The cache can live for up to 90 days. A message that was queued before your cutover, or that passes through a forwarder or mailing list that still holds the old selector in memory, can arrive signed with s2026a long after you deleted the record.
When that happens the receiving server looks for s2026a._domainkey and finds nothing. DKIM fails even though the mail was legitimately sent from your domain.
You will not see this in your own mail logs. The only reliable signal lives in the DMARC aggregate reports you already receive at your rua address.
Watch those reports for at least seven days after the planned removal date. Any signature that still references the retired selector means the record needs to stay live for another 30 days. Most forwarders and queues clear within a week; some legacy systems take longer.
Rotation cadence
Rotate every 6–12 months. Put the task on the calendar the same week you review SPF includes or rotate other long-lived secrets. Treat it as scheduled maintenance, not an emergency response to a suspected compromise.
If you only rotate when something feels wrong, you will rotate far too late and far too rarely.
Verification that the swap actually completed
Three quick checks confirm the rotation succeeded.
First, send a test message to any Gmail address and view the full headers. The DKIM-Signature line must show s=s2026b (or whatever new selector you chose). If it still shows the old selector, your MTA config change did not take effect.
Second, examine the DMARC rua reports for the domain. After the cutover date you should see zero dkim=fail rows that mention the old selector. Persistent failures from the retired selector are the stale-selector problem described above.
Third, run the built-in test from your MTA on the mail server itself:
opendkim-testkey -d yourdomain.com -s s2026b
It should report that the key matches the published record. Do the same for the old selector only while it is still published; once removed it will correctly fail the test.
If you want a deeper walkthrough of reading rua reports without paying for a SaaS dashboard, see the post on DMARC aggregate reports without a SaaS.
You already did the hard part
The original SPF/DKIM/DMARC checklist got your records green. This post gives you the habit that keeps them green after the first key ages out.
The dual-selector pattern is the smallest possible change that eliminates the risk of a rotation outage. The monitoring step with rua reports is the only way to know the job is truly finished instead of hoping the caches cleared.
The $19 Inbox/DNS Pack and the $79 QuickCheck
If you want the exact dual-selector DNS templates plus the 20-line opendkim or rspamd swap script, the Inbox/DNS Pack contains both ready to copy. No guessing at record syntax. No writing the flip logic from scratch.
After the rotation, if you want an outside set of eyes on a week of your actual rua reports to confirm the old selector is dead (including any forwarders still holding the cached key), the Inbox Cleanup QuickCheck is the option that removes the remaining uncertainty. You send the reports; I confirm the cutover completed and flag anything still signing with the retired selector.
Both are designed for solo founders who already understand the basics and just need the repeatable execution piece.
Do the rotation on a schedule. Use two selectors. Watch the reports for a week. That is the entire maintenance loop.