Im März 2026 stellt ein Deliverability-Team eines europäischen ESP bei einem internen Routing-Test fest, dass seine E-Mails an Mailman-Verteilerlisten systematisch bei der DKIM-Verifizierung fehlschlagen, obwohl die Schlüssel korrekt konfiguriert sind. Die Nachricht ist legitim, die Domain sauber, die Liste ist opt-in. Aber Mailman hat den From-Header umgeschrieben und die DKIM1-Signatur an diesem Punkt ungültig gemacht. DKIM2 zielt darauf ab, diese Art von Problem zu beheben. Die IETF-Arbeitsgruppe dkim hat im März 2026 die ersten Entwürfe des Protokolls angenommen: noch kein RFC, null produktive Einsätze, aber eine Architektur, die die Verifizierung über den gesamten Zustellweg verteilt.
Warum DKIM1 im Jahr 2026 an seine Grenzen stößt
DKIM1, formalisiert in RFC 6376 im Jahr 2011, behandelt einen klaren Bereich: Es beweist, dass die signierende Domain die Nachricht ursprünglich gesendet hat. Die Spezifikation überlebt keine Zwischenstationen. Jeder Server, der die Nachricht berührt, kann die Signatur ungültig machen: eine Mailingliste, die eine Fußzeile hinzufügt, ein Sicherheitsgateway, das URLs umschreibt, ein Forwarder, der das SMTP-Envelope ändert. Mit einer DKIM-Adoption nahe 90% bei direkten E-Mails im Jahr 2026 könnte man meinen, das Problem sei gelöst. Aber diese Rate misst den Erfolg bei E-Mails, die direkt ankommen, nicht diejenigen, die über Mailinglisten oder Forwarder laufen.
Das IETF-Dokument draft-ietf-dkim-dkim2-motivation beschreibt drei strukturelle Schwachstellen, die DKIM1 nicht beheben kann. Erste: Eine gültig signierte E-Mail kann empfangen werden, ohne dass es einen Beweis gibt, dass der Empfänger tatsächlich der vorgesehene Empfänger war. Zweite: Die Bounce-Adresse kann Domains referenzieren, die keine Rolle im Nachrichtentransit gespielt haben. Dritte: Es existiert kein Mechanismus, um legitime Änderungen durch Forwarder oder Mailinglisten zu dokumentieren. Diese Lücken liegen im Design des ursprünglichen Protokolls begründet, nicht in Konfigurationsfehlern.
Seit 2024 haben Google und Yahoo SPF, DKIM und DMARC für Massenversendungen obligatorisch gemacht. Dieser Druck hat die Adoption beschleunigt, ohne die architektonischen Probleme zu lösen. Die Arbeit wurde der IETF-Arbeitsgruppe dkim übertragen, die an mehreren komplementären Entwürfen arbeitet: Hauptspezifikation, Motivationsdokument, Bereitstellungsprofil über Milter-Schnittstelle und Best Practices Guide.
Die Kette der Signaturen: Überleben der Intermediäre
Der zentrale Mechanismus von DKIM2 nennt sich Kette der Signaturen. Statt von jedem Server zu verlangen, eine ursprünglich ausgestellte Signatur zu validieren, verlangt das Protokoll, dass jeder Zwischenstopp die von ihm vorgenommenen Änderungen dokumentiert und diese Dokumentation signiert. Der Endempfänger rekonstruiert somit die vollständige Sequenz der Transformationen und prüft die Legitimität jeder einzelnen.
Richard Clayton, Mitautor der DKIM2-Spezifikation, beschreibt den Ansatz als eine „modification algebra“: Die Intermediäre spezifizieren die genaue Natur ihrer Änderungen, anstatt nur einen Zustimmungstempel aufzudrücken. Eine Mailingliste, die einen Footer hinzufügt, deklariert dies in ihrer Signatur. Ein Sicherheitsgateway, das URLs umschreibt, tut dasselbe. Der Empfänger bewertet dann, ob jede Transformation erwartet und autorisiert war.
In der Praxis gehen die falsch positiven Ergebnisse, die heute häufige Ursache für DKIM1-Invalidierungen durch Verteilerlisten sind, aus dem Verantwortungsbereich des Absenders heraus. Clayton hat im April 2026 erklärt, dass es bereits funktionierenden Code gibt und Tests bei Mailbox-Providern in den kommenden Monaten erwartet werden. Die Haupttechnische Spezifikation (draft-ietf-dkim-dkim2-spec-01) ist vom 20. April 2026 datiert.
Asynchrone DSN und VERP: Dem Backscatter ein Ende setzen
Der zweite technische Aspekt von DKIM2 betrifft ein weniger sichtbares, aber für die Absenderreputation kostspieliges Problem: den Backscatter. Wenn ein Spammer die Rücksendeadresse mit der Domain eines unschuldigen Dritten fälscht, fallen die von legitimen Servern generierten Bounces in den Posteingang dieses Unschuldigen. Saubere IPs und Domains gelangen aufgrund von Traffic, den sie nie verschickt haben, auf schwarze Listen.
Steve Atkins von Word to the Wise, der das Thema seit mehreren Wochen verfolgt, merkt an, dass DKIM2 dieses Problem durch zwei kombinierte Mechanismen löst. Asynchrone Delivery Status Notifications (DSN) erlauben es einem Server, eine Nachricht per SMTP zu akzeptieren und dann später nach vollständiger Analyse den Fehlschlag zu benachrichtigen. VERP (Variable Envelope Return Path) codiert die notwendigen Metadaten direkt in der Rücksendeadresse, was das Parsen des Bounce-Körpers überflüssig macht. Die Kombination der beiden, so Word to the Wise vom 27. April 2026, ermöglicht es, den Bounce sofort zu registrieren und die asynchrone DSN ohne weitere Behandlung oder Speicherung zu ignorieren.
Für Deliverability Manager nehmen Bounces in DKIM2 einen kryptographisch signierten Weg zurück zum vorherigen Server in der Kette, anstatt zu einer gefälschten Adresse. Der Backscatter verliert seine Hauptangriffsfläche. Atkins warnt, dass die Volumina asynchroner Bounces bei der anfänglichen Implementierung um mehrere Größenordnungen steigen könnten. Eine erhöhte Inbound-Kapazität wird auf der ESP-Seite erforderlich sein.
Anti-Replay: Timestamps und Empfängerbindung
DKIM1 weist eine bekannte, aber unterschätzte Schwachstelle auf: den Replay-Angriff. Eine gültige DKIM-Signatur kann wiederverwendet werden, um die gleiche Nachricht an nicht vorgesehene Empfänger zu senden. Der Angreifer erhält eine legitime E-Mail, behält ihre Signatur intakt und verteilt sie großflächig. Die Anti-Spam-Filter sehen eine gültige Signatur und lassen sie durch.
DKIM2 schließt diese Lücke durch zwei komplementäre Mechanismen. Die Signaturen beinhalten nun die Daten des SMTP-Envelopes: Absender und Empfänger. Eine für alice@example.com signierte Nachricht kann nicht an bob@example.com gesendet werden, ohne die Signatur ungültig zu machen. Zudem steuern flags die autorisierte Verteilung der Nachricht. Dieser Mechanismus der Empfängerbindung könnte, wie Al Iverson von SpamResource bemerkt (der die Arbeiten der WG IETF DKIM verfolgt), die Angriffsfläche der ausgeklügeltsten Spam-Kampagnen verändern.
Die Timestamps ergänzen derweil das System. Eine DKIM2-Signatur hat eine explizite zeitliche Gültigkeit, die verhindert, dass eine mehrere Wochen alte legitime Nachricht in einer bösartigen Kampagne wiederverwendet wird. Iverson bemerkt, dass sich die DKIM-Schlüssel selbst mit DKIM2 nicht unbedingt ändern. Absender könnten keine bedeutenden Änderungen auf der DNS-Seite vornehmen müssen. Die Verifizierungsinfrastruktur und die Signaturkette entwickeln sich weiter, nicht die Absenderkonfiguration.
Was DKIM2 nicht ersetzt: Die Listenqualität
DKIM2 sichert den Lieferweg, ändert aber nichts an der Qualität der Empfänger. Eine Signatur, die die Intermediäre überlebt, kryptographisch geroutete Bounces und ein Schutz gegen Replay setzen voraus, dass die Zieladressen gültig und engagiert sind. In einer Liste, die 20% ungültige oder inaktive Adressen enthält, verbessert DKIM2 nicht die Inbox-Rate. Es authentifiziert E-Mails besser, die Filter aus anderen Gründen weiterhin zurückweisen.
Öffentliche Deliverability-Benchmarks, die von den großen Versanddienstleistern veröffentlicht werden, stimmen in diesem Punkt überein: Die Inbox-Raten variieren stärker in Abhängigkeit von der Engagement-Qualität der Liste als von den Authentifizierungsparametern. DKIM2 verstärkt die Authentifizierungsebene, kompensiert jedoch keine schlecht gepflegte Liste. Die Überprüfung der Adressen vor dem Versand bleibt die Voraussetzung für jede Lieferkompetenz-Pipeline. Das Protokoll sichert den Weg, nachdem die Empfänger validiert wurden, nicht im Vorhinein.
Vergleich DKIM1 und DKIM2 anhand der wichtigsten Kriterien
| Kriterium | DKIM1 (RFC 6376) | DKIM2 (draft IETF 2026) |
|---|---|---|
| Resistenz gegen Zwischenstationen | Keine: Jede Änderung macht die Signatur ungültig | Kette der Signaturen: Jeder Intermediär dokumentiert seine Änderungen |
| Anti-Replay-Schutz | Nicht vorhanden: Eine gültige Signatur ist wiederverwendbar | Empfängerbindung + Timestamps: Signatur an Empfänger und Zeitfenster gebunden |
| Bounce-Verwaltung | Asynchrone nicht-kryptografische Bounces, Backscatter möglich | Signierte Async-DSN + VERP: Rückkehr zum vorherigen Server in der Kette |
| Mailinglisten und Forwarder | Systematischer Signaturbruch | Änderungen dokumentiert über Modifikation algebras, Signatur gewahrt |
| RSSI-Sichtbarkeit | Begrenzt: Keine Verfolgung der Transitmodifikationen | Komplettes Audit der dokumentierten Transportkette |
| Status | Veröffentlichte RFC, seit 2011 implementiert | Entwurf von der IETF-Arbeitsgruppe im März 2026 angenommen, noch kein RFC |
Was vor der Implementierung zu beachten ist
Vier Dokumente wurden von der IETF-Arbeitsgruppe dkim angenommen: die Hauptspezifikation, ein Motivationsdokument (draft-ietf-dkim-dkim2-motivation), ein Bereitstellungsprofil über Milter-Schnittstelle und ein Leitfaden zu bewährten Praktiken. Alle sind mit draft-ietf-dkim vorangestellt, was anzeigt, dass sie offiziell im Pipeline der Arbeitsgruppe sind, nicht individuelle Vorschläge.
- Verfolgung der Hauptspezifikation: Das draft-ietf-dkim-dkim2-spec läuft im Oktober 2026 ab. Seine Erneuerung oder sein Fortschritt zum Status eines Proposed Standard wird das erste konkrete Signal eines Wegs zu einem RFC sein.
- Tests bei den Mailbox-Providern: Richard Clayton hat von Einsätzen bei Mailbox-Providern in den kommenden Monaten gesprochen. Wenn Gmail, Yahoo oder Outlook die Unterstützung von DKIM2 ankündigen, würden sich die Prioritäten auf ESP-Seite sofort ändern.
- Inbound-Infrastruktur der ESPs: Das erwartete Wachstum der Volumina asynchroner Bounces bei der Implementierung erfordert eine verstärkte Inbound-Kapazität. ESPs, die ihre Infrastruktur im Voraus vorbereiten, werden weniger operativen Druck haben.
- Politik zur Adressunterdrückung: Die asynchronen Bounces von DKIM2 können 24 Stunden oder mehr nach der ursprünglichen Sendung ankommen. Automatische Unterdrückungsregeln müssen überarbeitet werden, um diesen Zeitraum zu integrieren, ohne in den Abmeldelisten falsche Positive zu erzeugen.
Al Iverson erinnert im April 2026 daran, dass die Spezifikation noch nicht abgeschlossen ist und die Details sich ändern können. Die IETF-Arbeitsgruppe hat für 2026 Zwischensitzungen organisiert, um die Arbeiten zu beschleunigen. Die Agenda des Zwischentreffens vom 29. April 2026 dokumentiert die laufend überprüften Entwürfe.
Um den Fortschritt in Echtzeit zu verfolgen: Abonnieren Sie die Mailing-Liste ietf-dkim@ietf.org und überprüfen Sie den Status der Entwürfe auf datatracker.ietf.org/group/dkim, dem Forum, in dem der tatsächliche Zeitplan für DKIM2 entschieden wird.
