Getting Email Delivered - the ISIPP SuretyMail Blog

DKIM Explained: How to Set Up and Use DomainKeys Identified Mail Effectively

   
Summary: DKIM (DomainKeys Identified Mail) is an important authentication mechanism to help protect both email receivers and email senders from forged and phishing email. Here's how to set up and use DKIM.
 
 

DKIM (DomainKeys Identified Mail) is an important authentication mechanism to help protect both email receivers and email senders from forged and phishing email. Forged email is a serious threat to all parties in an email exchange.

Unsuspecting recipients of a forged email are unaware that this legitimate looking email from their banking institution is really a clever phish that will steal their credentials and transfer all their money away.

On the other hand, senders are also hurt by when their domain is forged and used in phishing because it diminishes the trust in their real messages. After all, the recipients don’t have a way to verify that the message was actually sent from the real source.

Or do they?

Aware of this limitation 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” — a technique that essentially allows an author to create a signature allowing anyone to verify that whatever was signed wasn’t altered.

Seeking broader industry support, in mid 2005 a consortium of Internet companies submitted to the IETF (Internet Engineering Task Force) the draft “DomainKeys Identified Mail — DKIM” specification.

DKIM was a derivative work based on the work of Yahoo and Cisco, keeping backwards compatibility with the original DomainKeys published data, so as to ensure an ever-increasing adoption rate.

Since then, DKIM has been backed by the largest ISPs, who regularly employ its authentication results in their mail processing workflows. There’s no doubt that DKIM adoption is increasing and that it is important to achieve better levels of reputation and email deliverability.

In close relationship with DKIM, ADSP or “Author Domain Signing Practices” allow for a mechanism to signal the receiving ISP when a DKIM signature should be expected.

[NOTE: ISIPP SuretyMail can set up your DKIM and ADSP for you if you would rather not do it yourself. For more information about this service, contact us here.]

How does DKIM Work?

Public Key Cryptography uses a pair of keys to perform its magic. One key, the “Private Key”, is kept safe by the email author. It cannot be shared in any way because whomever has this key will be able to sign a message on behalf of the author.

That is, if someone had the DKIM’s Private Key for `isipp.com`, then that person could send out email claiming to be from `isipp.com` — this is a very delicate situation, which is why organizations employing DKIM to protect their email must be very careful about how the Private Keys are stored and used.

To accompany the Private Key, there is a “Public Key”. The Public Key permits anyone to verify that a signature made with the corresponding Private Key is valid (and the signed contents haven’t been tampered with). As its name implies, the Public Key is, well, public. This means that it must be disseminated as widely as possible.

DKIM uses DNS to publish the Public Keys, so that any party that wants to validate a signature can easily find the public key. When deployed in conjunction with DNSSEC, DKIM provides a very strong mechanism to assure the origin of an email. However, even without the benefits of DNSSEC, DKIM represents a step in the right direction.

When an author wishes to send an email to a recipient, they (their mailing software) calculate a crypto signature that covers the relevant parts of the message using the Private Key. The signature is then placed in an email header and the message is then sent normally by the mail server. At any point in travel, and possibly at the recipient’s ISP, the signature is validated using the public key. If any part of the message covered by the signature was tampered, the signature won’t validate and the recipient will be alerted.

Spoofed emails won’t carry a valid signature so these are now easy to detect. Using DMARC, it’s possible to help the ISP decide what to do with these messages that don’t pass validation, typically asking for their rejection and possible reporting to the legitimate organization for further investigation.

Ideally DKIM works behind the scenes to protect both the sender and recipient with very little effort.

Using ADSP (Author Domain Signing Practices)

ADSP allows an author — by which we include the domain appearing in the right hand side of the `From:` address of the email — to specify one of the following signing practices:

* `unknown`: The domain might or might not sign the email it originates.

* `all`: The domain signs all the email it originates using DKIM.

* `discardable`: In addition to `all`, this value requests the recipient ISP to discard email from the domain with no valid signature, for whatever reason.

You can read more information about the ADSP records and semantics in RFC-5617

Setting Up DKIM

[NOTE: ISIPP SuretyMail can set up your DKIM and ADSP for you if you would rather not do it yourself. For more information about this service, contact us here.]

Nowadays DKIM is fully in production use and its user base grows daily as more sites start using it. Most email infrastructure elements (Mail Transport Agents, filters, etc) support DKIM directly or via software libraries or utilities that can be deployed. http://www.dkim.org/deploy/index.html 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 an email header as explained above. This could be an example of one such headers:

DKIM-Signature:
v=1;
a=rsa-sha256;
c=relaxed/relaxed;
d=isipp.com;
s=sel42;
t=1399817581;
bh=Pl25…dcMqN+E=;
h=Message-ID:Date:Subject:From:To:MIME-Version:Content-Type; b=Xp/nL93bv6Qo73K…KmskU/xefbYhHUA=

If you observe this header carefully you’ll note that it’s composed of fragments separated by a semicolon. 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 located at

._domainkey.

* `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.

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.

Publishing 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, must be rotated out of use periodically to limit the probability 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 the keys.

DKIM Key Rotation is actually very simple thanks to the introduction of the key selectors (the `s=` fragment in the DKIM Signature header). The key selector allows introducing new keys at any point, maintaining the old keys around for a prudent period of time so that all in-transit messages have time to be processed and delivered.

As mentioned below, DKIM Public Key data is published in the DNS. It’s typically published as TXT records that look like this:

selector._domainkey.isipp.com IN TXT “v=DKIM1;p=MIG…QIDAQAB”

Where the following parts are defined:

* `v=DKIM1`: This optional fragment identifies the record as a DKIM version 1 public key.

* `p=MIG…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 to 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 on your behalf. These signatures will appear legitimate to third parties as long as the DKIM public keys are published in the DNS.

In general, you should make sure that all 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 tapes 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 the 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.

[NOTE: ISIPP SuretyMail can set up your DKIM and ADSP for you if you would rather not do it yourself. For more information about this service, contact us here.]