DKIM Explained

Spamming our inboxes has been the preferred pastime of spambots ever since the first email mailbox was created. While annoying, most of these messages are just harmless attempts to get you interested in some products or services. We’ve learned to ignore them and with sophisticated spam filters these days we hardly even notice them. Things get a bit more tricky when a bot impersonating your best friend emails you about a new product she just found. Would you be able to resist seeing what she’s on about?


DKIM signature, along with other methods such as SPF or DMARC, is one of the most common methods of authenticating yourself as the sender of an email message. Below, we’ll explain why you should use it too and how it actually works. Let’s start!

Why use DKIM?

Imagine the following scenario. You’re in charge of selling your shiny new product and you know one CEO who might really be interested. You met with Yvonne randomly at a tech meetup two weeks ago and mentioned the product briefly, to her visible interest (at least you thought so). She gave you her business card and asked for an email with some more details, after which she rushed somewhere else.

Now you’re spending the entire afternoon crafting an email for her, explaining how it will make her company much more efficient. Having read through it at least 10 times, you press ‘send’ and close the laptop. You, then, nervously refresh the email app on your phone every half an hour, but with no result. A day passes, then another and another. Finally, after roughly a week and a half, you send a quick note “Yvonne, let me know if you would like to meet, happy to come over any time.”. Another week goes by, and then another – no response. You start wondering what went wrong.

Then, at another meetup three months later, you spot Yvonne across the hall. You approach her and start chatting. At some point, you discreetly mention your product and that conversation a while back. Puzzled, Yvonne says “Mark, I never heard from you. We couldn’t wait any longer so we’ve signed with another company and they’re pretty great”.


What really went wrong here? Mark indeed sent an email but it never reached Yvonne’s inbox. Since it didn’t bounce (he would have received a Delivery Status Notification (DSN) if it did), it must have skipped the inbox. It ended up in a ‘spam’ folder, along with potentially hefty payout he had hoped for.

Why did this happen? There are many potential reasons for poor deliverability but, as it turned out, Mark forgot to set up DKIM authentication for his email account. As a result, Yvonne’s server wasn’t quite sure if it was really Mark emailing her and discarded the message, just in case (putting “You really need to see this!” in the topic probably also played its part).

What is DKIM?

DomainKeys Identified Mail (DKIM) is a digital signature that’s added to every email sent from a given email address. It’s not a typical signature you expect to see on the bottom of a corporate email. As a matter of fact, normally you don’t even see the DKIM. It’s a seemingly random set of characters that are hidden in the source code of an email – a place where people don’t usually look but servers accepting incoming emails definitely will. After all, DKIM is an industry-standard for authentication.

DKIM would allow Mark to take responsibility for an email message that he was about to send to Yvonne. With this signature, he would say “Hey, I’m Mark, writing from my email address mark@whatevercompany.io on June 21th 2019 at 3:52 PM PST. I’m including in this email the following message: (…)”. When the message is received, Yvonne’s email server would read this message, think for a brief moment (like, really brief) and if everything sounds fine, display the message in Yvonne’s mailbox. Of course, adding DKIM signature doesn’t guarantee delivery but it significantly boosts the odds of a positive outcome.

Naturally, Mark doesn’t need to write such a message every single time he wants to email someone. It happens automatically every single time, once DKIM is configured for his domain. 

What does a DKIM Header look like?

Here’s an example of a DomainKeys Identified Mail record:

DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=newyork;
     c=relaxed/simple; q=dns/txt; t=1117574938; x=1118006938;
     h=from:to:subject:date:keywords:keywords;
     bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
     b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
              VoG4ZHRNiYzR

DKIM is made up of different elements, described with various tags and values corresponding to each. Let’s break down the meaning of each that was used above:


Tag and its value

Meaning

Mandatory/optional

v=1

Version. Always equals to ‘1’.

Mandatory

a=rsa-sha256

Signing algorithm (so the one used to create a DKIM record on the sender’s end). Usually, it’s either rsa-sha or rsa-sha256. There are other algorithms but they’re not always supported by receiving clients.

Mandatory

d=example.net

The domain of a sender of a message (where DKIM is signed)

Mandatory

s=newyork

Selector. This includes instructions on which public key to use to resolve a given DKIM (more about it later).

Mandatory

c=relaxed/simple

Canonicalization algorithm that’s used for both header and body.

Mandatory

q=dns/txt

Query method that’s used to retrieve the public key. By default, it’s ‘dns/txt’

Optional (recommended)

t=1117574938

A timestamp of when the message was signed

Mandatory

x=1118006938

Expire time of this DKIM (if an email arrives after the expiry time, the verification will fail even if everything else matches perfectly)

Optional (recommended)

h=from:to:subject:dat
e:keywords:keywords;

List of headers, separated by colons.

Mandatory

bh=MTIzNDU2Nzg5M
DEyMzQ1Njc4OTAxMj
M0NTY3ODkwMTI=

The hashed message body, after being canonicalized with the method from ‘c’ tag and then run through the hash function from tag ‘a’.

Mandatory

b=dzdVyOfAKCdLXdJO
c9G2q8LoXSlEniSbav+
yuU4zGeeruD00lszZVo
G4ZHRNiYzR

And finally, this is the digital signature of both headers and body, hashed with the very same function.

Mandatory

As you can see, the actual signature is only a small part of DKIM. Everything that’s above it is metadata, describing how the hashed values were calculated.

Notice how two of the tags were marked as optional – they’re not required for DKIM to be verified properly but add an extra layer of security. There are several other optional tags that you can use:


Tag

Meaning

Recommended or not

‘i’

identity of a user or an agent. The value of this tag is an email address, including a domain and subdomain as defined under ‘d’ tag.

Recommended

‘l’

length of the message body (number of characters) that was used to compute the body hash. If the tag isn’t used, it’s assumed that the whole body was used.
Not recommended

‘z’

list of message’s original headers.

Not recommended

How DKIM works?

Signing and receiving DKIM happens in three steps.

  1. The sender decides what to include in a DKIM record

As a sender, you can limit yourself to only certain parts of a header (‘From’, ‘To’, ‘cc’, ‘subject’ or others) but can also go as far as including the entire header and body in DKIM. You can also choose to add some or all of the optional fields that we mentioned above. While we’ve included them in the list, we don’t recommend using the last two tags from the previous table. They don’t bring much value and when misconfigured, they can lead to fake authentication even if the rest of the record is fine.

Technically, the more specific details are included, the more reliable authentication will be. But you need to be careful with this too as even the tiny details changed by your email server will lead to a failed DKIM authentication on the receiving side. Think, for example, about “forwarded by…” messages that are added to emails when forwarding them from email clients. If you included your entire body in DKIM, it will now inevitably fail as the body was just modified.

Don’t worry, though. You don’t need to decide on the shape of a DKIM every single time you send an email. It’s taken care of automatically by a server that you need to configure just once. 

     2. The DKIM is created and a message including it is sent

Once the server knows what to include in the DKIM and email sending is initiated, it starts hashing the content. You saw already how ‘b’ and ‘bh’ tags looked l in our example. To give you a further example, here’s how the previous step would look if hashed with the SHA256 method:

568291DDA7ECE2594254BC8E7D70DA150968D022021081BB6E3FC40DC9C260D6
CE328291830AB02CFB1D8CDEC3C2B35C73F92ADF335BCCF38C6784AC9922A8C1

Although it might seem complex, such hashes are extremely easy to decipher with various online tools (try it yourself!). That’s why, before an email is sent, each hash is encrypted with a so-called private key. For each selector you use, you can have a separate private key even if you send all emails from the same domain. This can mean one key for marketing emails, another for transactional ones and a third for emails sent to vendors. Using different private keys is important for security reasons.

Once everything is set up, an email is sent!

     3. A message is received and the server validates the DKIM signatures

Within seconds, a message is received by the receiving server and it needs to make an important decision – whether to allow the email in or not. When it sees that a DKIM is included with the message, it immediately starts the validation process.
With the ‘domain’ (‘d) and ‘selector’ (‘s’) fields visible in DKIM, the server can fetch the public key corresponding to this combination by running an appropriate DNS query (such data is publicly available). Then, with the newly acquired public key and ‘b’ and ‘h’ encrypted fields, the receiving server build its own hashes and compares them with the ones received in a message. If there’s a match – the authentication is successful. If not, DKIM authorization fails. It doesn’t mean that the message will be discarded but it lowers its chances of being delivered.

How to add DKIM signature to your emails?

Adding DKIM requires changing some details of your DNS records. Many email clients have it covered in detail so we won’t be focusing on it here. Check the following links for the details specific to the most popular providers:

If your email client doesn’t offer any help on implementing DKIM or you’re setting up your own infrastructure, check out the official docs of DKIM.

How to test if DKIM was configured properly?

Once DKIM is added, make sure that you validate it with an online DKIM analyzer. Use, for example, MXToolbox or Mail-tester.com, the latter one can be used to check SPF records simultaneously.

You can also just send a test email to your Gmail or Yahoo account and verify yourself if a message came with your DKIM signature.

Once the message arrives, expand the header with the triangle icon below the sender’s name. If the sender’s domain appears for both ‘mailed-by’ and ‘signed-by’, the message was verified successfully with DKIM.

dkim-signed

You can also click on the three dots in the top-right corner and “Show Original”. Here you’ll see the result of DKIM authentication. If it comes with the word ‘PASS’ and your domain address, everything works fine. If you send an email from Gmail and don’t set up a DKIM authorization, Gmail will assign a default one for you by adding something like “.20150623.gappssmtp.com” to your domain address. Such a message is also authenticated but not as effective as it would be with your individual DomainKeys Identified Mail setup.

To verify the DKIM record on Yahoo, click on “View Full Header” and search for the trace of DKIM. If you find dkim=pass (ok), you passed the test!

Other considerations

This wraps up our guide to DKIM but it shouldn’t be an end to your efforts to improve email deliverability. Check out our guide to deliverability where we list tons of other ideas. Make sure you also authenticate with SPF as well as DMARC to make your domain even more credible. It only takes a tiny bit of time and effort, but the payoff can be enormous.