DKIM, or DomainKeys Identified Mail, is a protocol used to authenticate email in order to combat mail spoofing and phishing attacks. For a more detailed description of phishing attacks please have at look at this post about DMARC.
This post is going to detail everything needed for you to get a complete understanding of DKIM and enable you to move ahead with your implementation. Let’s get started!
DKIM Protection Scope
When implementing DKIM we’re normally referring to the protection of outbound email: We implement DKIM to protect external mail systems from spoofing and phishing attacks that use our email domain name. In return this leads to an increased public trust in our email domain name. To protect your own users from spoofing and phishing attacks ensure that inbound email is doing DKIM and SPF checks as part of a broad protection suite.
DKIM is able to protect various parts of an email message from tampering but as a minimum it always protects the RFC5322.From address. This is different from SPF which protects the RFC5321.MailFrom address. Please have a look at this article to fully understand how RFC 5321 and RFC 5322 sender addresses relate to DKIM and SPF.
DKIM Signature
In order to protect your outbound email with DKIM you need to enable or implement software on your mail system. On most cloud mail solutions the DKIM signing component is already present and only needs to be configured. Follow the official guides to enable DKIM on Office 365 or Google Mail.
If you host your own mail system you may need to install DKIM signing as a separate component. To set up DKIM on Microsoft Exchange server you can find both paid versions and open source implementations.
Once set up, the DKIM software will generate a DKIM signature on all outbound emails according to the configuration of the DKIM component. The DKIM signature consists of a number of tags of which the most common are the following:
DKIM Signature Tags
| Tag | Description | Sample Value |
|---|---|---|
| v | Version of DKIM | v=1 |
| a | Hashing algorithm used for signing | a=rsa-sha256 |
| c | Canonicalization algorithm used to standardize header and body of message | c=relaxed/relaxed |
| l | Length of canonicalized body used to calculate body hash | l=1024 |
| d | Signing domain identifier (SDID) | d=observatory.dk |
| s | Selector (pointer to signing public key) | s=dkimselector |
| h | Defines what header elements are signed (colon separated) | h=mime-version:from:date:message-id:subject:to |
| bh | The hash value of the body truncated to l characters and canonicalized according to c | bh=Oc27asSN+js9bIMJp8kXahWrlfaZOrM0BWpoHJlD9MQ= |
| b | Signature value of the DKIM signature, generated by encrypting the selected headers (h) and the body hash (bh) using the private key | b=rlhLGKq4oIeIR8xd9ampWme0XNbn2oBRB+Wl2...BaRQ== |
For a more in-depth description of the tags please have a look at the DKIM standard RFC.
Asymmetric Cryptography and Digital Signature
DKIM provides both authentication and integrity of the mail message. It does so by utilizing asymmetric cryptography which depends on a public/private key pair.
The following illustration shows the relationship between the message hash computation (which is a fast operation) and private key encryption and public key decryption (both of which are slow operations):
The private key is secret and kept on the sending mail system and used to populate the DKIM signature tag (b). The public key is published via a DNS TXT record. Mail recipients can locate the public key by inserting “_domainkey” between the s tag and the d tag as found in the DKIM signature. E.g. if s=dkimselector and d=observatory.dk then the public key is published in the DNS TXT record “dkimselector._domainkey.observatory.dk”.
Signature Generation (Sender) and Signature Processing (Recipient)
Generation of the DKIM signature at the sending side involves two basic steps:
Processing of the DKIM signature at the receiving side involves the following steps:
Signature Validation
If signature validation is successful the following can be asserted about the mail message:
- Authenticity:
- We trust the sending domain to be in charge of their DNS records, therefore
- We trust the public key published in their DNS, therefore
- We trust any data encrypted with the corresponding private key to be authentic
- Integrity
- The message hash key encrypted by the sender private key is deemed authentic due to the above, and
- The sender message hash key matches the received message hash key, therefore
- The message sent and the message received are identical and the message has not been modified during transit
Wrap Up
Hopefully this gives you a thorough understanding of DKIM, the various DKIM tags, DKIM processing and how DKIM utilizes both hashing and public/private key pairs to ensure authenticity and integrity of email messaging.