DKIM2 ist die Weiterentwicklung von DKIM, welches 2007 von der IETF mit RFC 4871 eingeführt und 2011 mit RFC 6376 zuletzt aktualisiert wurde.

1. Einleitung

DKIM steht für „DomainKeys Identified Mail“ und ist eine kryptografische Signatur zur Sicherstellung der Integrität einer E-Mail während der Übertragung.

Beim Versand erzeugt der Absender mithilfe des privaten Schlüssels, Private Key, eine kryptografische Signatur für die E-Mail. Der öffentliche Schlüssel, Public Key, wird als TXT-Eintrag im DNS einer Domain hinterlegt. Damit kann der Empfänger beim Eingang der E-Mail die Integrität prüfen und sicherstellen, dass die E-Mail während der Übertragung nicht manipuliert wurde. Beispielsweise können dadurch Änderungen wie das nachträgliche Einfügen von Phishing-Links erkannt werden.

DKIM allein reicht als Authentifizierungsmechanismus dennoch nicht aus, denn auch Spammer können diese Methode fehlerfrei anwenden. DKIM bestätigt zunächst lediglich, dass eine E-Mail von einer Domain signiert wurde und während der Übertragung unverändert geblieben ist. Ob die signierende Domain tatsächlich mit dem sichtbaren Absender übereinstimmt und vertrauenswürdig ist, wird erst durch zusätzliche Mechanismen wie DMARC bewertet.

2. Schwächen von DKIM

Im Verlauf der letzten Jahre seit 2007 wurden verschiedene Missbrauchsmöglichkeiten und Schwächen sichtbar – DKIM Replay oder Probleme durch Mailinglisten und Weiterleitungen, um nur einige zu nennen.

Bei der direkten Übertragung einer E-Mail zwischen einem Versender und einem Empfänger erfüllt DKIM seinen Zweck. Bei fehlerhafter Integrität kann von einer missbräuchlichen Manipulation auf dem Übertragungsweg ausgegangen werden.

Bei Weiterleitungen, also mindestens drei beteiligten Stationen, die legitim und eine zentrale Funktion von E-Mail sind, kommt es jedoch sehr häufig zum ungewollten Bruch von DKIM. Die Zwischenstelle nimmt kleinere Änderungen vor, die gewollt sind, aber die Integrität der ursprünglichen Nachricht verändern. Beim Weitersenden der E-Mail an den finalen Empfänger kommt es dann bei der Validierung der DKIM-Signatur mit dem Public Key zum Fehler.

In einer längeren Kette von Absendern und Empfängern führt dies zu Unsicherheiten, weil man vielleicht eine Zwischenstation nicht kennt und nicht validieren kann, ob die zwischenzeitlich vorgenommenen Änderungen valide waren und genau welche dies waren.

3. Zielproblem und Motivation

Wie bekommt man es nun aber hin, eine E-Mail, welche zwischenzeitlich noch mehrfach weitergeleitet und gegebenenfalls bearbeitet wird, beim endgültigen Empfänger integer und sicher empfangen zu können und die Vorteile von DKIM weiterhin zu nutzen?

Genau da setzt DKIM2 als Weiterentwicklung an – notwendige Neuerungen auf altbewährten Mechanismen, um den Implementierungsaufwand zu verringern.

Beim Setup im DNS und dem Grundprinzip zur Funktionsweise von DKIM2 ändert sich nichts. Es wird weiterhin mit einem Schlüsselpaar gearbeitet und das bestehende Setup kann weiter genutzt werden. Somit müssen keine Änderungen am DNS vorgenommen werden.

DKIM2 versucht also die notwendigen Änderungen so gering wie möglich zu halten, aber dennoch durch kleine Anpassungen die Herausforderungen zu lösen, die man zwischenzeitlich mit Standards wie ARC oder DMARC versuchte zu lösen.

4. Exkurs: Mögliche Optimierung des Signaturalgorithmus

Beim Signaturprozess von DKIM2 bietet es sich an, von RSA auf ML-DSA umzustellen.

Die anwachsende Leistungsfähigkeit von Computern und Servern ermöglicht es, bewährte Signaturalgorithmen zu entschlüsseln. Um dies zu verhindern, wäre eine Umstellung auf weiterentwickelte Algorithmen sinnvoll.

Allerdings muss man auch sagen, dass es innerhalb des Ökosystems zu großen Kompatibilitätsproblemen kommen könnte.

Näheres dazu gibt es in RFC 9882, das die Verwendung von ML-DSA in der Cryptographic Message Syntax beschreibt.

5. DKIM2 kommt mit zwei Headern

DKIM2 besteht zukünftig aus zwei E-Mail-Headern:

1. Message-Instance
2. DKIM2-Signature

Message-Instance

Der Message-Instance Header dokumentiert und liefert die Details über die Veränderungen der E-Mail auf ihrem Weg durch mehrere Empfangs- und Absenderstationen.

Kernbestandteile des Message-Instance Headers sind die Hashes, welche über die Header, header-hash, und den Body, body-hash, gebildet werden, und das Recipe.

Das Recipe folgt der JSON-Syntax und legt mit eigenen Tags die eindeutige Interpretation der Veränderungen und deren Umgang damit fest. Das Recipe ist im „r=“-Tag hinterlegt und im E-Mail-Header in Base64 kodiert.

DKIM2-Signatur

Dies ist die eigentliche kryptografische Signatur, die, wie eingangs schon erwähnt, mit dem bekannten RSA-Algorithmus erstellt wird.

Alle DKIM2-Signaturen sind durch entsprechende Sequenznummerierungen, “i=#”, nacheinander aufsteigend erkennbar.

Hier ein einfaches Beispiel zur Veranschaulichung:

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

Message-Instance: v=2;
m=2;
r=eyJoIjp7InN1YmplY3QiOlt7ImQiOlsiUHJvamVrdHN0YXR1cyBVcGR
hdGUiXX1dfSwiYiI6W3siYyI6WzEsNl19XX0=;
h=sha256:bmV3SGVhZGVySGFzaFYy==:bmV3Qm9keUhhc2hWMg==

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

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

6. Prozessablauf

1. Ein Versender erstellt seine E-Mail, fügt den Message-Instance Header mit seinem Hash hinzu und signiert sie mit DKIM. Zu diesem Zeitpunkt gibt es noch kein Recipe, denn es handelt sich um die originale Version.
2. Der Empfänger dieser Nachricht kann diese damit validieren und deren Integrität feststellen. Wenn die E-Mail weitergeleitet werden soll, gibt es zwei Möglichkeiten:
   1. Ohne Änderung ist kein Recipe notwendig. Es muss aber eine weitere DKIM2-Signatur hinzugefügt werden.
   2. Wenn Änderungen an Headern und Body vorgenommen wurden, müssen diese zunächst im Recipe dokumentiert werden. Danach muss die E-Mail mit einer eigenen DKIM2-Signatur versehen werden. Diese wird dem E-Mail-Header hinzugefügt und an den nächsten Empfänger gesendet.
3. Der dritte Empfänger führt folgende Prüfungen durch:
   1. Validierung des Hashes der zweiten Message-Instance sowie der zugehörigen DKIM2-Signatur
   2. Abgleich der im Recipe dokumentierten Änderungen
   3. Vergleich des Hashes der ersten Message-Instance und Validierung der ersten DKIM2-Signatur

Stimmen alle Hashes überein und sind beide Signaturen gültig, gilt die E-Mail als integer, da sämtliche Änderungen auf dem Weg nachvollziehbar und jeweils durch eine eigene Signatur abgesichert sind.

4. Jetzt kann die E-Mail entweder:
   1. siehe Schritt 2a mit einer neuen DKIM2-Signatur weitergeleitet werden. Es muss kein Recipe erstellt werden.
   2. final entgegengenommen und zugestellt werden, oder
   3. erneut verändert werden, wobei diese Änderung in einem neuen Recipe der neuen DKIM2-Signatur, Signatur Nr. 3, hinzugefügt wird.

Diese Kette lässt sich theoretisch unendlich fortsetzen. Jeder Empfänger kann Änderungen und Signaturen des direkten Vorgängers sowie alle vorherigen Signaturen nachvollziehen, überprüfen und validieren.

7. Nutzen und Effekte

Zusammengefasst werden nicht nur Änderungen an einer E-Mail vorgenommen und neu signiert, sondern es wird transparent gemacht, was die Änderungen beinhalteten. Kein Rätselraten auf Seiten des Empfängers, sondern Rückversicherung durch eindeutige Nachverfolgbarkeit und mithilfe individueller kryptografischer Signaturen.

Für jeden Empfänger entsteht eine lückenlose Nachweiskette, Chain of Custody. Wirft die Validierung an irgendeiner Stelle Fragen auf, muss die E-Mail abgelehnt werden.

8. Einordnung und Vergleich

Mit dem Recipe und den dokumentierten Änderungen entsteht eine indirekte Kommunikation zwischen Sender und Empfänger und schafft Vertrauen zu jeder Zeit und an jeder Stelle in der Kette der Beteiligten.

Es werden darüber hinaus auch die Ansätze von ARC, siehe auch RFC 8617, übernommen. Mit der Authenticated Received Chain hat man bereits versucht, in einer Kette von Empfängern die Vertrauenswürdigkeit von einer Stelle zur nächsten zu übertragen. Dies setzte aber voraus, dass man seinem Vorgänger vertraut, dass er wiederum seinem Vorgänger vertraut. Empfänger 3 einer Kette kann also bei ARC nicht direkt die Vertrauenswürdigkeit von Versender 1 prüfen.

Bei DKIM2 verhält es sich etwas anders. Wenn ein Empfänger die DKIM2-Signaturen nicht validieren kann und die Änderungen aller Zwischenstellen nicht nachvollziehen kann, heißt dies letztlich: „Lehne diese E-Mail ab!“

9. Fazit

Aktuell ist DKIM2 noch kein offizielles RFC der IETF, sondern ein Entwurf, an dem intensiv gearbeitet wird und in dem es noch stetig Anpassungen geben kann. Dennoch ist es in meinen Augen eine der schnellsten Entwicklungen eines neuen Sicherheitsstandards für E-Mail, die ich in den letzten 20 Jahren beobachtet habe.

Seitens der Mailbox Provider nimmt die Implementierung sehr schnell Fahrt auf. Erste ESPs berichten von erfolgreichen Versendungen und Empfängen von E-Mails mit DKIM2.

DKIM2 ist endlich eine erreichte Konsolidierung von Anforderungen, siehe DMARC und ARC, und wird langjährige Sicherheitsprobleme lösen.

Aus meiner Sicht wird DKIM2 einen nachhaltigen Einfluss auf die Reputation von Versendern haben.

Versender, die schnell auf DKIM2 setzen, demonstrieren damit automatisch Transparenz und das grundlegende Verständnis für die sichtbar gewordenen Probleme der letzten 15 bis 20 Jahre.