DomainKeys Identified Mail

Overview#

DomainKeys Identified Mail (DKIM) is an email authentication Protocol designed to detect forged sender addresses in emails (email spoofing), a technique often used in phishing and email spam is defined in RFC 6376

DKIM allows the receiver to check that an email claimed to have come from a specific domain was indeed authorized by the owner of that domain.[1] It achieves this by affixing a digital signature, linked to a domain name, to each outgoing email message. The recipient system can verify this by looking up the sender's public key published in the DNS. A valid signature also guarantees that some parts of the email (possibly including attachments) have not been modified since the signature was affixed.[2] Usually, DKIM signatures are not visible to end-users, and are affixed or verified by the infrastructure rather than the message's authors and recipients.

DomainKeys Identified Mail Implementation#

Signing#

The signing organization can be a direct handler of the message, such as the author, the submission site or a further intermediary along the transit path, or an indirect handler such as an independent service that is providing assistance to a direct handler.

Signing modules insert one or more DKIM-Signature: header fields, possibly on behalf of the author organization or the originating service provider. The specification allows signers to choose which header fields they sign, but the From: field must always be signed. The resulting header field consists of a list of tag=value parts as in the example below: 

DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane;
     c=relaxed/simple; q=dns/txt; t=1117574938; x=1118006938;
     h=from:to:subject:date:keywords:keywords;
     bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
     b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
              VoG4ZHRNiYzR
Where the tags used are: The most relevant ones are b for the actual Digital Signature of the contents (headers and body) of the email message, bh for the body hash, d for the signing domain, and s for the selector.

Both header and body contribute to the Digital Signature. First, the message body is hashed, always from the beginning, possibly truncated at a given length (which may be zero). Second, selected header fields are hashed, in the order given by h. Repeated field names are matched from the bottom of the header upward, which is the order in which Received: fields are inserted in the header. A non-existing field matches the empty string, so that adding a field with that name will break the signature. The DKIM-Signature: field of the signature being created, with bh equal to the computed body hash and b equal to the empty string, is implicitly added to the second hash, albeit its name must not appear in h — if it does, it refers to another, preexisting signature. For both hashes, text is canonicalized according to the relevant c algorithms. The result, after encryption with the signer's Private Key and encoding using Base64, is b.

Algorithms, fields, and body length are meant to be chosen so as to assure unambiguous message identification while still allowing Digital Signatures to survive the unavoidable changes which are going to occur in transit. No data integrity is implied.

Verification#

A receiving SMTP server wanting to verify uses the DNS Domain name and the selector to perform a DNS lookup. For example, given the example signature above: This gives the TXT DNS Resource Record to be looked up as: 
brisbane._domainkey.example.net

The data returned from the query of this record is also a list of tag-value pairs. It includes the domain's Public Key, along with other key usage tokens and flags; as in this example: 

"k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDmzRmJRQxLEuyYiyMg4suA2Sy
MwR5MGHpP9diNT1hRiwUd/mZp1ro7kIDTKS8ttkI6z6eTRW9e9dDOxzSxNuXmume60Cjbu08gOyhPG3
GfWdg7QkdN6kR4V75MFlw624VY35DaXBvnlTJTgRg/EW72O1DiYVThkyCgpSYS8nmEQIDAQAB"
The receiver can use the Public Key (value of the p tag) to then decrypt the hash value in the header field, and at the same time recalculate the hash value for the mail message (headers and body) that was received. If the two values match, this cryptographically proves that the email was signed by the indicated domain and has not been tampered with in transit.

Signature verification failure does not force rejection of the message. Instead, the precise reasons why the authenticity of the message could not be proven should be made available to downstream and upstream processes. Methods for doing so may include sending back an FBL message, or adding an Authentication-Results header field to the message as described in RFC 7001.

DomainKeys Identified Mail Patent#

Although DomainKeys is covered U.S. Patent 6,986,049, Yahoo! has licensed its patent claims under a dual license scheme: the DomainKeys Patent License Agreement v1.2,[9] or GNU General Public License v2.0 (and no other version).

More Information#

There might be more information for this subject on one of the following:

Please see our Copyright And Intellectual Property Page and Standard Disclaimer Pages!