Wandering Thoughts archives

Sorting out DomainKeys and understanding its limits

Okay, first a disclaimer: most everyone talks about DomainKeys, but it is formally DomainKeys Identified Mail (DKIM). Plain 'DomainKeys' is the name of the earlier specification that was folded into DKIM.

Until I started digging into this in detail, I had the basic idea that DKIM signed email header fields, crucially including the From:, in order to assert that the email had been sent from a valid mail server for the sender's domain. In other words, I thought it was the message header version of SPF (which attempts to authorize the envelope sender); because it worked on message headers instead of the envelope sender, it avoided SPF's problems with forwarded email.

It turns out that this is totally wrong, and the Wikipedia DKIM page even sort of explains how it is wrong, if you read it carefully.

Simplified, DKIM is nothing more and nothing less than a way of letting a domain take authoritative responsibility for a 'message', where the message is the email body plus selected message headers (which headers are up to the DKIM signer, but the RFC requires From: to be included). Note especially that this responsible domain does not necessarily have anything at all to do with the domain of the From: header (and the RFC update is very explicit about this); you can't conclude that the From: is valid or honest from the presence of a valid DKIM signature, or conversely that the From: header is forged because the message is lacking a DKIM signature from the domain.

Thus, when GMail DKIM-signs their outgoing email all they are saying is 'this really originated on GMail, and you can verify that it has not been tampered with in transit'. They are not saying anything about whether the email really came from who it claimed to come from in the From: header, at least not in the DKIM signature; what From: addresses GMail lets people use is a local policy issue that is outside of what DKIM has anything to say about.

(As it happens, GMail does try to verify From: addresses before it lets people use them.)

It follows that you cannot use DKIM for two useful things without outside knowledge:

• you cannot use DKIM to verify that email From: your bank is actually from your bank, unless you already know that your bank always sends email with a DKIM signature pointing to its own domain and thus that email without a DKIM signature or with a valid one that points to another domain is invalid by policy.

• you cannot use DKIM to verify that email really originated at a domain's mail servers unless you have already know that the domain always, without any exceptions at all, DKIM-signs all outgoing email and thus an email message with anything but a valid signature from that domain is invalid by policy.

As far as I can tell, without such advance policy knowledge there are only two useful things that you can do with a DKIM signature. First, if there is a signature but it does not validate, either the message has been tampered with in transit (possibly accidentally, possibly due to having a virus sliced out of it by someone's mail filters) or the header has been forged. Second, if the signature does validate you theoretically have someone to blame if the message is spam or otherwise bad (not that this does you much good in practice).