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 explain why you should use it and how it actually works. Let’s get started!
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 briefly mentioned the product 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 ten 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.”
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 original message’s content 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 (mark@whatevercompany.io vs. mark@whatever-company.io).
What is DKIM?
DomainKeys Identified Mail (DKIM) is a digital signature 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 hidden in an email’s source code — a place where people don’t usually look, but servers accepting incoming emails definitely do. After all, DKIM is an industry standard for authentication.
DKIM would allow Mark to take responsibility for an email message 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 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 time he wants to email someone as 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 element used above:
Tag and its value | Meaning | Mandatory/optional |
---|---|---|
v=1 | Version. Always equals ‘1’. | Mandatory |
a=rsa-sha256 | 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. | Mandatory |
d=example.com | The domain of the sender of a message (where DKIM is signed). | Mandatory |
s=news | Selector — this includes instructions on which public key to use to resolve a given DKIM (more about this later). | Mandatory |
c=relaxed/relaxed | Canonicalization algorithm that’s used for both the 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=1126524832 | A timestamp of when the message was signed. | Mandatory |
x=1149015927 | Expiry 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:date:keywords:keywords; | List of headers, separated by colons. | Mandatory |
bh=MHIzKDU2Nzf3MDEyNzR1Njc5OTAyMjM0MUY3ODlqBLP= | The hashed message body, after being canonicalized with the method from “c” tag and then run through the hash function from “a” tag. | Mandatory |
b=hyjCnOfAKDdLZdKIc9G1q7LoDWlEniSbzc+yuU2zGrtruF00ldcFVoG4WTHNiYwG | 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 they add an extra layer of security. There are several other optional tags that you can use: “i” – Identity of a user or an agent (recommended to set); “l” – length of the message body, and “z”- list of message’s original headers (both not recommended to set).
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 to only certain parts of a header (“From”, “To”, “Cc”, “Subject”, etc.), and 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 mentioned above.
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 include 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 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:
568291DDA7ECE2594254BC8E7D70DA150968D022021081BB6E3FC40DC9C260D6
CE328291830AB02CFB1D8CDEC3C2B35C73F92ADF335BCCF38C6784AC9922A8C1
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. You can have a separate private key for each selector you use, 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 cover the process 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?
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 can be used to check SPF records simultaneously.
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 says ‘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.
Three major misconceptions about DKIM
DKIM encrypts your mail
It doesn’t. DKIM’s primary concern is to verify and confirm that the message is intact. The hashes under “bh” and “b” tags offer protection from message modification and replay, including partial protection from identity theft and forgery. A passed DKIM verification test basically means that the email sent has the permission to be sent from this domain, and that the message content was not altered while in transit.
A DKIM signature can be forged since its details are available in DNS records
No it cannot be forged. DKIM is based on PKI (Public key infrastructure), which means a pair of keys is involved. One public and one private. While it is true that the public key is published in the DNS records (and is available for everyone to retrieve), the private key is kept only on the email service provider server. The private key stays secret and is used to sign messages. The public key cannot sign messages and is used only for their verification.
DKIM saves you from spam once and for all
We wish. As DKIM digital signature only allows proving that the sender is authorized to send messages from the domain, and the message was not meddled with on the way, DKIM only lowers the chances of spammers using forged or stolen email addresses.
However, nothing stops them from buying a domain, setting up a DKIM record, and continuing with their spamming activities. In fact, this might even, in a certain way, legitimize spam.
Nevertheless, using a real domain instead of a forged one can most likely minimize phishing attacks like when you receive a forged email from your “bank” asking you to confirm your credit card details.
DKIM key rotation: keep your DKIM security up to date
Although DKIM public 1024-bits keys are hard to crack and 2048-bit keys are almost impossible they are still published in the DNS records and thus might become a target of attack. Private keys (signing key) could also be stolen if the system where it is stored is hacked.
To mitigate the risks of compromising DKIM keys, you need to minimize the time they are actively used. The process of systematic replacement of the old DKIM pair of keys with the new one is called DKIM key rotation.
In general, the recommended key rotation period is from quarterly replacement up to every six months. The frequency of key rotation should be established by the organization individually, but most definitely, it’s a must in the workflow.
The process of key rotation can become quite complicated within the companies that have multiple email streams, delegated subdomains, or streams sent on their behalf by third parties. Thus, to keep your email flow secure, the DKIM key rotation process should be planned ahead.
How to rotate DKIM keys?
The process of DKIM key rotation is divided into two major phases: preparation and rotation per se.
First, at the preparation phase, you identify all the mail streams being sent from your organization: from transactional messages, and conversational messages within the company to emails sent by third party vendors. Preparation also includes informing the internal stakeholders, email administrators, DNS administrators, and the internal tech support personnel responsible for email streams about the key rotation process. They should also know what to do in case of emergency key rotation if DKIM keys are unexpectedly compromised.
Second, at the implementation phase, you define your selector rotation scheme, rotate keys, and do the auditing afterwards.
Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG) have created a step-by-step guide for DKIM key rotation best practices. Remember, email security should always come first.
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 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.