Support for DKIM key rotation

Key rotation in a live system is problematic: as soon as you update config/dkim.key, that key is used to sign outgoing email, despite the fact that you’ve not had time to run sympl-dns-generate to generate an updated TXT record, let alone time to apply the update and wait for the TTL on the existing TXT record to expire.

It would be nice if Sympl supported a pair of DKIM selectors and key files, so that the key associated with the non-active selector could be updated separately, allowing time for the DNS change to propagate before switching to make the updated selector active for signing.

1 Like

Hi Lee

It gets my vote. At the moment, it’s a bit of a manual faff, whether migrating servers or rotating keys for better security. (For the former, I set dual dkim records by dropping *.txt in config/dns and letting OctoDNS do its thing).

Going for gold, (.pdf) suggests using three ‘active’ sets; current, future – and past.

Example of Key 2 → 3 : ← public key 1 is retired [“p=”] ← public key 2 used to validate old email for 7-30 days ← public key 3 used to sign current and new email ← public key 4 ready for future use

… where;

  • retired public keys are set empty in dns, seemingly, permanently. (Infinity seems overkill here; I’d prefer to kill the record at some point).
  • selectors/key pairs are unique, i.e., no recycling of selectors

When sympl supports dns integration I can’t see why a fully-fledged rollover scheme wouldn’t be feasible and desirable. All the admin needs to do is create config/

It seems that the tinydns files support timestamps – that could be useful to set a self-destruct on creation (setting ‘p’ empty in, say, expiry+10 days).

1 Like

This seems like a very useful feature - bringing the DNS integration back up to date is the next big step for Sympl, and adding support for rotating DKIM keys should be reasonably easy to add when I do.

Added to the feature list!

1 Like

Hi. I can’t use the DNS integration. In some cases, the DNS is outside of my control. If was such a domain, then I’d ask the owner of to add CNAME records so that I can manage services on their behalf. With DKIM, this means a one-off request to add CNAME records for and I then manage the actual keys through the domain the CNAME records point to. So I don’t want to have to add new selectors over time; I’d rather just bounce between s1 and s2 periodically. It would be great if this scenario could be taking into consideration when implementing support for DKIM key rotation.