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
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
be included). Note especially that this responsible domain does not
necessarily have anything at all to do with the domain of the
header (and the RFC update
is very explicit about this); you can't conclude that the
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
From: header, at least not in the DKIM signature; what
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).