How to rotate DKIM keys safely

13 June 2026 · 10 min read

Why DKIM keys need rotating in the first place

DKIM works because a private key, held only on your sending infrastructure, signs each outgoing message, and a matching public key, published in your DNS, lets receiving servers verify that signature. If anyone ever obtained your private key, they could forge mail that passes DKIM as if it came from you. So the security model rests entirely on one assumption: only you hold the private key.

That assumption decays over time. A key that has lived on a mail server for three years has been backed up, copied between hosts during migrations, exposed to former staff, and present on disks that were eventually decommissioned. The longer a key is in service, the larger the surface area for it to leak, and the more valuable a target it becomes. Rotation is simply the discipline of retiring a key before that risk compounds, and replacing it with a fresh one nobody has had time to compromise.

There are also practical reasons beyond pure hygiene. You may be moving from a 1024-bit key to a 2048-bit key for stronger cryptography. You may be switching email providers and inheriting a new selector. You may be responding to an actual or suspected exposure, where rotation stops being routine and becomes urgent. Or you may be subject to a compliance regime, such as one influenced by NIST or an internal security policy, that mandates rotating signing keys on a fixed schedule, often every 6 to 12 months.

Whatever the trigger, the goal is always the same: replace the key without ever producing a window in which legitimate mail fails DKIM. A botched rotation is worse than no rotation. If you publish a new public key but your server is still signing with the old private key, or you remove the old public key while messages signed with it are still in transit, you get verification failures. With a strict DMARC policy in place, those failures can mean delivery to junk or outright rejection. This guide walks through how to avoid that.

If you want to confirm what your current DKIM record looks like before you touch anything, run your selector through the DKIM checker first. You cannot safely change what you have not measured.

How selectors make safe rotation possible

The single most important concept in DKIM rotation is the selector. A selector is a short label that lets you publish more than one DKIM key for the same domain at the same time. The public key lives at a DNS name of the form:

selector._domainkey.example.com

When your mail server signs a message, it stamps the chosen selector into the message's DKIM-Signature header, in the s= tag:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=s1-2026; h=from:to:subject:date;
  bh=...; b=...

The receiving server reads d= (the domain) and s= (the selector), constructs the lookup s1-2026._domainkey.example.com, fetches the public key from there, and verifies. The crucial implication is this: two messages signed with two different selectors are verified against two completely independent DNS records. They do not collide. They do not interfere.

That is what makes zero-downtime rotation achievable. You do not edit an existing key in place. You introduce a brand new selector alongside the old one, let both coexist, switch signing over to the new selector, wait for any old in-flight mail to drain, and only then retire the old selector. At no point is there a moment where a freshly sent message lacks a valid published key to verify against.

Contrast this with the dangerous approach: editing the key material under your existing selector. If you overwrite default._domainkey with new key material, then for the duration of DNS propagation, messages signed with the old private key will be checked against the new public key and fail. Never rotate by overwriting. Always rotate by adding a new selector.

The safe rotation procedure, step by step

Here is the full sequence. The order matters, and the waiting matters.

1. Generate a new key pair under a new selector

Choose a fresh selector name. A naming convention that encodes a date or a rolling counter makes your life easier later, for example s1-2026 and s2-2026, or mar2026 and sep2026. Avoid generic names like default if you can, because they give you no signal about which key is which.

Generate at least a 2048-bit RSA key. 1024-bit keys are now considered weak and some receivers treat them with suspicion. If your DNS provider and signing software both support it, Ed25519 is an option too, though RSA-2048 remains the safest universally accepted choice. If your provider manages DKIM for you (Google Workspace, Microsoft 365, a transactional sender like Postmark or SendGrid), they will generate the key and give you the DNS record to publish, with the selector already chosen.

2. Publish the new public key in DNS

Add the new TXT (or CNAME, if your provider hosts the record on their side) at newselector._domainkey.example.com. Do not touch the old record yet. You now have two selectors live simultaneously. This is correct and intentional.

A typical DKIM TXT record looks like:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

3. Verify the new record resolves and is well formed before signing with it

This is the step people skip, and it is the step that prevents outages. Before you flip your mail server over to sign with the new selector, confirm the public key is actually visible in DNS and parses correctly. A typo in a long base64 p= value, a record split incorrectly across strings, or a TXT record your provider has not finished propagating will all cause silent verification failures the moment you start signing.

Check it with dig:

dig +short TXT newselector._domainkey.example.com

You should see the full v=DKIM1; ... p=... string. If it is truncated, empty, or wrong, fix it now, while the new selector is not yet signing anything. You can also confirm it with the DKIM checker, which validates the record format and key strength rather than just dumping the raw text.

Wait for DNS to propagate fully before moving on. Honour the TTL on the record. If your DKIM records carry a one-hour TTL, give it at least that long, and ideally a little more, so that resolvers worldwide have a consistent view.

4. Switch signing to the new selector

Only now do you reconfigure your mail server or provider to sign outgoing mail with the new selector and its private key. From this moment, new messages carry s=newselector and are verified against the record you already published and confirmed in step 3. Because that record is live and correct, verification succeeds immediately.

If your provider manages DKIM, this switch may happen automatically once you confirm the new record, or it may be a button in their dashboard. If you run your own signing (OpenDKIM, a Postfix milter, a Rspamd module), this is a configuration change and a service reload.

5. Let the old selector linger, then retire it

Do not delete the old DKIM record the instant you switch. Messages signed with the old selector may still be in transit, sitting in receiver queues, in greylisting delays, or in retry loops for temporarily unavailable destinations. Mail can legitimately take hours, occasionally days, to be delivered and verified. If you remove the old public key too soon, any of that in-flight mail will fail DKIM on arrival.

Leave the old selector published for a generous overlap. A common and safe choice is to keep it for at least one to two weeks after the switch, sometimes longer for low-volume domains where a stray retry could surface late. There is no penalty for leaving an unused public key in DNS a while longer; there is a real penalty for removing it too early. Once you are confident no mail signed with the old key is still circulating, delete the old TXT record. The rotation is complete.

A worked example with timing

Suppose today is the first of the month and you are rotating example.com.

• Day 0, morning. Generate a 2048-bit key under selector s2-2026. Publish s2-2026._domainkey.example.com in DNS. The existing selector s1-2026 keeps signing and stays untouched.
• Day 0, afternoon. Run dig +short TXT s2-2026._domainkey.example.com and the DKIM checker. Confirm the record is present, the p= value is complete, and the key validates. Wait out the TTL.
• Day 1. Switch the mail server to sign with s2-2026. New mail now uses the new key. Old mail already sent under s1-2026 still verifies fine, because that record is still published.
• Days 1 to 14. Both selectors remain in DNS. You monitor. Your DMARC aggregate reports should continue to show DKIM passing, now under the new selector, with the occasional tail of old-selector traffic decaying to nothing.
• Day 14 or later. Once the old selector shows no recent activity in your reports, delete s1-2026._domainkey.example.com. Done.

The whole point of this cadence is that there is never a single instant where a message is signed by a key whose public half is not published. Old and new overlap fully, then the old one drops off only after its traffic has drained.

Confirming success with DMARC reports

Switching the selector is not the end. You need evidence that real mail, sent to real receivers, is passing DKIM under the new key. DMARC aggregate reports are how you get that evidence. Every report you receive lists, per sending source, whether DKIM passed and which selector and domain were used in the auth_results.

After a rotation, you are looking for two things in those reports:

1. DKIM passing for your legitimate sending sources under the new selector.
2. The old selector's volume tailing off toward zero, confirming it is safe to retire.

If you are not already collecting and reading these reports, set that up before you rotate, not after. Our DMARC report analyzer turns the raw XML into something legible so you can actually see which selector is signing what. If you would rather not parse reports by hand at all, emailed monitoring watches your authentication results continuously and alerts you when something changes, which is exactly the kind of safety net a rotation benefits from.

Common mistakes that cause signing outages

These are the failure modes worth memorising, because each one has caused real delivery incidents.

• Overwriting the existing selector instead of adding a new one. As covered above, this guarantees a verification gap during propagation. Always add, never overwrite.
• Switching signing before the new record has propagated. If you start signing with s2-2026 while the DNS record is still propagating or contains a typo, every message in that window fails. Verify with dig and the DKIM checker first, and respect the TTL.
• Deleting the old selector too soon. In-flight and retried mail signed with the old key needs its public record to remain available. Keep a generous overlap of a week or two.
• A truncated or mis-split TXT record. DKIM public keys are long. Many DNS systems split long TXT values into multiple quoted strings, and getting that splitting wrong corrupts the key. After publishing, always re-fetch the record and confirm the p= value is intact end to end.
• Forgetting subdomains and parallel senders. If you sign mail from mail.example.com or use multiple providers (one for marketing, one for transactional), each may have its own selector and its own rotation. Rotating one does not rotate the others. Inventory every selector you publish before you start.
• Leaving a 1024-bit key in place. If you are already doing the work of rotating, move to 2048-bit. It is the same procedure and a meaningful security upgrade.
• Rotating with no monitoring. If you cannot see your DMARC results, you are rotating blind and will only learn of a failure when a customer complains. Set up reporting first.

How rotation fits with SPF, DMARC and your wider setup

DKIM rotation is one moving part in a larger authentication picture, and it interacts with the others. DMARC alignment requires that the domain in the DKIM d= tag matches (or is a relaxed-aligned subdomain of) the domain in the visible From header. Your rotation changes the selector, not the d= domain, so alignment is preserved as long as you keep signing for the same domain. If a rotation ever involves moving to a new provider that signs under a different d=, you must check alignment explicitly, because a DKIM signature that passes cryptographically can still fail DMARC if it is not aligned.

It is also worth using a rotation as a prompt to sanity-check the rest of your stack. Confirm your SPF record is still correct and within the ten-lookup limit with the SPF checker, and that your DMARC policy is what you expect with the DMARC checker. If you are tightening security generally, rotating keys pairs naturally with progressing your DMARC policy from p=none toward p=quarantine and p=reject, which is the journey our DMARC product and DKIM product are built to manage for you. You can read more on the full standards in requirements and look up any unfamiliar term in the glossary.

Building rotation into a routine

The first rotation always feels delicate. After you have done it once with selectors and overlap, it becomes a routine you can schedule. A sensible policy for most organisations is:

• Rotate DKIM keys every 6 to 12 months as standard hygiene.
• Rotate immediately and out of band if you suspect the private key has been exposed, for example after a server compromise or a departing administrator who had key access.
• Use dated or counter-based selector names so each rotation is self-documenting.
• Keep a written inventory of every selector and domain you sign for, so nothing is missed.
• Always confirm the new record resolves before switching, and always leave an overlap before retiring the old one.

Two selectors, full overlap, verify before you switch, drain before you delete. That sequence is the entire safety mechanism, and it is what lets you rotate as often as good security demands without ever dropping a signature on legitimate mail.

When you are ready, start by checking what you have live today with the DKIM checker, or browse the full set of free tools. If you would rather hand the whole lifecycle, key generation, publication, monitoring and timed retirement, to a managed service that does it without an email outage, that is precisely what DMARC Engine provides.