The introduction of the Simple Mail Transfer Protocol (SMTP) in 1982 marked a major advancement in global electronic communication. Designed to simplify message delivery, SMTP quickly became the backbone of email systems. However, it was not built with strong security in mind. Over time, threat actors have taken advantage of its weaknesses, particularly its inability to verify the sender’s identity from the recipient’s mail server—leaving it vulnerable to domain impersonation attacks.
To close this security gap, the Internet Engineering Task Force (IETF) introduced three key email authentication protocols: Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC).
Each protocol addresses different aspects of email authentication and has its own strengths and limitations. Among them, DKIM plays a vital role in ensuring the authenticity and integrity of messages. However, its setup and maintenance are more complex compared to SPF and DMARC, which can result in serious consequences if misconfigured. For example, in 2023, Twitter (now X) failed to rotate DKIM keys, causing their emails to be rejected by receiving mail servers. To help prevent such issues, this article offers a step-by-step technical guide to securely setting up DKIM. It also highlights important security and cryptographic considerations for maintaining a reliable and secure DKIM configuration over time.
|
Concept |
Description |
|
Why DKIM? |
DKIM provides specific security attributes, such as email integrity, that SPF does not offer. Furthermore, it uses Cryptography instead of IP whitelisting to verify the email authenticity. |
|
How to properly set up DKIM |
DKIM requires the creation of a cryptographic key pair, DNS record configuration, and email server configuration to digitally sign outbound emails. |
|
Security considerations to remember |
DKIM relies on cryptography to ensure email authenticity. However, key size and rotation, or algorithm weaknesses, need to be taken into consideration as well. |
|
Protecting DKIM from attacks |
DKIM is not bulletproof to cyberattacks and misconfigurations. By following security best practices, performing regular security awareness training, and regularly reviewing your DKIM implementation, the damage from attacks or misconfigurations can be minimized. |
While SPF is known to have a wider adoption than DKIM, it does not provide the same level of security. SPF allows a domain owner to publish a list of authorized servers in DNS, so that receiving mail servers can check whether the sending server is permitted to send emails for that domain. However, it doesn’t guarantee the integrity of the email body or any email header. Furthermore, if emails are forwarded between mail servers, e.g., if you are using Salesforce, the SPF verification fails.
On the other hand, DKIM relies on cryptographic algorithms to “sign” email headers and the body to guarantee email authenticity and integrity. Even if your email infrastructure changes or emails are legitimately forwarded, the email signature will still be valid, and the recipient can always verify its validity, regardless of the IP that sent the email. That is why, while we recommend implementing both protocols for a defense-in-depth approach, you should consider these key differences before choosing one.
Here is a technical step-by-step guide on how to set up DKIM from scratch:
DKIM relies on public-key cryptography to work. All algorithms in this field of cryptography require a public and a private key pair for different cryptographic operations. There are several packages or software in Linux and Windows that can help generate such keys for you. For our example, below, we use OpenSSL to create a 2048-bit (key length) RSA public and private key.
|
# Generate a 2048-bit private key |
These OpenSSL commands will store the 2048-bit private key in the dkim_private.key file and the 2048-bit public key in the dkim_public.key.
Since the public key in dkim_public.key file is surrounded by a header and a footer, e.g., -----BEGIN PUBLIC KEY-----, you will have to extract the public key part either manually or using this Linux command:
|
awk 'NR>1 && NR<NF {printf "%s", $0} END {print ""}' dkim_public.key | sed 's/-----BEGIN PUBLIC KEY-----//; s/-----END PUBLIC KEY-----//' | tr -d '\n' |
You need to base64-encode the public key first to avoid any misinterpretation of the special characters the public key might contain. There are several ways to base64-encode a string, e.g., on Linux:
|
echo "<public_key_from_step_2>" | base64 |
Create a DNS TXT record for your domain following the following syntax: <selector>._domainkey.<your_domain>. For example, if your test domain is “example.com” and we name the selector dkimTest, your DNS TXT record should look like this:
|
dkimTest._domainkey.example.com |
Set the value/content of the DNX TXT record to the following:
|
Name |
Type |
Content |
TTL |
|
dkimTest._domainkey.example.com |
TXT |
v=DKIM1; k=rsa; p= <base64_encoded_public_key> |
6000 |
Note that you can alternatively use a DNS CNAME record as well. However, RFC 6376, the core standard for DKIM, specifies the use of TXT records for this purpose.
Configure your mail server to send signed emails for your domain. For this, several things need to be configured, e.g., the secure storage of the private key. The exact location will depend on the mail server software you use, e.g., for Microsoft Exchange Online, you can follow the Microsoft documentation on how to do it.
Specify the configuration for the DKIM-Signature email header that the mail server appends to all signed outbound emails. This email header is required by the recipient’s mail server to identify the DNS TXT record that contains the public key, what part of the email was signed, and what cryptographic algorithms were used. Most mail servers or Mail Transfer Agents (MTAs) natively support DKIM and provide a GUI setup wizard or a command-line alternative for such configuration. For example, if your MTA uses the open-source OpenDKIM, you can specify the following configuration under /etc/opendkim.conf:
|
Domain example.com //specify your domain |
Every time an email is sent, the mail server will use the above configuration and will append the following DKIM-Signature to outbound emails.
|
DKIM-Signature: v=1; a=rsa-sha256; s=dkimTest; |
Email header list of fields:
|
Tag |
Purpose |
|---|---|
|
v=1 |
DKIM version number |
|
d= |
Your domain name |
|
a= |
Defines the cryptographic algorithm that was used for signing and hashing, e.g., rsa-sha256 |
|
s= |
The selector you created and placed as a subdomain in the DNS TXT record. |
|
h= |
Defines the list of email headers that were included in the signing process, e.g., Subject, Date, Message-ID, From, etc. |
|
bh= |
Contains a cryptographic hash of the email content/body. |
|
b= |
The digital signature of the email elements that were signed (i.e., certain email headers and the email body hash). |
|
l= |
This field is optional and, if specified, it defines how many bytes of the email body were hashed and included in the digital signature. |
Finally, perform several tests to ensure the configuration was successful and emails are correctly signed before using this configuration in production.
Since DKIM makes use of public-key cryptography, several security considerations should be kept in mind to ensure that DKIM provides the promised cryptographic properties, such as authenticity or integrity:
For most cryptographic protocols, the size (and randomness) of the cryptographic key(s) is an essential factor for the algorithm’s strength. Using short-length keys increases the attack surface against the chosen algorithm and undermines the security. For example, some researchers managed to crack a 512-bit DKIM key by only spending 8$ in computing power. That is why, during cryptographic key generation, it is important to be aware of the key length and make sure you generate long keys that make cracking extremely hard.
Once a key pair is generated, it usually remains valid indefinitely. However, just as with passwords or API keys, a critical security best practice is to rotate cryptographic keys regularly. This way, even if the keys are compromised and you are not aware of it, old leaked keys will no longer be valid and abused to impersonate your domain.
It is recommended to perform a key rotation at least once a year and when the staff with access to such keys is changed. Note that, if you are using Exchange Online, Microsoft provides a PowerShell cmdlet to make it easier for email administrators to rotate the DKIM cryptographic keys for your domain.
Before an email is signed, the mail server generates the hash of the email body (or part of it). You should be aware of the fact that, while hashing algorithms are one-way functions that cannot be reversed, the risk of hash collisions exists. If an insecure hashing algorithm is used, a threat actor can attempt to find a malicious message that generates the same hash as the original message, compromising the email's integrity. To avoid this attack, we recommend using either SHA-256 or SHA-512, which are considered secure by today’s standards.
Even if you are using strong cryptographic material and a secure public-key algorithm, there are certain attacks that threat actors might attempt if you are implementing poor security best practices:
DKIM heavily relies on the secure storage of the private key that is used to sign emails. It is often the case that developers or IT unintentionally leak private keys or credentials in general on GitHub, forums, or social media. Like passwords and other credentials, private keys should be stored in a secure location and only accessible by authorized users. Otherwise, once the private key is leaked, a threat actor can abuse it and forge signed malicious emails until the private key is rotated, a process that may take years.
It is important to emphasize that you can specify more than one key pair for DKIM in separate DNS TXT records. If a threat actor manages to compromise your authoritative name server or the registrar that is managing your DNS records, they can create a new DNS record for DKIM, using a public and private key they control.
While your organization will continue to send signed emails without issues, the threat actor can do the same by using the malicious DNS records they created, successfully impersonating your domain. Regularly review your DNS records and ensure that no new, unusual/unexpected record exists, e.g., for DKIM.
Until around 2013, Yahoo! used the same DKIM selector (default) across many subdomains. If even one of these subdomains is compromised or delegated, a threat actor could register their own private key in a DNS record for DKIM. This allows the threat actor to spoof emails from the main domain, yahoo.com, even if the main domain's DKIM keys are secure. That is why it is recommended to use unique selectors per subdomain and avoid sharing the same DNS records for DKIM.
To ensure that your employees avoid making such mistakes that can undermine DKIM or the security of your organization in general, it is always recommended to perform regular security awareness trainings.
Compared to SPF and DMARC, DKIM is more complex to set up for email security administrators with limited cryptography experience. However, the resulting security benefits to email security, such as ensuring not only the authenticity but also the integrity of the email, are worth the effort. While this guide demystifies the initial DKIM setup, periodic maintenance and monitoring are required to ensure your DKIM implementation continues to follow security best practices.