DomainKeys Identified Mail (DKIM) is one of the core 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.
It can be used to prove not only that an email is from who it says it is from but also that the email has not been modified in transit.
DKIM consists of an encrypted hash value (also called a DKIM signature) that is placed in the headers of emails. A DKIM signature is associated with a domain and for DMARC purposes, the DKIM domain must be the same as the From address of the email.
The hash value is generated by the sending system using components of the email (Subject, date, From address, To address etc.) and the hash is encrypted with the Private key to generate an encrypted hash value.
When the recipient's email system receives an email with a DKIM signature, it will attempt to verify the email. Part of the information in the header is the components used to generate the hash. The receiving server will know from the email which domain the encrypted hash is associated with, the DKIM selector which is used to identify the proper key in DNS and the components of the email that were used to generate the hash.
The receiving server will then generate a hash using the same criteria as the sending server. The receiving system will then do a DNS lookup to find the Public key associated with that DKIM signature. The receiver will decrypt the original hash value from the email header using the public key and if the hash it generated matches the decrypted hash value from the email, the email is successfully authenticated.
More Detail on 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.
DKIM Limitations
While DKIM is an effective component of a comprehensive anti-spam and anti-phishing solution, on its own it falls short of being a singular solution. Furthermore, it presents significant management overhead 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 from 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. DKIM best practices strongly suggest that domain name owners rotate (update) their DKIM keys on a regular basis (Public Key Management). 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.
DKIM in Authenticate
By adding an NS record for all your DKIM keys at once, you are telling inboxes to check for DKIM keys with Valimail. You can then manage your keys through Authenticate, where they are easy to see and associated with the senders that use them.