Rotate DKIM Keys Without Breaking Email

Q: What should I check after cutover?

Check message headers for dkim=pass , the new selector, and aligned d= domain. Then watch DMARC aggregate reports, provider logs, complaint rates, and inbox placement at Gmail and Outlook.

Drowning in unreadable DMARC report XML? Paste one into our free reader for a plain-English read. Read your report.

Do not replace the selector in place

A DKIM rotation breaks mail when receivers see a signature that points to a DNS record they cannot find, or a record that still has the old public key cached.

DKIM uses a selector. The selector is the s= value in the DKIM-Signature header. Receivers look up selector._domainkey.example.com and use that public key to check the message. A safe rotation gives the new key its own selector, lets DNS settle, then moves signing. The old selector stays live until old signed mail has aged out of queues and DMARC reports look normal.

Inventory every system that signs as your domain: Google Workspace, Microsoft 365, your help desk, your CRM, your marketing ESP, and any SMTP relay.
Pick a fresh selector name, such as m365-2026q3 or google-2026-07. Do not reuse the old selector during the cutover.
Create the new DKIM key in the sending platform, but leave current signing alone.
Publish the new selector in DNS as the provider tells you. It may be a TXT record with a public key or a CNAME to the provider.
Keep the old selector published. It is still needed for mail already signed with the old key.

The safe rotation runbook

The clean path is publish, wait, verify, sign, watch, then retire. Skipping the wait is what causes record-not-found and verification failures.

Lower the old selector TTL a day before the change if your DNS host allows it. This helps caches expire faster, but it does not replace real verification.
Publish the new selector and check it from outside your network. Use dig TXT newselector._domainkey.example.com or your DNS provider's checker.
Wait at least one full TTL after the new record appears on public resolvers. If you do not know the TTL, wait 24 hours for business mail.
Turn on signing with the new selector. If your platform can dual-sign, run old and new signatures together for a short overlap. If it cannot, move one lower-risk sender first.
Send test mail to Gmail, Outlook, and a mailbox outside your company. Read the headers and confirm dkim=pass, the new s= selector, and the expected d= domain.
Watch DMARC aggregate reports for the next few days. If you need help reading XML RUA files, use the free DMARC report reader.
Remove the old selector only after DMARC stays clean and the last old-signed mail has had time to leave queues. A week is a safer default than a same-day delete.

Keep DMARC aligned while you rotate

A new DKIM key can pass cryptography and still fail DMARC if the signing domain does not line up with the visible From domain.

DMARC passes when SPF or DKIM passes and aligns with the From domain. During a DKIM rotation, check that the new d= domain is the same organizational domain you expect. If your visible From is billing.example.com, signing as example.com usually aligns under relaxed DMARC. Signing as a vendor domain does not.

Your DMARC policy tells receivers what you prefer when aligned SPF and aligned DKIM both fail. p=none monitors, p=quarantine asks receivers to treat failing mail as suspicious, and p=reject asks them to reject it. Rotate keys while you have useful rua reporting. Moving to reject with no reports makes failures harder to see.

Do not touch SPF at the same time unless you have to. SPF should have one SPF TXT record for the domain, stay under the RFC 7208 limit of 10 DNS-querying mechanisms and modifiers, and avoid +all. Most production records use ~all during cleanup or -all when the sender list is known. MX records help mail come back to you, while sending IP reputation, forward and reverse DNS, blocklists, spam complaints, and content affect Gmail and Outlook placement. A DKIM miss is one of the fastest ways to make good mail look suspicious. A free InboxRadar domain check can show whether SPF, DKIM, DMARC, and MX are all passing before and after the change.

Common mistakes that cause outages

Most DKIM rotation failures come from a small set of avoidable timing and ownership mistakes.

Replacing the old selector's public key before all senders have stopped using the old private key.
Deleting the old selector minutes after cutover, while retries and delayed mail are still signed with it.
Creating two TXT records at the same selector name. Receivers may get the wrong one and fail the signature.
Rotating only the main mailbox provider and forgetting the help desk, billing system, calendar tool, or marketing sender.
Assuming a provider is signing because the DNS record exists. The message header is the source of truth.
Using a selector name that hides ownership, such as default, so nobody knows what system can be retired later.

Use the protocol docs as the backstop

When a vendor UI disagrees with another checklist, fall back to the standards and sender guidelines.

SPF behavior comes from RFC 7208, DKIM from RFC 6376, and DMARC from RFC 7489. Google and Microsoft publish sender guidelines that explain what they expect for authentication, DNS, complaints, and bulk mail. Use those sources when you need the exact rule, then use message headers and DMARC reports to prove your own domain is clean.

If your rotation notes need AI search visibility

Some teams publish deliverability docs for customers. If you want those docs to show in AI answers, make sure crawlers can fetch real HTML.

The crawlers that decide whether you appear in AI answers are OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google, and Applebot for Apple Intelligence. Google AI Overviews use the normal Google Search index, so there is no separate opt-out crawler. Disallowing those crawlers in robots.txt removes you from that engine.

GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls. Blocking them does not block live AI search visibility. Google-Extended and Applebot-Extended are robots-only control tokens with no separate crawl user-agent. Robots.txt is a stated policy, not proof of behavior. Perplexity-User and Bytespider are reported to ignore it, so use logs carefully and avoid claims you cannot prove. Only Googlebot documents JavaScript rendering. Client-side-only content may be an undocumented risk for other AI crawlers. You can check crawlability with the free AI visibility checker.

FAQ

How often should DKIM keys be rotated?

There is no single public rule that fits every domain. Many teams rotate yearly, after staff or vendor changes, or after any suspected key exposure. The key is to use a planned selector cutover, not an in-place overwrite.

Can I reuse the same DKIM selector?

Reuse is risky during a rotation because DNS caches may still hold the old public key while new mail is signed with the new private key. Use a new selector for the new key, then remove the old selector after the overlap window.

Should I change DMARC to p=none before rotating?

If you already enforce DMARC and have good reporting, you may not need to relax it. For high-risk or messy sender fleets, a temporary move to p=none can reduce damage while you find gaps. Decide before the change and keep the window short.

What should I check after cutover?

Check message headers for dkim=pass, the new selector, and aligned d= domain. Then watch DMARC aggregate reports, provider logs, complaint rates, and inbox placement at Gmail and Outlook.