Twice a year is a reasonable default for most organisations, and more often if your sector expects it. The value of a schedule is less about any single rotation than about proving the process works before you need it urgently.
Smart DKIM
DKIM adds a cryptographic signature to your mail so receivers can verify it was not altered and genuinely came from an authorised system.
DKIM is usually configured once, per service, by whoever set that service up. Each one publishes its own selector in your DNS. A year later there are eleven selectors, three belong to tools you no longer use, and nobody is certain which of the rest are actively signing.
Key rotation is the part that quietly never happens. Keys should be replaced periodically, and a 1024-bit key left in place for years is a genuine weakness — but rotating one means coordinating DNS and the sending platform in the right order. Get the order wrong and you break signing for a live service, so it stays on the backlog.
Every selector that appears in your reports is inventoried alongside the service using it, its key length, and when it was last changed. Orphaned selectors from decommissioned tools become obvious instead of accumulating.
Rotation is handled in the safe order: publish the new key, confirm it validates, move signing across, then retire the old selector once traffic has drained. Nothing is removed while mail still depends on it.
Recommended key length
Downtime on rotation
Selector accounted for
The two protocols fail in different ways, and only one survives a mailing list.
SPF checks the sending server against your published list. The moment a message is forwarded, the forwarding server is not on that list and SPF fails — which is why mail relayed through mailing lists and alumni addresses so often fails SPF while being entirely legitimate.
DKIM travels with the message. The signature covers the content and headers, so it survives forwarding as long as nothing rewrites the body. For DMARC purposes, that makes DKIM the more durable of the two alignment paths.
In practice you want both. DMARC passes if either aligns, so a service that signs with DKIM keeps authenticating even when its mail takes an indirect route to the recipient.
Something not covered here? Talk to our team.
Twice a year is a reasonable default for most organisations, and more often if your sector expects it. The value of a schedule is less about any single rotation than about proving the process works before you need it urgently.
Once no mail is signing with them, yes — and you should, because a stale selector with a weak key is an unnecessary liability. The inventory shows which selectors still carry traffic, so removal is based on evidence rather than assumption.
2048-bit. Some older platforms still default to 1024-bit, which is why the inventory flags key length explicitly rather than only reporting whether a signature exists.
Most mainstream platforms do. Where one does not, that service has to rely on SPF alignment alone, which is worth knowing before it turns into a deliverability problem — it appears in your sender inventory either way.
