Zusammenfassung

  • Ein DKIM-Erfolg belegt eine gültige Signatur über ausgewählte, kanonisierte Nachrichtenteile mit dem Schlüssel des Selectors s= unter der Signierdomain d=. Er autorisiert nicht automatisch die im From-Feld sichtbare Domain und identifiziert keine Person.
  • Erst DMARC nach RFC 9989 prüft die Ausrichtung zur Autorendomain. Auch ein ausgerichteter Erfolg sagt weder Wahrheit noch Harmlosigkeit, Aktualität oder geschäftliche Handlungsvollmacht aus.

Der grüne Status gehörte der falschen Domain

Der Prüfer fand den öffentlichen Schlüssel im DNS-Namensraum des Angreifers, bildete die vorgeschriebenen Hashes und bestätigte die Signatur. Genau das sollte er tun. Der Fehler begann erst, als ein nachgelagertes System das Wort „pass“ aus seinem Subjekt löste und dem sichtbaren Bank-Absender zuschrieb.

DKIM schafft einen überprüfbaren Verantwortungsbezug zu einer Domain, damit Empfänger anschließend eine Vertrauensentscheidung treffen können. Es ist keine Beglaubigung jedes Namens in der Nachricht. Wer eine Domain kontrolliert, kann dort einen Schlüssel veröffentlichen und schädliche Mail technisch einwandfrei signieren.

Welche Bytes wirklich unter der Signatur liegen

Im Feld DKIM-Signature benennt d= den Signing Domain Identifier, s= den Schlüssel-Selector und h= die einbezogenen Headerfelder. bh= enthält den Hash des kanonisierten, erfassten Body-Teils. b= signiert die kanonisierten Header einschließlich des DKIM-Felds, dessen eigener Signaturwert dabei leer behandelt wird.

Damit besteht die Prüfung aus nachvollziehbaren Einzelschritten: Kanonisierungsregel anwenden, Body-Hash berechnen, mit bh= vergleichen, den Schlüssel für s= unter d= ermitteln und b= über den konstruierten Headerinput prüfen. Weicht der Body-Hash ab, ist die gesamte Signatur ungültig – auch wenn die reine Headerrechnung sonst aufgehen würde.

Das From-Feld muss in h= enthalten sein. Dadurch lässt sich eine spätere Änderung genau dieses Feldes erkennen. Es beweist aber nicht, dass d= die dort geschriebene Domain beherrscht. Ein Angreifer kann eine fremde Behauptung unverändert und korrekt signieren.

Kanonisierung ist keine Bedeutungsprüfung

DKIM kennt für Header und Body die Modi simple und relaxed. Relaxed toleriert definierte Änderungen an Leerraum und Feldnamen, die beim Transport häufig entstehen; simple ist enger. Beide Regeln beschreiben Bytes, nicht Bedeutung. Ein gutartiger Formatwechsel kann eine Signatur zerstören, während eine gefährliche Anweisung unverändert gültig bleibt.

Besonders sichtbar wird die Grenze beim optionalen Tag l=. Es beschränkt den erfassten Body auf eine Anzahl kanonisierter Oktette. Ein danach angehängter Text kann außerhalb des Hashs liegen. Das half bei Vermittlern, die Fußzeilen ergänzen, eröffnet aber auch Raum für unautorisierte Zusätze. Bei l=0 ist der gesamte Body unsigniert.

Eine Oberfläche darf daher nicht die komplette sichtbare Nachricht unter ein einziges Signatursiegel stellen, wenn nur ein Präfix erfasst ist. Entweder wird die Grenze kenntlich gemacht, oder die Signatur darf nicht als Schutz des gesamten angezeigten Inhalts erscheinen.

Ausrichtung beantwortet die Frage nach der Autorendomain

RFC 9989 ist der aktuelle DMARC-Standard und ersetzt RFC 7489. Er setzt dort an, wo ein nacktes DKIM-Ergebnis endet: an der Domain im RFC5322.From-Feld, der Author Domain.

DMARC fragt, ob diese Domain zu einer authentifizierten DKIM-Domain d= oder zu einem SPF-Identifikator ausgerichtet ist. Im strikten Modus müssen die Domains identisch sein. Der gelockerte Modus akzeptiert dieselbe Organizational Domain nach den festgelegten Ermittlungsregeln.

Im Eingangsbeispiel besteht DKIM für receipt-alert.example; die Ausrichtung zu bank.example scheitert. Beide Befunde müssen im Protokoll erhalten bleiben. Ein allein gespeichertes dkim=pass unterschlägt gerade die Abweichung, die für die behauptete Autorenschaft entscheidend ist.

Auch DMARC ist keine Inhaltsfreigabe. Ein Erfolg bestätigt die autorisierte Verwendung der Autorendomain. Er erklärt eine Nachricht weder für wertvoll noch für sicher. Kompromittierte Konten und legitim angeschlossene Versandplattformen können schädliche, aber korrekt ausgerichtete Mail erzeugen.

Die Identitäten bleiben getrennt

Das optionale i= kann eine feinere Identität unterhalb der Signierdomain angeben. RFC 6376 verlangt keine Übereinstimmung mit einer Headeridentität und warnt davor, daraus eine umfassende Bindung an einen Endnutzer abzuleiten.

SMTP-Umschlag, SPF-Identifikator, DKIM-Signierdomain, RFC5322.From-Adresse und authentifiziertes SMTP-Konto sind verschiedene Datensätze. Eine Nachricht kann mehrere DKIM-Signaturen unterschiedlicher Domains tragen. Jede wird separat bewertet; für DMARC genügt eine authentifizierte, ausgerichtete Identität.

Authentication-Results transportiert solche Ergebnisse zu Filtern und Benutzeroberflächen. Autorität erhält dieses Feld jedoch vom vertrauenswürdigen Erzeuger, nicht von seiner Schreibweise. Am Eingang müssen fremd eingespeiste Kopien entfernt oder isoliert werden; nur Ergebnisse autorisierter Prüfer der empfangenden Verwaltungsdomäne dürfen gelten.

Vermittler, Mutation und überlieferte Beobachtungen

Mailinglisten und Gateways hängen Fußzeilen an, ändern Betreffzeilen, kodieren Bodies neu oder schreiben Umschlagdaten um. Das kann eine zuvor gültige DKIM-Signatur und damit die DMARC-Ausrichtung brechen. Ein später Fehler beweist nicht, dass eine frühere Form nie authentifiziert war. Er rechtfertigt aber auch keine pauschale Annahme eines früheren Erfolgs.

ARC kann eine geordnete Kette früherer Authentifizierungsbewertungen über Vermittler hinweg tragen. Das ist zusätzliche Evidenz, keine automatische Vertrauensvererbung. Der endgültige Empfänger bewertet ARC-Signierer, Kette und lokale Richtlinie selbst.

Zeitstempel verhindern keinen Replay

t= kann den Signaturzeitpunkt und x= ein Ablaufdatum angeben. RFC 6376 stellt ausdrücklich klar, dass Ablauf kein Replay-Schutz ist. Eine abgefangene, weiterhin gültige Nachricht lässt sich erneut zustellen oder mehrfach verarbeiten.

Mailauthentifizierung und geschäftliche Idempotenz brauchen deshalb getrennte Register. Eine echte, korrekt signierte Zahlungsanweisung kann veraltet, doppelt oder außerhalb der aktuellen Vollmacht liegen. Transaktionskennung, Workflowzustand, Kontokontrollen und gegebenenfalls menschliche Bestätigung entscheiden über die Handlung.

Negative Tests, die die Subjekte bewahren

Signieren Sie eine Angriffsmail unter einer eigenen Domain, zeigen Sie aber eine fremde From-Domain. Der Test muss gleichzeitig dkim=pass und fehlende DMARC-Ausrichtung protokollieren. Signieren Sie danach schädlichen Inhalt unter einer autorisierten, ausgerichteten Domain: Die Authentifizierung soll bestehen, während Inhalts- und Kontorisiko unabhängig entscheiden.

Ändern Sie signierte und unsignierte Header getrennt, hängen Sie eine sichtbare Anweisung hinter die l=-Grenze, variieren Sie Leerraum unter simple und relaxed, erzwingen Sie einen bh=-Fehler und spielen Sie eine intakte Mail erneut ein. Prüfen Sie mehrere Signaturen mit unterschiedlichen Pass- und Alignment-Ergebnissen.

Fügen Sie schließlich ein gefälschtes Authentication-Results ein, rotieren Sie den Selector durch DNS-Cachezustände und leiten Sie die Nachricht über einen Fußzeilen-Vermittler. Jeder Befund muss Objekt, Domain, Umfang, Erzeuger und entscheidende Richtlinie nennen.