DKIM, or DomainKeys Identified Mail, is a cryptographic method for email authentication. It allows to sign an email message with a domain-specific key, making it possible to detect if the message was forged or modified while being transmitted by verifying the digital signature contained in the message.

DKIM is an Internet Standard since 2011, when the specification was published with RFC 6376. Today, it’s a fundamental technology in email security, playing an essential role in preventing email spoofing and spam.

The DKIM functioning isn’t the most straightforward to understand if you don’t have some cryptography or security background, as it requires having an understanding of concepts like the public-key cryptography and digital signatures. We’ll start from that and then go through the DKIM functioning.

About public-key cryptography and digital signatures

Public-key cryptography is an encryption method that uses a pair of related keys: a public key and a private key.

The fundamental idea is that a message encrypted with a public key can only be decrypted with the corresponding private key. Not only that: the opposite is also true! In fact, a message encrypted with a private key can only be decrypted with the corresponding public key.

This very important property unlocks lots of real-world use cases: for example, you could encrypt a message with your public key so that only the people that own the corresponding private key can decrypt and see the original message.

This is the foundation of most modern web security protocols and relies on two important requirements: the private key must be kept secret and stored in a secure way, while the public key can and should be published so that anyone can use it.

However, in the context of DKIM, cryptography is not used to hide the content of the message (cryptographers would say that confidentiality is not protected), but to create a digital signature.

A digital signature is the output of a signing algorithm where the input message is processed and encrypted with the private key of the sender. Anyone can then verify that the digital signature is valid by using the public key.

By having both the input message and the public key, a recipient can verify that the message was not modified (integrity) and that it was indeed created and signed by the owner of the private key, i.e. the sender (authentication).

As long as the private key is kept secret, a digital signature also provides non-repudiation, which means that the signer cannot claim it was someone else to produce and sign the message.

Example of DKIM signature

A digital signature is made of random bytes but can be represented as a short text string, like the following one:

nG0hb5r4SvnUbQx1qJwB2LywUUBWzkpHqLEPE3SkOsDTupXq6zbcSpULbVy8ZU/vwIjuP6ZbTJmMUoB/ezaGjwAyFVtW7FM3PZUzzl1eyge5EvS2ChjzXG6QD/uTaip9XLf9dhji3pJ1BU3fmZPPs1Jn9RrmXAZUNOKQ2JRV8NA=

This is a real DKIM signature copied from an email message: it’s not reversible, so it can be shared without revealing any information about the original message.

High-level mechanism

Keeping in mind the concepts introduced above, DKIM works like this:

  • The sender of the message (usually the mail server) extracts some key information from the email message and signs them with its private key, obtaining the digital signature. The signature is then inserted, along with some other information, in the DKIM-Signature header of the email message.
  • The recipient mail server reads the DKIM-Signature header, which also contains the domain associated with the DKIM signature and a selector, which is a name assigned to the DKIM key pair.
  • The mail server queries the {selector}._domainkey.{domain} domain for a TXT record, obtaining a public key in the response.
  • It now has all the information needed to verify the digital signature, i.e. the original message and the public key. The verification algorithm either succeeds or fails, determining if the message is authentic.
  • If DMARC is enabled for the domain, the further step is to check if the DKIM signature domain is aligned with the domain of the sender, giving an indication on whether the email was forged by a malicious actor.

Using multiple DKIM signatures

An email message may not have DKIM signatures at all: in that case the message authenticity and integrity cannot be verified.

A message can also have more than one DKIM signature, a scenario that is more common that one might think.

For example, your email service provider may have shared DKIM keys, common to all customers, while also having domain-specific or customer-specific DKIM keys, used only for that domain/customer.

As the M3AAWG (Messaging, Malware and Mobile Anti-Abuse Working Group) says:

[Email Service Providers] should strongly consider double-signing with their own domain as well, to allow separate reputation assessments based on each of the domain names. ESPs should use distinct DKIM keys for each customer.

It’s therefore frequent to find more than one DKIM-Signature header in an email, and usually only one is linked to the sender domain.

DKIM and DMARC alignment

As you might have noticed, DKIM alone doesn’t provide a mechanism to ensure that a signature was indeed created by the owner of the sender domain.

It’s trivial for a spammer to forge an email message where the sender address is spoofed but the DKIM signature is valid, even though for a different domain.

This is where DMARC comes into play, by checking whether at least one valid DKIM signature is aligned with the sender domain.

Alignment can be either strict, where the signature domain must match exactly the domain of the sender of the message, or relaxed, where subdomains are ignored.

It’s important that all email messages contain at least one valid DKIM signature aligned with the sender domain. It’s also important to carefully choose a DKIM alignment mode to prevent unwanted alignment failures.

Managing DKIM keys

It’s a recommended practice to frequently change DKIM keys. The rationale is that a leaked DKIM private key may allow anyone to claim that an email was sent even if it wasn’t.

If DKIM keys are changed frequently, through a process called rotation, the impact is at least limited to a specific period of time where that key was being used.

To allow multiple DKIM keys for the same domain, DKIM has the concept of selector. The selector is basically a name assigned to a key pair, and allows to query public keys independently.

DKIM can be broken by mail servers

A common issue with DKIM is that sometimes mail servers can modify the content of email messages and therefore break DKIM signatures, depending on how they are built.

For example, a forwarding mail server might change the subject of the email by adding some text, and that would almost certainly break the DKIM signature. The same applies if the mail server adds something to the email footer, for example.

Another situation where DKIM signing may break is in the context of mailing lists, or distribution lists. Since the mailing list servers acts as a relay to distribute message to many subscribers, the server needs to mail the message again and while doing so it may add additional text like unsubscribe links that may break the DKIM signature.

For this reason it’s usually recommended to achieve full DMARC compliance, not only by ensuring that DKIM signatures are aligned, but also by achieving SPF alignment.