The DomainKeys Identified Mail (DKIM) email authentication standard enables email servers to check incoming emails to verify the sender and detect email message alterations. This standard solves the problem of determining if emails have been intercepted and modified in transit and helps to detect SPAM and spoofed emails.
By implementing DKIM, an organization improves the reputation of its own emails and enables receiving email servers to improve their own email security.
This article helps to understand:
- How Does DKIM Work?
- How to Set Up DKIM
- Testing if DKIM is Working
- DKIM Advantages
- DKIM Disadvantages
- DKIM FAQ
- Bottom Line
How Does DKIM Work?
At a high level, DKIM enables an organization to provide encryption hash values for key parts of an email. Using public-private encryption key pairs, receiving email servers can compare the received email hash value against the received hash value to validate if any alterations took place in transit.
A successful DKIM check also verifies ownership of the email by matching the organization in the “from” fields of the email with the DNS associated with the organization. Emails that fail to match DKIM hash values suggest possible alteration and may be rejected, quarantined, or marked as SPAM to caution the recipient.
DKIM Fundamentals
The Internet Engineering Task Force (IETF) publishes full information on the DKIM and its standards, which were last updated in 2011. DKIM deploys as text files in an organization’s hosted Domain Name Service (DNS) record, but the standard can be complex to deploy correctly and maintain. Fortunately, the complexity can be easily managed by understanding the different components and how they work.
Basic DKIM DNS Record Structure
The DKIM DNS record is very simple and conveys information both through the content of the record as well as the file name. The content will often look something like:
v=DKIM1; p=76E679F05F709AF665853833EEC3F5ADE69A2392BEBE40658267AB3BD3CB6CBE
Where “v” stands for version and always equal to DKIM1. The “p” field is the public encryption key value.
The file name will be in the format of <selector>._domainkey.<domain>. Selector indicates the version of the file, and the organization will have a different selector for each mail server. Domain is the domain of the organization. For example the filename nashville._domainkey.exampledomain.com is the nashville selector for the organization using exampledomain.com.
Basic DKIM Process
The DKIM process works in steps:
- The organization publishes the DKIM file with their DNS
- The organization determines which header fields to include in the hashing process as well as if the full body text or a portion of the body text should be hashed
- The sending mail server calculates the hash value of the selected fields and includes the DKIM information as the DKIM email signature (see below) in the email as it sends
- The receiving mail server or email gateway uses the included DKIM signature and the organization’s public encryption key (stored within the DKIM record on file with the DNS) to recalculate and verify the DKIM signature
As a caution, when determining the items to be hashed, the organization must balance exactness and usability. More fields and text will be more secure, but emails often will have minor changes made during the sending and forwarding that could cause a visibly exact and uncompromised email to fail the hash value due to extra spaces or line breaks.
See the Top Secure Email Gateway Solutions
DKIM Email Signature
The sending organization determines which fields of the email will be encrypted to create the DKIM hash string to be included with the sent email as a digital signature. The sending email server takes the text values of the selected fields and creates a hash string using a hashing algorithm, typically SHA-256. Once the hash string has been generated, the mail server uses a private encryption key to encrypt the hash string and includes the encrypted hash string within the email header as a DKIM email signature.
Typically, the organization will select the sending domain and portions of the body of the message to generate the hash value.
Example:
DKIM-Signature: v=1; a=rsa-sha256; d=sampledomain.com; s=nashville; c=relaxed; q=dns/txt; t=1117574938; x=1118006938; h=from:to:subject:date:keywords:keywords; bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ VoG4ZHRNiYzR
The component elements of this file include:
| Element and Value | Meaning | Mandatory Element? |
|---|---|---|
| v=1 | v=Version, always equal to 1 | Mandatory |
| a=rsa-sha256 | a=Signing algorithm. Although many algorithms can be used, mail servers may only support rsa-sha or rsa-sha256 | Mandatory |
| d= sampledomain.com |
d=Signing Domain Identifier (SDID) or the domain of the organization sending the email and the domain where the DNS and DKIM record will be found | Mandatory |
| s=nashville | s=Selector – a unique name for this DKIM file; when using multiple DKIM files the receiving mail server will search for the correct public key based upon the selector name | Mandatory |
| c=relaxed | c=Canonicalization algorithm; the values can be either ‘relaxed’ or ‘simple’; when calculating the hash value, should the calculation be simple and no changes to the email header or body should be tolerated, or should the calculation be relaxed and allow small changes to the way the header is wrapped or white space is treated in the email body | No, but recommended |
| q=dns/txt | q= query method used to retrieve the public key; by default, “dns/txt” which means a DNS query must be used and a text file (TXT) will be returned | Mandatory |
| t=1127574938 | t=timestamp, or when the message was signed | Mandatory |
| x=1168006938 | x=expiration of the DKIM; after this expiration date, DKIM will fail even if all other verification matches | No, but recommended |
| h=from:to:subject: Date:keywords: keywords; |
h=headers, a list of headers separated by colons in the email header included in the DKIM calculation; it is best to avoid header fields likely to be modified during transit | Mandatory |
| bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; | bh=the hashed message body after canonicalized using the hash function from a (above) | Mandatory |
| b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ VoG4ZHRNiYzR |
b=digital signature of headers and body hashed with the hash function from a (above); while this is the signature, all other DKIM information in the email tells how to calculate the signature hash correctly | Mandatory |
| i (not included above) | i = Agent or User Identifier (AUID) tag used when the default value of the SDID domain is preceded by the @ character | No |
| l (not included above) | l = length of the message body; value limited to no more than 76 decimal digits and specifies the number of bytes in the message body | No |
| z (not included above) | z = Copied header fields which would display all of the header fields and their contents separated by a vertical bar character (|) |
DKIM Selector
An organization’s DNS server will host a DKIM entry, or selector, for each email server in the organization. The unique selector name will be included in the DKIM file name as well as in the “s” tag in the sent email signature so that the receiving email server knows which DKIM entry to use in the DKIM verification process.
DKIM Key Rotation
As with any encryption use, the longer a key stays in use, the more likely it may be stolen or compromised. To reduce this risk, it is recommended to rotate keys (replace current ones with new ones) every four to six months.
How Do Mailservers Verify DKIM?
When an email arrives at the receiving email server with an encrypted DKIM signature, the header will be examined for the information regarding the fields used for encryption, type of hashing algorithm used, and the DKIM selector to check for the public encryption key. The receiving mail server then performs its own encryption of the noted email fields, uses the public key to decrypt the encrypted email signature hashcode, and looks for a match.
Matching DKIM hashcodes verify the integrity of the email and emails that pass this process will be delivered to the recipient. Hashcodes that do not match will be discarded, pushed to a SPAM folder, or flagged as suspicious depending on the settings of the email server.
Related Email Authentication Standards
DKIM provides authentication of the integrity of sent emails with a narrow scope. A more robust solution will also implement the SPF and DMARC authorization frameworks as well.
SPF: The Sender Policy Framework (SPF) authentication method designates the authorized mail servers that send email from an organization’s domain.
DMARC: Domain-based Message Authentication Reporting and Conformance (DMARC) enables more direct control over emails that fail SPF and DKIM and enables reporting on legitimate and spoofed emails.
How to set up Domain Keys Identified Email (DKIM)
Domain Keys Identified Email (DKIM) requires files added to the domain’s DNS server, encryption key generation, as well as changes to outgoing email servers.
Installing a DKIM Record With the Domain DNS
Adding a DKIM entry to a domain’s DNS consists of:
- Log into the domain registrar and click on the option to manage or configure DNS settings
- Find and click the ‘Add a New Record’ option and choose a ‘TXT’ record
- For the host name option, DKIM requires a unique ‘selector’ for the DKIM file name for each sending email server
- Each file requires the publishing of a public cryptography key; the key should be unique for each selector
Generating The DKIM Encryption Keys
There are multiple ways to generate a public key that can be used for a DKIM record. In many cases, an organization will find that their DKIM signature will be generated by the Mail Transfer Agent (MTA) application. For others, self generated keys may be required.
On Linux systems, a common approach is using the ssh-keygen tool, while on Windows, PuTTYgen is a reasonable option. There are also multiple online tools that can help generate the public/private key pair; one of the easiest is DKIM Core Tools.
DKIM Signer Setup On A Mail Server
The DNS entry for DKIM is only half the requirement. The other half is getting a DKIM signer setup on a mail server, which can be complex or difficult for many email systems.
However, many email providers publish guides to set up DKIM and some provide services to assist their customers. Samples of published guides include:
For companies that prefer to outsource, DKIM service providers and consultants can be found that will offer a variety of services from basic initial setup to ongoing management and encryption key rotation.
Learn more: DMARC Setup & Configuration: Step-By-Step Guide.
Testing if DKIM is Working
Once published, DKIM analyzers such as MXToolbox or Mail-tester.com can be used to check for errors. Test emails can then be sent to verify DKIM signature files.
Once the test message arrives, expand the email header. If the sender’s domain appears for both “mailed-by” and “signed-by”, the message was verified successfully with DKIM.
“Show Original” options can also be used to inspect the email header and observe the result of DKIM authentication. If it says ‘PASS’ and the domain address, everything works fine.
DKIM Advantages
Organizations that adopt DKIM can enjoy the following significant benefits.
Flags Malicious Content
Emails that do not pass DKIM raise red flags for receiving email servers that the received email may have been intercepted and the email content may contain spam content or even malicious content.
Impersonation Mitigation
The subset of email phishing attacks known as email spoofing attempts to impersonate legitimate organizations and deliver malicious content to victims wrapped in the authority of the impersonated organization. When deploying a properly configured DKIM, it becomes more difficult to impersonate the organization.
When any mail server receives a spoofed email, it will look for DKIM signatures and reject the spoofed email that does pass DKIM. This will help to protect the reputation of the company by blocking spam emails trying to use the organization’s brand. Additionally, this will help to block phishing attacks attempting to spoof the organization’s own employees — such as when a phishing attack attempts to impersonate the CEO.
Improved Domain Reputation
When an organization does not establish DKIM, email servers that receive the organization’s emails may flag or reject them because authenticity of the organization’s domain cannot be verified. Establishing DKIM improves the reputation of the organization’s domain and improves the deliverability rate of legitimate emails. The email service company Postmark disclosed a troubleshooting process that tangibly demonstrates how DKIM signatures enabled emails containing PDF documents to be delivered properly instead of routed to SPAM folders.
Survives Email Forwarding
The Sender Policy Framework (SPF) standard can validate the authorized email servers to send emails for the organization, but forwarded emails do not match the sending email server IP addresses and fail SPF. However, DKIM encryption algorithms survive email forwarding and can validate forwarded emails to prevent the content from being flagged as spam or spoofed.
DKIM Disadvantages
Although an important and useful standard to adopt, DKIM does present some challenges that need to be acknowledged.
Challenging to Maintain
Organizations need to regularly update their DKIM files to reflect changing email server information or to rotate encryption keys. Service providers can simplify the process, but will add additional costs to the DKIM adoption.
Domain owners should ideally track and rotate keys regularly, but some attempt to use the same key for all services, which makes tracking impossible and key rotation more difficult.
Incomplete Solution
DKIM only verifies the integrity of the email header and does not compare against the “from” email address presented to the user. If a phishing attacker creates their own DKIM encryption keys, a DKIM check can still pass as valid. To be more robust, SPF, DKIM, and DMARC should be used in combination to protect an organization’s reputation and validated emails.
Encryption Key Theft
Encryption keys can be stolen and an attacker that obtains an organization’s encryption key can sign emails as if they were the organization itself.
Poor ROI Measurements
Although an organization can recognize reputation improvements and more reliably deliverable emails, these benefits will be difficult to quantify for return on investment measurements. Additionally, the primary benefit of flagging malicious email content generally applies only to other organizations. Receiving email servers and email security tools use the DKIM record to block spam and phishing email, but outside organizations will enjoy the majority of the benefit from verified emails. While the investment is low to implement DKIM, the intangible ROI and other disadvantages explain why adoption isn’t higher than 13%.
Potentially Spoofable
DKIM can be adopted by any organization — even malicious actors and spammers. Since a DKIM check does not always include the “From” information in the body of the email, malicious actors can publish their own DKIM files to authenticate their spoofed emails or spam.
Requires Proper Email Server Settings
DKIM only works on email servers set up to check for DKIM or using email security tools performing the same task. Servers can easily skip DKIM checks and allow spam and spoofing emails to proliferate.
Server Overhead
Calculating the hash values and looking up DNS records will slow down email deliveries and consume server resources. Although not very demanding on an individual email basis, a large number of emails could result in significant server loads.
DKIM FAQ
How Does DKIM Encryption Work?
The sending email server determines which fields of the email will be encrypted. The private key of the sender’s domain is encoded in the digital signature of every sent email. A public key is stored with the Domain Name System (DNS) for download by any email server receiving emails with the encrypted digital signature. The DKIM signature encrypts the hash value for the email, but does not encrypt any component of the email itself.
Can a DKIM Signature Be Forged?
Although the public encryption key is available, a DKIM signature cannot be forged. DKIM is based on PKI (public key infrastructure), which means a pair of keys, one public and one private, are used. While the public key is published in the DNS record, the private key remains exclusive to the email service provider server. The secret private key is used to sign messages and the public key is used only for verification.
Does DKIM Provide End-to-End or Full Email Encryption?
No. DKIM provides an encrypted hash value in the DKIM signature, but does not provide any other encryption benefits. Organizations need to adopt other encryption solutions as needed.
See the Best Encryption Software & Tools
Is DKIM Similar to Other Message-Signing Protocols?
Message-signing protocols such as Pretty Good Privacy (PGP) andSecure/Multipurpose Internet Mail Extensions (S/MIME) enable users to authenticate the message body of an email. However, these protocols cannot address the authentication of the sender. DKIM authenticates both the sender and the content and fields of the email.
Bottom Line: Implement DKIM To Improve Email Delivery
DKIM email authentication gives receiving email servers increased confidence in the validity of the message and increases the likelihood that the message will be delivered as desired. While the standard can be time-consuming to maintain, the improved confidence alone should be reason enough for most organizations to implement DKIM, and the other benefits related to reducing spoofed emails, improved email forwarding, and impersonation mitigation simply help to justify the effort.
Read Next: What is Network Security? Definition, Threats & Protections
This article was originally written and published by Sean Michael Kerner on January 12, 2018 and updated by Chad Kime on May 24, 2023.
