DKIM Explained
DKIM signature, along with other methods, is one of the most common methods of authenticating yourself as the sender of an email.
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 email authentication. Of course, adding a DKIM signature doesn’t guarantee delivery, but it significantly boosts the odds of a positive outcome.
Why use DKIM?
Imagine the following scenario. You’re sending a quick follow-up message to a potential investor after a meeting, “Yvonne, let me know if you would like to proceed with what we discussed earlier.” Some time goes by, and you never got a reply from Yvonne but you bump into her in another meeting and discreetly mention that email. Puzzled, Yvonne says, “Mark, I never heard from you back.”
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.
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 type of cyber attack 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 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. (bh – body hash) | 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?
DKIM signing and receiving 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 header fields (“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 SMTP 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 mail 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 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 email 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?
gappssmtp is a default domain key for emails sent through the gmail SMTP server. DKIM authentication record will sometimes show gappssmtp. For example, you received an email from name@railsware.com, the DKIM record will show railsware-com.20150623.gappssmtp.com.
To check the DKIM authentication record, for suspicion of phishing or otherwise, locate the “show details” dropdown under the sender’s name. The section “signed by” is what you are looking for to determine if the email was sent from a secure server. If it says “gmail” then the DKIM record will include gappssmtp, therefore the email was sent from a secure server with a default authentication key.
Emails sent through a service, such as a calendar, drive, box or so, do not have a DKIM. Instead, you will only be able to locate a signature provided by the service. Those signatures, including gappssmtp, are assigned automatically and simply verify the security of the email you received. It is a standard, automated procedure done for verification purposes.
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 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 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 name 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 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.
Thanks for reading the article by Piotr Malek. You can find more on the original Mailtrap Blog.