Forge Proof your Domain Reputation With DKIM

Spam, the unwelcomed junk that finds its way into our mailbox has become rampant these days. What is worse is that recently Gmail users received spam from themselves! Although Gmail assured that the accounts were not hacked, such bugs really can freak anyone out. Upsetting almost all of the internet users, it is possibly the oldest of the security problems as it has been four decades that we are dealing with spams ?

Earlier there was no way one could authenticate the email sender as original designers of SMTP neglected including it. DKIM came to the rescue and made it easy for the recipient to verify that the domain from which the message claim to originate is, in fact, the actual sender of that message. DKIM is a way to authenticate the reputation and identity of the sender and their email signing practices for further handling such as email delivery.

What is DKIM?

DKIM (DomainKeys Identified Mail) is a security standard for emails, and it is designed to ensure that emails do not get altered during the transit phase from the sending server to the recipient server.

When it leaves the server that is sending it, it is signed with a private key using public key cryptography. The public key is published on the domain’s DNS, and it is used by the recipient servers to authenticate the message. It ensures that there is no alteration in the message’s body. The message passes DKIM. The recipient server verifies the hash made with the private key using the published public key. Only then it becomes authentic.

Why should you implement DKIM?

It is simple to pretend to be some other trusted sender over SMTP. This has increased the chances of end users receiving spam emails since they appear like they came from a legitimate source. Email spoofing from domains that are trusted has been in practice for a long time. This is mainly for malicious intentions and phishing campaigns. With DKIM, these practices have been made almost impossible.

DKIM is exceptionally compatible with the email infrastructure that is in existence. It works wonderfully with SPF and DMARC to create an extra layer of security that is needed by domains. Also, recipient servers that have not implemented DKIM can conveniently receive signed messages. However, DKIM is an optional tool for extra security and not a standard that is adopted worldwide.

DKIM is not compulsorily required. But, we strongly recommend using it because you can to authenticate the emails from your domain. At Aritic Mail, we use DKIM to sign emails, and ISPs such as Yahoo, AOL, and Gmail so that we can adequately monitor received messages. We have done some tests and have proved that the chances of email delivery increase with this protocol in place.

DKIM also enables ISPs to build your domain’s reputation. When you send emails that have good delivery practices like low bounces and spam, with high engagement, your delivery will be excellent ?

Now that you know the importance of DKIM let us move on to the issues that DKIM does not solve. DKIM will always ensure that the message you send is the one that is received. Of course with no changes in it. This does not mean that the message is encrypted. There are many ESPs that uses TLS that is opportunistic to encrypt the message for transit between the recipient and sending servers. Even so, it is also possible to send emails that are not encrypted if the server refuses dealings with TLS. When delivery of signed messages takes place, ensure that the SMTP headers maintains DKIM. Nevertheless, it will not encrypt the message.

Having understood what DKIM can do for you, it is essential to look at how it actually works.

How does DKIM work?

Typically, DKIM uses two actions to verify the message. Firstly it acts on the sending server that sends signed emails. Secondly, on the recipient server where it checks the signatures of the received emails. This process involves the pairing of private and public keys. The private key is never exposed and is kept safe on your server or the ESP. The public key is included on your domains DNS records where it is revealed to the world for purposes of verifying messages. Now let us understand how this protocol works on the sending and receiving servers.

Sending a DKIM signed message

You can always generate private and public keys on your own if you are using your own server. But when you are using servers such as Google Apps, Campaign Monitor or other providers, these keys will be generated for you.

To satisfactorily explain how DKIM works, let us consider an example of Aritic Mail. We ensure that we safely store your private key on our server and use it to sign all your messages when you send them. While sending a message, we create a hash from the header’s content. We will sign this hash using the private key. The signature will have everything needed by the recipient server to authenticate the message. It will look as shown below.


DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=20130519032151pm; d=ariticmail.com;
h=From:Date:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:To:Message-ID;
i=support@ariticmail.com; bh=vYFvy46eesUDGJ45hyBTH30JfN4=;
b=iHeFQ+7rCiSQs3DPjR2eUSZSv4i/Kp+sipURfVH7BGf+SxcwOkX7X8R1RVObMQsFcbIxnrq7Ba2QCf0YZlL9iqJf32V+baDI8IykuDztuoNUF2Kk0pawZkbSPNHYRtLxV2CTOtc+x4eIeSeYptaiu7g7GupekLZ2DE1ODHhuP4I=

Explanation of the header

DKIM Signature: it is the header registered for every message that is signed by DKIM

V=2; the DKIM’s version that the sending server uses

a=rsa-sha1; is the algorithm used for the generation of the hash for the private/public key. The two supported algorithms for this hash are rsa-sha1 and rsa-sha256

c=relaxed/relaxed; used to set the sending domain’s canonicalization posture. It helps in regulating whitespaces and text wrapping changes that occur in the message. The two canonicalized postures we have here are ‘simple’ which prevents any changes and ‘relaxed’ that allow changes that are common to the whitespace and header line wrapping. You can manage canonicalization in the header and body separately, and you will have to use the header/body format.

s=20130519032151pm; it is a public DKIM key selector for verification. Typically, a domain can have numerous public DKIM keys, and this selector will ensure the recipient server uses the right public key.

d=ariticmail.com; this is the email domain behind the signature on the message. It is vital for the DKIM signature to use the name of the domain here since it helps with the reputation of the domain with ISPs. This is because you are sending emails that are valid regardless of the provider you are using.

From: Date: Subject: MIME-Version: Content-Type: Content-Transfer-Encoding: To: Message-ID; they are the headers included in the message when it is being signed.

I=support@ariticmail.com; this is the sender’s identity and is an email address.

The body hash’s value is bh=vYFvy46eesUDGJ45hyBTH30JfN4=; before the signing of the message headers.

b=iHeFQ+7rCiSQs3DPjR2eUSZSv4i/Kp+sipURfVH7BGf+SxcwOkX7X8R1RVObMQs
FcbIxnrq7Ba2QCf0YZlL9iqJf32V+baDI8IykuDztuoNUF2Kk0pawZkbSPNHYRt
LxV2CTOtc+x4eIeSeYptaiu7g7GupekLZ2DE1ODHhuP4I=
It is a cryptographic signature of all the information that precedes from the signature field of DKIM. We consider it as a string that is empty during the process of verification.

The computed signature is as shown above. All the outgoing SMTP headers will contain it. This message is ready for you to send, but wait for the recipient server to confirm that nothing has changed during the transit.

Verification of a message signed by DKIM

Verification takes place with ensuring the version number is as per the DKIM specification. This is how the email system will start verifying a DKIM signed message. It also makes sure that the domain of the sender is similar to the domain set included in the signature. Also if the ‘h=’ tag has the ‘from’ field in the header.

The recipient server will then proceed to retrieve the public key from the domain that sent the email. That is after the signature verification is over. The ‘d=’ tag will be used by the server to check for sending domain on the DNS records. The ‘s=’ tag is used to choose the correct DKIM key. Ariticmail’s public key looks like this:


20130519032151pm._domainkey.ariticmail.com. 3599 IN TXT "k=rsa\; 
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCSGLvJw6sZ5YEeFe5tl6D7h6IiE1J5kmMH6TEpG99BIHDuXg3vz/qRblKa0WcbI4SLDwsMkq17VheGt7ZZANqrCjcieHkKC8u52h5mezNFHRcKiOpr06o8PfkbqQsCX58ZpALcH0S1aQb6zkpebYsA111l1pGv5qlKvsbJ9t+9jwIDAQAB"

When the public key is handy, a hash will be computed by the recipient server to validate the authenticity of the message.

Implementing DKIM on your Domain

DKIM’s set up is usually the same regardless of the kind of ESP you are using. It requires that you have a private key kept safely somewhere and the public key shared in the DNS records of your domain.

One of the best practices to follow while dealing with DKIM keys is to rotate them once in a while. The DKIM standards recommend to rotate your keys every quarter. As you do so, don’t forget to revoke the old keys. To accomplish this efficiently, add the new keys and wait for few days before you remove the old keys from your domain’s DNS records.

At Aritic Mail, we manage the rotation process for you easily. By using the Aritic Mail dashboard, you can quickly create a new key and verify the same.