Direct answer: Rotate DKIM by publishing a new selector with a new public key, waiting until DNS serves it everywhere, then switching the signer. Keep the old selector published at least 7 days (7–14 is the usual drain window) so queued and retried mail still verifies. Never overwrite p= on the live selector. Vendor-managed CNAME selectors (ArawaMail, SES Easy DKIM) are not yours to edit.
Two kinds of DKIM in the same company stack
Before you touch DNS, decide which keys you actually control.
- Customer-managed TXT keys. You hold the private key. The public key lives in a TXT record at
{selector}._domainkey.example.com. This is the overlap playbook below. - Provider-managed CNAME selectors. ArawaMail writes DKIM CNAMEs into Cloudflare when you enable sending. Amazon SES Easy DKIM works the same way: the vendor owns the private key and points your selector at their zone. Do not replace those CNAMEs with a TXT you generated. Do not invent an in-product ArawaMail “rotate DKIM” button—public docs do not describe one.
If several vendors send as the same From domain, that is inventory (one selector or subdomain per vendor), not a rotation. Leave ArawaMail CNAMEs alone and rotate only the TXT keys you generated yourself.
Why overwriting p= breaks mail
Receivers cache DNS. MTAs retry for days. A message signed with key A that arrives after you replaced key A on the same selector name fails DKIM. DMARC then loses the DKIM identifier for that message even when SPF still passes. The failure window is not “a few minutes of TTL.” It is every copy still in a queue or a retry loop.
Safe pattern: new name, then new signer, then old name retired. Unsafe pattern: edit p= on default._domainkey in place.
Overlap timeline
| Step | What you do | When it is done |
|---|---|---|
| 1. Publish | Create a new selector name and publish its TXT (2048-bit RSA, rsa-sha256). | Record exists in the authoritative zone. |
| 2. Verify | Look up the new name from more than one resolver. Confirm a single TXT, no CNAME collision, and a complete p=. | Public DNS answers match what you published. |
| 3. Switch | Point the signer at the new selector only. Leave the old TXT in DNS. | New outbound mail carries the new selector in DKIM-Signature. |
| 4. Overlap | Keep the old public key live so in-flight mail still verifies. | Minimum 7 days after switch; 7–14 days is the common range; 30 days on low-volume domains if you prefer caution. |
| 5. Retire | Delete the old record, or publish empty p= only if you intend to revoke that key immediately. | After the drain window, when queues should have flushed. |
How to name the new selector
Date-based names audit cleanly: s202609, 2026q3. Avoid recycling default or google unless a vendor forces that name. One selector name, one record type, one public key.
- Do not publish two TXT values on one selector.
- Do not leave a CNAME and a TXT on the same selector name.
- Do not reuse a retired selector name the same week you deleted it; wait out caches.
Key length, algorithm, and cadence
2026 operator baseline: 2048-bit RSA signed with rsa-sha256, rotated every 6–12 months (the cadence still cited in current M3AAWG-style and DKIM2 BCP drafts). Do not recommend 1024-bit except as a last-resort compatibility exception. Do not use rsa-sha1. 4096-bit RSA often needs multi-string TXT records and is usually unnecessary. Ed25519 appears in some MTA docs; it is optional and not an ArawaMail-documented algorithm.
DKIM2 dual-signature drafts exist and still assume regular rotation. They are not required for this procedure.
Worked examples
Safe. Publish s202609._domainkey.example.com with a new 2048-bit public key. Confirm the TXT from two resolvers. Switch the signing host to s202609. Wait 14 days. Delete s202603._domainkey.
Unsafe. Open default._domainkey, paste a new p=, save. Mail signed yesterday with the previous key starts failing as soon as resolvers pick up the new value.
Vendor-managed. ArawaMail already published DKIM CNAMEs when sending was enabled. SES Easy DKIM still auto-rotates with selector overlap on the AWS side. Leave those CNAMEs in place. If you only needed SES domain verification, use How to verify a domain in Amazon SES (Easy DKIM) instead of this playbook.
If your provider publishes CNAMEs
Skip steps 1–5 on those names. You do not generate an ArawaMail keypair. You do not swap the CNAME for a TXT. Rotation, if it happens, is the vendor’s problem. Your job is not to delete the CNAME during a “cleanup.” Google Workspace is commonly described as exposing one active key at a time in the admin UI—do not assume every vendor supports overlap the same way. Amazon SES Easy DKIM does overlap on the AWS side.
What rotation does not change
Rotating DKIM does not change SPF, MX, or MAIL FROM. Those are different records and different failure modes. A DKIM fail after a sloppy rotation often gets blamed on SPF. Check the selector in the DKIM-Signature header against live DNS before you touch anything else. For how the three mechanisms interact, see SPF, DKIM, and DMARC explained. After a rotation, skim aggregate data in How to read a DMARC report for a spike in DKIM fail aligned to the old selector. Lookups live on ArawaMail free email tools.
How we analyzed this
The overlap rule is stable: publish a new name first. Cadence, key length, and vendor CNAME behavior were checked against ArawaMail sending docs (DKIM as Cloudflare CNAMEs, no customer rotation UI) and current SES Easy DKIM behavior on draft day, 1 September 2026. Exact ArawaMail CNAME hostnames are issued in-product and are not copied here.
FAQ
How often should we rotate DKIM keys?
Every 6–12 months for customer-managed 2048-bit RSA keys is the 2026 baseline. Rotate immediately after a suspected private-key leak.
Can we change the key in place on the same selector?
No. Publish a new selector first. Overwriting p= on the live name fails signatures for in-flight mail.
How long must old and new selectors overlap?
At least 7 days after the signer switches; 7–14 days is the common safe range. Some operators leave 30 days on quiet domains.
What if we use CNAME-delegated DKIM from a vendor?
Do not edit or delete the CNAME. ArawaMail and SES Easy DKIM own those private keys. Follow this playbook only for TXT keys you generated.
Does rotating DKIM change SPF or MX?
No. Different records. Fix the selector inventory, not the apex SPF, when DKIM starts failing after a rotation.
How do we verify the new selector before switching signing?
Query {selector}._domainkey.example.com from more than one resolver. You want one TXT, a complete p=, and no CNAME+TXT clash. Then send one test message and confirm the new selector name in the signature header.