Note: This is the third in a four-part series explaining the basics of email authentication. See the other posts:
DomainKeys Identified Mail (DKIM) is one of three key standards enabling email authentication.
Unlike SPF, which uses rule sets to determine authorized IP addresses, DKIM uses public key cryptography to authenticate individual email messages.
Think of it as a mathematical way for a sender to sign a message, and for recipients to verify who it was signed by.
DKIM: Under the Hood
Here’s a somewhat more technical explanation: With DKIM, the server sending an email message digitally signs the message in a way that cryptographically combines the contents of the message (including its main headers) with a secret, private key that only the sender has access to.
The domain owner authorizes this private key by placing the corresponding public key in a DNS record at a location specified by the message’s DKIM header, which includes a domain name and a “selector” (a domain prefix).
The result is a string of characters (the signature) that the server attaches to the message, along with details about which private key was used to sign the message (the domain and selector).
Receiving servers use DNS to retrieve the public key found at the indicated domain and selector, then use that key to decrypt the signature and validate that it matches the message. If there’s a match, then the message hasn’t been tampered with since it was signed, and the recipient knows exactly which domain and selector it was signed by.
Using DNS allows domain owners to authorize specific senders, by placing public keys in separate selector records (so a single domain could have many selectors, each one for a different sender). It also makes it possible for any recipient to validate DKIM signatures by accessing DNS and retrieving the corresponding record.
Here’s an example of a DKIM signature header:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :cc:to; bh=ioNDMhThwg3kEHqhQd5AFfgAGXl9Hj/wFRM/2J5DLQg=; b=h/aJ+Vt1e1zI1t0xUKklCzweu5BfN5hNKp0RNuYwNNmIvIPLdUpshRIHReOuppFCb5 23aH6BRKHH+bMjEODLNL3uE8zSlV72r01nexFsOvLBywj5GfO29lFsLpDKTvtKq8W0Pf JF15GVwuT2sfqnoIDu3syZ72NLrJc1kdN98DFE7dSSB2M2c2CDWFUxtamKln+PPLBGUA 6+81raWC4vH/PQjGvXLQR2lrzjPz4kMUpNyx38+LGBQcoxxYgCtI4mDIbIFLwymgZkfw 24c/1x8Zw26IkLjDxZ7pFAzUSbkHVEJTnyL57v+Z/Tm20Kzjqkb9FgtkjwZcQXMae8oD 9HSA==
In this header, the d= line indicates the domain and s= indicates the selector that mail servers will use to find the appropriate DKIM key. The list of headers covered by the signature is shown by h=, while bh= is the signature covering those headers. Finally, b= is the digital signature for the message body.
Notably, the domain used to sign a message doesn’t have to match the domain name shown in the message’s From address. It could be any domain — as long as that domain has published a DKIM record in DNS. All the sender has to do is indicate which domain and selector it’s using in the DKIM header of the message.
Advantages of DKIM
When DKIM was created, it was intended to be an anti-spam tool, not an anti-fraud mechanism. The goal was to verify who actually sent a message, so, for instance, you could reliably trace a message back to SendGrid, no matter which client SendGrid was sending it on behalf of. In this goal, it succeeds.
Because the DNS system is globally distributed and well-secured, this gives DKIM signatures provable authority: Only the owner of a domain can sign messages for that domain.
Also, DKIM signatures can survive forwarding: If the contents of the message are not altered, the DKIM signature will still work. (This is not true of SPF authentication.)
DKIM also guarantees that the contents of the message have not been altered, because the signature is based on the message body as well as key headers (such as From, To, and Subject). As a result, if you trust the entity that signed the message, you can trust the contents. An altered message’s DKIM signature will no longer authenticate properly.
Shortcomings of DKIM
DKIM is not particularly effective against email fraud, or phishing, on its own.
To stop phishing, the most important address is the domain in the From field. This is what humans use to determine who or what a message is coming from. DKIM has nothing to say about this, by design. The domain used to sign a message could be completely different from the domain shown in the From field.
In other words, devious people can create messages that appear to come from someone you’d trust, such as your bank, because they show the bank’s email address in the From field, but which are signed via DKIM using a domain controlled by the hackers. Most people are not going to dig into the message headers of all inbound messages to verify that the DKIM signature details look like something legitimate. (And even if they did, it’s unlikely that they’d be able to tell a legitimate sender from a malicious one, given the large number of legitimate email-sending services that are not household names.)
A second problem is that the security of the system depends on the secrecy of the private key used to sign messages. If a hacker were to get ahold of a domain’s private key, he or she could start signing messages as that domain, and they would pass DKIM validation perfectly. Worse, the domain owner might have no idea that this is happening, because DKIM signatures don’t require any kind of connection to the servers controlled by the domain owner. Such attacks could be executed from anywhere in the world.
By contrast, SPF authentication can only be spoofed by hackers who manage to gain control of the specific IP addresses listed in a company’s SPF record. For all practical purposes, that would mean taking over a specific server — the kind of security breach that would eventually be much easier for the owner of that server to detect.
This weakness leads to a third issue with DKIM: the complexity of public key management. In order to maintain consistent security and forestall damage from private-key theft, organizations should update (or rotate) their DKIM keys on a regular basis. That and other issues prove to be maintenance hassles that most organizations don’t bother with.
For large email service providers (ESPs), it’s tempting to use a single DKIM key for all of their customers, but that means theft of a single key compromises all of the ESP’s customers.
Solving DKIM’s Limitations
In combination with some necessary additions, DKIM is an effective component of a comprehensive anti-spam and anti-phishing solution.
First and foremost, the open DMARC standard incorporates DKIM and combines it with SPF authentication to achieve a far greater level of protection than either offer on their own. One big advantage of DMARC: The policy specified in a DMARC record can ensure that the DKIM key’s domain and the domain shown in the From address are “aligned,” i.e. that they match. This prevents phishers from using a bogus domain in the From address while signing the message with an unrelated domain that they control. Neither DKIM nor SPF alone can do this.
Better DKIM key management is also needed to provide true security and protection. Currently, email senders need to understand the significance of different DKIM key lengths (longer keys are more secure). They need to track the age of specific keys so they can rotate them regularly. In many cases, this is not happening. And while senders could manually create individual DKIM key records for each email service they use, they often don’t, meaning all services use the same key, making tracking impossible.
As with most aspects of email authentication, automation can help to address many of the limitations that make DKIM difficult to implement in practice.
ValiMail helps companies with DKIM management and with setting up an effective DMARC policy incorporating DKIM. To find out more, request a demo today.
SPF and DKIM are key parts of an email authentication program, but they aren't complete without DMARC. Find out why in the final installment of our series: What Is DMARC?