Was „dkim=pass“ wirklich bedeutet

Wenn Sie die Kopfzeilen einer E-Mail geöffnet haben, dort eine Zeile wie dkim=pass header.d=supplier.com; spf=pass; dmarc=pass gefunden haben und nun wissen möchten, ob die Nachricht damit unbedenklich ist: Es bedeutet, dass die Nachricht wirklich von dieser Domain kam, und nicht mehr. Es sagt nichts darüber, ob die Rechnung echt ist, ob die Bankverbindung stimmt oder ob die Person, die getippt hat, Ihr Lieferant war.

Das ist keine Spitzfindigkeit. Der teuerste Rechnungsbetrug in Europa besteht alle drei Prüfungen, jedes Mal, weil er aus dem echten Postfach des Lieferanten verschickt wird. Wenn Sie eine Zahlungsaufforderung vor sich haben, liest die E-Mail-Prüfung die Nachricht und sagt Ihnen, welche dieser Dinge sie tatsächlich belegen konnte — und, ebenso wichtig, welche nicht.

Was jede der drei Prüfungen tatsächlich fragt

Sie werden oft so geschrieben, als wären sie ein einziges Urteil. Es sind drei verschiedene Fragen, und keine davon lautet „Ist diese E-Mail ehrlich“.

SPF fragt, ob der Server, der die Nachricht zugestellt hat, einer von denen ist, die der Inhaber der Domain zum Versand zugelassen hat. Es ist eine Frage nach einer IP-Adresse. Sie sagt nichts darüber, wer die Nachricht geschrieben hat oder was darin steht.

DKIM fragt, ob eine kryptografische Signatur über Teile der Nachricht zu einem öffentlichen Schlüssel passt, der im DNS der Domain veröffentlicht ist. Ein Bestehen bedeutet, dass jemand mit dem privaten Schlüssel dieser Domain diese Teile signiert hat und sie seither nicht verändert wurden. Es ist die stärkste der drei — und es ist eine Aussage über die Domain, nicht über die Absicht des Absenders.

DMARC fragt, ob SPF oder DKIM für eine Domain bestanden haben, die zu der From:-Adresse passt, die der Leser sieht, und sagt den empfangenden Servern, was zu tun ist, wenn beides nicht der Fall ist. Es bindet die beiden anderen an den sichtbaren Absender. Das ist wirklich wertvoll und dennoch keine Aussage über den Inhalt.

dkim=pass header.d=supplier.com bedeutet also: Das ist tatsächlich die Domain Ihres Lieferanten. Genau das würden Sie auch erwarten, wenn ein Krimineller im Postfach Ihres Lieferanten sitzt.

Der Betrug, der jede Prüfung besteht

Die Variante des Rechnungsbetrugs, die funktioniert, ist keine Nachahmer-Domain. Es ist eine echte E-Mail aus dem echten Postfach des echten Lieferanten, meist erreicht mit einem Passwort aus einem fremden Datenleck oder über eine Phishing-Seite, die Wochen zuvor ausgefüllt wurde.

Alles authentifiziert sich, weil alles echt ist:

• Die Nachricht ist von der eigenen Domain des Lieferanten signiert, also besteht DKIM;
• sie verlässt den eigenen Mailanbieter des Lieferanten, also besteht SPF;
• die From:-Adresse passt, also besteht DMARC;
• der Mailverlauf ist echt, denn es ist der echte Verlauf.

Nur die Bankverbindung ist neu. Die E-Mail-Authentifizierung hat zur Bankverbindung keine Meinung.

Deshalb ist „die E-Mail hat sich authentifiziert“ nie ein Grund zu zahlen, und deshalb endet jedes Ergebnis auf dieser Seite — auch die unauffälligen — mit demselben Satz über den Anruf unter einer Nummer, die Sie bereits hatten. Ausführlicher steht das in ein Lieferant möchte per E-Mail seine Bankverbindung ändern.

Wer die Zeile geschrieben hat, die Sie lesen

Es gibt eine zweite Falle, und sie ist leicht zu übersehen.

Authentication-Results: ist eine Kopfzeile, die der Mailserver geschrieben hat, der die Nachricht empfangen hat — in der Regel Ihr eigener Anbieter. Wenn Sie dort dkim=pass lesen, lesen Sie das Urteil eines anderen, festgehalten im Moment der Zustellung. Das ist normalerweise vertrauenswürdig, weil Ihr eigener Anbieter es geschrieben hat.

Kopfzeilen sind aber nur Text. Wurde der Block an Sie weitergeleitet, in ein Ticket eingefügt, aus dem Screenshot eines Kollegen abgeschrieben oder von demjenigen übergeben, der bezahlt werden möchte, dann ist die Zeile mit dkim=pass eine Behauptung dessen, der den Text erzeugt hat — und tippen kann das jeder. Es gibt keine Kryptografie, die eine Kopfzeile schützt, in der steht, die Kryptografie sei gelungen.

Die ehrliche Unterscheidung verläuft zwischen drei ganz verschiedenen Situationen:

Was Sie haben	Was sich belegen lässt
Die vollständige Rohnachricht samt Signatur	Die Signatur lässt sich jetzt prüfen, von Ihnen
Nur Kopfzeilen, mit einer Authentication-Results-Zeile	Das festgehaltene Urteil des empfangenden Servers, auf Treu und Glauben
Keines von beidem — nur die sichtbare E-Mail	Nur das, was die Domain veröffentlicht: SPF, DMARC, MX

Jedes Werkzeug, das Ihnen das Zweite zeigt und es das Erste nennt, sagt Ihnen etwas, das Sie nicht nachprüfen können. Die E-Mail-Prüfung benennt, welches der drei sie gerade tut, und stuft nie eines zum anderen hoch: Ein dkim=pass, das in einem eingefügten Kopfzeilenblock steht, wird als Urteil des Empfängers gemeldet, und zwar mit genau diesen Worten.

Wann ein „fail“ mehr wiegt als ein „pass“

Ein Bestehen ist ein schwacher Beleg. Ein Nichtbestehen ist ein starker Beleg und ein Grund innezuhalten.

Wenn die DKIM-Prüfung tatsächlich läuft und widerspricht — die Signatur passt nicht zum Inhalt —, dann wurde die Nachricht nach dem Signieren verändert oder von dieser Domain überhaupt nie signiert. Steht DMARC auf p=reject und die Nachricht ist trotzdem durchgefallen, hätte sie nicht zugestellt werden dürfen.

Eine Asymmetrie sollte man mitnehmen: nicht prüfbar ist nicht dasselbe wie nicht bestanden. Eine nicht erreichbare DNS-Abfrage, ein widerrufener Schlüssel, eine abgelaufene Signatur oder eine Signatur, die nur einen Teil des Textkörpers abdeckt — all das heißt, dass die Berechnung nicht zu Ende geführt werden konnte. Das ist kein Befund gegen den Absender, und ein Werkzeug, das es als einen solchen darstellt, verschwendet das einzige Signal, bei dem Handeln sich gelohnt hätte.

Was mit einer Nachricht zu tun ist, bei der Sie unsicher sind

1. Antworten Sie nicht darauf. Ist das Postfach kompromittiert, geht Ihre Antwort an den Angreifer, und eine Postfachregel kann sie vor dem echten Lieferanten verbergen.
2. Rufen Sie den Lieferanten an, unter einer Nummer aus einer alten Rechnung, aus Ihrem Buchhaltungssystem oder von seiner Website, die Sie durch eigenes Eintippen der Adresse aufgerufen haben.
3. Prüfen Sie die Kennungen getrennt — die USt-IdNr., den Handelsregistereintrag und, bei einem polnischen Lieferanten, ob das Konto auf der weißen Liste steht. Die Rechnungsprüfung erledigt all das aus dem Dokument selbst.
4. Behandeln Sie die Änderung der Bankverbindung als das Ereignis, nicht die E-Mail darum herum. Das ist der Vorgang, der einen Anruf wert ist, was auch immer die Kopfzeilen sagen.

Was Ihnen das nicht sagen kann

Die E-Mail-Authentifizierung prüft den Kanal, nicht die Behauptung. Sie kann Ihnen nicht sagen, dass die Ware bestellt wurde, dass der Betrag stimmt, dass die schreibende Person dort noch arbeitet oder dass das Konto Ihrem Lieferanten gehört. Polen ist das einzige Land der EU, das eine Antwort auf diese letzte Frage veröffentlicht — weshalb sich die weiße Liste dort lohnt, wo sie greift.

Überall sonst ist die Kontrolle, die das aufdeckt, ein Telefonat unter einer Nummer, die Sie bereits hatten.