DKIM2: Stand der Standardisierung und wie Sie sich vorbereiten

⚡TL;DR

• DKIM2 ist kein Standard: keine RFC, kein Dokument im Last Call und ein Zeitplan der IETF-Charta mit rund sieben Monaten Rückstand.
• Die Arbeit findet in der historischen Arbeitsgruppe dkim statt, die im Februar 2025 eine neue Charta erhalten hat. Eine Gruppe "dkim2" gibt es nicht.
• Die aktuelle Spezifikation (draft-ietf-dkim-dkim2-spec-04, 5. Juli 2026) stützt sich auf zwei Header: DKIM2-Signature pro Hop und Message-Instance, um Änderungen in Form von JSON-Recipes zu beschreiben.
• Fast die gesamte Syntax von 2025 ist verschwunden: mv=, pp=, a=, b=, bh=, der Header Mail-Version:.
• Drei Implementierungen (Rust, Python, Go) haben im Juli 2026 ihre Interoperabilität nachgewiesen, eine vierte in C wurde seitdem angekündigt: die konkreteste Veränderung der Lage seit einem Jahr.
• Domaininhaber: nichts zu tun. Ihre Schlüssel und Ihre _domainkey-Einträge bleiben unverändert gültig.

ℹ️ Die Begriffe DKIM Replay, Backscatter, Message-Instance und Recipe sind im Glossar am Ende des Artikels erklärt.

DKIM2 schleppt einen widersprüchlichen Ruf mit sich. Man liest, es werde DKIM "bald" ersetzen, es mache DMARC hinfällig, oder im Gegenteil, es existiere nur auf dem Papier. Die Realität im Juli 2026 ist einfacher: Das Protokoll ist noch immer nicht standardisiert, aber es ist nicht mehr theoretisch, denn drei unabhängige Implementierungen signieren, prüfen und rekonstruieren gemeinsam Nachrichten.

Warum gibt es DKIM2?

DKIM (STD 76, RFC 6376) signiert den Inhalt einer Nachricht. Das ist seine Stärke und, nach zwanzig Jahren Betrieb, seine Grenze: Die Signatur sagt weder etwas über den zurückgelegten Weg noch über die bei jedem SMTP-Hop tatsächlich genutzten Adressen.

Die Replay-Lücke, die DKIM nicht schließt

Ein Angreifer, der eine legitim signierte Nachricht erlangt, kann sie massenhaft erneut versenden, ohne das anzutasten, was die Signatur abdeckt: Sie bleibt gültig, DMARC geht weiterhin durch, und die signierende Domain trägt den Rufschaden. Das ist DKIM Replay, das keine Schlüsselrotation wirklich beseitigt.

Die Weiterleitung, die die Signatur zerstört

Eine Mailingliste, die eine Fußzeile ergänzt, den Betreff mit einem Präfix versieht oder einen Abmelde-Header einfügt, entwertet den signierten Hash. DKIM bietet keine Möglichkeit, die Änderung zu beschreiben, also auch keine Möglichkeit, sie rückgängig zu machen, um die Ursprungssignatur zu prüfen.

Die Bounces, die bei einem Dritten landen

Wenn ein Server eine Nachricht zunächst annimmt und danach einen Bounce erzeugt, geht dieser Bounce an die Envelope-Adresse, die möglicherweise gefälscht ist. Das ist Backscatter: Ein unbeteiligtes Opfer erhält Unzustellbarkeitsberichte für Mail, die es nie versendet hat.

DKIM2 geht alle drei zugleich an: Jeder Hop bringt seine eigene nummerierte Signatur an, deklariert den von ihm genutzten Envelope und dokumentiert, was er verändert hat. Der Pfad wird prüfbar, und die Änderungen werden umkehrbar.

Wie weit ist die Standardisierung?

Eine Gruppe mit neuer Charta, drei Dokumente

Eine Arbeitsgruppe "dkim2" gibt es bei der IETF nicht, und das ist die erste Fehlerquelle. Die Arbeit läuft in der historischen Gruppe dkim, deren überarbeitete Charta die IESG am 20. Februar 2025 unter dem Vorsitz von Murray Kucherawy und Pete Resnick genehmigt hat.

Drei Gruppendokumente sind aktiv:

• draft-ietf-dkim-dkim2-spec-04 (5. Juli 2026), Standards Track, 43 Seiten, läuft am 6. Januar 2027 ab. Autoren: Richard Clayton (Yahoo), Wei Chuang (Google), Bron Gondwana (Fastmail).
• draft-ietf-dkim-dkim2-bcp-00 (18. Juni 2026), Todd Herr. Angenommen, aber bewusst zurückgestellt, solange die Gruppe keine Betriebserfahrung gesammelt hat.
• draft-ietf-dkim-dkim2-dns-00 (20. Juli 2026), Wei Chuang.

Was der Zeitplan sagt

Keines dieser Dokumente ist im Last Call der Arbeitsgruppe (WG Last Call), keines wurde bei der IESG eingereicht, keine RFC existiert. Die Meilensteine der Charta zielten jedoch auf "alle Dokumente bis zum 31. Dezember 2025 bei der IESG eingereicht": Der Rückstand beträgt rund sieben Monate, und der Zeitplan wurde nicht überarbeitet.

Im vergangenen Zeitraum gab es nur wenige tatsächliche Meilensteine. November 2025: Die Drafts motivation, header und mailversion werden nicht mehr gepflegt. 20. März 2026, auf der IETF 125: Die Spezifikation von Richard Clayton wird zum Hauptdokument, und das JSON-Format wird für die Beschreibung der Änderungen ausgewählt. 24. März 2026: erster Gruppen-Draft der Spezifikation. 24. Juni 2026: spec-03 führt das Tag nd= ein. 24. Juli 2026: DKIM-Session auf der IETF 126 in Wien.

Die toten Dokumente

Jeder 2025 verfasste Text über DKIM2 verweist auf Drafts, die inzwischen aufgegeben oder ersetzt wurden: Prüfen Sie stets die genannten Namen und Revisionen. draft-ietf-dkim-dkim2-motivation-02 ist abgelaufen; draft-ietf-dkim-dkim2-header-00 und draft-gondwana-dkim2-mailversion-00 sind als "Dead WG Document" markiert. Ihr Inhalt wurde übernommen, neu geschrieben oder verworfen.

Ein weiterer kursierender Fehler: Mehrere Veröffentlichungen behaupten, die Gruppe habe ein "Deployment-Profil per milter" angenommen. Das ist falsch. Am 8. Mai 2026 schrieb der Vorsitzende der Gruppe, dass "the working group does not wish to pursue adoption at this time".

Was DKIM2 konkret ändert

Die Mechanik beruht auf zwei getrennten Headern.

Der Header DKIM2-Signature

Jeder Hop fügt eine Zeile hinzu. Abschnitt 8 der Spezifikation legt die Pflichten fest: "The i=, m=, t=, d= and s= tags MUST be present. There MUST be either an nd= tag or both mf= and rt= tags. The other tags are optional."

Tag	Pflicht	Rolle
i=	ja	Sequenznummer des Hops. Der ursprüngliche Absender signiert mit i=1, jeder folgende Hop zählt hoch. Eine Lücke in der Nummerierung, und die gesamte Nachricht gilt als unsigniert.
m=	ja	Höchste Message-Instance-Nummer zum Zeitpunkt der Signatur.
t=	ja	Zeitstempel, ausgedrückt in Epoch-Sekunden UTC (ein Integer, kein formatiertes Datum).
d=	ja	Signierende Domain. Aus ihr wird die DNS-Abfrage zum Abruf des Schlüssels gebildet.
s=	ja	Tripel Selektor:Algorithmus:Signatur-base64.
mf=	bedingt	Beim Versand genutztes MAIL FROM, base64-kodiert, spitze Klammern inbegriffen.
rt=	bedingt	RCPT TO, base64, spitze Klammern inbegriffen. Mehrere Empfänger können gelistet werden.
nd=	bedingt	Domain, die den nächsten Hop signieren wird. Schließt mf= und rt= aus.
n=	nein	Freier Nonce, höchstens 64 Zeichen.
f=	nein	Flags.

Das Tag s= folgt der ABNF sig-set = selector ":" sig-name ":" message-sig, wobei sig-name den Wert rsa-sha256 oder ed25519-sha256 hat; mehrere Signaturen unterschiedlicher Algorithmen dürfen koexistieren, aber "a different selector MUST necessarily be used for each signature". Das d= wiederum muss exakt den am weitesten rechts stehenden Labels der in mf= genannten Domain entsprechen: d= ist also entweder diese Domain selbst oder eine ihrer übergeordneten Domains. Zu mf=<user@mail.example.com> passt somit d=example.com, während umgekehrt mf=<user@example.com> mit d=mail.example.com abgelehnt wird. Nur ein leeres mf=, also <>, der Fall der Unzustellbarkeitsberichte, ist von dieser Übereinstimmung befreit.

Auf der Kryptoseite schreibt die Spezifikation zum Signieren RSA mit mindestens 1024 Bit vor und verlangt von Prüfern, 1024 bis 2048 Bit zu akzeptieren; die Unterstützung größerer Schlüssel ist optional. Der öffentliche Exponent ist 65537, das Padding PKCS#1 v1.5, der Hash ungekürzt, SHA256 verpflichtend, und Ed25519 in der Variante PureEdDSA (RFC 8032, Abschnitt 5.1): "Signers SHOULD implement both RSA-SHA256 and Ed25519-SHA256, Verifiers MUST implement both". Eine mehr als 14 Tage alte Signatur darf ignoriert werden, aber das ist ein MAY, keine Pflicht.

Die Flags f= wurden überarbeitet. exploded zeigt an, dass die Nachricht an mehr als eine Adresse geht; fehlt das Flag, darf ein MTA annehmen, dass nur eine einzige Kopie existiert, und genau das ist der Hebel gegen Replay. donotexplode und donotmodify sind Verbote, die sich an Intermediäre richten. feedback fordert eine Rückmeldung an, sein Fehlen bedeutet, dass diese Rückmeldung nicht erwünscht ist, und feedhere erlaubt einem Intermediär, diese Rückmeldung weiterzuleiten, ohne das endgültige Ziel preiszugeben. Jedes unbekannte Flag muss ignoriert werden.

Ein Prüfer erzeugt einen der vier Zustände PASS, FAIL, PERMERROR oder TEMPERROR, in Anlehnung an RFC 8601.

Der Message-Instance

Der zweite Header beschreibt den Zustand der Nachricht und den Weg zurück zum vorherigen Zustand: "The m= and h= tags MUST be present. The r= tag is optional."

Das Tag m= ist die Revisionsnummer: 1 am Ursprung, hochgezählt bei jeder neuen Instanz; eine Lücke macht die Nachricht unprüfbar. Das Tag h= hat die Form sha256:<Hash der Header>:<Hash des Bodys>, beide in base64, und mehrere Sätze dürfen koexistieren. Das Tag r= enthält "the base64 encoded version of the JSON object that contains the recipes that allow the previous instance of the message to be recreated".

Wichtiger Punkt für Betreiber: Wenn Sie nichts ändern, fügen Sie keinen Message-Instance hinzu; ein Relay, das die Nachricht unverändert weitergibt, hat nichts zu beschreiben.

Die Recipes bilden ein JSON-Objekt, identifiziert durch das Schema https://dkim2.org/schemas/recipe-v1, mit einem Schlüssel "h" für die Header und/oder "b" für den Body. Jedes Recipe ist ein Array von Schritten, die jeweils genau einen Schlüssel tragen: {"c": [Anfang, Ende]} kopiert einen Bereich von Zeilen oder Instanzen, {"d": ["..."]} gibt literale Daten aus. Ein "b": null zeigt einen nicht rekonstruierbaren vorherigen Body an; ein leeres Array unter einem Feldnamen bedeutet "entferne alle seine Vorkommen". Klassische Falle: Header werden von unten nach oben nummeriert, Body-Zeilen von oben nach unten.

Ihre DNS-Schlüssel ändern sich nicht

Der öffentliche Schlüssel wird unter <Selektor>._domainkey.<d=> abgerufen, genau wie heute: "these keys are no different, and are stored in the same locations as those for DKIM1". Kein neuer Eintragstyp, keine vorzubereitende DNS-Migration.

nd= oder mf=/rt=: die Übergabekette

Eine Folge mehrerer DKIM2-Signature mit nd= ist erlaubt, aber sie "MUST end with a DKIM2-Signature that contains mf= and rt= tags", und die in nd= deklarierte Domain muss exakt dem d= der nächsten Signatur in der Reihenfolge der i= entsprechen.

Abschnitt 9.3 stellt diese Variante als Übergabekette für imaginäre Hops vor. Nehmen Sie ein System, das Mail auf einer Domain empfängt und von einer anderen aus weitersendet: Die Kontinuität zwischen dem rt= des vorherigen Hops und dem mf= des folgenden Hops ist unterbrochen. Statt eine Signatur mit erfundenen mf= und rt= zu fabrizieren, die die Kette mit fiktiven Adressen verschmutzen würde, kündigt das System über nd= an, wer der nächste Signierende sein wird. Das ist die Option, die die Spezifikation empfiehlt.

Beispiel-Header

spec-04 enthält kein einziges Beispiel für eine Nachricht oder einen Header: Der Draft, der sie liefern sollte, draft-robinson-dkim2-message-examples-00, ist 2025 abgelaufen. Das folgende Beispiel ist daher aus der ABNF-Grammatik des Dokuments rekonstruiert und hat keinerlei normativen Wert.

Szenario mit zwei Hops: Ein Absender schreibt an eine Mailingliste, die Liste fügt einen Header List-Unsubscribe hinzu und sendet weiter.

DKIM2-Signature: i=2; m=2; t=1740001000; d=test2.dkim2.com;
  mf=PGJvdW5jZUB0ZXN0Mi5ka2ltMi5jb20+; rt=PHJlY2lwaWVudEBleGFtcGxlLmNvbT4=;
  s=ed25519:ed25519-sha256:FDYZopU8W+c7...;
DKIM2-Signature: i=1; m=1; t=1740000000; d=test1.dkim2.com;
  mf=PHNlbmRlckB0ZXN0MS5ka2ltMi5jb20+; rt=PGxpc3RAdGVzdDIuZGtpbTIuY29tPg==;
  s=ed25519:ed25519-sha256:oKZmf7rabJv4...;
Message-Instance: m=2; h=sha256:u4RFAizDeEqt...:SgG5fNGEg1x2...;
  r=eyJoIjp7Imxpc3QtdW5zdWJzY3JpYmUiOltdfX0=;
Message-Instance: m=1; h=sha256:SLtzk6LO68CC...:SgG5fNGEg1x2...;
Received: from test1.dkim2.com by relay.example.com; ...
List-Unsubscribe: <mailto:unsub@relay.example.com>
From: sender@test1.dkim2.com
To: list@test2.dkim2.com
Subject: ...

Entschlüsseln wir das. Die Envelope-Werte stehen in base64, spitze Klammern inbegriffen, wie es die Spezifikation verlangt. Beim ersten Hop hat mf= den Wert <sender@test1.dkim2.com> und rt= den Wert <list@test2.dkim2.com>. Beim zweiten sendet die Liste weiter: mf= hat den Wert <bounce@test2.dkim2.com> und rt= den Wert <recipient@example.com>. Die Kontinuität der Kette ist mit bloßem Auge sichtbar, und genau darin liegt der Nutzen des Mechanismus.

Die lehrreichste Stelle ist das r= des Message-Instance mit der Nummer 2. Aus base64 dekodiert ergibt es:

{"h":{"list-unsubscribe":[]}}

Auf Deutsch: "um zur vorherigen Instanz zurückzukehren, entferne alle Vorkommen des Feldes List-Unsubscribe". Ein Prüfer, der die Signatur i=1 validieren will, wendet dieses Recipe an, erhält die Nachricht so zurück, wie der Absender sie versendet hat, berechnet den Hash neu und vergleicht. Die Änderung hat die Kette nicht zerstört: Sie wurde deklariert und umkehrbar gemacht.

Die Werte von s= und die Hashes in h= sind gekürzt: Sie würden von privaten Schlüsseln und von einer realen Nachricht abhängen und sind daher vom Leser nicht nachrechenbar. Das Beispiel soll die Struktur der Header zeigen, es ist nicht zum Nachprüfen gedacht.

Was sich seit den Drafts von 2025 geändert hat

Wenn Sie Ende 2025 einen DKIM2-Leitfaden gelesen haben, ist so gut wie die gesamte darin beschriebene Syntax verschwunden.

Element von 2025	Status in spec-04
Einzelner Header DKIM2: (Active/Historical)	Gestrichen, ersetzt durch das Paar DKIM2-Signature und Message-Instance
Header Mail-Version:	Gestrichen, überführt in Message-Instance; die kompakten Recipes weichen base64-kodiertem JSON
mv=	Umbenannt in m=
v=	Existiert nicht und wird nicht existieren
pp= (Stellvertretung)	Gestrichen; nd= nimmt diesen Platz seit spec-03 ein (24. Juni 2026)
a=	Gestrichen, in s= aufgegangen
b=	Gestrichen, von s= absorbiert
bh=	Verschoben in das h= des Message-Instance
h= (Liste der signierten Felder)	Bedeutung umgekehrt: DKIM2 signiert alles außer einer Ausschlussliste
t=	Wechselt vom formatierten Date-Time zum Epoch-Integer
f=modifiedbody, f=modifiedheader	Gestrichen, als redundant zu den Versionsdaten bewertet
f=donotforward	Gestrichen
f=feedhere	Neu, eingeführt in spec-03

Das Fehlen von v= ist gewollt

Abschnitt 8 begründet es: "Experience from IMF onwards shows that it is essentially impossible to change version numbers. If it becomes necessary to change DKIM2 in the sort of incompatible way that a v=2 / v=3 version number would support, it is expected that header fields will be labelled as DKIM3 instead." Ein größerer Bruch würde also einen Header DKIM3-Signature hervorbringen, keine interne Versionsnummer.

Die Umkehrung des h=

DKIM zählt die Felder auf, die es signiert. DKIM2 macht es umgekehrt: Es signiert alles außer sieben Feldfamilien, die in Abschnitt 4.1 aufgelistet sind, nämlich ARC-*, Authentication-Results, Delivered-To, DKIM-Signature, Received, Return-Path und X-*. Genau die Felder, die ein Intermediär im Transit legitimerweise hinzufügt oder ändert.

ARC geht in den Ruhestand

ARC setzte am selben Symptom an: Weiterleitung zerstört SPF und DKIM. Doch es beschränkte sich darauf, ein versiegeltes Zeugnis der vor dem Relay festgestellten Authentifizierungsergebnisse zu transportieren, ohne je die Replay-Lücke zu schließen. Das ist Nachvollziehbarkeit, keine Ende-zu-Ende-Integrität. Die IETF stuft es heute in den Status "Historic" um und konzentriert die Anstrengungen auf DKIM2, das die Ursache statt des Symptoms behandelt. Die Einzelheiten dieser Umstufung und ihre praktischen Folgen behandelt ein eigener Artikel.

Wie weit sind die Implementierungen?

Hier war das Jahr entscheidend: Es ging von null Implementierungen auf drei, die sich untereinander verstehen, und eine vierte wurde seitdem angekündigt.

Am 4. Juli 2026 versammelte eine Interoperabilitätsdemonstration drei unabhängige Implementierungen: mail-auth in Rust (Stalwart Labs), die Python-Implementierung von Bron Gondwana und die Go-Implementierung von Steve Atkins. Signieren, Prüfen und Rekonstruktion über Recipes wurden in beide Richtungen getestet, auch auf Ketten mit mehreren Hops. Berichtetes Ergebnis: Bei deaktiviertem Header-Folding bestehen alle Kombinationen. Dabei wurden zwei Folding-Bugs gefunden, einer auf Go-Seite (striktes base64, ohne Entfernen der Leerzeichen), einer auf Python-Seite (Aufteilung an : ohne vorheriges Unfolding).

Am 8. Juli 2026 hat Bron Gondwana die Testsuite in der GitHub-Organisation dkim2wg zusammengeführt und eine vierte Implementierung in C (PhoenixDKIM) erwähnt.

Zum Zeitplan gibt es Prognosen, datiert und zugeordnet. Laura Atkins (Word to the Wise, 23. April 2026) erwartet funktionierendes DKIM2 bei den großen Anbietern bis Ende 2026. Al Iverson (Spam Resource, 21. April 2026) erinnert daran, dass die Spezifikation noch nicht final ist und sich die Dinge noch ändern können, und betont, dass sich die Schlüssel selbst bislang nicht ändern. Keine Primärquelle nennt ein Pflichtdatum für Versender, und die kursierenden Pflichtzeitpläne stützen sich auf keine Primärquelle.

Was noch nicht entschieden ist

Die Gruppe traf sich am 24. Juli 2026 auf der IETF 126 in Wien. Die folgenden Punkte wurden dort aufgeworfen, nicht entschieden; die Protokolle der Session sind noch nicht veröffentlicht.

1. Null-Recipes für Header: Sollen sie gestrichen werden, weil kein Anwendungsfall erkennbar ist?
2. Irreführende Message-Instance: Die aktuellen MUST NOT sind zu streng und haben während der Interoperabilitätstests zu abgewiesenen Nachrichten geführt.
3. Post-Quanten-Algorithmus: Die Gruppe sucht Expertenrat; die erkannte Schwierigkeit ist, dass sehr lange Schlüssel im DNS über UDP schlecht durchkommen.
4. Groß- und Kleinschreibung der Feldnamen: Sollen in den JSON-Recipes Kleinbuchstaben vorgeschrieben werden?
5. Unzustellbarkeitsberichte: Braucht es ein eigenes Flag und das Weglassen des Message-Instance?
6. Alignment und DMARC: "The DKIM2 spec deliberately stays away from saying anything about DMARC", das Thema wird an das Best-Practice-Dokument verwiesen. Erwartet wird ein Alignment zwischen dem ursprünglichen From:, dem anfänglichen MAILFROM und dem d= der ersten DKIM2-Signature, während DKIM2 heute nur das Alignment der beiden letzteren verlangt.
7. Nur mit DKIM1 weitergeleitete Nachrichten: Sollen sie mit DKIM2 signiert werden?
8. Feedback-Schleifen: Soll ihr Format standardisiert werden?

Diese Liste ist das beste Maß für die tatsächliche Reife des Protokolls und der Grund, warum das Best-Practice-Dokument eingefroren bleibt.

Operative Auswirkungen

Die Folgen sind je nach Rolle nicht dieselben, und die Verteilung ist unausgewogen.

Domaininhaber: nichts zu tun

Heute ist keine Maßnahme erforderlich. Sinnvoll ist einzig, ein gesundes DKIM1 mit kontrollierter Schlüsselrotation und ein funktionierendes DMARC zu behalten: Das ist das Fundament, auf dem DKIM2 aufsetzen wird.

Eine Klarstellung, die immer wieder nötig ist: DMARC verschwindet nicht. Es behält einen eigenen Wert, den DKIM2 nicht nachbildet: insbesondere die aggregierten Reports auf Domain-Ebene und die Erkennung von Spoofing der From:-Domain.

ESPs, Relays und Mailinglisten: die eigentliche Baustelle

Bei jedem Hop signieren, Änderungen in Form von Recipes nachverfolgen und vor allem einen unterschätzten Nebeneffekt einplanen: den Zustrom eingehender asynchroner Bounces. DKIM2 gibt die Nachricht an den vorherigen Hop zurück, was Volumen und Art der zu verarbeitenden Rückläufer verändert, ein Punkt, den Laura Atkins besonders hervorhebt.

Ein weiterer Aufmerksamkeitspunkt: Die Doppelsignatur (die der Marke und die der Plattform), wie sie heute in DKIM praktiziert wird, lässt sich nicht unmittelbar übertragen. Al Iverson merkte am 9. Mai 2026 an, dass es streng genommen keine direkten Mehrfachsignaturen gebe.

Prüfer: oben anfangen

Die Prüfung verläuft entgegen der Intuition: Man startet beim höchsten i=, der jüngsten Signatur, und arbeitet sich dann die Kette hinauf, indem man die Recipes anwendet, um die vorherigen Instanzen zu rekonstruieren.

Vorbereitungsplan

1. Inventarisieren Sie Ihre Mailströme: wo Sie signieren, wo Sie prüfen, welche Zwischen-Hops existieren, welche Mechanismen zum Umschreiben des Envelopes (SRS, VERP) im Einsatz sind.
2. Sanieren Sie DKIM1: aktuelle Selektoren, Schlüssel in korrekter Länge, dokumentierte Rotation.
3. Bauen Sie einen Prototyp auf Relay-Seite, falls Sie ein Relay betreiben: mf= und rt= in base64 mit spitzen Klammern, Nummerierung i=, Epoch-Zeitstempel, Wahl der Algorithmen.
4. Modellieren Sie Ihre gängigen Änderungen als JSON-Recipes: Fußzeile, Betreffpräfix, List-Unsubscribe. Diese Übung deckt die schwierigen Fälle auf.
5. Dimensionieren Sie die Verarbeitung eingehender asynchroner Bounces, den am häufigsten vergessenen Punkt.
6. Fassen Sie Ihr DNS für DKIM2 nicht an: Es gibt nichts Neues zu veröffentlichen.
7. Beobachten Sie draft-ietf-dkim-dkim2-spec und planen Sie Feature-Flags ein: vier Revisionen in gut drei Monaten, die Syntax bewegt sich noch.

FAQ

Ist DKIM2 2026 ein Standard?

Nein. Am 25. Juli 2026 gibt es keine DKIM2-RFC: Die Spezifikation steht im Stadium draft-ietf-dkim-dkim2-spec-04, veröffentlicht am 5. Juli 2026, und kein Dokument der Gruppe befindet sich im Last Call oder wurde bei der IESG eingereicht. Die Meilensteine der Charta zielten auf eine Einreichung bis zum 31. Dezember 2025, also rund sieben Monate Rückstand.

Muss ich meine DNS-Einträge für DKIM2 ändern?

Nein. Die Spezifikation stellt klar, dass die DKIM2-Schlüssel nicht anders sind und an denselben Orten gespeichert werden wie die von DKIM1, unter selektor._domainkey.ihredomain. Kein neuer Eintragstyp, keine einzuplanende DNS-Migration.

Was ist der Unterschied zwischen DKIM2-Signature und Message-Instance?

DKIM2-Signature wird von jedem SMTP-Hop hinzugefügt: Sequenznummer i=, Zeitstempel, signierende Domain, Signatur und genutzter Envelope. Message-Instance beschreibt den Zustand der Nachricht und den Weg zurück zum vorherigen Zustand, über base64-kodierte JSON-Recipes im Tag r=. Ein Intermediär, der nichts ändert, fügt eine Signatur hinzu, aber keinen Message-Instance.

Ersetzt DKIM2 DMARC?

Nein. DMARC behält einen eigenen Wert, den DKIM2 nicht nachbildet: aggregierte Reports auf Domain-Ebene und Erkennung von Spoofing der From:-Domain. Die Spezifikation vermeidet es im Übrigen bewusst, über DMARC zu sprechen, und verweist die Frage des Alignments an das Best-Practice-Dokument.

Gibt es funktionierende Implementierungen von DKIM2?

Ja: Drei Implementierungen haben ihre Interoperabilität nachgewiesen, und eine vierte wurde seitdem angekündigt, ohne an der Demonstration teilgenommen zu haben. Am 4. Juli 2026 versammelte eine Interoperabilitätsdemonstration mail-auth in Rust (Stalwart Labs), eine Python-Implementierung von Bron Gondwana und eine Go-Implementierung von Steve Atkins, auch auf Ketten mit mehreren Hops. Eine vierte Implementierung in C, PhoenixDKIM, wurde erst danach erwähnt, am 8. Juli 2026, als die Testsuite in der GitHub-Organisation dkim2wg zusammengeführt wurde.

Was muss ich heute tun, wenn ich einfach eine Unternehmensdomain betreibe?

Nichts, das speziell DKIM2 betrifft: Stellen Sie sicher, dass Ihr aktuelles DKIM korrekt veröffentlicht und signiert ist, dass Ihr DMARC steht und überwacht wird, und dass Ihre Schlüsselrotation dokumentiert ist. Die eigentliche Migrationsarbeit betrifft die ESPs, die Relays und die Mailinglisten, nicht die Domaininhaber.

📖 Glossar

DKIM Replay

Massenhafter oder auf andere Ziele gerichteter erneuter Versand einer bereits von einer legitimen Domain signierten Nachricht, ohne das zu verändern, was die Signatur abdeckt: Diese bleibt gültig, denn DKIM signiert den Inhalt, aber weder den SMTP-Envelope noch die Route. Der Ruf der signierenden Domain leidet unter Mail, die sie nicht versendet hat, und keine DKIM1-Gegenmaßnahme (Rate-Limit pro Selektor, Schlüsselrotation, strengeres DMARC) schließt die Lücke. In DKIM2 umfasst die Signatur den Envelope des Hops und verkettet den Pfad über die Nummer i=.

Backscatter

Unerwünschte Bounces (NDR, DSN) oder automatische Antworten, die an einen unbeteiligten Dritten gehen, dessen Adresse im MAIL FROM oder im Return-Path gefälscht wurde: Sein Postfach wird mit Unzustellbarkeitsberichten überflutet. In DKIM1 lehnt man schon während des SMTP-Austauschs ab statt erst danach, mit SRS oder VERP zur Verfolgung der Bounces; in DKIM2 laufen die Rückläufer die signierte Kette hinauf bis zum vorherigen Hop, also zu einem tatsächlich beteiligten Akteur.

Message-Instance

DKIM2-Header, der den Zustand einer Nachricht zu einem Zeitpunkt ihres Wegs beschreibt: m= (Revisionsnummer) und h= (Hash der Header und des Bodys) verpflichtend, r= (Recipes) optional.

Recipe

JSON-Beschreibung, base64-kodiert im Tag r= eines Message-Instance, mit der sich die vorherige Instanz der Nachricht rekonstruieren lässt.

Quellen

• draft-ietf-dkim-dkim2-spec, die Spezifikation
• draft-ietf-dkim-dkim2-bcp, die Best Practices
• draft-ietf-dkim-dkim2-dns, der DNS-Teil
• Dokumente der IETF-Arbeitsgruppe dkim
• Protokoll der DKIM-Session auf der IETF 125
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 8463: ein neues Signaturverfahren für DKIM (Ed25519)
• Laura Atkins, "DKIM2: What it means for the future of email"
• Al Iverson, "What is DKIM2?"
• Al Iverson, "More on DKIM2: VERP, async bounces, signatures and hops"

DKIM2 bleibt ein laufendes Projekt. Diese Seite wird mit jeder neuen Revision des Spezifikations-Drafts aktualisiert.

Prüfen Sie Ihr aktuelles DKIM

Wiederverwendet wird Ihre aktuelle DKIM-Konfiguration (RFC 6376). Prüfen Sie Ihre Selektoren live mit dem DKIM Record Checker und validieren Sie die Syntax jedes veröffentlichten Eintrags mit dem DKIM Syntax Validator.

Verwandte E-Mail-Authentifizierungs-Anleitungen

• ARC wird bei der IETF auf "Historic" gesetzt - Was die Umstufung wirklich ändert und was nicht
• DMARCbis: Neuerungen im kommenden Standard - Die Weiterentwicklungen von DMARC mit DMARCbis
• Was ist ARC (Authenticated Received Chain)? - Die ARC-Authentifizierungskette verstehen
• BIMI, VMC und CMC: DNS-Kompatibilität - Vollständiger Leitfaden zu BIMI und Markenzertifikaten
• Gmail Bulk Sender: die neuen Anforderungen - Einhaltung der Gmail-Massenversandregeln