DKIM Key Rotation

Several people have asked me about how to rotate DKIM keys in the past few days (as if you’re modifying anything to mitigate replay attacks, you need to invalidate the signatures of all the mail you sent before you made those changes).
 

 [icon name=”key” class=”2x spin”]

You really, really should be rotating your DKIM keys on a regular basis (monthly, weekly, quarterly?) in an automated way, so you shouldn’t need to be special-casing a change like this. Lots of people don’t, though, so here’s a quick summary of how to change your DKIM signing keys:

  1. Pick a new selector – either one that you’ve never used before, or (if you’re using ping-pong selectors) one that you’ve not used in the past week
  2. Generate a new key pair
  3. Add the new public key to your DNS servers
  4. Check that the new public key is visible on each of your public DNS servers
  5. Start signing outgoing mail with your new selector and new private key
  6. Wait 24 hours
  7. Delete the old public key from your DNS servers

DNS negative caching can cause some minor problems, if you’re not careful – if a DNS resolver queries for your public key before you’ve published it then it will cache that the key doesn’t exist for a short time. There are a few things to do to avoid that.
First, if you’re reusing a selector that you’ve ever used in the past then you should wait 24 hours after publishing the new public key before you start signing with the new private key. That will avoid having the nonexistent key cached at remote ISPs who happen to look it up based on an old message which used the same selector as your new keys.
Second, you shouldn’t manually look up the new public key in DNS before you know it’s published, so as to avoid you caching the nonexistent key in your own DNS caching resolver. That’ll cause mail you send to yourself or to other people at your company / ISP to fail DKIM validation, which is likely not a bad problem, but can make diagnosing signature failures difficult.
If you need to look for the key in DNS before it’s published (for example, to make sure that changes have published to your external DNS servers) you can avoid that by querying the authoritative servers directly (e.g. using @your.name.server with dig, or “host -t txt foo._domainkey.example.com your.name.server” with host).
You should probably avoid using web-based lookup tools to check your key records before they’re published too, for the same reason – but you can safely use our validation tools (as they only cache results for a maximum of sixty seconds).
Happy rotating!
 

 [icon name=”key” class=”2x spin”]

 

Related Posts

DMARC: Please Be Careful!

(Cross posted from Spam Resource.)
Every couple of days, somebody new pops up on the DMARC-Discuss mailing list to ask some question or share an observation. It’s great to see people interested and joining the conversation. Clearly, DMARC interest and adoption are growing. What’s really frustrating, though, is that for about a quarter of the new subscribers, their first mailing list message goes to the spam folder in my Gmail account. It has become sort of an intelligence test I apply to new subscribers — I’ve stopped digging those messages out of the spam folder. I’m figuring that if they can’t figure out how to implement a DMARC record, or they don’t understand that it’s not really compatible with mailing lists nor is it meant for hobbyist domains, then I think perhaps they’ve got some things they’ve got to figure out before they’re ready to join the discussion.
To that end, let me take a moment to jot down some recommendations for folks who are considering implementing DMARC.

Read More

DKIM and injected headers

If you look at the DKIM-Signature header in any piece of email signed with DKIM you’ll see that one of the fields it contains, the h= field, lists some email header names, for example:

Read More

Hotmail moves to SPF authentication

Hotmail has recently stopped using Sender ID for email authentication and switched to authenticating with SPF. The protocol differences between SenderID and SPF were subtle and most senders who were getting a pass at Hotmail were already publishing SPF records.
From an email in my inbox from September:

Read More