What is DomainKeys Identified Mail?
DKIM stands for Domain Keys Identified Mail. It is an anti-spam fighting technique and one of the important email authentication method. It affords the greatest assurance that the sender is who they say they are and gives email providers a way to track and hold senders accountable for the messages they’re sending. In its the abbreviation of DKIM there are actually two parts
Part1 – Domain Keys (Means DKIM is a domain-based authentication method).
Part2 – Identified Mail (Signature-based Internet mail authentication standard).
History of DKIM
The original DKIM was designed at Yahoo by Mark Delany (Australian Computer Programmer specializing in e-mail infrastructure and anti-spam techniques)in 2004. Though the DKIM concept which we use is not the one he has designed, because there were several comments enhanced by anti-spam experts from Yahoo and Cisco . In 2004 by the effort of Yahoo and Cisco, an enhanced domain based anti-spam technique was developed which is called as DKIM. On the Cisco, side Identified Internet Mail was designed and on Yahoo side enhanced DomainKeys was designed and combining both resulted as the DomainKey Identified Mail.
Why DKIM?
So far you must have got some idea why we use it. But in details to understand why we needed this let’s think about what would have happened when DomainKeys was not in use. Recall the SPF – to prevent forging it was designed so now to prevent what — DKIM comes into the picture? Interesting! Spoofing email from trusted domains is a popular technique for malicious spam and phishing campaigns, and DKIM makes it harder to spoof email from domains that use it.
Let’s take an example of our traditional Post Service. 15-20 years back people used to communicate via letter, mainly there were two types of a letter – Postcard and Envelope. A postcard was used for sharing that information which is not confidential or doesn’t relate to your privacy. An envelope was used to share some confidential information so that it can’t be read or changed or modified during its transition period. This was the way to secure the integrity of the information using Envelope. In the same way for electronic message also we can secure our email using DKIM so that spammer can’t modify the actual content and integrity of email should be maintained as it was sent by the sender.
DKIM in Details
First of all – Like SPF, you don’t need DKIM to send an email, remember this is not mandatory but highly recommended. Unfortunately, DKIM is not a universally adopted standard. DKIM is compatible with existing email infrastructure and works with SPF and DMARC to create a layered security for domains sending emails. Mail servers that don’t support DKIM signatures are still able to receive signed messages without any problems. It’s an optional security protocol. Even if it is not required, I strongly recommend having these things set up before you start your email program.
An additional benefit of DKIM is that ISPs use it to build a reputation on your domain over time. As you send the email and improve your delivery practices (low spam and bounces, high engagement), you help your domain build a good sending reputation with ISPs which improves delivery. While it’s important to understand what DKIM does, it’s also important to be clear about what it doesn’t solve. Using DKIM will make sure your message hasn’t been altered, but it doesn’t encrypt the contents of your message. Many ESPs use opportunistic TLS to encrypt messages as they move between sender and recipients, but it’s still possible to send unencrypted messages if an email server refuses a TLS handshake. Once a message has been delivered, the DKIM signature will remain in the SMTP headers but won’t encrypt the content of the message in any way.
Implementation and How it works?
DKIM works on a signature basis. It generates two keys one is publicly visible to outside world and added into the sending domain DNS. The second one is a Private key which is securely installed on a mail server. If you run your own mail server, you can generate this pair on your own. Any time you use a service like Google Apps, Campaign Monitor, Zeta Hub Platform or other email providers that support DKIM they’ll normally generate the key for you.
If you are using an ESP for your email campaign, then they must keep your private key securely stored on our servers and sign each message as it is sent. When a message is sent a hash is created by your ESP from the content of the message headers and then they will use your private key to sign the hash. This signature carries everything a recipient server needs to validate the message and looks like this:
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=uoe; d=universityofemail.com;
h=From:Date:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:To:Message-ID;
i=blogs@universityofemail.com; bh=uOevy70eesUDGJ71hyBTH60Jf4N=;
b=uiHeFQ+7orCiSQs3eDPjR2eUSZSv4i/Kp+usipURofVH7BGf+SexcwOkX7X8R1RuVObMQsFocbIxnrq7Bea2QCf0YZlL9iqJf32V+baDI8IykuDztuoNUF2Kk0pawZkbSPNHYRtLxVU2CTOtc+x4eIeSeYptaiu7g7GupOekLZ2DE1ODHhEuP4I=
Each of the element used above is explained as below:
DKIM-Signature: is the header registered for DKIM signed emails.
v=1; the version of DKIM being used by the sending server. (Currently only this version is used widely)
a=rsa-sha1; the algorithm used to generate the hash for the private/public key. There are two officially supported signature algorithms for this hash, rsa-sha1 and rsa-sha256. (You don’t need to know actually how the algorithm is written and this is out of scope of our discussion)
c=simple/relaxed; sets the canonicalization posture for the email sending domain. This regulates whitespace and text wrapping changes in a message. There are two canonicalized postures. `Simple` doesn’t allow any changes, and `relaxed` allows common changes to whitespace and header line wrapping. Canonicalization in the header and body can be managed individually and uses a header/body format.
s=uoe; is used as a selector for the public DKIM key for verification. Domains can have multiple public DKIM keys, and the selector value makes sure recipient servers are using the correct public key.
d=universityofemail.com; is the email domain that signed the message. It’s important that your DKIM signature use your domain name here because this bolsters your domain’s reputation with ISPs as you send valid email, regardless of the Email Service Provider you use.
i=blogs@universityofemail.com; is the identity of the signer and is usually provided as an email address.
bh=uOevy70eesUDGJ71hyBTH60Jf4N=; is the value of a body hash generated before the message headers are signed.
b=uiHeFQ+7orCiSQs3eDPjR2eUSZSv4i/Kp+usipURofVH7BGf+SexcwOkX7X8R1RuVObMQsFocbIxnrq7Bea2QCf0YZlL9iqJf32V+baDI8IykuDztuoNUF2Kk0pawZkbSPNHYRtLxVU2CTOtc+x4eIeSeYptaiu7g7GupOekLZ2DE1ODHhEuP4I= is the cryptographic signature of all the preceding information from the DKIM-Signature field. This entry is treated as an empty string during the verification process.
From:Date:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:To:Message-ID; are the headers included with the message when it was cryptographically signed.
Public Key which need to be added in email sending domain’s DNS
uoe._domainkey.universityofemail.com. 1289 IN TXT "k=rsa\;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNAUDCBiQKBgQCSGLvJow6sZ5YEeFe5tl6D7h6IiE1J5kmEMH6TEpG99BIHDuXg3vz/qRblKa0WcbI4SLDwsMkq17UVheGt7ZZANqrCjcieHkKC8ou52h5mezNFHRcKiOpr06o8PfkbqEQsCX58ZpALcH0S1aQb6zkpebYsA111l1pGv5qlKvsbJ9t+9jwIDAQAB"
With the public key in hand, the recipient server computes a hash from the public key in order to verify the message hasn’t been changed.Mail systems start DKIM verification by making sure the version number meets the DKIM specification, the identity of the sender’s domain matches the domain set in the signature, and the “h=” tag contains the From header field.
Once the signature has been validated, the recipient server tries to retrieve the public key for the sending domain. The server uses the “d=“ tag to look up the DNS records for the sending domain, and the “s=” tag to select the correct DKIM key. For this case, the domain is universityofemail.com and selector is ‘uoe’.
General setup for DomainKeys is the same no matter which ESP you use. You just need to store your private key somewhere securely and you need to share a public key in your domain’s DNS records. Like another security mechanism for example your internet banking password, usually your bank such as HDFC sets a password ageing feature due to which you have to update your password in every 72 days or so. In the same way, it is also recommended and best practice to periodically rotate your DKIM keys. The standard DKIM key rotation period is per quarter and it also recommends you revoke your old DKIM keys as part of this rotation. The best way to manage this is by adding your new keys, and a few days later removing your old keys DNS records for your domain.
Resources:
DKIM Key Checker:
By ProToDave
By DKIMCore
By Mail Tester
Email Header Analyzer
By Google: Using this you may get some detail about specific header elenent used in Gmail email header.
MX Toolbox: In general
By Microsoft: Using this you may get some detail about specific header element which is used Hotmail/Outlook email header.
