How we're likely to DKIM sign some of our email messages

May 30, 2020

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.

Written on 30 May 2020.
« What sort of SSH keys our users use or have listed in their authorized keys files
Mail forwarding is slowly dying (probably) »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat May 30 23:23:43 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.