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

Troubleshooting tools

There have been a number of comments on my post about Hotmail moving to SPF authentication having to do with troubleshooting authentication failures. I have been helping clients troubleshoot these issues, and am able to take on new clients to solve authentication problems. Contact me for more information.
Of course, many of these issues can be solved with access to the right tools. Steve’s been working on a number of tools that may help the troubleshooting process and we’ve recently launched them on Emailstuff.org. The website itself contains a number of DNS and data related tools we use for investigations and thought we’d share with the public at large.
One of the really useful tools is the SPF record expander. Plug in any domain, like google.com, and see what IP addresses they authorize to send mail.

Read More

DKIM and Gmail

After they were a a little embarrassed by their own DKIM keys being poorly managed a few months ago, Google seem to have been going through their inbound DKIM handling and tightening up on their validation so that badly signed mail that really shouldn’t be treated as DKIM signed, won’t be treated as signed by Gmail.
This is a good thing, especially as things like DMARC start to be layered on top of DKIM, but it does mean that you really need to check your signing configuration and make sure you’re not doing anything silly.

Read More

Gmail FBL update

Last week Gmail started contacting ESPs that signed up for their new FBL with more information on how to set up mailings to receive FBL emails.
One of the struggles some ESPs are having is the requirement for DKIM signing. Many of the bigger ESPs have clients that sign with their own domains. Gmail is telling these ESPs to insert a second DKIM signature to join the FBL.
There are a couple reasons this is not as simple or as doable as Gmail seems to think, and the challenges are technical as well as organizational.
The technical challenges are pretty simple. As of now, not all the bulk MTAs support multiple signatures. I’ve heard that multiple signatures are being tested by these MTA vendors, but they’re not in wide use. This makes it challenging for these ESPs to just turn on multiple signatures. For ESPs that are using open source software, there’s often a lot of customization in their signing infrastructure. Even if they have the capability to dual sign, if they’re not currently using that there is testing needed before turning it on.
None of the technical challenges are show stoppers, but they are certainly show delayers.
The organizational challenges are much more difficult to deal with. These are cases where the ESP customer doesn’t want the ESP to sign. The obvious situation is with large banks. They want everything in their infrastructure and headers pointing at the bank, not at their ESP. They don’t want to have that second signature in their email for multiple reasons. I can’t actually see an ESP effectively convincing the various stakeholders, including the marketing, security and legal staff, that allowing the ESP to inset a second signature is good practice. I’m not even sure it is good practice in those cases, except to get stats from Gmail.
Hopefully, Gmail will take feedback from the ESPs and change their FBL parameters to allow ESPs to get information about their customers who sign with their own domain.

Read More