Berücksichtigte Anwendungen: Gmail im Browser, neues und klassisches Outlook für Windows, iCloud Mail im Browser und Thunderbird.
Die sichtbare Absenderadresse einer E-Mail ist kein Echtheitsbeweis – sie kann gefälscht sein. Jede E-Mail enthält zusätzlich technische Headerfelder, die normalerweise verborgen sind. Diese Felder dokumentieren unter anderem den Transportweg der Nachricht und können Ergebnisse technischer Authentifizierungsprüfungen enthalten.
Dieser Artikel zeigt Ihnen Schritt für Schritt, wie Sie den vollständigen Header öffnen, welche Felder Sie wirklich brauchen und wie Sie SPF, DKIM und DMARC einordnen. Ob Sie die Internetheader anzeigen können, hängt vom Mailprogramm und Ihren Berechtigungen ab. Ist die Ansicht gesperrt oder unklar, wenden Sie sich an Ihre IT oder Ihren E-Mail-Anbieter; eine eigenständige technische Auswertung kann zusätzliche Fachkenntnisse erfordern.
Wichtig ist eine Grenze: Eine Headeranalyse kann technische Hinweise liefern. Sie kann nicht beweisen, dass eine Nachricht harmlos, eine Zahlungsaufforderung berechtigt oder eine Person wirklich der Absender ist.
Akutfall: Wenn Sie schon gehandelt haben
- Geld bereits überwiesen? Kontaktieren Sie sofort Ihre Bank oder Ihren Zahlungsanbieter über einen Ihnen bereits bekannten offiziellen Weg.
- Passwort oder Bestätigungscode bereits eingegeben? Öffnen Sie den echten Dienst unabhängig von der Nachricht, ändern Sie dort das betroffene Passwort und beenden Sie – sofern angeboten – andere aktive Sitzungen.
- Verdächtigen Anhang oder eine Datei geöffnet oder ausgeführt? Öffnen oder starten Sie die Datei nicht erneut. Nutzen Sie das betroffene Gerät vorerst nicht für vertrauliche Anmeldungen und holen Sie fachkundige Hilfe.
- Unsicher, was genau passiert ist? Brechen Sie eine eigene Headeranalyse ab, statt sie zur Risikobewertung zu nutzen.
Das Wichtigste in Kürze
- Die wichtigen Felder suchen: Öffnen Sie zuerst den vollständigen Header und suchen Sie dort
Authentication-Results:sowie die Werte für SPF, DKIM und DMARC. - Herkunft prüfen, bevor Sie werten: Bewerten Sie
Authentication-Resultsnur, wenn Sie zuverlässig wissen, dass das Feld aus Ihrer vertrauenswürdigen Empfangsumgebung stammt – sonst brechen Sie die Eigenanalyse ab. - Pass ist keine Entwarnung: Ein technisches
passbedeutet nur, dass genau diese technische Prüfung bestanden wurde – nicht automatisch „Nachricht sicher". Prüfen Sie wichtige Aufforderungen trotzdem unabhängig.
Kapitel 1: Wie öffnen Sie den vollständigen Header in Ihrem E-Mail-Programm?
Der vollständige Header ist normalerweise versteckt. Nutzen Sie nur den für Ihr Mailprogramm belegten Weg. Klicken Sie in einer verdächtigen Nachricht keine Links an und öffnen Sie keine Anhänge. Löschen Sie eine möglicherweise beweisrelevante Nachricht nicht vorschnell; bewahren Sie sie für eine erforderliche Meldung sicher auf. Können Sie die Headeransicht nicht sicher erreichen, verzichten Sie auf die Eigenanalyse und nutzen Sie einen unabhängig bekannten offiziellen Kontaktweg. Wenn Ihre Oberfläche deutlich anders aussieht, raten Sie keinen Menüpfad. Beenden Sie die Eigenanalyse und wechseln Sie zu Kapitel 8.
Gmail im Browser
- Öffnen Sie Gmail auf einem Computer im Browser.
- Öffnen Sie die betreffende E-Mail.
- Suchen Sie rechts neben Antworten das Drei-Punkte-Menü.
- Klicken Sie auf dieses Menü.
- Wählen Sie Original anzeigen.
- Es öffnet sich eine neue Ansicht mit dem Nachrichtenursprung.
Die Ansicht zeigt technische Informationen zum Nachrichtenursprung. Welche Headerfelder tatsächlich vorhanden sind, hängt von der Nachricht und ihrer Verarbeitung ab. Fehlt Authentication-Results:, raten Sie keinen Ersatzwert – die in diesem Artikel beschriebene SPF-/DKIM-/DMARC-Auswertung ist dann über dieses Feld nicht vollständig möglich; wechseln Sie zu Kapitel 8. Rückweg: Schließen Sie die Ansicht mit dem Nachrichtenursprung.
Neues Outlook
- Öffnen Sie die E-Mail.
- Wählen Sie oben im Nachrichtenfenster Weitere Aktionen.
- Wählen Sie Anzeigen.
- Wählen Sie Nachrichtendetails anzeigen.
- Prüfen Sie, ob die technischen Nachrichtendetails angezeigt werden.
Sie sehen technische Headerdaten, zum Beispiel From: und Transportfelder. Fehlt Authentication-Results:, raten Sie keinen Wert dazu – wechseln Sie zu Kapitel 8. Rückweg: Schließen Sie den Bereich mit den Nachrichtendetails.
Klassisches Outlook unter Windows
Für klassisches Outlook unter Windows ist der Menüweg „Datei → Eigenschaften" in einer Antwort auf Microsoft Q&A beschrieben. Die genaue deutsche Beschriftung wurde hier nicht an einer installierten Outlook-Version überprüft. Abhängig von Version und Oberfläche können Menünamen abweichen. Weicht Ihre Ansicht ab, nutzen Sie die aktuelle Herstellerhilfe statt einen Pfad zu erraten.
- Öffnen Sie die E-Mail per Doppelklick in einem eigenen Fenster.
- Klicken Sie auf Datei.
- Wählen Sie Eigenschaften, sofern diese Menüfolge in Ihrer Version vorhanden ist.
- Suchen Sie das Feld Internetkopfzeilen.
- Lesen Sie dort die technischen Headerdaten.
Im Feld Internetkopfzeilen stehen mehrere technische Zeilen. Rückweg: Schließen Sie das Eigenschaftenfenster. Finden Sie den Bedienweg nicht oder fehlen Headerfelder, nutzen Sie die aktuelle Herstellerhilfe oder wechseln Sie zu Kapitel 8.
iCloud Mail im Browser
- Öffnen Sie
icloud.com/mail. - Öffnen Sie die betreffende E-Mail.
- Wählen Sie Mehr.
- Wählen Sie Alle Header einblenden.
Zusätzliche Headerfelder werden sichtbar. Prüfen Sie anschließend, ob Authentication-Results: tatsächlich vorhanden ist. Rückweg: Wählen Sie Mehr → Standard-Header einblenden. Finden Sie den Bedienweg nicht oder fehlen Headerfelder, nutzen Sie die aktuelle Herstellerhilfe oder wechseln Sie zu Kapitel 8.
Thunderbird
- Wählen Sie die betreffende E-Mail aus.
- Drücken Sie unter Windows/Linux Strg+U.
- Unter macOS drücken Sie Command+U.
- Der Nachrichtenquelltext öffnet sich.
Am Anfang sehen Sie technische Felder wie From: und Received:. Prüfen Sie, ob Authentication-Results: vorhanden ist. Rückweg: Schließen Sie das Fenster mit dem Nachrichtenquelltext. Finden Sie den Bedienweg nicht oder fehlen Headerfelder, nutzen Sie die aktuelle Herstellerhilfe oder wechseln Sie zu Kapitel 8.
Nutzen Sie nur den dokumentierten Bedienweg Ihres eigenen Mailprogramms. Bleibt die Ansicht unklar, beenden Sie die Eigenanalyse und wechseln Sie zu Kapitel 8.
↑ Zurück zum Inhaltsverzeichnis
Kapitel 2: Welche Headerfelder brauchen Sie für die Prüfung?
Ein vollständiger Header kann sehr lang aussehen. Für die erste Einordnung brauchen Sie nur wenige Felder.
From:
From: enthält die sichtbare Absenderadresse. Beispiel: From: kontakt@bank.example. Das ist die Adresse, die im sichtbaren Absenderfeld steht – sie ist allein kein Echtheitsbeweis.
Reply-To: wenn vorhanden
Reply-To: gibt an, wohin eine Antwort geschickt werden soll. Beispiel: Reply-To: support@separate-domain.example. Eine Abweichung zwischen From: und Reply-To: kann legitime Gründe haben. Treffen Sie bei einer unerwarteten Domain keine Betrugsentscheidung nur anhand dieser Abweichung; prüfen Sie die Nachricht unabhängig über einen bekannten offiziellen Weg.
Return-Path:
Return-Path: enthält eine technische Rücksendeadresse aus dem SMTP-Umschlag, also aus den technischen Adressangaben bei der Mailübertragung. Beispiel: Return-Path: <noreply@mail-service.example>. Return-Path: kann sich aus legitimen technischen Gründen von From: unterscheiden, etwa bei Versanddiensten, Weiterleitungen oder Mailinglisten.
Received: oft mehrfach vorhanden
Received: dokumentiert Stationen des Transportwegs. Beispiel, zwei Stationen derselben Nachricht:
Received: from gateway.isp.example (gateway.isp.example [192.0.2.10]) by mailbox.example with SMTP id abc123 for user@mailbox.example; Mon, 17 Aug 2026 10:30:45 +0000
Received: from mail.sender.example (mail.sender.example [203.0.113.50]) by gateway.isp.example with SMTP id xyz789 for user@mailbox.example; Mon, 17 Aug 2026 10:30:30 +0000
Neue Received-Zeilen werden beim Transport normalerweise oben ergänzt. Deshalb stehen jüngere Stationen weiter oben und ältere weiter unten. Aber: Die oberste Zeile zeigt nicht automatisch Ihren Mailanbieter. Die unterste sichtbare Zeile beweist nicht, welcher Mensch die Nachricht verfasst hat. Vor dem Eintritt in Ihre vertrauenswürdige Empfangsinfrastruktur können Einträge falsch oder irreführend sein. Für Normalnutzer ist die Received-Kette deshalb nur begrenzt als Echtheitsprüfung geeignet.
Authentication-Results: das wichtigste Feld für diese Anleitung
In Authentication-Results: können Ergebnisse von SPF, DKIM und DMARC stehen. Beispiel:
Authentication-Results: mailbox.example; spf=pass smtp.mailfrom=noreply@sender.example; dkim=pass header.d=sender.example; dmarc=pass header.from=sender.example
Hier stehen drei Ergebnisse: spf=pass, dkim=pass, dmarc=pass.
Wichtig: Dieses Feld ist nur dann sinnvoll auswertbar, wenn Sie zuverlässig wissen, dass es von Ihrer vertrauenswürdigen Empfangsumgebung erzeugt wurde. Die technische Eigenanalyse ist keine Sicherheitsfreigabe; Mailprogramme werten solche Angaben nicht zwangsläufig für Endnutzer aus. Bei Unsicherheit brechen Sie ab und nutzen Kapitel 8. Direkt nach Authentication-Results: steht normalerweise eine Kennung des prüfenden Systems. Diese Kennung heißt authserv-id. Ein vertraut klingender Name reicht nicht. Können Sie die Herkunft nicht sicher bestimmen, brechen Sie die technische Bewertung ab und gehen Sie zu Kapitel 8.
↑ Zurück zum Inhaltsverzeichnis
Kapitel 3: Was bedeuten SPF, DKIM und DMARC wirklich?
SPF: Sender Policy Framework
SPF prüft nicht automatisch die sichtbare From:-Adresse. Geprüft wird eine technische SMTP-Identität, insbesondere die Domain aus dem sogenannten MAIL FROM. Einfach gesagt, SPF fragt: Darf dieser sendende Server für diese technische Domain senden?
Typische SPF-Ergebnisse: spf=pass – der sendende Server war für die geprüfte SPF-Domain autorisiert. spf=fail – der Server war laut veröffentlichter SPF-Regel nicht autorisiert. spf=none – die Prüfung konnte keine Aussage zur Autorisierung treffen. spf=neutral – die SPF-Regel trifft keine positive oder negative Festlegung. spf=softfail – die SPF-Regel liefert eine schwache negative Aussage. spf=temperror – vorübergehender Fehler. spf=permerror – dauerhafter Auswertungsfehler.
Ein Angreifer kann eine eigene täuschend ähnliche Domain registrieren und SPF dafür korrekt einrichten. Dann kann spf=pass erscheinen, obwohl die Domain gar nicht zur erwarteten Organisation gehört.
DKIM: DomainKeys Identified Mail
DKIM arbeitet mit einer digitalen Signatur. Einfach gesagt, DKIM fragt: Ist die Signatur für die in ihr angegebene Domain (die sogenannte Signing Domain) gültig, und wurden die signierten Teile seit dem Signieren nicht so verändert, dass die Signatur ungültig wird?
Typische DKIM-Ergebnisse: dkim=pass – die Signatur wurde erfolgreich geprüft. dkim=fail – die Signaturprüfung ist fehlgeschlagen. dkim=none – die Nachricht war nicht mit DKIM signiert. Weitere Werte wie neutral, policy, temperror oder permerror können ebenfalls vorkommen.
Ein dkim=pass identifiziert nicht automatisch eine bestimmte Person als Absender. Auch eine eigene Lookalike-Domain eines Angreifers kann korrekt mit DKIM signiert sein.
DMARC: Domain-based Message Authentication, Reporting, and Conformance
DMARC verbindet SPF oder DKIM mit der sichtbaren Absenderdomain im From:-Feld. Einfach gesagt, DMARC fragt: Passt mindestens eine erfolgreich authentifizierte technische Domain nach den DMARC-Regeln zur sichtbaren Absenderdomain? Diese Beziehung nennt man Alignment (Übereinstimmung der technisch geprüften Domain mit der sichtbaren Absenderdomain nach den DMARC-Regeln).
Typische DMARC-Ergebnisse: dmarc=pass – mindestens ein erfolgreich geprüfter Domain-Identifier erfüllt das erforderliche Alignment. dmarc=fail – kein erfolgreich geprüfter Domain-Identifier erfüllt das Alignment. dmarc=none – keine anwendbare DMARC-Richtlinie gefunden. dmarc=temperror – vorübergehender Auswertungsfehler. dmarc=permerror – dauerhafter Auswertungsfehler.
Auch dmarc=pass bedeutet nicht „Nachricht sicher". DMARC bewertet weder den Inhalt noch die Berechtigung einer Zahlung, Passwortänderung oder anderen Aufforderung. Wie Sie diese drei Ergebnisse systematisch ohne Scheinsicherheit einordnen, zeigt die Entscheidungstabelle in Kapitel 4.
↑ Zurück zum Inhaltsverzeichnis
Kapitel 4: Wie führen Sie die Headeranalyse praktisch durch?
Nutzen Sie diese Reihenfolge. Überspringen Sie keinen Schritt.
Ort
Öffnen Sie den vollständigen Header über den für Ihr Mailprogramm belegten Weg.
Handlung
Suchen Sie From: und ein vertrauenswürdiges Authentication-Results:-Feld und lesen Sie die Werte für SPF, DKIM und DMARC.
Kriterium
Prüfen Sie nicht nur pass oder fail, sondern auch, welche Domain tatsächlich bewertet wurde und ob das Feld aus Ihrer vertrauenswürdigen Empfangsumgebung stammt.
Erfolgssignal
Sie können die ausgewertete Empfangsumgebung, die relevanten Ergebniswerte und die authentifizierte Domain eindeutig benennen.
Fehlerweg
Fehlt ein Feld, ist die Herkunft unklar oder können Sie einen Wert nicht sicher einordnen, brechen Sie die Eigenanalyse ab und wechseln Sie zu Kapitel 8.
Schritt 1 – Vollständigen Header öffnen: Nutzen Sie den in Kapitel 1 beschriebenen Weg für Ihr Mailprogramm. Erfolg erkennen Sie daran, dass Sie mehrere technische Headerzeilen sehen. Funktioniert der belegte Weg nicht, wechseln Sie zu Kapitel 8.
Schritt 2 – From: suchen: Lesen Sie die sichtbare Absenderadresse und notieren Sie sich die Domain hinter dem @. Beispiel: support@bank.example, Domain: bank.example.
Schritt 3 – Authentication-Results: suchen: Sind mehrere solcher Zeilen vorhanden, ist das nicht automatisch verdächtig. Können Sie aber nicht bestimmen, welche Zeile aus Ihrer vertrauenswürdigen Empfangsumgebung stammt, verwenden Sie keine davon für eine Echtheitsentscheidung. Ist keine Zeile vorhanden, raten Sie keine Ersatzwerte – wechseln Sie zu Kapitel 8.
Schritt 4 – Herkunft des Feldes prüfen: Schauen Sie direkt nach Authentication-Results: auf die Kennung des prüfenden Systems, die authserv-id. Was Sie nicht tun dürfen: nur deshalb vertrauen, weil der Name vertraut klingt. Was Sie tun dürfen: nur eine Zuordnung verwenden, die aus offizieller Dokumentation Ihres Maildienstes oder – bei einem Firmenkonto – von Ihrer zuständigen IT stammt. Können Sie das nicht sicher sagen, brechen Sie hier ab und wechseln Sie zu Kapitel 8.
Schritt 5 – SPF, DKIM und DMARC ablesen: Suchen Sie innerhalb des vertrauenswürdigen Authentication-Results-Feldes nach spf=, dkim= und dmarc= und notieren Sie jeweils den exakten Wert dahinter, zum Beispiel spf=pass, dkim=pass, dmarc=pass. Ordnen Sie unbekannte Werte nicht selbst einer bekannten Bedeutung zu.
Schritt 6 – Bewertete Domain prüfen: Suchen Sie nach Angaben wie header.from=, header.d= oder smtp.mailfrom=. Für DMARC ist besonders header.from= wichtig. Fragen Sie: Ist diese Domain wirklich die Domain, die Sie erwartet haben? Verwenden Sie dafür nur eine Domain, die Sie zuverlässig kennen oder aus offiziellen Unterlagen beziehungsweise einer bereits installierten offiziellen App ableiten können. Ist die Zuordnung unklar, brechen Sie die technische Bewertung ab und wechseln Sie zu Kapitel 8.
Schritt 7 – Ergebnis einordnen: Ordnen Sie Ihr Ergebnis anhand der folgenden Tabelle ein.
Entscheidungstabelle: Beobachtung, Einordnung, sicherer Schritt
| Was fällt auf? | Wie ordnen Sie es ein – und was tun Sie? |
|---|---|
SPF, DKIM und DMARC zeigen pass | Mehrdeutig. Die technischen Prüfungen waren erfolgreich. Das ist noch kein Sicherheitsurteil über Inhalt, Link oder Aufforderung. Prüfen Sie zusätzlich, welche Domain tatsächlich authentifiziert wurde und ob Sie diese Domain erwartet haben. |
Ein Wert zeigt fail | Warnsignal. Die betreffende technische Prüfung ist fehlgeschlagen. Das ist ein Warnsignal, aber für sich allein noch kein Phishing-Beweis. Reagieren Sie nicht über die Nachricht und prüfen Sie den behaupteten Vorgang unabhängig. |
Ein Wert zeigt none, neutral, temperror oder permerror | Mehrdeutig. Die Prüfung liefert keine klare positive Bestätigung beziehungsweise ist nicht eindeutig auswertbar. Raten Sie nicht. Beenden Sie die Eigenanalyse, wenn Sie den Wert nicht sicher einordnen können. |
| Alle Prüfungen bestehen, aber die authentifizierte Domain ist unerwartet oder täuschend ähnlich | Warnsignal. Auch eine fremde oder täuschend ähnliche Domain kann technisch korrekt SPF, DKIM und DMARC verwenden. Verlassen Sie die Nachricht und prüfen Sie den Vorgang über einen unabhängig bekannten offiziellen Zugang. |
SPF, DKIM, DMARC zeigen pass
Mehrdeutig: zusätzlich geprüfte Domain mit erwarteter Domain abgleichen.
Ein Wert zeigt fail
Warnsignal: nicht reagieren, Vorgang unabhängig prüfen.
Ein Wert zeigt none, neutral, temperror oder permerror
Mehrdeutig: nicht raten, Eigenanalyse bei Unsicherheit beenden.
Alle pass, Domain aber unerwartet oder ähnlich
Warnsignal: Nachricht verlassen, unabhängig über bekannten Zugang prüfen.
Ein unbekannter Wert, der sich keiner dieser Zeilen zuordnen lässt? Nicht raten – nutzen Sie Kapitel 8.
Schritt 8 – Sichere Entscheidung treffen: Fragen Sie sich: Haben Sie diese Nachricht erwartet? Verlangt sie eine wichtige Handlung? Bleibt trotz Headeranalyse irgendein Zweifel? Bleibt Zweifel oder geht es um Zahlung, Passwortänderung, Kontosperrung oder Bestätigungscode, wechseln Sie zu Kapitel 9.
↑ Zurück zum Inhaltsverzeichnis
Kapitel 5: Was kann eine Headeranalyse nicht beweisen?
Die Headeranalyse ist eine technische Zusatzprüfung, aber kein Echtheitsbeweis. Die folgenden sechs Prüfpunkte zeigen, wo SPF, DKIM und DMARC an ihre Grenzen stoßen.
- Keine Aussage zu Inhalt oder Berechtigung: SPF, DKIM und DMARC prüfen technische Eigenschaften. Sie bewerten nicht, ob eine Zahlung wirklich berechtigt ist, ein Passwortwechsel tatsächlich verlangt wurde, ein Link harmlos ist oder eine konkrete Person die Nachricht geschrieben hat.
- Keine automatische Bestätigung der Senderidentität: Eine fremde Domain kann technisch sauber eingerichtet sein. Eine erfolgreich authentifizierte Domain ist deshalb nicht automatisch die Domain, die Sie erwartet haben.
Authentication-Results:ist nicht automatisch vertrauenswürdig: Solche Felder können an verschiedenen Stationen entstehen. Entscheidend ist, ob das von Ihnen ausgewertete Feld tatsächlich aus Ihrer vertrauenswürdigen Empfangsumgebung stammt.Received:ist kein Identitätsbeweis: Eine technisch plausibel wirkende Transportkette beweist nicht, dass die Nachricht tatsächlich von der behaupteten Organisation stammt.- Auch bestandene Prüfungen können täuschen: Ein Angreifer kann eine eigene täuschend ähnliche Domain registrieren und SPF, DKIM sowie DMARC dafür korrekt einrichten. Ein
passbestätigt dann nur die tatsächlich verwendete, nicht die erwartete Domain. Ein ausführliches Beispiel finden Sie in Kapitel 7. - Kein Ersatz für die unabhängige Bestätigung: Bei wichtigen oder unerwarteten Aufforderungen – Zahlung, Passwortänderung, Bestätigungscode – ersetzt kein technisches Prüfergebnis die unabhängige Bestätigung über einen bekannten offiziellen Weg. Mehr dazu in Kapitel 9.
BELEGTER PRAXISFALL
So wirkt eine technisch überzeugend aufgemachte Nachricht im Alltag: angebliches Sparkassen-Update
Im Phishing-Radar-Archiv dokumentiert die Verbraucherzentrale eine E-Mail mit dem Betreff „Update dringend erforderlich!": Der Absender gibt sich als Sparkasse aus und behauptet, für „S-pushTAN Online" sei ein Sicherheitsupdate notwendig. Empfänger sollen über die Schaltfläche „Update jetzt durchführen" reagieren.
Die Verbraucherzentrale benennt ausdrücklich die ungewöhnliche Absenderadresse und die Aufforderung, direkt auf einen Link zu klicken, als auffällige Merkmale dieser Nachricht. Ob diese Nachricht SPF, DKIM oder DMARC bestanden hätte, nennt der Eintrag nicht – technische Headerdaten dieser konkreten Nachricht liegen hier nicht vor; nennen Sie diese Angabe deshalb nicht als bestätigten Teil dieses Falls.
Der Fall zeigt, dass eine gut gemachte, auf den ersten Blick glaubwürdig wirkende Nachricht in der Praxis vorkommt. Genau deshalb ist weder ein unauffälliges Erscheinungsbild noch ein etwaiges technisches pass allein eine Sicherheitsgarantie – entscheidend bleibt die unabhängige Prüfung des behaupteten Vorgangs im echten Dienst.
Quellenhinweis:
Verbraucherzentrale, Phishing-Radar-Archiv: „Angeblich 'dringendes Update' bei der Sparkasse erforderlich", dokumentierter Fall, Stand 27.08.2026. Dieses Beispiel zeigt eine dokumentierte Masche, keine aktuelle Live-Warnung und keine technische Header-Auswertung der konkreten Nachricht.
↑ Zurück zum Inhaltsverzeichnis
Kapitel 6: Wie lesen Sie einen Beispiel-Header?
Hier ist ein erfundenes Lernbeispiel:
From: support@sicher-bank.example
Reply-To: kontakt@sicher-bank.example
Return-Path: <noreply@mail.sicher-bank.example>
Authentication-Results: mailbox.example; spf=pass smtp.mailfrom=noreply@sicher-bank.example; dkim=pass header.d=sicher-bank.example; dmarc=pass header.from=sicher-bank.example
So lesen Sie das Beispiel: From: zeigt support@sicher-bank.example. Return-Path: weicht ab – das kann technisch legitim sein. spf=pass bedeutet: Der Server war für die geprüfte SPF-Domain autorisiert. dkim=pass bedeutet: Die DKIM-Signatur wurde erfolgreich geprüft. dmarc=pass bedeutet: Mindestens ein erfolgreich geprüfter Domain-Identifier erfüllt das erforderliche Alignment.
Was dürfen Sie daraus schließen – und was nicht?
Nur: Die dokumentierten technischen Prüfungen wurden für die jeweils geprüften Identitäten bestanden. Was Sie daraus nicht schließen dürfen: „Die Nachricht ist sicher." „Der Link ist sicher." „Die Zahlung ist berechtigt." „Die Person hat diese E-Mail wirklich geschrieben."
Für die praktische Prüfung bedeutet das: Lesen Sie nach pass immer weiter bis zur bewerteten Domain (header.from=, header.d= oder smtp.mailfrom=). Nur wenn diese Domain tatsächlich zur erwarteten Organisation gehört, haben Sie einen vollständig ausgewerteten Header. Welche Domain dagegen eindeutig nicht passt, zeigt das nächste Beispiel.
↑ Zurück zum Inhaltsverzeichnis
Kapitel 7: Warum können auch bestandene Prüfungen täuschen?
Zweites erfundenes Lernbeispiel:
From: support@sicher-dank.example
Authentication-Results: mailbox.example; spf=pass smtp.mailfrom=support@sicher-dank.example; dkim=pass header.d=sicher-dank.example; dmarc=pass header.from=sicher-dank.example
Alle drei Prüfungen können pass zeigen. Trotzdem ist sicher-dank.example nicht dasselbe wie sicher-bank.example. Ein Angreifer kann eine eigene täuschend ähnliche Domain registrieren und SPF, DKIM sowie DMARC dafür korrekt einrichten.
Technische Authentifizierung bestätigt die tatsächlich verwendete Domain. Sie sagt nichts darüber aus, welche Organisation Sie erwarten. Deshalb gilt: pass + falsche oder unerwartete Domain = keine Entwarnung.
Prüfen Sie deshalb in jedem Fall die Domain selbst Zeichen für Zeichen, nicht nur die Statuswörter pass, fail oder none. Taucht eine Ihnen unbekannte, vertauschte oder nur ähnlich klingende Domain auf, ordnen Sie das als Warnsignal ein (siehe Kapitel 5) und prüfen Sie den behaupteten Vorgang unabhängig (Kapitel 9) – unabhängig davon, wie überzeugend die technischen Prüfungen aussehen.
↑ Zurück zum Inhaltsverzeichnis
Kapitel 8: Wann sollten Sie die eigene Headeranalyse abbrechen?
Brechen Sie die Eigenanalyse ab, wenn mindestens einer dieser Punkte zutrifft: Sie finden den vollständigen Header nicht. Der Bedienweg sieht deutlich anders aus als beschrieben. Authentication-Results: fehlt. Sie können nicht bestimmen, welches Authentication-Results-Feld vertrauenswürdig ist. Die Received-Kette ist für Sie nicht eindeutig. Sie wissen nicht, welche Domain tatsächlich authentifiziert wurde. Ein Ergebniswert ist Ihnen unklar.
Was tun Sie dann konkret?
- Klicken Sie nichts in der verdächtigen Nachricht an.
- Verwenden Sie keine Telefonnummer, keinen QR-Code und keine Antwortadresse aus der Nachricht.
- Öffnen Sie den behaupteten Dienst über einen Weg, den Sie unabhängig von der Nachricht kennen. Nutzen Sie zum Beispiel eine bereits installierte offizielle App, einen gespeicherten und vorher geprüften Zugang, eine Internetadresse aus offiziellen Vertrags- oder Kontounterlagen oder eine Telefonnummer aus vorhandenen offiziellen Unterlagen.
- Prüfen Sie dort, ob die behauptete Aufforderung wirklich existiert.
- Bei einem Firmenkonto geben Sie die Nachricht an die zuständige IT- oder Sicherheitsstelle weiter, wenn Sie die technische Herkunft nicht sicher einordnen können.
Erfolg erkennen
Sie entscheiden nicht mehr aufgrund unklarer Headerzeilen, sondern über einen unabhängig verifizierten offiziellen Weg.
Fehlerweg
Finden Sie keinen unabhängigen offiziellen Weg oder bleibt die technische Herkunft unklar, führen Sie die verlangte Handlung nicht aus. Bei einem Firmenkonto geben Sie die Nachricht an die zuständige IT- oder Sicherheitsstelle weiter.
↑ Zurück zum Inhaltsverzeichnis
Kapitel 9: Wann sollten Sie die Nachricht unabhängig überprüfen?
Verlassen Sie sich bei wichtigen oder unerwarteten Aufforderungen nie allein auf den Header.
Unerwartete oder geänderte Zahlungsaufforderung: Zahlen Sie nicht über den Link oder die Kontodaten aus der Nachricht. Öffnen Sie den bekannten offiziellen Dienst selbst oder nutzen Sie vorhandene Vertragsunterlagen und bestätigen Sie die Änderung über einen bekannten offiziellen Kontaktweg. Erfolgssignal: Sie haben die Änderung über einen unabhängig bekannten offiziellen Weg bestätigt oder verworfen. Fehlerweg: Lässt sich die Änderung nicht unabhängig bestätigen, lösen Sie keine Zahlung aus.
Passwortänderung, Kontosperrung oder Sicherheitswarnung: Verwenden Sie nicht den Link aus der E-Mail. Öffnen Sie die bereits installierte offizielle App oder einen bekannten Zugang und prüfen Sie dort, ob die Warnung tatsächlich angezeigt wird. Erfolgssignal: Die Warnung ist im unabhängig geöffneten echten Dienst nachvollziehbar. Fehlerweg: Finden Sie die Warnung dort nicht oder bleibt sie unklar, verwenden Sie keinen Link aus der E-Mail und nutzen Sie ausschließlich den offiziellen Support.
TAN, Bestätigungscode oder zusätzliche Anmeldung wird verlangt: Geben Sie keinen Code aufgrund der E-Mail-Aufforderung ein. Öffnen Sie den echten Dienst selbst und prüfen Sie, ob Sie diesen Vorgang tatsächlich selbst ausgelöst haben. Erfolgssignal: Sie können den angezeigten Vorgang eindeutig einer von Ihnen selbst ausgelösten Aktion zuordnen. Fehlerweg: Haben Sie den Vorgang nicht selbst ausgelöst oder bleibt die Zuordnung unklar, geben Sie keinen Code ein und bestätigen Sie nichts.
Arbeitskontext – unklare Aufforderung an ein Firmenkonto: Nutzen Sie einen bekannten internen Kontaktweg und fragen Sie die zuständige IT, Sicherheitsstelle oder verantwortliche Person. Verwenden Sie nicht die in der Nachricht genannten Kontaktdaten. Erfolgssignal: Die zuständige interne Stelle hat den Vorgang über einen bekannten internen Weg bestätigt oder übernommen. Fehlerweg: Ist die zuständige Stelle nicht erreichbar, reagieren Sie nicht über die verdächtige Nachricht und führen Sie die verlangte Handlung nicht aus.
Technische Prüfung zeigt pass, aber Inhalt oder Aufforderung bleiben ungewöhnlich: Werten Sie ein technisches pass nicht als Berechtigung für Zahlung, Passwortwechsel oder andere Handlung. Prüfen Sie den behaupteten Vorgang zusätzlich unabhängig. Ein technisches pass bestätigt eine technische Prüfung – nicht die Berechtigung einer Zahlung, eines Passwortwechsels oder einer anderen Handlung.
↑ Zurück zum Inhaltsverzeichnis
Kapitel 10: Wie kontrollieren Sie Ihre Mail-Header-Analyse systematisch Schritt für Schritt?
Nutzen Sie diese Reihenfolge nach Ihrer Headeranalyse:
Schritte für den Alltag
1. Header öffnen und From prüfen: Öffnen Sie den vollständigen Header über den für Ihr Mailprogramm belegten Weg und notieren Sie die sichtbare Absenderdomain aus From:.
2. Authentication-Results finden und einordnen: Suchen Sie Authentication-Results:. Prüfen Sie, ob das ausgewertete Feld tatsächlich aus Ihrer vertrauenswürdigen Empfangsumgebung stammt. Können Sie das nicht sicher feststellen, brechen Sie die Eigenanalyse ab.
3. SPF, DKIM, DMARC lesen und Domain prüfen: Lesen Sie die exakten Werte für spf=, dkim= und dmarc= und prüfen Sie bei jedem pass-Ergebnis, welche Domain tatsächlich bewertet wurde. Werten Sie das nicht als Entwarnung für Inhalt, Links oder Handlungsaufforderungen.
4. Bei Unklarheit abbrechen: War ein Wert oder die Herkunft unklar, beenden Sie die technische Eigenanalyse.
5. Wichtige Aufforderungen unabhängig prüfen: Nutzen Sie bei wichtigen oder unerwarteten Aufforderungen einen unabhängigen offiziellen Prüfweg. Haben Sie bereits Geld überwiesen, ein Passwort preisgegeben oder einen verdächtigen Anhang geöffnet, nutzen Sie sofort die Akutfall-Box am Artikelanfang statt weiter zu analysieren.
Weiterführende Fragen:
↑ Zurück zum Inhaltsverzeichnis
Offizielle Hilfe und Anlaufstellen
Vier offizielle Angebote für unterschiedliche Anliegen rund um die technische Header-Prüfung. Bei einem laufenden Vorfall haben die passenden Sofortmaßnahmen Vorrang. Wenn Sie bereits Zugangsdaten preisgegeben oder Geld überwiesen haben, nutzen Sie zuerst die Akutfall-Box am Artikelanfang.
Service-Center des BSI
IT-SicherheitInformationen und Unterstützung bei Fragen zu Phishing, E-Mail-Sicherheit und IT-Sicherheit allgemein. Keine Polizeidienststelle für Strafanzeigen.
Google Messageheader-Tool
Technische PrüfungAnalysewerkzeug, mit dem Sie den eingefügten vollständigen Header einer E-Mail strukturiert auswerten lassen können, einschließlich Transportweg und Authentifizierungsergebnissen, wenn die händische Auswertung an ihre Grenzen stößt.
IETF / RFC-Editor
Technische StandardsOffizielle technische Standarddokumente zu SPF, DKIM, DMARC und dem Authentication-Results-Feld, falls Sie eine Angabe aus diesem Artikel am Originaltext nachvollziehen möchten.
Verbraucherzentrale – Phishing-Radar
Verdacht meldenVerdächtige E-Mails an das Phishing-Radar weiterleiten. Die Meldungen werden ausgewertet, aber nicht individuell beantwortet.
Quellen
IETF / RFC Editor: RFC 5321 – Simple Mail Transfer Protocol (SMTP). Abrufdatum: 14.10.2026.
IETF / RFC Editor: RFC 5322 – Internet Message Format. Abrufdatum: 14.10.2026.
IETF / RFC Editor: RFC 8601 – Message Header Field for Indicating Message Authentication Status. Abrufdatum: 14.10.2026.
IETF / RFC Editor: RFC 7208 – Sender Policy Framework (SPF) for Authorizing Use of Domains in Email. Abrufdatum: 14.10.2026.
IETF / RFC Editor: RFC 6376 – DomainKeys Identified Mail (DKIM) Signatures. Abrufdatum: 14.10.2026.
IETF / RFC Editor: RFC 9989 – Domain-Based Message Authentication, Reporting, and Conformance (DMARC). Veröffentlichung: Mai 2026. Abrufdatum: 14.10.2026.
Google Gmail-Hilfe (englische Fassung; deutsche Oberflächentexte nicht einzeln geprüft): Trace an email with its full header. Abrufdatum: 14.10.2026.
Microsoft Support (englische Fassung; deutsche Oberflächentexte nicht einzeln geprüft): View internet message headers in Outlook – Abschnitt „New Outlook". Abrufdatum: 14.10.2026.
Verbraucherzentrale: So lesen Sie den E-Mail-Header. Stand: 04.11.2024. Abrufdatum: 14.10.2026.
Microsoft Q&A / Faery Fu-MSFT (moderierte Antwort, Profilkennzeichnung „Moderator", keine allgemeine Produktdokumentation): Email header of a sent email. Abrufdatum: 11.10.2026.
Apple Support (englische Fassung; deutsche Oberflächentexte nicht einzeln geprüft): View all email headers in Mail on iCloud.com. Abrufdatum: 14.10.2026.
Mozilla Support: Keyboard shortcuts – perform common Thunderbird tasks quickly. Abrufdatum: 14.10.2026.
Verbraucherzentrale – Phishing-Radar: Archiv, Eintrag „Angeblich 'dringendes Update' bei der Sparkasse erforderlich", 27.08.2026. Für die dokumentierte Fallillustration in Kapitel 5.
