Zusammenfassung

  • Revision 01 des DKIM2-Best-Practices-Entwurfs der DKIM Working Group wurde am 9. September 2026 bereitgestellt. Sie ist ein aktiver Internet-Draft, keine veröffentlichte BCP und kein IETF-Beschluss zur Ablösung bestehender Verfahren.
  • Absender sollen DKIM1 und DKIM2 nutzen, bis DKIM2 „effektiv allgegenwärtig“ ist. Schwelle, Nenner, Beobachtungszeitraum, Population und erklärende Instanz sind nicht definiert.
  • Der tägliche Anteil mit und ohne DKIM2 kann die Policy eines Empfängers steuern. Er bildet nicht automatisch Absender, Weiterleiter und andere Empfänger außerhalb seiner Sicht ab.
  • Ein aggregierter, datenschutzgerechter Ausstiegsnachweis könnte Umfang, Ausnahmen, Entscheidung und Rückkehrbedingung festhalten. Das ist Daniel Kades Vorschlag, keine Forderung des Drafts.

Die Übergangsregel besitzt ein Zielwort statt eines Messpunkts

Revision 01 erschien am 9. September. Laut Änderungsverzeichnis wurden Abschnitte neu geordnet und benannt sowie weite Teile des Textes überarbeitet. Als Gründe nennt es die laufende Entwicklung von DKIM2 und den zeitlichen Abstand zu Revision 00. Der Datatracker-Eintrag führt das Dokument als WG Document der DKIM Working Group und mit IESG-Status I-D Exists; Shepherd, zuständiger Area Director und Telechat-Termin fehlen.

Im Kopf des Dokuments steht als beabsichtigter Status Best Current Practice, während Datatracker derzeit Intended RFC status: None zeigt. Diese Metadatenabweichung ändert den heutigen Stand nicht: Der Text ist weder BCP noch RFC und kann weiter verändert werden oder auslaufen.

Abschnitt 3.3 formuliert die Koexistenz: Ausgehende Nachrichten sollen mit DKIM1 und DKIM2 signiert werden, bis DKIM2 „effectively ubiquitous“ ist. Die Wendung erscheint zweimal, aber ohne Prozentzahl, Stichtag oder Zeitfenster. Unklar bleibt auch die Zähleinheit. Nachrichtenvolumen, Domains, Organisationen und vollständige Transportketten ergeben verschiedene Verteilungen.

Ein weltweiter Einheitswert wäre nicht zwingend die richtige Lösung. Mailbetrieb ist dezentral, und Betreiber tragen unterschiedliche Risiken. Doch gerade deshalb muss erkennbar sein, auf welcher Population eine lokale Ausstiegsentscheidung beruht. Sonst klingen zwei nicht vergleichbare Messungen wie derselbe Befund.

Abschnitt 3.2 betrifft zudem eine andere Form von Parallelität: mehrere DKIM2-Signaturen mit unterschiedlichen kryptografischen Algorithmen. Algorithmus-Redundanz innerhalb von DKIM2 und Protokollkoexistenz mit DKIM1 haben eigene Abhängigkeiten. Ein pauschales „DKIM2 bereit“ belegt beides nicht.

Der Empfänger misst seine Zustellung, nicht das gesamte Ökosystem

Kommt eine Nachricht ohne DKIM2 an, soll ein DKIM1-fähiger Empfänger auf seine bestehende DKIM1-Disposition zurückgreifen. Diese Policy darf sich mit dem täglich beobachteten Anteil von Nachrichten mit und ohne DKIM2 sowie dem Verhalten der Mailbox-Inhaber verändern. Während der Übergangszeit soll bloßes Fehlen von DKIM2 jedoch nicht allein zur Ablehnung führen.

Das schützt legitime Nichtteilnehmer und unvollständige Pfade. Zugleich erhält „ohne DKIM2“ mehrere Bedeutungen. Der Absender kann noch nicht teilnehmen, ein Forwarder kann außerhalb des Systems liegen, eine dokumentierte Ausnahme kann greifen, eine Signatur kann entfernt worden sein oder die Messung kann den Pfad falsch einordnen.

Große Consumer-Maildienste, Unternehmens-Gateways, Mailinglisten und regionale Provider sehen andere Populationen. Nach Nachrichten gezählt dominieren Massenversender. Nach Domains gezählt verschwindet deren Größenunterschied. Wer erst hinter einem Abuse-Filter zählt, nimmt abgewiesene Quellen gar nicht in den Nenner auf.

Die Statistik kann daher korrekt und die Verallgemeinerung trotzdem falsch sein. Für eine lokale Policy genügt eine lokale Sicht. Wer daraus Interconnection- oder Ökosystemreife ableiten will, muss Population, Ausschlüsse, Gewichtung und Zeitraum nennen.

Pfadzustände sind keine weltweiten Reifegrade

Abschnitt 6 unterscheidet drei Zustände. Bei Never Left hat jede teilnehmende Administrative Management Domain beim Ausgang signiert. In and Out steht für eine unterbrochene Teilnahme. Never Entered bedeutet, dass keine DKIM2-Signatur ankam. Damit lässt sich ein beobachteter Nachrichtenpfad beschreiben, aber kein globaler Rollout bewerten.

Forwarder sind dabei ein eigener Kontrollpunkt. Ein teilnehmender Weiterleiter muss vorhandene DKIM2- und DKIM1-Signaturen zu prüfen versuchen und jede behandelte Nachricht mit DKIM2 signieren, auch ohne Inhaltsänderung. Signiert wird am letzten Hop vor dem Verlassen der eigenen Infrastruktur. Selbst ein bereiter Ursprung und ein bereites Ziel garantieren daher keine vollständige Kette.

Abschnitt 7.1 erwartet, dass Empfänger bei zunehmender Reife vor allem auf DKIM2 setzen und nicht dauerhaft zwei Verifikationspfade betreiben. Wann Reife erreicht ist, wird wiederum nicht definiert. Das Dokument gibt die Richtung vor, aber keinen Abschlussnachweis.

Auch die mit Fragezeichen markierten Teile zu DMARC und SPF dürfen nicht als Stilllegungsplan gelesen werden. Die Einleitung nennt sie ungelöste Fragen der Working Group und ihren Text spekulativ. Revision 01 prüft mögliche Folgen künftiger Verbreitung; sie beschließt kein Ende von DKIM1, DMARC oder SPF.

Bei bekannten DKIM2-Domains ist Fehlen ein anderes Signal

Der Security-Teil beschreibt ein Downgrade-Risiko der Koexistenz. Wer eine DKIM2-Signatur auf dem Pfad entfernen kann, könnte einen Empfänger, der DKIM2 noch nicht verlangt, auf eine schwächere reine DKIM1-Behandlung zurückfallen lassen. Besondere Prüfung wird empfohlen, wenn eine sonst als DKIM2-Nutzer bekannte Domain mit plausibler DKIM1-, aber ohne DKIM2-Signatur eintrifft.

Die Quellen belegen weder einen konkreten Angriff noch eine Häufigkeit. Der Fall zeigt dennoch, warum die allgemeine Abwesenheitsquote zu grob ist. Eine noch nie mit DKIM2 beobachtete Domain und eine bekannte DKIM2-Domain mit plötzlich verschwundener Signatur gehören nicht in denselben Risikowert.

Der Ausstieg muss deshalb reversibel geplant werden. Ein sprunghafter Anstieg bekannter Domains mit nur DKIM1, ein Rückgang vollständiger Ketten oder Zustellprobleme in einer Ausnahmegruppe können Rückkehrsignale sein. Die Regel sollte vor der Policy-Änderung feststehen.

Ein begrenzter Ausstiegsnachweis

Statt eines Zertifikats weltweiter Allgegenwart schlage ich einen Nachweis je Betreiber und Entscheidung vor. Er enthält:

  1. erklärenden Betreiber, Rolle und kontrollierte Entscheidung;
  2. betrachtete Absender-, Forwarder- und Empfängerkohorten;
  3. Nenner, Gewichtung, Ausschlüsse und Beobachtungsfenster;
  4. Raten für DKIM2-Präsenz, vollständige und teilweise Ketten sowie Abwesenheit;
  5. verwendete Verifikations-, Zustell- oder Nutzerindikatoren;
  6. bekannte DKIM2-Domains, die ohne DKIM2 ankamen;
  7. verbleibende Ausnahmen mit DKIM1-Abhängigkeit;
  8. angewandte Schwelle und Policy-Version;
  9. Entscheidungszeit, Rückkehrsignal und nächstes Review.

Die öffentliche Fassung kann aggregiert sein. Empfängeradressen, individuelles Verhalten und Nachrichteninhalte sind nicht nötig. Wohl aber eine Bezeichnung des Geltungsbereichs: lokale Bereitschaft, eine benannte Interconnection-Kohorte oder breiter zusammengetragene Community-Evidenz.

Das folgt der Minimum-Initial-Specification-Logik von Heng Lu: Gemeinsam standardisiert wird nur die kleinste Koordinationsgrundlage, während Annahme und Policy bei den betroffenen Akteuren bleiben.

Evidenzgrenze

Die Dokumenthistorie belegt Revisionen und Prozesszustand; der offizielle 00–01-Vergleich den Umfang der Textänderung. DKIM2-Basisspezifikation und DNS-Dokument sind ebenfalls aktive Drafts.

Die geltenden RFCs beschreiben DKIM, SPF, Authentication-Results und DMARC, messen jedoch keine DKIM2-Verbreitung. Im Quellenpaket fehlen repräsentative Erhebung, Gesamtkosten, gemessener Angriff und Abschaltdatum. Dieser Beitrag leitet daraus keine Rollout-Quote und keinen Ruhestandskalender ab.

Quellen