DKIM2 is the evolution of DKIM, which was introduced by the Internet Engineering Task Force (IETF) in 2007 with Request for Comments (RFC) 4871 and was last updated in 2011 with RFC 6376.

1. Introduction

DKIM stands for “DomainKeys Identified Mail” and is a cryptographic signature used to ensure the integrity of an email during transmission.

When an email is sent, the sender uses a private key to generate a signature for it. The public key is stored as a TXT record in the DNS of a domain. This enables the recipient to verify the email’s integrity upon receipt and ensure it has not been altered during transmission. For example, this makes it possible to detect changes such as the subsequent insertion of phishing links.

However, DKIM alone is not sufficient as an authentication mechanism, because spammers can also apply this method correctly. DKIM initially confirms only that an email has been signed by a domain and has remained unchanged during transmission. Whether the signing domain actually matches the visible sender and is trustworthy can only be assessed through additional mechanisms such as DMARC.

2. Weaknesses of DKIM

Since 2007, various forms of abuse and weaknesses have become apparent, including DKIM replay and issues caused by mailing lists and forwarding.

DKIM fulfils its purpose when an email is transmitted directly between a sender and a recipient. If the integrity of the email is compromised, it can be assumed that it has been manipulated during transmission.

However, in forwarding scenarios involving at least three legitimate stations performing a central email function, DKIM very often breaks unintentionally. The intermediary makes intentional changes that alter the integrity of the original message. When the email is then forwarded to the final recipient, validation of the DKIM signature with the public key fails.

In a longer chain of senders and recipients, this creates uncertainty because an intermediary may be unknown, making it impossible to validate the changes made in the meantime or determine precisely what they were.

3. Target Problem and Motivation

So, how can an email that has been forwarded and modified several times still be received by the final recipient securely and with its integrity intact, while continuing to make use of the benefits of DKIM?

This is precisely where DKIM2 comes in – it is an evolution of DKIM, incorporating necessary innovations based on proven mechanisms to reduce implementation effort.

The DNS setup and the basic principle of how DKIM2 works remain unchanged. A key pair is still used and the existing setup can be used as it is. This means that no changes need to be made to the DNS.

Therefore, DKIM2 seeks to keep the necessary changes as limited as possible while using minor adjustments to address the challenges that standards such as ARC and DMARC have attempted to solve in the meantime.

4. Digression: Possible Optimisation of the Signature Algorithm

When signing using DKIM2, it is advisable to switch from RSA to ML-DSA.

The ever-increasing processing power of computers and servers means that established signature algorithms can be decrypted. The most effective way to prevent this is to start using more advanced algorithms.

However, it should be noted that this could cause significant compatibility issues within the ecosystem.

Further details can be found in RFC 9882, which covers the use of ML-DSA in the Cryptographic Message Syntax standard.

5. DKIM2 Comes with Two Headers

In future, DKIM2 will consist of two email headers:

1. Message-Instance
2. DKIM2-Signature

Message-Instance

The Message-Instance header documents the changes made to an email as it passes through multiple receiving and sending stations.

The core components of the Message-Instance header are the hashes formed over the headers, header-hash, and the body, body-hash, and the recipe.

The recipe follows JSON syntax and uses its own tags to define the unambiguous interpretation of changes and how they are to be handled. The recipe is stored in the “r=” tag and encoded in Base64 in the email header.

DKIM2-Signature

This is the actual cryptographic signature which, as mentioned at the outset, is created using the familiar RSA algorithm.

All DKIM2 signatures can be identified by their corresponding sequence number, “i=#”, in ascending order.

The following example illustrates this:

Message-Instance: v=1;
m=1;
h=sha256:aG9UNGVhZGVySGFzaFYx==:Ym9keUhhc2hWMQ==

Message-Instance: v=2;
m=2;
r=eyJoIjp7InN1YmplY3QiOlt7ImQiOlsiUHJvamVrdHN0YXR1cyBV
cGRhdGUiXX1dfSwiYiI6W3siYyI6WzEsNl19XX0=;
h=sha256:bmV3SGVhZGVySGFzaFYy==:bmV3Qm9keUhhc2hWM
g==

DKIM2-Signature: i=1; d=original.example.email; t=1780329600;
mf=seb@origin.example.email;
rt=liste@mailingliste.example.email;
s=sel1:ed25519-sha256:MEUCIQD3xK...FAKE...==

DKIM2-Signature: i=2; d=mailingliste.example.de;
t=1780329650;
mf=bounce@mailingliste.example.email;
rt=bob@receiver.example.email;
f=exploded;
s=sel-liste:ed25519-sha256:AnotherFAKEsigValue...==

6. Process Flow

1. The sender creates their email and adds the Message-Instance header with its hash, then signs it with DKIM. There is no recipe yet at this point, because this is the original version.
2. The recipient can validate the message and determine its integrity. If the email is to be forwarded, there are two options:
   1. A recipe is not required if no changes have been made. A further DKIM2 signature must be added.
   2. If changes have been made to the headers or body, these must first be documented in the recipe. The email must then be provided with its own DKIM2 signature. This is added to the email header and sent to the next recipient.
3. The third recipient performs the following checks:
   1. Validation of the hash of the second Message-Instance and the associated DKIM2 signature
   2. Comparison with the changes documented in the recipe
   3. Comparison of the hash of the first Message-Instance and validation of the first DKIM2 signature

If all the hashes match and both signatures are valid, the email is deemed to have retained its integrity, because all the changes made to it can be traced and each one is secured by a separate signature.

4. The email can now either:
   1. Be forwarded with a new DKIM2 signature. A recipe is not required; see process step 2a
   2. Be finally accepted and delivered, or
   3. Be modified again, in which case this change is added in a new recipe for the new DKIM2 signature, signature no. 3.

In theory, this chain can continue indefinitely. Each recipient can trace, check and validate the changes and signatures of the immediate predecessor, as well as all previous signatures.

7. Benefits and Effects

In summary, not only are changes made to an email and re-signed, but transparency is also created about what those changes entailed. Recipients are not left to guess, but are reassured by clear traceability and individual cryptographic signatures.

This creates a complete chain of custody for each recipient. If any questions arise during the validation process, the email must be rejected.

8. Classification and Comparison

The recipe and the documented changes facilitate indirect communication between the sender and the recipient, establishing trust at every stage of the process.

DKIM2 also incorporates the approaches used by ARC, see also RFC 8617. With the Authenticated Received Chain, an attempt had already been made to transfer trustworthiness from one party to the next in a chain of recipients. However, this approach required the trustworthiness of each party in the chain to be verified by the party before it. Therefore, Recipient 3 in a chain cannot use ARC to directly verify the trustworthiness of Sender 1.

DKIM2 behaves somewhat differently. If a recipient cannot validate the DKIM2 signatures and cannot trace the changes made by all intermediaries, the ultimate conclusion is: “Reject this email!”

9. Conclusion

Currently, DKIM2 is not an official IETF RFC, but rather an intensively developed draft that is still subject to ongoing adjustments. Nevertheless, in my view, this is one of the fastest developments of a new email security standard that I have observed in the last 20 years.

Implementation is gaining momentum very quickly among mailbox providers. The first ESPs are reporting the successful sending and receipt of DKIM2-signed emails. DKIM2 finally consolidates requirements, see DMARC and ARC, and will solve long-standing security issues.

I believe that DKIM2 will have a lasting impact on senders’ reputations.

Those who adopt it quickly will automatically demonstrate transparency and a fundamental understanding of the problems that have become apparent over the last 15 to 20 years.