What is DKIM?

Why and how to rotate keys

DKIM keys should be rotated periodically — replaced with fresh keys on a schedule — because a key that never changes is a key that, if ever compromised, stays compromised indefinitely. Rotation is done by publishing a new key under a new selector, switching signing to it, and retiring the old one after a grace period so in-flight mail still verifies. The mechanics are simple but easy to get wrong: retire an old selector too soon and recently-sent mail fails verification. This is exactly the kind of operational detail that quietly breaks authentication when nobody owns it, and our DKIM checker helps you confirm a new key is published before you cut over.

RSA, ed25519, and testing mode

Most DKIM uses RSA keys, with 2048-bit the current baseline and 1024-bit now considered weak. A newer option, ed25519, is an elliptic-curve algorithm that produces much shorter keys with equivalent strength — excellent where supported, but because not every receiver validates it yet, it's usually published alongside an RSA key rather than instead of one. One more flag to watch is the t=y tag, which marks a key as being in testing mode and tells receivers to ignore DKIM failures; useful during setup, but a key left in testing indefinitely weakens the protection DMARC depends on. Rotating on a sensible cadence — many senders rotate every few months to a year — keeps the window of exposure small if a key is ever compromised, and pairing rotation with monitoring means a botched cutover surfaces immediately rather than silently failing mail for hours. The operational discipline of managing selectors, key lengths, and rotation across every sending source is precisely the kind of work that drifts when no single owner is responsible for it, and where a managed setup earns its place. Treating signing as an operated system rather than a one-time setup is ultimately what keeps it correct and dependable as the surrounding infrastructure changes around it.