DKIM key rotation: how to roll over selectors with zero downtime

# Generate new key pair
openssl genrsa -out dkim-20260308.key 2048
openssl rsa -in dkim-20260308.key -pubout -outform PEM | \
  grep -v "^-" | tr -d '\n' > dkim-20260308.pub.txt

# Publish new selector via Cloudflare API
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_records" \
  -H "Authorization: Bearer $CF_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "TXT",
    "name": "dkim-20260308._domainkey",
    "content": "v=DKIM1; k=rsa; p=YOUR_PUBLIC_KEY_HERE",
    "ttl": 300
  }'

The key benefit of API-driven rotation: you can build a cron job that rotates keys on a schedule (quarterly is a good cadence), monitors DMARC reports for old-selector traffic, and retires selectors automatically once they're clear. No human intervention, no forgotten keys sitting around for years.

For platforms that send email on behalf of multiple customers (like agent infrastructure), coordinating rotation across dozens of sending domains becomes manageable only with automation. You can stagger rollouts, run health checks against each domain's DMARC data, and roll back instantly if something breaks.

## The rollback plan

Sometimes a rotation goes wrong. Maybe the new private key didn't deploy correctly to all sending nodes. Maybe a typo in the DNS record broke the public key format. Whatever the cause, emails signed with the new selector start failing DKIM checks.

The fix is fast if you kept the old selector active: revert your signing configuration to use the old selector and private key. Since the old DNS record is still published (you're in the grace period), authentication resumes immediately. No DNS changes needed, no propagation delay.

This is why the grace period isn't optional. It's your rollback window. Delete the old selector too early and you've burned your safety net.

## How this connects to deliverability

DKIM is one leg of the email authentication tripod (SPF, DKIM, DMARC). A failed DKIM signature doesn't automatically bounce your email, but it weakens your DMARC alignment. If SPF also fails (common when sending through third-party infrastructure), DMARC will instruct receivers to quarantine or reject the message.

For AI agents sending email autonomously, authentication failures are invisible until the damage is done. The agent doesn't get a bounce notification for a spam-foldered message. It just never hears back. We covered the broader picture in our guide on [email deliverability for AI agents](/blog/email-deliverability-ai-agents), but the short version is: keep your authentication chain intact, and DKIM rotation is the most likely place to accidentally break it.

## Recommended rotation cadence

Quarterly rotation (every 90 days) is a reasonable default. It balances security against operational overhead. Some organizations rotate every 6 months, which is acceptable for lower-risk use cases. Annual rotation is the bare minimum.

If you suspect a key compromise, rotate immediately. Don't wait for the next scheduled window.

For automated systems and agent-based email infrastructure, quarterly rotation is easy to set up once and forget. The scripts run, the DMARC reports confirm, the old selectors retire. The only time a human needs to get involved is when something breaks, and if you followed the dual-selector approach, breaking is hard to do.

---

*Give your agent its own email. [Get started with LobsterMail](/) — it's free.*

---

<FAQ>
  <FAQItem question="What is a DKIM selector rollover and why does it matter for deliverability?">
    A selector rollover is the process of switching DKIM signing from one selector to another so you can replace an old key with a new one. It matters because a broken DKIM signature weakens DMARC alignment, which can cause receiving servers to quarantine or reject your email.
  </FAQItem>
  <FAQItem question="How does the dual-selector method achieve zero downtime during DKIM key rotation?">
    You publish the new key under a different selector name while keeping the old selector active. Emails signed with the old key still verify against the old selector, and new emails verify against the new one. There's no gap in authentication.
  </FAQItem>
  <FAQItem question="How long should DNS TTL be set before starting a DKIM selector rollover?">
    Lower your TTL to 300 seconds (5 minutes) at least 24-48 hours before rotation. This ensures DNS resolvers worldwide aren't caching stale records when you make changes.
  </FAQItem>
  <FAQItem question="How do I know when it's safe to retire the old DKIM selector after rotation?">
    Check your DMARC aggregate reports. When the old selector no longer appears in any report, no receivers are seeing emails signed with that key. A minimum grace period of 7 days is recommended regardless.
  </FAQItem>
  <FAQItem question="What DKIM key length should I use when generating a new key: 1024-bit or 2048-bit?">
    Use 2048-bit RSA. 1024-bit keys are considered weak by modern standards. Note that 2048-bit keys exceed the 255-byte DNS TXT string limit, so the key must be split across multiple quoted strings in the record.
  </FAQItem>
  <FAQItem question="Can I use date-stamped selector names instead of selector1 and selector2?">
    Yes, and it's often better for troubleshooting. A selector like `dkim-20260308` tells you exactly when the key was created. The only constraint is that your mail server or platform must support arbitrary selector names (some managed platforms like Microsoft 365 only allow fixed pairs).
  </FAQItem>
  <FAQItem question="How do DMARC aggregate reports help confirm a safe DKIM selector transition?">
    DMARC aggregate reports, sent daily by major receivers, include the selector used for each authenticated message batch. By monitoring these reports, you can see exactly when old-selector traffic drops to zero and know it's safe to delete the old DNS record.
  </FAQItem>
  <FAQItem question="What happens to emails in transit if I delete the old DKIM selector too early?">
    Any email still in a retry queue that was signed with the old key will fail DKIM verification when the receiving server tries to look up the deleted selector. This can result in those messages being quarantined or rejected, depending on your DMARC policy.
  </FAQItem>
  <FAQItem question="How do I rotate DKIM keys programmatically using DNS APIs?">
    Generate a new key pair with OpenSSL, publish the public key under a new selector using your DNS provider's API (Cloudflare, Route 53, etc.), update your mail server's signing config, then schedule deletion of the old record after the grace period. The whole flow can run as a cron job.
  </FAQItem>
  <FAQItem question="Does DKIM key rotation affect SPF or DMARC records?">
    No. DKIM, SPF, and DMARC are independent DNS records. Rotating DKIM keys only changes the DKIM TXT records under your `_domainkey` subdomain. Your SPF and DMARC records remain unchanged.
  </FAQItem>
  <FAQItem question="How often should DKIM keys be rotated according to current best practices?">
    Quarterly (every 90 days) is a solid default. Every 6 months is acceptable for lower-risk setups. Annual rotation is the bare minimum. Rotate immediately if you suspect key compromise.
  </FAQItem>
  <FAQItem question="What is the recommended grace period for keeping the old DKIM selector active?">
    At least 7 days. Email retry queues can hold messages for up to 5 days per RFC 5321, and 7 days gives a comfortable margin. Use DMARC reports to confirm when it's truly safe to remove.
  </FAQItem>
  <FAQItem question="How do I coordinate DKIM rotation across multiple sending domains or subdomains?">
    Use DNS API automation to stagger rollouts. Rotate one domain at a time, verify DMARC alignment for each before moving to the next, and maintain a central log of selector versions per domain. This prevents a single misconfiguration from affecting all sending domains at once.
  </FAQItem>
  <FAQItem question="What is the rollback procedure if a DKIM key rotation causes email authentication failures?">
    Revert your mail server's signing configuration to use the old selector and private key. Since you kept the old selector's DNS record active during the grace period, authentication resumes immediately with no DNS changes or propagation delay needed.
  </FAQItem>
  <FAQItem question="How does Microsoft 365 handle DKIM selector rotation between selector1 and selector2?">
    Microsoft 365 uses a fixed two-selector system. When you trigger rotation in the admin portal, signing moves from selector1 to selector2 (or vice versa). The old selector remains published for 5-7 days automatically. You cannot use custom selector names in M365.
  </FAQItem>
</FAQ>