DomainKeys Identified Mail (DKIM) is the second of three Internet standards that enable email authentication. Like Sender Policy Framework (SPF), DKIM uses DNS to store information used to validate email senders. However, DKIM uses public key cryptography to perform the authentication instead of relying on IP addresses of authorized servers, as SPF does.
Established in 2007, DKIM was created to block spam and address some of SPF’s shortcomings. It allows receivers to verify the sender’s identity — and guarantees message content has not been altered. And unlike SPF, DKIM is compatible with most email forwarding services.
How it Works
- For each authorized third party sender, domain name owners publish a DKIM record to the Domain Name System (DNS) containing their domain name, a domain prefix, and a public cryptographic key.
- To authorize third-party senders, domain name owners provide them with a private cryptographic key, corresponding to the public equivalent.
- For each outgoing message, the sender adds:
- A DKIM header specifying the DKIM record location in DNS
- A cryptographic digital “signature” that mathematically encodes the message body and headers using the private key.
- Using the location in the DKIM header, receivers of a DKIM-signed email:
- Go to the DNS address specified in the DKIM header to retrieve the public key
- Decrypt the signature using the public key, which enables them to validate that the message headers and body are unchanged.
While DKIM is an effective component of a comprehensive anti-spam and anti-phishing solution, on its own it falls short. Furthermore, it presents significant management overhead and lacks necessary automation to be effective. Limitations include:
DKIM-Signature vs. From Addresses — DKIM tests use the domain name specified in an email’s ‘DKIM Signature’ field, which is hidden to readers, and not the visible ‘From’ address. This allows bad actors to use a fake domain in the visible ‘From’ address while using their own hidden, DKIM address to sign the message.
Private Key Loss — DKIM relies on an authorized sender’s safekeeping of private keys. If obtained by a bad actor, private keys can be maliciously used to sign messages and pass DKIM tests. Furthermore, domain owners would likely not be aware of this malicious activity as DKIM does not require any notifications to the domain name owner.
Public Key Management — Because of the risk of losing control over private keys, DKIM best practices strongly suggest that domain name owners rotate (update) their DKIM keys on a regular basis. This requires significant administrative overhead most companies don’t perform — especially if it involves distributing that key to all the third-party senders who need to be authorized.