Published 20 October 2026 · By Bram Van Daele, Teneo
Most DKIM guides say that keys should be rotated and leave it there. This one describes the rotation itself: the six steps, the order they have to run in, how long to wait between them, and what the standards and the mailbox providers say about each. At the end we describe how the console on our relay runs the same sequence.
A DKIM key rotation has six steps in a fixed order. You create the new key, publish its record under a new selector, wait until that record is visible, switch signing to the new key, keep the old record for at least a week, and then revoke the old key. When the order is kept, nothing changes for your recipients. When a step is skipped, mail fails verification in one of two ways, and both are described below.
What a rotation actually is
DKIM puts a signature on each message and tells the receiver where to find the public key: the d= tag names the domain, the s= tag names the selector, and the receiver looks up a TXT record at selector._domainkey.domain. Selectors exist for exactly one reason. RFC 6376 says it in the first paragraph that introduces them: "To support multiple concurrent public keys per signing domain, the key namespace is subdivided using selectors," and a little further, "selectors make it possible to seamlessly replace public keys on a routine basis."
In practice this means a rotation adds a second key next to the first, moves the signing over, and takes the first away afterwards. The same RFC gives the example of a domain moving from a selector called january2005 to february2005: the domain "merely makes sure that both public keys are advertised in the public-key repository concurrently for the transition period."
Three consequences follow from that, and all three are in the standards rather than in anyone's opinion:
- A missing key is a hard failure, not a shrug. If the receiver asks DNS for the key and the record is not there, the verifier "MUST immediately return PERMFAIL (no key for signature)". Under DMARC that failed signature counts as a DMARC failure unless aligned SPF passes on the same message. Except at Microsoft: for anyone sending 5,000 messages a day or more to its consumer mailboxes, Outlook.com requires that "Both SPF and DKIM checks must pass", so a passing SPF does not rescue a failed signature there. Microsoft is alone among the large providers in that requirement, which is not the first time it has gone its own way on email.
- Verification happens on receipt, not on sending. A message you signed this morning is verified whenever it arrives, which for a deferred message can be hours or days later. RFC 6376 therefore advises that "the old public key should be retained for a reasonable validation interval before being removed from the key server."
- Do not reuse a selector. Reusing one for a new key "makes it impossible to tell the difference between a message that didn't verify because the key is no longer valid and a message that is actually forged. For this reason, Signers are ill-advised to reuse selectors for new keys."
The sequence, step by step
RFC 5863, the DKIM deployment guide, lists the order in one place: the key record "is published in the DNS", then "Wait for DNS updates to propagate (if necessary)", then "The signer verifies correct registration of the key record", and only then "The signer begins generating signatures using the new key pair". M3AAWG's key rotation best practices, revised in March 2019, add the timings. Put together:
- Generate the new pair and pick a new selector. 2048 bits. RFC 8301 sets 1024 as the floor and says signers "SHOULD use RSA keys of at least 2048 bits"; Google's sender guidelines require 1024 or longer for mail to personal Gmail accounts and recommend 2048. A selector with a date in it is the easiest way never to reuse one; M3AAWG's example is
sales-201309-1024. - Publish the new record. Do not sign with it yet. The new key exists on the signing server but is not the default. M3AAWG, in so many words: "Wait for the DNS modification(s) to propagate before signing any email."
- Wait until the record is visible, and check that it is the right record. Not "wait a while": look it up, and compare the
p=value you get back with the key you generated. How long this takes depends on your DNS provider, not on DKIM; Cloudflare's automatic TTL is 300 seconds, Google tells Workspace admins it "can take up to 48 hours for DKIM authentication to start working". - Switch signing to the new key. From this moment every new message carries the new selector. Mail already queued carries the old one and keeps verifying, because the old record is still there.
- Keep the old record for at least seven days. M3AAWG: the first public key "should be kept unchanged in the DNS for a minimum of seven days, and up to 30 days", so that receivers can "still validate old email or email that was still in transit during the transition process".
- Revoke the old key rather than deleting the selector. The standard way is to publish the old selector with an empty key: "p=" with nothing after it. RFC 6376 defines that as revoked, RFC 5863 calls it "a gravestone for an old selector", and M3AAWG adds: "Do not delete the selector entry for public key 1." A receiver that finds the gravestone knows the key once existed and was retired; a receiver that finds nothing cannot tell your retired key from a forgery.
The two places it goes wrong
Signing too early. This is the common one, and the sender does not notice it, because the sending side has no error to show. Mail goes out signed with a selector that a share of the world's resolvers cannot find yet. Every one of those messages gets "PERMFAIL (no key for signature)" at the receiver, and if SPF does not align on that message, a DMARC failure too. With a p=reject policy, that is mail in the bin. There is a second trap inside this one: if a receiver looked up the new selector before you published it, that resolver caches the absence. RFC 2308 sets the length of that negative cache from your zone's SOA minimum field, which on some zones is hours. Publishing first and signing later avoids both.
Retiring too early. The mirror image. Signing switched on Monday morning, old record deleted Monday afternoon because "it's done". Every message signed before the switch and still in a queue somewhere, a receiver that was deferring, a batch waiting out a rate limit at Microsoft, now fails verification on arrival. The seven days exist to cover the last message that was signed with the old key and has not arrived yet.
Two smaller ones worth knowing. A 2048-bit public key is longer than one DNS string allows: RFC 1035 caps a character string at 255 octets, so the record must be split into several quoted strings that the receiver concatenates, which is also what Google tells admins who try to paste it in one piece. And if your provider signs for you through a CNAME, such as Microsoft 365's selector1 and selector2 pair, you are not rotating the key, they are, and in Microsoft's case the new key "takes four days (96 hours)" to start signing after you ask for it.
What we do on the relay
We built this sequence into the console because the manual version has too many places to stop halfway. One click on a domain starts a rotation. The relay creates a new 2048-bit key under a dated selector, teneo followed by the date, without making it the signing key. You get a mail with the new TXT record, already split into strings where your DNS provider needs that, and one sentence that matters: your mail keeps being signed with the current key until the new record can be seen in DNS.
From then on the console looks the record up every hour and compares the p= value it finds with the key it created. Only an exact match counts. When it matches, the relay makes the new key the signing key, reads it back to confirm, and mails you again: this domain now signs with the new selector, keep the old record until a date seven days out. On that date the old key is removed from the relay and you get the third mail, which says that the old record can be removed or left in place, since it no longer does anything. The only action on your side in the whole sequence is publishing one DNS record.
Two observations from our own logs. In a recent rotation through this flow, the new record was visible 69 minutes after the start, so the switch happened on the next hourly check. And across the sending domains registered on our relay in October 2026, more than nine in ten still sign with a 1024-bit key. They all pass today, at Gmail and everywhere else, and that is the main reason they have not been rotated. The rotation button in the console was built so that moving a domain to 2048 bits takes one click and one DNS record.
What you can actually do
If you sign your own mail, or your relay leaves rotation to you, the playbook assembled from the sources above:
Write the date into the selector. For example teneo20261021 or mail-2026-10. Any naming works as long as it produces a new name every time, because that is what prevents selector reuse.
Lower the TTL on the old record a day before you touch anything. RFC 1034 said it in 1987: "If a change can be anticipated, the TTL can be reduced prior to the change to minimize inconsistency during the change."
Check the new record from outside your own network before you sign. Query a public resolver, not the authoritative server, and compare the key byte for byte. Steve Atkins' 2014 write-up at Word to the Wise puts it as a separate step for a reason: "Check that the new public key is visible on each of your public DNS servers."
Sign, then do nothing for a week. Set a reminder for the revocation at the time you switch. In our experience the old record gets deleted the same afternoon whenever that reminder is missing.
Revoke with an empty p=, keep the selector. The gravestone costs you one DNS record and gives receivers the one piece of information a deleted record cannot.
Put the next one in the calendar. M3AAWG's cadence is "at least every six months", with April and October as its example. Al Iverson's five DKIM tips from November 2024 repeat the six months and add his own view on size: "nowadays, 2048-bits is best, IMHO."
The bigger picture
Back in 2017, Brandon Long, then running Gmail's delivery side, wrote on the mailop list: "Unfortunately, most folks don't seem to rotate very often." Nothing we see in 2026 suggests that has changed. We do not think the reason is laziness. A rotation done by hand has a period in which a mistake is invisible to the sender and visible to every receiver, and when it goes well, nothing visible happens at all. Work with that profile tends to be postponed.
What helps is removing the manual waiting and checking. Publish before you sign, verify before you switch, wait before you revoke, and have a machine do the waiting and the checking so that nobody has to remember the dates. Done that way, a rotation twice a year is uneventful, which is what the authors of the standard had in mind when they introduced selectors.
Rotating on Teneo? Open the domain in the console, press Rotate key, publish the record from the mail, and the console does the rest: hourly checks, the switch, the seven days, the retirement.
Frequently asked questions
How often should DKIM keys be rotated?
M3AAWG's best common practices, revised in 2019, say "at least every six months", a cadence they loosened from quarterly because twice a year "balances the risk of compromised keys and operational effort". Some operators rotate monthly, some annually; no RFC prescribes a period.
What happens if I start signing before the DNS record is visible?
Receivers that cannot find the key return "PERMFAIL (no key for signature)", a hard DKIM failure. If SPF does not align on that message, DMARC fails as well, and under a reject policy the message is refused. Resolvers that looked the record up before it existed may also cache its absence for as long as your zone's SOA minimum allows.
How long should the old DKIM key stay in DNS after a rotation?
At least seven days and up to thirty, according to M3AAWG, so that mail signed before the switch and still in transit can be verified on arrival. DKIM is checked when a message is received, not when it is sent.
Should I delete the old selector or set p= to empty?
Set it to empty. RFC 6376 defines an empty p= as a revoked key, RFC 5863 calls it a gravestone, and M3AAWG says "Do not delete the selector entry". A revoked record tells receivers the key existed and was retired; a missing one looks the same as a forgery.
Is a 1024-bit DKIM key still acceptable in 2026?
It still verifies. RFC 8301 makes 1024 bits the minimum and recommends 2048; Google requires at least 1024 for mail to personal Gmail accounts and recommends 2048. The practical reason to move is that a 2048-bit key costs nothing extra once the rotation is routine.
Sources: RFC 6376, RFC 5863, RFC 8301, RFC 1034, RFC 1035, RFC 2308, RFC 7208 and RFC 7489; M3AAWG DKIM Key Rotation Best Common Practices (M3AAWG078, revised March 2019); Google's email sender guidelines and Workspace DKIM pages; Microsoft Learn on DKIM in Microsoft 365; Cloudflare and Route 53 TTL documentation; public mailop archive posts from 2017 and 2020; Word to the Wise (2014); Spam Resource (2024). Teneo observations are from our own console, October 2026, as shares only. No private communications were used.