Domain Keys Identified Mail (DKIM) is method of verifying that an email is tied to a specific organization or sender. Not only does the DKIM signature bind the email to the sender, it matches the signing domain name with the sender. In the past, both IP addresses and domain names were used to identify the source of an email. However, this method is not the most reliable. Organizations and senders can change their domain names and obtain different IP addresses to send their email , thereby avoiding blacklists. DKIM, when used properly for authentication, eliminates the chance of a sender spoofing a domain name or IP address. ESPs can also overwrite the original senders DKIM signature with their own, thereby taking responsibility for the email.
The DKIM signature is added to the header field of an email message. By default, the signature contains a SHA-256 cryptographic hash value calculated based on the headers and body of the email message. When the email is sent, the receiving SMTP server uses the domain name field of the DKIM signature to perform a DNS look-up which locates the domains public key. The public key is then used to decrypt the hash value in the header field, then immediately used to recalculate the hash value of the email message. If these two values match, the email is proven un-tampered with.
The domain name field (d=) is one of the most important aspects of the DKIM signature. However, an article written by J.D. Falk of ReturnPath looks at the other fields of the DKIM signature and how they affect deliverability. The version field (v=) must always equal 1 or the DKIM signature isn’t valid. The algorithm field (a=) determines which algorithm is used, and has no affect on deliverability. The canonicalization field (c=) determines the degree of minor changes the email can have during transit before it is rejected.
With a simple Canononicalization algorithm, any minor changes made to the email during transit will cause the DKIM signature verification to fail. With a relaxed algorithm, the changes will not affect the messages ability to be verified. This field does not have any affect on deliverability, unless the email message verification fails. The header (h=) field determines which header fields you are signing and does not have any affect on deliverabilty All of the signed header fields can be copied into the signature with the z= tag, which has no affect on deliverability. The selector (s=) field is a way to look up which key your using and has no affect on deliverabilty. The body length limit (l=) tag specifies how much of the message the signer is responsible for. This tag is controversial due to the fact that malware and other unwanted data can be in the unsigned portion. This could affect deliverability, and it is not recommended you use this field. The q= value must be “dns/txt”, the t= is the time the signature was created, and the x= is when it expires, none of which affect deliverabilty. The i=tag identifies users, even though it looks like an email address, and does not affect deliverability.
Even though a sender or organization is clearly identified with the DKIM signature, spoofing and illegitimate email can still occur. Marketers can still send large volumes of email, but their reputation can more easily be determined. If DKIM is implemented industry-wide, it forces senders to take responsibility for their brand’s legitimate email. Currently, the DKIM signature is optional and is not required for an organization to send email. However, the signature can be used to increase the reputation and trustworthiness of an organization. Gmail, AOL, and Yahoo! have already adopted DKIM signatures, and many more ISPs are sure to follow.