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 trickier 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 a CEO who may be really 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 off somewhere else.
Now you’ve spent 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 your 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 room. 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 did indeed send 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 had), it must have skipped her inbox. It ended up in her spam folder, along with the 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).
The main purpose of DKIM is to prevent spoofing. Email spoofing is changing the content of the original message and sending it from an alternative sender that looks like a trusted source. This is a type of cyber attack and is widely used for fraud — for example, someone sending payment request messages from an email address that looks like yours (firstname.lastname@example.org vs. email@example.com).
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’d 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 firstname.lastname@example.org on June 21st 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 a 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
Version. Always equals ‘1’.
|Signing algorithm (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.|
|The domain of the sender of a message (where DKIM is signed).|
|Selector — this includes instructions on which public key to use to resolve a given DKIM (more about this later).|
|Canonicalization algorithm that’s used for both header and body.|
|Query method that’s used to retrieve the public key — by default, it’s “dns/txt”.|
|A timestamp of when the message was signed.|
|Expiry time of this DKIM (if an email arrives after the expiry time, the verification will fail even if everything else matches perfectly).|
|List of headers, separated by colons.|
|The hashed message body, after being canonicalized with the method from “c” tag and then run through the hash function from “a” tag.|
|And finally, this is the digital signature of both headers and body, hashed with the very same function.|
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 they add an extra layer of security. There are several other optional tags that you can use:
Recommended or not
Identity of a user or an agent — the value of this tag is an email address, including a domain and subdomain as defined under the “d” tag.
|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|
|List of message’s original headers.|
How does DKIM work?
Signing and receiving DKIM happens in three steps:
- The sender decides what to include in a DKIM record
As a sender, you can limit yourself only to certain parts of a header (“From”, “To”, “Cc”, “Subject”, etc), 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 tiniest 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 the 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 have already seen how “b” and “bh” tags looked in our example. To give you a further example, here’s how the previous step would look if hashed with the SHA256 method:
Although it may 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 emails and a third for emails sent to vendors. Using different private keys is important for security reasons.
Once everything is set up, the 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 that corresponds 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 builds its own hashes and compares them with the ones received in the message. If there’s a match, the authentication is successful. If not, DKIM authorization fails. That doesn’t mean that the message will be discarded, but it lowers its chances of being delivered.
How do you 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 DKIM’s official documentation.
How can you test whether DKIM was configured properly?
You can also just send a test email to your Gmail or Yahoo account and verify whether a message arrived with your DKIM signature yourself.
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.
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.
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!
What is Gappssmtp?
Sometimes you will see 20150623.gappssmtp.com in the DKIM authentication record. Everything is fine — this is a default DKIM domain key (d=*.gappssmtp.com). It appears when a sender hasn’t set the DKIM authentication with their domain, but sends messages with the Gmail SMTP server. Gmail signs such messages automatically.
Such a message is also authenticated, but not as effectively as it would be with your individual DomainKeys Identified Mail setup.
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 on 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 little bit of time and effort, but the payoff can be enormous.