DKIM key rotation means replacing the key pair that signs your mail, on a schedule or after a security concern, without breaking authentication. It sounds risky because a wrong move makes legitimate mail fail, but the design of DKIM makes it straightforward: selectors let you publish a new key beside the old one, switch signing and retire the old key later. This guide explains how that works and gives a step-by-step plan.
How DKIM signing and selectors work
When your platform sends a message, it creates a signature using a private key and adds it to the headers. The signature names the signing domain, written d=, and a selector, written s=. A receiver builds a DNS name from them, selector._domainkey.domain, fetches the public key published there and checks the signature. If the key matches and the signed parts of the message are unchanged, DKIM passes.
DKIM-Signature: v=1; a=rsa-sha256; d=mail.example.com; s=2026a;
h=from:to:subject:date:message-id; bh=...; b=...In this example the selector is 2026a, so the receiver looks up 2026a._domainkey.mail.example.com. Because the selector is just a label you choose, you can publish several at once. That is the whole trick behind rotation: the old selector continues to verify old mail while the new selector signs new mail.
Why rotate at all
- Limit exposure. A private key that has existed for years has been seen by more systems and people. Rotation limits the value of any past leak.
- Respond to staff changes. If an administrator who had access to the key leaves, replacing it removes a lingering risk.
- Move to stronger keys. Many older domains still publish 1024-bit keys. Rotation is the natural moment to upgrade.
- Meet policy. Security reviews and some customer questionnaires ask how often keys change.
- Keep the process practised. A team that rotates twice a year handles an emergency rotation calmly.
Rotation is not a deliverability tool. Changing keys does not improve inbox placement by itself. Its purpose is security and hygiene. Do it carefully so that it does not harm delivery, and do not expect a reputation boost.
Choosing a key length
The DKIM standard sets 1024 bits as the minimum for signers and recommends 2048 bits. Verifiers are not required to accept anything shorter than 1024 bits. For most senders the sensible choice today is 2048-bit RSA, which gives a comfortable margin without a large performance cost.
| Key length | Position | Practical note |
|---|---|---|
| 512 bits | Not acceptable | Considered broken and rejected by modern receivers |
| 1024 bits | Minimum allowed, still common | Works, but upgrade at the next rotation |
| 2048 bits | Recommended | Needs a TXT value split into several strings or a CNAME |
| 4096 bits | Allowed by the standard | Rarely needed, and the record can exceed practical DNS size limits |
The 255-character limit
A single string in a TXT record can hold at most 255 characters, and a 2048-bit public key is longer than that. The record therefore holds several quoted strings, which the receiver joins together. Most DNS providers handle this when you paste a long value. If yours does not, split it manually or ask your sending platform for a CNAME option.
2026a._domainkey.mail.example.com. TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."
"...rest of the public key..." )Before you start: two models of key management
| Model | How it works | What you do to rotate |
|---|---|---|
| Platform-managed (CNAME) | You publish a CNAME from your selector to a name the platform controls, and the platform changes the key behind it | Little or nothing; confirm the schedule and that the CNAME stays in place |
| Customer-managed (TXT) | You publish the public key yourself, and the platform signs with the private key you supplied or it generated | Follow the full plan below |
| Self-hosted signing | Your own mail server signs, and you hold the private key | Generate keys, update the server configuration and DNS |
A safe rotation plan
- Inventory selectors. List every selector published under _domainkey for the domain, and identify which system uses each. Unknown selectors are a finding in themselves; do not delete them until you know what signs with them.
- Choose a naming scheme. Use selectors that include a date or sequence, such as 2026a and 2027a, so you can tell keys apart at a glance.
- Generate the new key. Create a 2048-bit key pair, or ask your platform to issue one. Store the private key only where the signing system needs it.
- Publish the new public key. Add the new selector record. Do not touch the old one. Confirm that it resolves from outside your network.
- Test before switching. Sign a test message with the new selector and confirm that DKIM passes in the received headers.
- Switch signing. Change the signing configuration to use the new selector for all new messages. From this moment the old key signs nothing new.
- Monitor. Watch DMARC aggregate reports and bounce data for a spike in DKIM failures over the next days.
- Wait for stragglers. Keep the old record published for at least several days. Queued, retried or forwarded messages are verified when processed, not when sent.
- Retire the old key. Remove the old selector record and delete the old private key from every system that held it.
- Record the rotation. Note the date, the new selector and the date of the next rotation in your runbook.
How long to keep the old key
The old public key must remain in DNS until no mail signed with it can still be in transit or waiting to be verified. For ordinary transactional and marketing mail, a few days is enough. If you send through mailing lists or forwarding services that hold messages, or if your retry schedule is long, wait longer. Keeping an old key published for a little too long costs nothing. Removing it too soon causes failures that are hard to diagnose.
What can go wrong, and how to spot it
| Problem | Sign | Fix |
|---|---|---|
| Selector mismatch | DKIM fails with key not found | Compare the s= value in the signature with the DNS name |
| Truncated public key | DKIM fails with bad key or signature mismatch | Re-paste the key and check that all string parts are present |
| Old key removed early | Failures only on delayed mail | Restore the old record and wait longer next time |
| Signing not switched | New selector never appears in headers | Check the signing configuration and any cached settings |
| Two systems share a selector | Intermittent failures after one system rotates | Give each system its own selector |
| CNAME removed during cleanup | DKIM suddenly fails everywhere for a platform-managed key | Restore the CNAME exactly as provided |
Use reports to confirm success
DMARC aggregate reports show, per sending source, how many messages passed or failed DKIM and SPF. Check them in the days after rotation. A clean rotation shows the new selector appearing and the failure count staying flat. If failures rise for one source, it probably still signs with a key that is no longer published. Our guide to DMARC aggregate reports explains how to read them.
Emergency rotation
If you suspect that a private key has been exposed, rotate immediately and shorten the overlap. Publish and switch to a new key as fast as you safely can, then remove the compromised key even though some delayed mail may fail. An attacker with the old private key could sign forged mail that passes DKIM for your domain for as long as the public key remains published, so the exposure window matters more than the loss of a few delayed messages. Enforced DMARC and a reject policy limit what such forgeries can do, but the key should still be retired quickly.
Make rotation routine
- Put the rotation date in a shared calendar, with a named owner.
- Keep a table of selectors, the systems that use them and their creation dates.
- Use a dedicated selector for every sending system.
- Alert on DKIM failure rates, so a bad rotation is noticed within hours.
- Practise on a low-risk subdomain first if the process is new to your team.
Need help planning a rotation? Tell us which domains and sending systems you use and we will suggest a safe order.
Further reading and sources
Frequently asked questions
What is a DKIM selector?
A selector is a label that tells receivers which public key to fetch. The signature names a selector and a domain, and the receiver looks up a DNS record at selector._domainkey.domain. Because the selector is part of the name, one domain can publish many keys at once, which is what makes rotation safe.
How often should I rotate DKIM keys?
There is no single required interval. Many organisations rotate once or twice a year, or whenever someone with access to the private key leaves or a compromise is suspected. Choose a schedule you will actually follow, and rotate sooner if you ever suspect a key has been exposed.
Which DKIM key length should I use?
Use 2048-bit RSA where your DNS provider and sending system support it. The DKIM standard requires signers to use at least 1024 bits and recommends 2048, and verifiers must not accept keys shorter than 1024. Longer keys give more margin as computing power grows.
Why is my 2048-bit key rejected by my DNS provider?
A 2048-bit public key is longer than 255 characters, which is the limit for a single string in a TXT record. It must be split into several quoted strings that are joined by the receiver. Many providers split it automatically; if yours does not, split it by hand or use a CNAME to the platform-hosted record.
Can I delete the old key right after switching?
Not safely. Messages can be delayed in queues or retried for days, and receivers verify the signature when they process the message. Keep the old record published for at least several days, and longer if you send through slow forwarding paths.
What happens if I remove a key that is still in use?
Messages signed with that selector fail DKIM verification. If SPF aligns, DMARC can still pass, but if SPF does not align the message may be quarantined or rejected under an enforced DMARC policy. This is why signing is switched first and the old key removed later.
Does my sending platform rotate keys for me?
Some platforms manage DKIM keys and publish them through a CNAME that you point once, so rotation happens on their side. Others give you a static record that you must replace. Check which model your platform uses before you plan a rotation.
Should different mail streams use different selectors?
Yes, it is a good practice. Separate selectors for transactional, marketing and internal systems make it easy to rotate or revoke one without affecting the others, and they make header analysis clearer.
Can I test a key before switching to it?
Yes. Publish the new record first, confirm it resolves, then send test messages signed with the new selector to an inbox you control and check that DKIM passes in the headers before switching all traffic.