Zusammenfassung

  • draft-chuang-dkim2-sender-policy-01 wurde am 12. September 2026 als Individual Submission veröffentlicht. Der Entwurf ist nicht von einer IETF-Arbeitsgruppe angenommen; ein zuständiger Area Director ist nicht verzeichnet.
  • Das Kennzeichen unaligned stammt bereits aus Revision 00. Revision 01 ergänzt eine prüfbare Vorbedingung für die ursprüngliche Nachricht und empfohlene Kontrollen zur Bindung an den Empfänger.
  • Laut Vorschlag bedeutet unaligned auf der maßgeblichen Grenzsignatur, dass keine DMARC-Ausrichtungsprüfung erwartet wird; das Ausrichtungsergebnis soll pass anzeigen.
  • Ein belastbarer Entscheidungsnachweis muss deshalb unterscheiden, ob Ausrichtung geprüft oder erlassen wurde, und die frühere Signatur, den betrachteten From-Zustand sowie erklärende und akzeptierende Instanz festhalten.

Die grüne Anzeige kommt am Ende, die Begründung davor

Revision 01 setzt nicht bei der letzten Ergebniszeile an, sondern beim Zustand der Nachricht vor dem Eintritt in die DKIM2-Verarbeitung. Die ursprüngliche Nachricht muss eine erfolgreiche DKIM-Signatur tragen, die nach DMARC ausgerichtet ist. Diese Signatur soll außerdem für einen weiteren DKIM2-Empfänger weiterhin verifizierbar sein. Die Ausnahme stützt sich damit auf einen früheren, erneut prüfbaren Authentifizierungszustand.

Hinzu kommen zwei empfohlene Plausibilitätsprüfungen. Signierte To- oder Cc-Felder sollen mit dem Empfänger aus SMTP RCPT TO verglichen werden. Zudem soll die signierte Empfängerdomain zur d=-Domain des ersten DKIM2-Signierenden passen. Beide Kontrollen sollen verhindern, dass ein für einen bestimmten Transportkontext gedachter Verzicht als frei übertragbare Erlaubnis für beliebige Empfänger endet.

Der offizielle Vergleich der Revisionen 00 und 01 ist für die Einordnung entscheidend. Das Wort unaligned gab es schon zuvor. Neu ist nicht die bloße Möglichkeit einer Ausnahme, sondern ihre stärkere Einbettung in Herkunftsnachweis und Empfängerbezug. Wer Revision 01 als Erfindung des Kennzeichens beschreibt, verfehlt die Änderung. Wer aus den neuen Voraussetzungen einen Beweis der aktuellen Ausrichtung ableitet, überdehnt sie.

Zwei Zeitpunkte werden in einen Wert gepresst

„Die ursprüngliche Nachricht war beim Eintritt ausgerichtet“ ist eine Aussage über die Vergangenheit. „Die aktuell sichtbare Identität ist beim letzten Empfänger ausgerichtet“ wäre eine Aussage über die Gegenwart. Die Aussagen betreffen möglicherweise verschiedene Nachrichtenzustände, Identitäten und administrative Grenzen. Eine frühere Signatur kann die Entscheidung begründen, eine spätere Ausrichtungsprüfung zu erlassen. Sie ersetzt aber nicht die Prüfung, die erlassen wurde.

Genau an diesem Punkt wird pass semantisch zu eng. In einer üblichen DMARC-Auswertung lesen Menschen und Systeme das Ergebnis als Antwort auf eine Messfrage: Stimmt eine authentifizierte Identität hinreichend mit der sichtbaren From-Domain überein? Im unaligned-Pfad kann dieselbe Zeichenfolge eine Policy-Antwort ausdrücken: Diese Messung war hier nicht erforderlich. Der unmittelbare Empfänger kennt seine lokale Regel. In einer aggregierten Statistik, einer Sicherheitsoberfläche oder einer späteren Untersuchung fehlt sie möglicherweise.

Die etablierten Dokumente liefern dafür klare Bezugspunkte. RFC 9989 beschreibt die DMARC-Ausrichtung. RFC 5598 ordnet die Rollen und administrativen Domänen der Internet-Mailarchitektur. RFC 8601 zeigt, weshalb Authentifizierungsergebnisse an eine Vertrauensgrenze gebunden sind und ein von außen stammender Ergebnis-Header nicht einfach übernommen werden darf. Die DKIM2-Basisspezifikation und der Entwurf zu Best Practices wollen Bearbeitung über Vermittler hinweg nachvollziehbar machen. Keine dieser Grundlagen macht die lokale Ausnahme eines Empfängers automatisch zur Tatsache für den nächsten.

Der alternative Bruch ist sichtbarer

Der Sender-Policy-Entwurf beschreibt auch eine andere Möglichkeit: Ein Relay kann From umschreiben, die „Verantwortung“ für die Nachricht übernehmen und nachfolgende Empfänger dazu bringen, frühere Authentifizierung außer Betracht zu lassen. Das beeinträchtigt die Kontinuität der ursprünglichen Absenderidentität, markiert aber einen deutlicheren Verantwortungswechsel. unaligned bewahrt mehr sichtbare Kontinuität und verlangt dafür eine feinere Beweiskette.

Beide Wege verteilen Kosten. Umschreiben kann Zuordnung, Antworten und Benutzererwartungen verändern. Eine Ausrichtungsbefreiung kann die Darstellung erhalten, belastet jedoch Protokollierung, Berichte und spätere Auslegung. Eine gemeinsame Erfolgsquote verdeckt diese Unterschiede. Gute Governance muss nicht eine Variante verbieten, sondern den tatsächlich gewählten Verantwortungsmodus lesbar halten.

Dazu braucht es keine zentrale Einheitsentscheidung. Empfänger dürfen dieselben Nachweise nach ihrer eigenen Risikopolitik unterschiedlich behandeln. Interoperabel sein muss die Beschreibung des Geschehens: Ausrichtung geprüft und bestanden; Prüfung aufgrund einer Grenzpolicy erlassen; zugrunde liegende frühere Signatur; verwendeter From-Zustand; Domain, die unaligned erklärte; Empfänger, der die Ausnahme akzeptierte. Ob dies durch einen eigenen Wert, einen strukturierten Grund oder einen gebundenen Entscheidungsdatensatz geschieht, ist nachgeordnet.

Der Grund muss allerdings an Beleg und Vertrauensgrenze haften. Wird er losgelöst weitergereicht, kann eine lokale Bewilligung wie ein allgemein gültiger Authentifizierungsfakt wirken. Auch die Benutzeroberfläche darf nicht behaupten, „DMARC-Ausrichtung bestanden“, wenn der Prüfpfad festhält, dass sie nicht verlangt wurde. „Nach lokaler Policy akzeptiert“ ist eine andere und präzisere Aussage.

Die Governance-Texte von Heng Lu bieten einen passenden Maßstab. Ein Policy Mirror kann formale Regeln spiegeln, ohne die tatsächliche Ausübung von Entscheidungsmacht abzubilden. Eine minimale Anfangsspezifikation kann den notwendigen Entscheidungsnachweis standardisieren und spätere lokale Entscheidungen offenlassen. Und wer Realität statt Fürsprache zum Produkt macht, muss auch den Status des Entwurfs nüchtern benennen: aktive Individual Submission, nicht angenommene IETF-Policy.

Quellen