Some headers are very recognizable, such as “Subject”, “From”, “Cc”. They’re probably the ones that your mail client shows you by default. Other ones are there in the email, but you don’t tend to see them unless you really look. One of them is “DKIM-Signature”.<\/p>\n\n\n\n
![\"A](\"http:\/\/blogs.it.ox.ac.uk\/networks\/files\/2026\/05\/Screenshot_1-5-2026_91047_teams.microsoft.com_.jpeg\")
<\/a><\/figure>\n\n\n\nThe purpose and anatomy of a DKIM-Signature<\/h2>\n\n\n\n
The DKIM Signature is not meant to be written by a human, or even added automatically by your mail client like Outlook or Thunderbird. A mail relay server is supposed to receive the message and add this header en-route to the message’s intended recipient. Its content is a cryptographically secure hash of (amongst other things) the message body. With this signature, the body of the email, if it is altered, will be shown as being altered, and thus you are not to trust its contents. Think of this as a wax seal on a formal letter; any tampering will be immediately obvious to the recipient and the contents should be considered suspect.<\/p>\n\n\n\n
Which mail server en-route can sign? In principle any one of them can sign it, but for us at the University of Oxford, we have ownership of the ox.ac.uk domain and so our mail relays are signing for that domain as mail leaves our border. Sympa is the maillist software we use at the University of Oxford. It is very flexible and powerful. One feature that people use is message confirmation. Say you are the moderator of a list, and you want it that people can email the list, but you wish to first have a copy of the email sent to you, the moderator, so you can read and accept or reject its distribution to this list. If you cast your mind back 30 seconds to when you read my overly simplified explanation of DKIM, you will remember that Headers are at liberty to be modified (to a certain extent) after a DKIM signature has been added to a message. However, Embedded Headers are different. Because they occur inside the To take a concrete example. We created a Confirmation email and sent identical copies to multiple destinations. One went through a Hotmail-like server and I can verify that the DKIM is broken, the other did not and its DKIM signature remains valid. Content-Transfer-Encoding: 8bit This didn’t change when I received it at my non-Hotmail email account. Contrast this with the same email when I sent it to a Hotmail-like address:<\/p>\n\n\n\n Content-Transfer-Encoding: 8bit Notice how the MIME-Version has moved to the end? Reordering headers, again to a certain extent, is perfectly valid to do in a Header section, but this is an Embedded Header and the change results in a change to the Confirm email’s body, and thus is a DKIM breaking one. Secondly, and harder to spot, did you notice how a space character “ What happens when a DKIM signature fails? Surprisingly the RFC makes no mention about what a mail relay is to do upon receipt of an email with a DKIM-Signature that fails validation. As such there is no agreed standard, and mail providers do as they please [Aside: you may wish to read up about DMARC<\/a> for a standards defined procedure for handling invalid mail, involving DKIM, but that’s not what is happening here]. It is our understanding that Hotmail can reject messages with a DKIM failure, and this is despite the fact that as far as we can tell, it is Hotmail itself that is altering the body of these messages, causing the failure in the first place.<\/p>\n\n\n\n There isn’t much of a conclusion here sadly. There are multiple ways in which a DKIM signature can break, and this post goes into a little detail about just one of them. Sadly maillist software such as Sympa have a hard time with DKIM due to the nature of sending mail on behalf of other domains but, in this particular instance at least, there sadly is not much we at the University of Oxford can do as the breakage is outside our systems. At the very least I hope you found this post informative. This blog post springs out of some debugging we in Networks Development and Support have been doing to understand why some Sympa email is being rejected by Hotmail, due to a DKIM failure. To get there, it may be good … Continue reading
Changing the body is one thing, but that’s not the only thing that’s important in an email. The Subject is a pretty important header, as is the Date, so they’re usually added to the signature being signed, but there are so many headers that it doesn’t make sense to include all of them (they’re hidden by the
mail client anyway). There’s also the fact that headers can be added to after an email has been sent, for diagnostics and the like.
So, the takeaway is this: email bodies are signed and cannot change without breaking the signature. In addition, some headers can be included in the signature, but as a general rule, there is more scope for header modification after an email is signed.
I hope you appreciate that these few paragraphs breeze over a fairly complex process. If you wish to know more, RFC 6376<\/a>, with its 75 pages, goes into the full details of DKIM’s implementation in exquisite detail, and is a cracking read to boot.<\/p>\n\n\n\nThe anatomy of a Sympa confirmation email<\/h2>\n\n\n\n
Thus, the route of an email [X] is as follows
[X] from Client -> Sympa -> Moderator receives [Confirm [X]]
So, the moderator receives an email which has text along the lines “Do you authorize the distribution of the following email?: [X]”.
Here’s where things get a little more interesting. [Confirm [X]] is a special email in that it has a little preamble text, but after that, embedded inside this email, is another email. This email includes Headers, which from now on I will call Embedded Headers.<\/p>\n\n\n\n<\/a><\/figure>\n\n\n\n
What I think is happening<\/h2>\n\n\n\n
body of e.g. [Confirm [X]], they in fact are immutable and must not change after signing.
However, after some testing done (and my thanks go out to the Unix Platform Services Team for their help with this), I have a repeatable test-case that these Embedded Headers are seemingly being modified after signing, as if they were not embedded, and so DKIM signatures are being broken. Even worse, sometimes mail providers, after changing the order of the Headers, can sometimes reject the email because it has been altered. There may be other providers, but the main reports appear to be from Hotmail domains.<\/p>\n\n\n\n
The original email contains in its Embedded<\/strong> Headers the following, with some details elided:<\/p>\n\n\n\n\n
Content-Disposition: inline
X-Sympa-To: <maillist-name>@<maillist-domain>
To: <maillist-name>@<maillist-domain>
Subject: Testing
Message-ID: <xukckclq2lqvsm353bukwkiqsaphgvlvuk6lp5cp3wgvy7qa7v@rvkwlaj5km5g>
MIME-Version: 1.0
Content-Type: text\/plain; charset=us-ascii
Content-Disposition: inline
<\/p>\n<\/blockquote>\n\n\n\n\n
Content-Disposition: inline
X-Sympa-To: <maillist-name>@<maillist-domain>
To: <maillist-name>@<maillist-domain>
Subject: Testing
Message-ID: <xukckclq2lqvsm353bukwkiqsaphgvlvuk6lp5cp3wgvy7qa7v@rvkwlaj5km5g>
Content-Type: text\/plain; charset=us-ascii
Content-Disposition: inline
MIME-Version: 1.0
<\/p>\n<\/blockquote>\n\n\n\n <\/code>” for the Content-Transfer-Encoding has been removed so “: 8bit<\/code>” (two spaces) now becomes “: 8bit<\/code>” (one space)? Perfectly valid to do in a Header, but this isn’t a Header, it’s in an Embedded Header section.<\/p>\n\n\n\nConclusion and the future<\/h2>\n\n\n\n
As to what the future holds, this talk about DKIM may be moot. There is currently a DKIM2 standard in the works. One interesting feature it touts is that modifications to email bodies are now allowed, but you are to record (in the Headers) what changes you made. My crystal ball grows hazy when I ask it how quickly this standard will be adopted, but for now at least it looks like a promising step in the right direction.
<\/p>\n","protected":false},"excerpt":{"rendered":"