DKIM2: was neu ist, was sich ändert und wichtige Termine

TL;DR — DKIM2 ist eine Neufassung, die derzeit als Internet-Drafts im IETF entsteht. Sie soll Quelle und Ziel jedes SMTP-Hops signieren, Signaturen zu verketten (i=1, i=2, ...), von Intermediären vorgenommene Änderungen dokumentieren und Bounces (DSN) entlang der Kette nachvollziehbar machen. DKIM2 ist noch kein Standard: Die Entwicklung schreitet schnell voran, aber die wichtigsten Bausteine stehen.

ℹ️ Die Begriffe DKIM Replay und Backscatter sind im Glossar am Ende des Artikels erklärt.

Warum jetzt über DKIM2 sprechen?

DKIM (STD 76, RFC 6376) ist weit verbreitet, um E-Mail-Inhalte zu signieren. Doch es stößt an Grenzen bei DKIM Replay, bei Änderungen durch Mailinglisten/Forwarder und bei Backscatter (Bounces an Dritte). DKIM2 schlägt ein Modell vor, bei dem jeder Relay seine eigene Signatur hinzufügt, nummeriert, und das Paar Quelle → Ziel des nächsten Hops explizit deklariert. Das ermöglicht:

• Replays zu erkennen und einzuschränken;
• Bounces und Reports entlang des authentifizierten Pfads zurückzuleiten;
• Änderungen am Body/an den Headern zu beschreiben und, wenn möglich, rückgängig zu machen, um die Ursprungssignatur zu prüfen.

Wichtigste Neuerungen (gegenüber DKIM "v1")

1. Neuer DKIM2-Signature-Header (ohne Versionsfeld)

   • Nummerierung mit i= (1, 2, ...). Eine Lücke in der Sequenz macht die Kette ungültig.
   • Zeitstempel t=; ein Prüfer kann eine Signatur nach Ablauf eines Fensters (z. B. 14 Tage) als abgelaufen betrachten.
   • Algorithmen: RSA-SHA256 und Ed25519-SHA256 sind vorgesehen, Krypto-Agilität ist geplant.
   • Schlüssel im DNS: wie bei DKIM unter selector._domainkey.domain.

2. Verkettung und Abgleich mit dem SMTP-Envelope

   • mf= (MAIL FROM) und rt= (RCPT TO) beschreiben den Envelope des signierten Hops.
   • Jeder neue Hop muss dem vorherigen Ziel entsprechen (oder über pp= „Proxy-signiert“ werden).
   • Der Verifizierer prüft zuerst die jüngste Signatur (höchstes i).

3. Modellierung von Änderungen

   • Der Draft führt einen MailVersion-Header ein, der beschreibt, wie man zur vorherigen Version zurückkehrt (Rezepte für Body/Header).
   • Die Signatur trägt mv= für die abgedeckte Nachrichtenversion.
   • Ein f=-Feld (Flags) kann modifiedbody, modifiedheader, exploded, donotmodify, feedback usw. anzeigen.

4. Bounces und Feedback

   • DSN und Feedback werden nach oben in der Kette zu einem beteiligten Akteur geleitet, was Backscatter begrenzt.
   • Möglichkeit, Feedback-Präferenzen anzugeben (je nach Draft-Version).

5. Kompatibilität und Koexistenz

   • DKIM2 ersetzt DKIM (RFC 6376) nicht sofort: Eine Übergangsphase mit Koexistenz ist zu erwarten.
   • DNS-Records bleiben unter _domainkey. Proxy-Signaturen (pp=) sind vorgesehen, mit Alignment-Vorgaben und Autorisierungsnachweisen über DNS (z. B. dedizierter Record oder MX-Beziehung), abhängig vom Draft.

Was wegfällt oder sich deutlich ändert

• Kein v= in DKIM2-Signature (bei einem größeren Bruch würde eher ein zukünftiger „DKIM3-Signature“-Header entstehen als eine interne Versionsnummer).
• Vereinfachte Liste signierter Header: Ein verpflichtendes Grundset ist definiert; h= bleibt für besondere Fälle möglich.
• Vereinfachte Ablaufbehandlung: stützt sich auf t= und Empfehlungen auf Prüferseite statt auf ein streng normatives Feld.
• Von DKIM geerbte, als zu komplex eingestufte Parameter (z. B. z=) fallen in den ersten Drafts weg.

⚠️ DKIM2 befindet sich in Ausarbeitung: Syntax (Tag-Namen, Flags, Fristen) kann sich ändern. Prüfen Sie die unten genannten Draft-Versionen.

Beispiel-Header (aktueller Draft-Stand)

DKIM2-Signature: i=1; t=2025-10-24T08:01:02Z; d=example.com; s=sel2025;
  a=ed25519-sha256; bh=BASE64(...); b=BASE64(...);
  rt=user@dest.tld; mf=bounce@example.com; mv=2; f=modifiedheader,feedback

MailVersion: v=2; bh=BASE64(...);
  h.Subject=d:*,t:[Re] Sonderangebot;
  h.From=d:*,b=am9obi5kb2VAZXhhbXBsZS5jb20=

Operative Auswirkungen (Kurzfassung)

• ESPs / Relays: müssen jeden Hop signieren, mf=/rt= verwalten, einfache Änderungen (Rezepte) erfassen/rückgängig machen und erneut an ausgerichtete Zieldomänen zustellen.
• Empfänger: prüfen zuerst die letzte Signatur (i=Max) und gehen bei Bedarf zurück; bei harten Fehlern früh verwerfen.
• DNS: Selektoren und Schlüssel bleiben unverändert unter _domainkey; planen Sie „Proxy“-Autorisierungen gemäß dem DNS-Mechanismus des Drafts.
• DMARC: Solange DMARCbis auf DKIM (RFC 6376) verweist, stützt sich DMARC weiter auf DKIM. Der Übergang DMARC→DKIM2 erfolgt nicht sofort.

Zeitplan: jüngste Meilensteine

• 5. Nov. 2024: Erste öffentliche Analysen zu DKIM2 (z. B. Red Sift).
• 20. Nov. 2024: Ankündigungsbeiträge von DMARC-Anbietern.
• 3. Sept. 2025: IETF-Arbeitsgruppe übernimmt das Motivation-Dokument (draft-ietf-dkim-dkim2-motivation-01).
• 17.–20. Okt. 2025: Veröffentlichung der Drafts -spec-02 (Spezifikation), -dns-03 (DNS), -header-04 (Header) und -modification-algebra-04 (MailVersion).

Vorbereitungsplan

1. Inventarisieren, wo Sie bereits DKIM signieren/prüfen (Flows, Hops, SRS/VERP, Mailinglisten).
2. Prototypen auf Relays: mf=/rt= berechnen, i= hinzufügen, Algorithmen wählen (Ed25519 empfohlen), t= handhaben.
3. Nachverfolgen typischer Änderungen (ML-Footer, Umschreiben von From:) und das Zurücksetzen per MailVersion testen.
4. DNS: Zyklus der Schlüsselrotation standardisieren; Mechanismus für „Proxy“-Autorisierungen vorbereiten.
5. Verifikation: Strategie „neueste i= zuerst“ implementieren, 5xx während des SMTP-Austauschs bei ungültiger Signatur, 4xx bei DNS TEMPFAIL.
6. Drafts beobachten (siehe unten) und Feature-Flags einplanen, um Feldänderungen nachzuvollziehen.

Glossar

DKIM Replay

• Definition: Wiederverwendung (Replay) einer bereits mit DKIM signierten Nachricht durch eine legitime Domäne, um sie unverändert massenhaft oder an andere Ziele zu versenden. Die Signatur bleibt gültig, weil DKIM den Inhalt (Body/Header), nicht aber den SMTP-Envelope oder den Pfad signiert.
• Warum?: Ein Angreifer erlangt eine Kopie einer signierten E-Mail (z. B. Newsletter) und verteilt sie unverändert; DMARC kann weiterhin durchgehen, wenn From: ausgerichtet bleibt.
• Symptome: Volumenspitzen auf derselben Signatur (bh= identisch), Spam-Beschwerden, Schaden am Ruf der signierenden Domäne.
• Gegenmaßnahmen: Rate-Limits pro Selektor, Schlüsselrotation, kurze Laufzeiten, strengeres DMARC (p=reject), verhaltensbasierte Filter auf Empfängerseite.
• Was DKIM2 ändert: Die Signatur enthält den Envelope je Hop (mf=/rt=) und verkettet den Pfad (i=), wodurch Replay erkennbar wird (inkonsistenter Pfad) und zielgerichtete Maßnahmen möglich werden.

Backscatter

• Definition: Unerwünschte Bounces (NDR/DSN) oder Autoresponder, die an unbeteiligte Dritte gehen, deren Adresse in MAIL FROM/Return-Path gefälscht wurde.
• Warum?: Server akzeptieren die Nachricht zunächst und erzeugen später einen Bounce; bei gefälschter Adresse geht der Bounce an das Opfer.
• Symptome: Flut von DSN/Autorespondern auf einer legitimen Mailbox, Rufschäden, mögliche Listings.
• Gegenmaßnahmen: Während des SMTP-Austauschs ablehnen (nicht danach), strenge SPF/DMARC, SRS/VERP zur Verfolgung von Bounces, Regeln gegen Autoresponder.
• Was DKIM2 ändert: DSN/Feedback lassen sich entlang der signierten Kette nach oben routen, wodurch Backscatter reduziert wird und der tatsächlich beteiligte Akteur erreicht wird.

Quellen und weiterführende Links

• DKIM2 – Spezifikation: draft-clayton-dkim2-spec-02 (20. Oktober 2025, läuft am 23. April 2026 ab).
• DKIM2 – DNS: draft-chuang-dkim2-dns-03 (20. Oktober 2025).
• DKIM2 – Header: draft-gondwana-dkim2-header-04 (20. Oktober 2025).
• DKIM2 – Modifikationsalgebra / MailVersion: draft-gondwana-dkim2-modification-algebra-04 (17. Oktober 2025).
• Motivation (IETF-Arbeitsgruppendokument): draft-ietf-dkim-dkim2-motivation-01 (3. September 2025, ersetzt die Individualversionen).
• DKIM-Überblick: RFC 6376; Updates: RFC 8301, RFC 8463.

DKIM2 bleibt ein laufendes Projekt. Wir aktualisieren diese Seite, sobald sich die Drafts einer RFC annähern.