Let us help YOU get to the inbox like we've helped these others!
Of the current email authentication mechanisms, SPF, DKIM, and DMARC, DKIM seems to be the most confusing for people. What is a DKIM selector? What are the DKIM tags? How does one create a DKIM record? Is there a good DKIM record generator? Here is a plain English explanation of DKIM, and a breakdown of the anatomy of a DKIM record.
DKIM, which stands for DomainKeys Identified Mail, is one of the three major authentication mechanisms which help to protect email receivers from accepting forged (spoofed) email, and which help to protect email senders from being spoofed. Without such authentication mechanisms, unsuspecting recipients of a spoofed email can be blinded to the fact that a legitimate-looking email that seems to be from their banking institution is really a cleverly disguised phishing email that will steal their credentials and transfer all their money away. When email first became available to everyone, it was really pretty easy to spoof an email like this.
About 20 years ago, concerned about of this vulnerability in the architecture of email, two proposals took shape: Yahoo’s DomainKeys and Cisco’s Identified Internet Mail. Both proposals were based in the use of public key cryptography, which in this context is a method that enables the author of an email to create a verifiable signature that allows anyone to verify that whatever was signed with that verifiable signature wasn’t altered. Looking for broad industry support, in mid-2005 a consortium of Internet companies submitted to the IETF (Internet Engineering Task Force) the draft for the “DomainKeys Identified Mail – DKIM” specification.
DKIM evolved from the works of Yahoo and Cisco, and kept backwards compatibility with the original DomainKeys published data, so as to ensure an ever-increasing adoption rate. Since then, DKIM has been supported by the largest ISPs and mailbox providers, who regularly include its authentication results in their mail processing workflows and, importantly for you, in their inbox placement and spam filtering algorithms.
In conjunction with DKIM, something called ADSP or “Author Domain Signing Practices” was created to allow for a mechanism to signal to the receiving ISPs and inbox providers that they should expect to see a DKIM signature from the sender. As DKIM.org explained it at the time, “Author Domain Signing Practices (or just ‘practices’) consist of a machine-readable record published by the domain of an author which includes statements about the domain’s practices with respect to mail it sends with its domain in the From: line.”
As you may have guessed (although it’s ok if you didn’t, we get that a deep dive into this stuff isn’t everybody’s cup of tea), ADSP has been absorbed into and replaced by DMARC.
How exactly does DKIM Work?
DKIM takes advantage of public key cryptography (hence the ‘K’ in DKIM). Public key cryptography uses a pair of keys to perform its magic. One key, the “private key”, is kept safe by the administrator of the email author’s email server. It cannot be shared in any way because whomever has this key will be able to sign email messages on behalf of the author; in other words it allows them to claim to be the author who actually holds that private key.
For example, if someone got hold of the DKIM private key for `isipp.com`, then that person could send out email claiming to be from `isipp.com` – this would essentially be stealing ISIPP’s email identity, and this is why organizations must be very careful about how their private DKIM key is stored.
The counterpart to the DKIM private key is the DKIM public key. The public key provides anyone with the means to verify that a signature made with the corresponding private key is valid, and that the DKIM-signed contents haven’t been tampered with. As its name implies, the public key is, well, public. This means that it can and should be disseminated as widely as possible. To publish and disseminate the public keys, DKIM uses DNS. This means that any party that wants to validate a signature can easily find the public key in the sender’s DNS records.
(Note that when DKIM is deployed in conjunction with Domain Name System Security Extensions (DNSSEC), the combination of DKIM plus DNSSEC provides a very strong mechanism to protect against spoofing, and so this is considered best practice for organizations such as financial institutions that are likely to be spoofed. DNSSEC also uses public key cryptography, as well creating a “chain of trust” to confirm the ownership and contents of a DNS record. However even without DNSSEC, DKIM is an effective authentication mechanism.)
DKIM from Send to End
When an email sender whose email sending system has DKIM set up hits ‘send’ on an email, their email sending program calculates a cryptographic signature using their private DKIM key. That cryptographic signature is inserted in the outgoing email header, and the message is then sent on to the recipient. At any point along the way any of the email servers through which that email passes can validate that signature using the public key, as can of course the receiving system at the other end. If any part of the message covered by the signature seems suspicious, the signature won’t validate.
This means that spoofed email won’t authenticate, because it does not carry a valid DKIM signature. Using DMARC, it’s possible to tell the receiving system what to do with email messages like this that don’t pass validation; typically you would tell the receiving system on the other end to reject a non-validating message.
How to Set Up DKIM
At this point you can read on to learn all the details of how to set up DKIM and how to create a DKIM record for yourself. Or, if you prefer, you can check out EasyDmarc.com’s free DKIM generator wizard here.
Most email infrastructure elements (Mail Transport Agents, filters, etc) support DKIM directly or via software libraries or utilities that can be deployed. DKIM.org has an up-to-date list of tools that can be used for deployment using a variety of elements.
Regardless of your mail sending architecture, outbound messages will need to pass through a filter that will generate the corresponding signature and store it in the email header as explained above. This is an example of one such set of headers:
As you can see, this DKIM header is composed of fragments separated by a semicolon. These fragment are also known as “tags”, and the purpose of each fragment is as follows:
* `v=1`: This indicates the DKIM version in use. For the time being this must be “v=1”.
* `a=rsa-sha256`: The algorithm suite that was used to generate the crypto signature. The current specification defines `rsa-sha1` and `rsa-sha256`. The latter is recommended. Note that while the specification leaves room for defining other algorithms, using an algorithm not known to an ISP negates the effect of using DKIM in the first place because the recipient is required to ignore unknown signatures.
* `c=relaxed/relaxed`: The “canonicalization” scheme used to pre-process the headers prior to calculating the crypto signature, to protect against small (and normal) transformations that the headers could be subjected to in transit, such as line folding. The specification provides for two algorithms: “simple”, which means don’t change headers in any way; and “relaxed” that normalizes the headers dealing with character case, whitespace folding and line breaks to try and be more robust when headers are changed in transit. Note that the `c=` fragment defines two algorithms. One is used for processing the headers covered by the signature, the other is used for processing of the message’s body.
* `d=isipp.com`: The domain name of the organization that claims responsibility for issuing this DKIM signature – in this example that is isipp.com. Typically the signing organization is either the ESP sending on behalf of a customer or the email author (domain) itself. Note that a sender responsible for various mail streams can use separate signatures thanks to the “selector”, discussed below.
* `s=sel42`: The “selector” used to find the corresponding public key to validate the signature. The DKIM validator will fetch the public key by issuing a DNS query for the TXT record for that sender. That DNS TXT record will be located at
* `t=1399817581`: The UTC timestamp of signature creation, expressed as the number of seconds since 00:00:00 on January 1st, 1970 (Unix Epoch time).
* `bh=Pl25…dcMqN+E=`: A crypto hash of the body part of the message. Note that an author can choose to protect only a part of the content, by using `l=` to specify the number of octets to consider for generating this hash. This is often used in scenarios where a very large number of signatures must be done and the processing cost of signing the whole messages is prohibitive. Note that by not covering the complete contents, it would be possible for the message to be tampered with without detection.
* `h=Message-ID:Date:Subject:From:…`: The colon-separated list of header lists that were signed. This allows the sender to omit headers that will be changed or stripped by expected mail handling while including headers that are relevant, such as message identifiers, source and destination address, abuse handling information, etc.
* `b=Xp/nL93bv6Qo73K…KmskU/xefbYhHUA=`: The crypto signature data itself, encoded in Base64 and possibly with whitespace inserted to conform to line length limitations.
If you want to get into the truly technical nitty-gritty, RFC-6376 §3.5 contains a detailed description of all the fragments and flags that can be added to customize the extent of protection that DKIM provides through its signatures.
How to Publish DKIM Public Keys
The first step towards publishing DKIM public keys is deciding on your key rotation schedule. Private keys, and the corresponding public keys, should be rotated out of use periodically to limit the possibility of a compromised or broken key being used. Common practice involves rotating the keys at varying intervals. Some organizations rotate keys weekly, while other organizations can go up to a year or more before changing their DKIM keys.
DKIM key rotation is actually very simple thanks to the introduction of the key selectors (the `s=` tag or fragment in the DKIM signature header). The key selector allows introducing new keys at any point, while keeping the old keys around for a prudent period of time so that all in-transit messages have time to be processed and delivered correctly.
As mentioned above, DKIM public key data is published in the DNS record. It’s typically published as a TXT record that looks like this:
selector._domainkey.isipp.com IN TXT “v=DKIM1;p=MIG..(big long strong of characters)..QIDAQAB”
Where the following parts are defined:
* `v=DKIM1`: This optional fragment identifies the record as a DKIM version 1 public key.
* `p=MIG..(big long strong of characters)..QIDAQAB`: This fragment contains the public key in Base64 encoding.
(RFC-6376 §3.6.1 contains a detailed description of all the fragments and flags that can be added to the DNS record.)
To add a new key, simply assign it a new selector and configure your DKIM signing component to start using the new key. As long as the old public key data remains in the DNS, all in-flight email will still pass validation. New messages will be using the new selector and therefore will validate using the newly added key.
It’s very important that whenever you add a new key record to the DNS, you verify that each name server is returning the correct data when queried for the new selector.
After a reasonable time – for example think about the largest interval that a message can sit dormant in a mail queue and then multiply it by 3 – you can safely remove old DKIM public keys from the DNS.
Disposing of Obsolete or Deprecated DKIM Private Keys
As explained above, if anyone is able to get a copy of your private keys, they will be able to sign messages as you. These signatures will appear legitimate to third parties as long as those DKIM public keys are published in your DNS.
In general, you should make sure that all previous copies of the private keys are destroyed. This includes backups and system images used for QA or other purposes. Sometimes overwriting the private key with zeroes and waiting for a full backup media cycle (i.e., when all forms of media have been overwritten with the new data) can be an effective method.
Once this process has completed, the overwritten private key can be removed.
The public key should be removed from your DNS as soon as the wait time for in-transit messages has elapsed. This ensures that even if an attacker got hold of the private key, they are unable to trick anyone into accepting forged messages.
It’s not considered good practice to keep copies of obsolete key material around, for any purpose. Keys must be destroyed after their lifecycle has expired to prevent misuse.