DKIM

TL;DR

DomainKeys Identified Mail (DKIM) is a method to cryptographically sign email. The goal of DKIM is to reduce email spam and fraud. Email services use DKIM as one of the methods for determining the authenticity of an email.

With DKIM the sending email service adds a cryptographic signature to the email headers using the sender's private key. This signature is used by the receiving service to determine if the sender, and the email content, are to be trusted.

The domain willing to use that email service (that's you) publishes the public key of the sender in the DNS of the domain. By doing so you indicate to the receivers that a sender that holds the corresponding private key is to be trusted to send email for the domain.

DKIM is considered an improved mechanism over SPF because it also protects the email content from tampering, and it doesn't suffer from the problems with email forwarding that SPF has.

Cryptographic signatures

To understand how DKIM works, you first need to understand what cryptographic signatures are, and how they work. If you are already familiar with cryptographic signatures and Public Key Infrastructure you can skip this segment.

A cryptographic signature is different from a 'human' signature.

A human signature is a handwritten scribble (like someone's name, or even an 'X'). If placed on a document, it proves (to certain extent) the identity and intent of the signer.

A cryptographic signature is a (very long) number that uniquely and mathematically matches the information that was signed. The signed information can be anything that can be digitally represented, such as a document, email or financial transaction. The cryptographic signature proves identity and intent of the signer, and also authenticity of the signed information.

A cryptographic signature is created by applying a mathematical function on the information to sign in combination with a cryptographic key. The key consists of two parts (represented as long numbers) that are mathematically linked to each other. One part is called the private key, it is meant to be kept secret by its owner. The other part is called the public key, and like the name suggests it is public (not secret) information. Here comes the clever bit: a cryptographic signature can only be created with the private key, but it can be validated by anyone with the public key.

You can sign a document with a private key, and publish the resulting signature along with the document and the public key. Anyone can use the public key to validate that the signature was created with the corresponding private key. This scheme is called a Public Key Infrastructure (PKI), it allows for anyone to validate a signature without needing access to the private key.

Unlike a human signature, a cryptographic signature is unique to the information that is being signed. For every document and key combination there will be a different and unique signature. If a single letter in a signed document was to be changed, the signature would no longer be valid for that document. This means that a cryptographic signature can be used to check if a signed document is authentic, thus has not been tampered with. This also makes copying a cryptographic signature pointless, as it will only be valid for the original email.

DKIM

DomainKeys Identified Mail (DKIM) leverages Public Key Infrastructure (PKI) to cryptographically sign email. The signature proves that the email is authentic and that the sender was authorized to use the domain name in the sender address. DKIM is defined in RFC6376.

To use DKIM, an RSA key pair is created by the service that sends the email. This can be an on-premise email service, but also a third party cloud service such as Microsoft 365 or Mailchimp. The private key is kept secret by the sending service, but the public key is shared with anyone willing to implement this service.

A domain administrator publishes the public key of the sender through DNS as a DKIM record. By doing so, the domain is allowing the sending service to use that domain as the sender address.

The sending service automatically adds a cryptographic signature to every email that it sends using the private key. Any email service receiving the email will request the public key through DNS, and validate the signature using that public key.

If the signature is valid, it proves that:

• The sending service is authorized by the domain to send email on behalf of that domain.
• The email is authentic (not a single letter in the email was changed during transport)

By publishing a DKIM record in a DNS zone, the domain is saying "Any email service that holds the private key that corresponds to this public key is allowed to send email for this domain."

By adding a DKIM signature to an email, the sender is saying "Here is proof that I have access to the private key"

By validating a DKIM signature of an email, the receiver is saying "I have found proof that this email is authentic and the sender was authorized to send email for this domain"

The DKIM DNS record

The public key to validate the DKIM signature is published in a DNS record for the domain. A DKIM record is of type TXT and must be placed at address [selector]._domainkey.[domain]. The selector is an identifier for the DKIM key, more about this later.

A DNS query on [selector]._domainkey.[domain] may only result in 1 TXT type record maximum. If you have multiple keys, you can publish each corresponding public key with a different selector. That way different private keys can be used to sign the email. For example: You can have a key for an on-premise email service and one for a third party such as Mailchimp.

DKIM keys are not meant to ever change. If you need to use a new DKIM key, you should use a new selector also. Because DKIM records never change they can have a high time-to-live (TTL) value. A TTL of 1 day (86400 seconds) or more is not uncommon for DKIM records.

Here is an example of a DKIM record:

google._domainkey.mailhardener.com. 86400 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAgAF0AKrnAY2oscOh7jlBBPJDHgWO/HR/TxPr18yG6uFs3jVLkz1qZpI0QJX90aVnpPiu1C+6MZzUwzYYY/f8g8rVGxwj2D/anjih4sKUFmun2IluFiS93RcPZXYWNXor4gALdsdAVB7ak4/30l0uVAU3OEwFX77yWNT6BDSiobfpKMDG4TV4iZiohOlc1gHHX" "HYbLbcQ1uM9CLPkuqHKQkudLjvAbvl0eqDtAzThAahsmhl5Lc7Qru1SJShv47RxzIxShBL6MGTxEGiIR09244oQf++CmKCT8TPxptT/Y6mrLO5+t//dlvSVLsrKhF6xqZWwSOL0pskJiDdqDAxDGQIDAQAB"

We have a DKIM record validator tool available here, you can use it to inspect and validate a DKIM DNS record.

Field specification

The following information can be placed within a DKIM record:

The selector

Every DKIM record must have a unique identifier known as the selector. The selector is part of the address that is used to query the DKIM record in the DNS. A DKIM signature in the headers of an email will also contain this selector, so the receiver knows where to query the DKIM DNS record.

Since the selector is used as the DNS name of the DKIM record, it can contain only characters that are valid for a domain name. So a maximum of 255 characters containing letters, numbers and hyphens (-).

Spaces, dots, and underscores are not allowed. As with all DNS names, a selector is not case-sensitive.

Because the v=DKIM1 part in the DKIM record is optional (unlike, for example, the version indicator in a DMARC record), there is no way for a validator to distinguish a DKIM record from any other TXT type DNS record. It is therefore required that a DNS query on the selector address yields no more than one TXT record.

The DKIM signature header

An email message consists of 2 parts:

• Metadata on the sender, receiver, etc. These are known as headers.
• The actual email contents, known as the body.

The headers contain information such as the date, subject, return address and more. The headers are used by email services and clients to process the email. Most email programs will hide the headers from the user.

When using DKIM, a DKIM-Signature header is added to the email that contains the DKIM signature, and other implementation details instructing the receiving service on how to validate the signature.

The DKIM header is added to an email by the sending service. An email message may contain more than one DKIM header, as an email can be signed by multiple parties and by multiple keys.

Here is an example of an email with a DKIM header:

From: John Doe <john@example.com>
To: example@mailhardener.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 
    d=example.com; h=subject:from:to; 
    s=selector1; bh=edgxW+m2NmYw6Pxq6wY+B9YA+Z8SvmZ+y5zRCKxm6ik=; b=ClVxK8f
    QZzK9147Bc/s4wrvS0VZCpdDuwTvGWzj/cWCjiDsY/Y3ShRnsv/2lTe0nXW01OB7
    hanPe3VEm1fuR0wV+G8ODeiV43NuELKVwWvhZD7Rb0B7SlBWpPBuJH6A+q8i+rwe
    61p6Ay5Ff6EMGnqeHS/RiRZqa8rjViLXUQkM=
Subject: This email is signed with DKIM

This is an email signed with DKIM

In the sample email message the DKIM header was added by the sender in order to prove that the service that sent the email was really allowed to send email on behalf of example.com.

The DKIM header contains the domain name d=example.com, and the selector s=selector1. This means that the receiver is supposed to query the DNS service for a DKIM TXT type record at selector1._domainkey.example.com.

The bh field contains the BASE64 encoded hash digest of the email body. The h field indicates which headers of the email were also included in the signature input. The a=rsa-sha256 indicates that the SHA256 hash function was used to create the digest. Finally, the b field contains the BASE64 encoded RSA signature.

Field specification

Here is the full list of fields that can be used in the DKIM-signature header:

SHA1 deprecation

To create a cryptographic signature, the email contents are first ran through a hashing function, which outputs a hash digest. This is a fixed length value that is (or should be) unique to the message content. In a well-designed hashing method, when a single letter in the email is changed, the hash digest should change completely, this is known as the 'avalanche', or 'waterfall' effect. With a good hashing method, it should also be unfeasible (impossible) to find an input (other than the original email message) that would hash to the same digest, this is known as finding a 'collision'. With these two properties of a hashing function, it should be impossible to craft an email with a valid DKIM signature without having access to the private key.

At the time when the DKIM standard was drafted, SHA1 was widely accepted as a cryptographically strong, collision resistant hashing method. As such, SHA1 was selected as one of the supported hashing methods for DKIM.

However, in the years following the release of the first DKIM standard, researchers found weaknesses in SHA1 that would allow for calculating collisions. With a collision, it is (in theory) possible to craft an email message that matches a known good signature, meaning that you can send DKIM valid email messages without access to the private key.

Due to this weakness, SHA1 is now widely regarded as cryptographically unsafe. SHA1 is therefore deprecated, meaning that it should no longer be used for any application.

Within the scope of email, there are many legacy systems that may still sign with SHA1, so it is recommended that DKIM validators should still accept SHA1 hashes. For DKIM signers, it is strongly recommended to use SHA2-256 as the hashing method.

It is possible for a domain to force rejection of SHA1 based DKIM signatures by adding h=sha2 to the DKIM DNS record. This indicates to DKIM validators (the receiver) that only SHA2 based hashes are acceptable for this key. But, the DKIM signer (the sender) is still the one who dictates which hashing method is used, though they should no longer use SHA1 due to its deprecation, they may still be using SHA1 for legacy reasons. So, before adding h=sha2 to a DKIM DNS record, it is recommended to contact the vendor of the sending service first, to verify that they are using SHA2 exclusively.

Debugging DKIM issues

Debugging DKIM issues can be frustrating, as email services (by design) do not give feedback when email is rejected.

If you are experiencing DKIM related issues with one of the services you are using to send email on behalf of your domain, there are some simple steps to take to debug the issue.

The easiest method is by sending yourself an email from the service you are experiencing problems with, then inspect the email headers using your email client.

1. Verify that the sender address (in the From header) is actually set to your domain. This means that the part of the sender address after the '@' sign must match your domain.
2. Verify that at least one DKIM-Signature header has your domain in the d= section of the header.
3. Verify that the correct selector is used in the s= section of the DKIM-Signature header found in step 2.
4. Verify that the DKIM selector exists at [selector]._domainkeys.[yourdomain], and that it is a valid DKIM record. You can use our DKIM record validator to verify the record is valid.

Most inbound (receiving) email services will add debugging headers to the email before delivering it to the inbox. Check if you can find a Authentication-Results header, it should contain information on SPF, DKIM and DMARC results, and whether the validation has passed or failed.

Note that a DKIM header may be found valid, but that does not necessarily imply the email is DKIM aligned, see more about DKIM alignment in the section below.

DMARC DKIM alignment

As DKIM is optional to use in email, a malicious sender may just send email without a DKIM-Signature header, or just send the email with a DKIM-Signature for a domain that they control.

To mitigate this weakness in DKIM, DMARC may be used to mandate that any email received claiming to be from your domain, must be at least SPF or DKIM aligned.

DKIM alignment means that there must be at least one DKIM-Signature with the d= value set to the domain that is used in the RFC5322.From address (in the From header).

An email containing a DKIM header for a different domain than the one used in the From header is considered DKIM verified, but not DMARC aligned.

Example: An email with a From: info@mailhardener.com header, that has a valid DKIM signature with d=attacker.com is not DMARC aligned, even though the DKIM signature is valid.

Advantages of DKIM over SPF

As explained in our document about SPF, SPF is also used to authorize an SMTP service to send email on behalf a domain. So why use DKIM, if SPF is much easier to set up?

• DKIM proves the authenticity of the email, so the email was not changed in any way while in transit.
• DKIM signatures stay intact when emails are automatically forwarded. Forwarding does not break DKIM like it does with SPF.
• DKIM is unique to the domain, so it can be used safely on email services that serve many domains.

This does not mean that DKIM is a replacement of SPF. SPF should still be used as it is a quick and effective method for receivers to perform basic verification of email.

Conclusion

DKIM is, especially when combined with DMARC, a very effective email hardening technique.

With DKIM, both the authenticity of the email message, and the authorization of the sender are proven to the receiver, which allows for effective fraud prevention. DKIM is a vast improvement over SPF, which has many safety and practicality issues.

Domain administrators should always strive for 100% DKIM coverage for all email sent from the domain. DKIM coverage can be verified and monitored by using DMARC reporting with a DMARC report aggregation service such as Mailhardener.

Further reading

• DMARC
• Email hardening guide
• How to recreate a DKIM record with OpenSSL
• How to use DKIM with Ed25519

Tools

• DKIM record generator
• DKIM record validator
• DNS record splitter

Updates

• 08-07-2019: renamed 'digital signature' to 'cryptographic signature' to avoid confusion with email footer texts which are commonly known as 'digital signatures' or just 'signatures'.
• 09-02-2021: added additional section on the parts of the DKIM-Signature email header.