# Was „dkim=pass“ wirklich bedeutet

> Sie haben die Kopfzeilen geprüft, und die E-Mail-Authentifizierung ist durchgegangen.

Canonical: https://vetthisvendor.com/de/guide/dkim-pass-does-not-mean-genuine
Published: 2026-08-12. Updated: 2026-08-12.
Author: Jose Pollman, VetThisVendor.

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](/de/tools/supplier-email-check) 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](/de/guide/supplier-changed-bank-details).

## 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](/de/tools/supplier-email-check) 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](/de/guide/polish-white-list) steht. Die
   [Rechnungsprüfung](/de/tools/invoice-checker) 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](/de/guide/polish-white-list) dort lohnt, wo sie greift.

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