How we're likely to DKIM sign some of our email messages
For years, we have more or less deliberately not set up DKIM signing for any of our outgoing email, for various reasons (see my current views on using DKIM here, from 2015). For various local reasons beyond the scope of this entry, we may be about to change our view and start DKIM signing some things.
The actual mechanics of configuring basic DKIM signing in Exim turn out to be pleasantly simple. Exim even documents the OpenSSL and GNU TLS commands that you need to run to generate keys; the only obstacle I ran into is that Bind limits the size of a single string in DNS TXT records, and base64 encoded 2048 bit RSA keys are too big, so you have to split them up. This leaves the policy issues as the hard things, where we need to decide what we want to sign and with what keys.
(All of the following is tentative and may change before we go live.)
For our current purposes, the most important email to DKIM sign is email directly sent by our users. This email goes through one of our two mail submission servers (one for unauthenticated SMTP, one for authenticated SMTP) and is then sent either to our central mail machine or directly to the outside world. This makes the submission machines the natural place to do our DKIM signing. They could use separate DKIM signing keys and I was initially planning to do so, but after thinking about it I don't see the need to make our life more complicated. So our mail submission servers will use a common key that's set up and maintained by hand, with no particular schedule for key rollover.
Our mail submission machines don't require you to use your local
email address as your envelope sender or
From:, and a few people
use this to send with alternate (non-local) email addresses. After
thinking about it, I don't think we want to DKIM sign that email,
only email from an address here. We can always insure that email
for our own addresses aligns with our (nonexistent) DMARC policy, but DKIM signing for other email addresses
runs various practical risks (even though it is an authentic
sending source attribution).
There is additional email we generate locally that doesn't flow through our submission machines; this includes at least bounce messages, 'vacation' auto-replies, and some periodic email. I don't know if people normally DKIM sign bounces (although they do come from you), but the other messages are all authentically from us. However, it would be more complicated to DKIM sign them in our environment and so on the first round of implementation I'm planning to skip signing them. If the lack of a DKIM signature increases the chances of a vacation auto-reply getting a lower reputation score, it's not the end of the world.
(We're not planning to set up a DMARC policy to go with our DKIM signing; we'll just quietly DKIM sign some email.)
We will definitely not DKIM sign email from the outside world that we're re-forwarding back into the outside world (for example, if an outside person emails a person here who forwards all of their email to GMail). This includes email that is sent to one of our simple mailing lists, which alters the envelope sender but doesn't do anything else that would invalidate an existing DMARC signature.