Why rotate DKIM keys#
Industry best practice: rotate DKIM keys every 6-12 months. Reasons:
- Security — limit blast radius if a key is ever compromised (rare, but possible via DNS-host breach)
- Cryptographic hygiene — same logic as password rotation
- Compliance — some industries (financial, healthcare) require explicit key rotation policies
- Best practice — major senders (Google, Microsoft) rotate; following the pattern signals professionalism
Most senders rotate annually. Some rotate every 6 months. Below 6 months is operational overhead with diminishing returns.
The 30-day dual-key transition#
A clean rotation doesn't replace the key instantly. Instead:
Day 0: Generate new key. Both old + new keys active.
Day 1-30: AcelleMail signs with BOTH keys. Receivers verify with either.
Day 30+: Disable old key. AcelleMail signs only with new key.
Day 60+: Remove old key from DNS entirely.
Why dual-key? Messages in transit at the moment of rotation:
- Sent at Day 0 with old key + received Day 1 → DKIM verifies against old key
- Sent at Day 30 with new key + received Day 32 → DKIM verifies against new key
If you replace instantly: messages-in-flight fail signature check + go to spam.
Rotate in AcelleMail#
Open the sending-domain detail#
In AcelleMail's sidebar, Sending → Sending domains. The list shows every domain you've registered with status chips (Verified / Pending / Failed) and per-auth indicators:
Click into your domain row. The detail page surfaces exactly which DNS records to publish (TXT for SPF, CNAMEs for DKIM, TXT for DMARC) with copy-paste-ready values + current verification state per check:
In the sending-domain detail page, DKIM Keys section:
- Current active key:
acellemail selector (or whatever your install uses)
- "Rotate key" button
Click Rotate key. AcelleMail:
- Generates a new keypair (2048-bit RSA by default)
- Assigns a new selector (e.g.
acellemail2)
- Begins dual-signing — every outgoing message gets two DKIM signatures (one per key)
- Shows you the new CNAME to publish at your DNS host
Publish the new DKIM CNAME#
The detail page shows the new CNAME:
Type: CNAME
Name: acellemail2._domainkey.yourdomain.com
Value: acellemail2._domainkey.acellemail.com
TTL: 3600
Add this at your DNS host alongside the existing acellemail._domainkey.yourdomain.com. Don't delete the old one yet.
Verify the new key#
After DNS propagation (5-60 minutes):
- Click Verify domain in AcelleMail
- Both selectors should show Verified
- Send a test campaign
- Open the test email → "Show original" → search for
DKIM-Signature: headers
- You should see TWO DKIM-Signature headers — one per selector
The auth chips on the sending-server detail#
Open Settings → Sending servers → click your active server. The toolbar shows the live SPF / DKIM / DMARC chip status:
- Green chips on all three = receiving servers can confirm you're authorized to send from this domain.
- Any chip red = receiving servers immediately downgrade reputation. Click Verify domain in the toolbar to walk through the DNS-fix wizard.
DKIM chip should remain Green throughout the dual-key period.
Day 30+: Disable the old key#
After 30 days of dual-signing, retire the old key:
- AcelleMail sending-domain detail → DKIM Keys
- Click Disable on the old
acellemail selector
- AcelleMail stops signing with the old key; only new key is used
- Wait 30 more days (for any super-stale messages still in transit)
Day 60+: Remove the old DNS record#
After another 30 days of single-key operation:
- At your DNS host, delete the
acellemail._domainkey.yourdomain.com CNAME
- Verify with
dig CNAME acellemail._domainkey.yourdomain.com +short — should return nothing
Now your domain only publishes the new key. Rotation complete.
The annual rotation cycle#
For a typical 1-year rotation:
Jan 1: Generate new key (selector: acellemail-2026). Begin dual-signing.
Jan 1-31: Publish new CNAME. Verify both keys active.
Jan 31: Disable old (selector: acellemail-2025). New key only.
Feb 28: Remove old DNS record entirely.
Calendar this. Set reminders for the 30-day + 60-day milestones.
Common UI signals + fixes#
| Symptom |
Likely cause |
UI fix |
| Both old + new keys show Verified, but DKIM chip stays Red |
Receivers seeing mixed signal |
Verify each via dig; AcelleMail re-check |
| New key fails signature check |
Wrong CNAME target at DNS host |
Re-copy exact CNAME value from AcelleMail's wizard |
| Old key still being used after disable |
Cached AcelleMail config; restart processing |
AcelleMail admin → clear sending-server cache; re-test |
| Test email has only 1 DKIM-Signature header during dual-key period |
One of the keys isn't actually signing |
Check AcelleMail dual-key feature is enabled; force re-rotate |
| DNS host shows "duplicate CNAME" warning |
Old + new CNAMEs both pointing to same target |
Verify each has a unique selector name |
| Rotation completes but old key still in DNS after 60 days |
You forgot to delete the old record |
Delete now; verify with dig |
Rotation triggers (beyond annual)#
Rotate EARLY if:
- DNS host security incident (potential exposure)
- AcelleMail security advisory mentions DKIM
- Compliance audit requires it
- Switching DNS providers (and rotating during transition)
NEVER rotate during:
- Critical campaign send windows (e.g. Black Friday)
- Within 7 days of a major sending-config change
- During a DMARC enforcement step-up
Multi-domain rotation#
If you have multiple sending domains, rotate one at a time:
Week 1: Rotate mail.brand.com
Week 4: Mail.brand.com rotation complete; rotate news.brand.com
Week 7: News.brand.com complete; rotate events.brand.com
Don't rotate all simultaneously — easier to debug if something breaks per-domain.
Key length#
Modern recommendation: 2048-bit RSA. Some DNS hosts have TXT length limits — if you can't publish a 2048-bit DKIM TXT directly, AcelleMail's CNAME approach (default) avoids this entirely.
For maximum security: 4096-bit. Rarely needed; some DNS hosts can't host 4096-bit TXT.
For legacy compatibility: 1024-bit. Still works at all receivers; not recommended for new setups.
Advanced: programmatic rotation triggers + emergency rapid-rotation + multi-tenant key management
Programmatic rotation:
#!/bin/bash
# Quarterly cron — rotate DKIM keys on a schedule
# Acelle API: POST /api/v1/admin/sending-domains/{uid}/dkim/rotate
domains=$(curl -sH "Authorization: Bearer $TOKEN" \
"https://acellemail.com/api/v1/admin/sending-domains" | jq -r '.data[].uid')
for d in $domains; do
curl -X POST -H "Authorization: Bearer $TOKEN" \
"https://acellemail.com/api/v1/admin/sending-domains/$d/dkim/rotate"
echo "Rotated $d"
done
# Then schedule a follow-up to publish CNAMEs (via DNS host's API)
Emergency rapid-rotation (compromised key):
If a key is compromised (unlikely but possible):
Day 0: Generate new key. Sign with new only (skip dual-signing — security > deliverability).
Immediately disable old key.
Send "incident in progress" alert to your DMARC reporting address.
Day 0+: Expect some bounce-rate spike for 24h as in-flight messages with old key fail.
Day 1: Remove old DNS record entirely.
Day 7: Resume normal operations; monitor for any abnormal DMARC reports.
Cost: ~24h of degraded delivery. Worth it for compromise scenarios.
Multi-tenant key management:
For SaaS sending-on-behalf, each tenant has their own DKIM:
Customer A: acellemail._domainkey.customerA.com (key A1)
Customer B: acellemail._domainkey.customerB.com (key B1)
Per-tenant rotation. The platform manages the keypair; customer publishes the CNAME at their DNS host.
Key rotation audit log:
# Log every rotation event for audit purposes
{
"event": "dkim_key_rotated",
"domain": "mail.brand.com",
"old_selector": "acellemail-2025",
"new_selector": "acellemail-2026",
"operator": "michael@nanosoft.tech",
"at": "2026-01-01T09:00:00Z",
"reason": "annual rotation"
}
Persist to your audit log. Useful for compliance + incident-investigation.
Selector naming conventions:
acellemail-2024 — year-based, easy to track age
acellemail-q1-2025 — quarterly granularity (if rotating every 3 months)
acellemail-prod-1 — sequential, no time correlation
Pick a convention + stick to it. Mixing conventions creates confusion later.
DKIM verification across receivers:
After each rotation, check verification at multiple receivers:
# Test with mail-tester.com
echo "Send a test email and verify the score"
# Test with DKIM Reporter from Postmark
# https://postmarkapp.com/email-headers
# Paste your email; see per-receiver pass/fail
# Direct dig verification of CNAME
dig CNAME acellemail-2026._domainkey.brand.com @1.1.1.1
dig CNAME acellemail-2026._domainkey.brand.com @8.8.8.8
Cross-check ensures no per-receiver caching surprises.
DKIM-Signature header inspection:
After rotation, examine raw emails:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=brand.com; s=acellemail-2026; t=1735756800;
h=From:To:Subject:Date:Message-ID;
bh=AbCdEfG=;
b=XyZ123...;
s= is the selector — should be your new selector value. d= is the signing domain.
If you see two DKIM-Signature headers during dual-key period, you'll see both selectors. After Day 30+, only the new selector.
Related articles#
