DKIM works with a pair of keys. Your mail platform holds the private key and uses it to stamp a signature onto every message it sends. You publish the matching public key in DNS, and receiving mail servers look it up to confirm the signature is real and that the message wasn't tampered with along the way.

The public key lives at a DNS name built from something called a selector:

So if your selector is s1 and your domain is example.com, receivers go looking for s1._domainkey.example.com. The selector is just a label. Its only job is to tell the receiver which key to fetch, which means you can have several keys published side by side without them stepping on each other.

Rotating a key means retiring an old key pair and putting a new one into service. You generate a fresh pair, publish the new public key under a new selector, switch your mail platform over to signing with the new private key, and eventually retire the old public key.

Two reasons, and the second one matters more than people expect.

The obvious one: keys get stolen or cracked. A private key sitting on a mail server for three years is a much bigger prize than one that gets replaced twice a year. If somebody does walk off with it, they can sign mail as you until you notice. Rotating on a schedule caps how long a stolen key stays useful.

The one people miss: rotation is a fire drill. M3AAWG makes this point repeatedly in their key rotation guidance, and it holds up in practice. The first time you rotate a key it will be awkward; you'll discover the DNS team is a different team, that nobody knows who owns the Klaviyo account, or that one vendor requires a support ticket. If you only do it during an actual emergency, you'll be figuring all that out under pressure. Do it routinely and it becomes boring, which is exactly what you want.

Straight from the M3AAWG best common practices document (March 2019 revision):

Two of those deserve a note.

The overlap window exists because mail already in flight, and mail sitting in a mailbox that a filter re-checks later, still needs the old public key to validate. Pull it too early and you'll fail signatures on messages you already sent.

Emptying p= instead of deleting the record is a small thing that saves confusion later. A record with v=DKIM1; p= says "this key was intentionally retired." A missing record says "something might be broken." Leave the tombstone.

Never reuse selector names. If you republish s1 with a different key, old mail signed with the original s1 key will now fail validation, and any receiver caching the old value gets an inconsistent answer. Pick a naming scheme that makes reuse impossible — including a date is the easy way, e.g. mktg-202607-2048. That tells you the stream, the month it went live, and the key size, which is genuinely useful at 2 a.m.

This is the fork in the road that determines how much work rotation is for you. Almost every platform you deal with will use one of these two models.

You publish the public key directly in your own DNS as a TXT record:

The whole key sits in your zone. Nobody can change it but you. That's the upside and the downside, nothing rotates unless you rotate it.

How a rotation goes:

A useful habit worth stealing from the M3AAWG document: keep one key pre-published and unused at all times. If you're signing with s2, have s3 already sitting in DNS doing nothing. If s2 gets compromised, the emergency response is a single config change on the mail server rather than a DNS change, a propagation wait, plus a config change. It costs you nothing to leave it there.

Instead of the key itself, you publish a pointer to a record the vendor controls:

The actual TXT record with the key lives on the vendor's DNS. When they want to rotate, they change their end. Your DNS never changes, and you don't have to be involved at all.

How a rotation goes: usually it doesn't involve you. The vendor generates the new key, publishes it behind their end of the CNAME, and switches signing over. You may not even get a notification.

This is why most of the big ESPs moved to CNAME delegation, as it lets them rotate on their own schedule without filing a DNS change request with every customer.

Two things to watch for:

One note on the record count: when you see a platform asking for three or four CNAMEs, that's the rotation mechanism, not redundancy. Amazon SES is the clearest example; it runs an active key (signing now), a passive key (still published so older mail validates), and a pending key (staged for next time). During a rotation, records shuffle roles rather than getting created and destroyed. Same pattern as the pre-published spare key in the TXT model, just automated.

Below are the 22 sending services in our current inventory, split by who's responsible for the rotation. Check which model your account is actually on before acting; several of these platforms offer both, and older accounts are often still on the manual path.

Nothing to do on a schedule. Your job is to keep the records intact and verify they still resolve.

These Services publish the key in your DNS as a TXT record and will not rotate on their own. Every one of these needs a calendar entry.

You cannot rotate what you don't know about. This is the step people skip and then regret.

List every mail stream leaving your domains. Transactional mail, marketing campaigns, employee mail, the phishing simulation platform, the ticketing system, the CI server that emails build failures. Anything that signs as you.

If you're a Valimail customer on Enforce Enterprise, most of the inventory above already exists. The DKIM Continuous Protection Report is effectively the table you were about to build by hand. (It's an Enforce Enterprise feature; if you don't see it, reach out to your Account Manager)

The report lists every DKIM record Valimail knows about for your domains, with one row per key:

If you're starting from nothing, this is a reasonable target:

If six months feels like too much for your first pass, do it once and see how long it actually takes. It's usually less than people fear, and the second time is much faster than the first.