I have, first for work, then for “fun”, created something. A little program to rotate DKIM keys. For work, this was a somewhat large rollout. We had more than 3800 domains that were to be included in DKIM signing (because we also rolled out DMARC, with the reject-policy. Which means every email from our sender domains had to be signed with DKIM), now that we don’t deliver that service to our customers anymore this number has shrinked to 65. Still a number of domains you don’t want to do key rotation manually for.

Enough history, how do I forget all that again?

Well, one idea is to use the newest iteration of the little program I wrote, which I called dkimrotate (or in this iteration dkimrotate3). I am hunting the last bugs, and for now it probably won’t work for anybody not using my exact setup (which is, PowerDNS as the DNS server, accessible via API, and opendkim’s standard installation with configuration in /etc/opendkim. Oh, and sudo access for the user actually copying the created configuration to opendkim’s configuration directory).

But if’n I don’t

(got that quote from the hilarious Buster Scruggs segment, the best 15 minutes or so in the otherwise rather dull movie “The Ballad of Buster Scruggs”)

There is much evidence in my opendkim logs that other people don’t rotate their DKIM keys as often as I do. I follow the W3 recommendation of using 1024-bit keys and rotating them every three months (or more often in this time of testing). I’m stretching it a bit by letting the last three keys that have been “rotated out” stay in DNS until a rotation would produce one more. So you won’t find a key older than a year wherever I have dkimrotate (the older or the newer variant) deployed.

But here are some keys with dates encoded in the selector that would make me worried:

E793B3C00F6: s=email0517 d=email.apple.com a=rsa-sha256 SSL
255D93C0198: s=scph0823 d=klarna.no a=rsa-sha256 SSL
680133C0303: s=feb2018 d=svea.com a=rsa-sha256 SSL
9E9D93C0303: s=scph0620 d=mail.prisjakt.no a=rsa-sha256 SSL
2E9843C0303: s=scph1219 d=nyhetsbrev.spar.no a=rsa-sha256 SSL

And all of these are from today, september 21st 2026. So if these selectors are indicating the date when the key was created (and I have no reason to believe they aren’t), they are between three and nine(!) years old by now. Which means anybody could have brute-forced them by now, totally removing the “security” this signing is supposed to give us.

I wonder if Apple just put a DKIM key in their configuration and called it good. Oh, and add to that the fact that per NIST, RSA-1024 is disallowed anyway (well, maybe email is so insecure as a medium to begin with, so this doesn’t exactly hit the DKIM crowd as hard).

And the future?

I plan to at least give dkimrotate a possibility to use longer keys than RSA-1024, what I’m still a bit unsure about is if elliptic keys (ED-25519) could be used sending email to entities still having RSA-1024 keys (the Apple one up there is luckily a 2048-bit key. Still, 9.5 years? WTF?). The scph* keys are all just RSA-1024 btw. and adding date stamps in the selector does not exactly help in their case.

So, as of writing this the current DKIM public key for bleen.dev is selector 20260916-1024-yyrwohko, meaning it was published last wednesday, is a RSA-1024-key and has the unique identifier yyrwohko (those were introduced in the original dkimrotate just so we don’t have the same identifier for - statistically - 42 domains).

Oh, and post-quantum cryptography? Right now the current RFC¹ for DKIM allows for two kinds of keys, RSA or elliptic (and since only RSA was in the draft, many people use just that, just like zip-compression instead of gzip in DMARC reports… but that’s a rant for another time).