Was ist Mail-Header-Analyse und wie führen Sie sie durch?

Phishing
Verfasst von MySecureGuard

Autor: MySecureGuard Redaktion

Veröffentlicht: 11.09.2026

Inhaltlich geprüft: 05.10.2026

Zuletzt aktualisiert: 05.10.2026

Geprüft für Gmail im Browser, neues und klassisches Outlook für Windows/Outlook im Web, iCloud Mail im Browser und Thunderbird · Stand: 05.10.2026

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. Sie müssen dafür kein Administrator und kein Programmierer sein.

Wichtig ist aber 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.

Wenn eine Nachricht Zeitdruck erzeugt, nutzen Sie als einfache kognitive Notbremse einen kurzen Drei-Sekunden-Stopp: Klicken, antworten oder bestätigen Sie nicht sofort. Öffnen Sie zuerst den Header beziehungsweise den echten Dienst über einen unabhängig bekannten Weg und prüfen Sie, was tatsächlich verlangt wird.

SICHERER WEG
Der Drei-Sekunden-Stopp ist keine Sicherheitsgarantie. Er schafft nur den Moment, in dem Sie aus dem vorgegebenen Kontaktweg aussteigen und technisch oder unabhängig prüfen können.

Wenn Sie zuerst nur den sichtbaren Namen und die sichtbare Absenderadresse prüfen möchten, lesen Sie Wie entlarven Sie gefälschte E-Mail-Absender?.

DAS WICHTIGSTE IN KÜRZE

  • Öffnen Sie zuerst den vollständigen Header mit dem für Ihr Mailprogramm belegten Weg.
  • Suchen Sie dort nach Authentication-Results: sowie nach den Werten für SPF, DKIM und DMARC.
  • Ein technisches pass bedeutet nur, dass genau diese technische Prüfung bestanden wurde. Es bedeutet nicht automatisch „Nachricht sicher“.
  • Bewerten Sie Authentication-Results nur, wenn Sie zuverlässig wissen, dass das Feld aus Ihrer vertrauenswürdigen Empfangsumgebung stammt.
  • Können Sie Herkunft, Felder oder Ergebnis nicht sicher einordnen, brechen Sie die Eigenanalyse ab und prüfen Sie die Nachricht über einen unabhängigen offiziellen Weg.
  • Wenn Sie bereits auf einen Link geklickt, Daten eingegeben, einen Anhang geöffnet oder Geld überwiesen haben, wechseln Sie direkt zu Kapitel 9 von Wie funktioniert Phishing und was wollen die Angreifer? und ordnen zuerst ein, was tatsächlich passiert ist.

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.

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

  1. Öffnen Sie Gmail auf einem Computer im Browser.
  2. Öffnen Sie die betreffende E-Mail.
  3. Suchen Sie rechts neben Antworten das Drei-Punkte-Menü.
  4. Klicken Sie auf dieses Menü.
  5. Wählen Sie Original anzeigen.
  6. Es öffnet sich eine neue Ansicht mit dem Nachrichtenursprung.

Woran erkennen Sie, dass es geklappt hat?

Sie sehen technische Zeilen wie From:, Received: oder Authentication-Results:.

Was tun, wenn Authentication-Results: fehlt?

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

  1. Öffnen Sie die E-Mail.
  2. Suchen Sie oben in der Nachricht Weitere Aktionen.
  3. Öffnen Sie Weitere Aktionen.
  4. Wählen Sie Anzeigen.
  5. Wählen Sie Nachrichtendetails anzeigen.
  6. Die technischen Nachrichtendetails werden eingeblendet.

Woran erkennen Sie, dass es geklappt hat?

Sie sehen technische Headerdaten, zum Beispiel From: und Transportfelder.

Was tun, wenn Authentication-Results: fehlt?

Raten Sie keinen Wert dazu. Wechseln Sie zu Kapitel 8.

Rückweg: Schließen Sie den Bereich mit den Nachrichtendetails.

Klassisches Outlook unter Windows

  1. Öffnen Sie die E-Mail per Doppelklick in einem eigenen Fenster.
  2. Klicken Sie auf Datei.
  3. Wählen Sie Eigenschaften.
  4. Suchen Sie das Feld Internetkopfzeilen.
  5. Lesen Sie dort die technischen Headerdaten.

Woran erkennen Sie, dass es geklappt hat?

Im Feld Internetkopfzeilen stehen mehrere technische Zeilen.

Rückweg: Schließen Sie das Eigenschaftenfenster.

Fehlerweg: Finden Sie den beschriebenen Bedienweg nicht oder fehlen die benötigten Headerfelder, übertragen Sie keinen Menüpfad aus einem anderen Programm. Nutzen Sie die aktuelle Herstellerhilfe oder wechseln Sie zu Kapitel 8.

iCloud Mail im Browser

  1. Öffnen Sie icloud.com/mail.
  2. Öffnen Sie die betreffende E-Mail.
  3. Wählen Sie Mehr.
  4. Wählen Sie Alle Header einblenden.

Woran erkennen Sie, dass es geklappt hat?

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.

Fehlerweg: Finden Sie den beschriebenen Bedienweg nicht oder fehlen die benötigten Headerfelder, übertragen Sie keinen Menüpfad aus einem anderen Programm. Nutzen Sie die aktuelle Herstellerhilfe oder wechseln Sie zu Kapitel 8.

Thunderbird

  1. Wählen Sie die betreffende E-Mail aus.
  2. Drücken Sie unter Windows/Linux Strg+U.
  3. Unter macOS drücken Sie Command+U.
  4. Der Nachrichtenquelltext öffnet sich.

Woran erkennen Sie, dass es geklappt hat?

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.

Fehlerweg: Finden Sie den beschriebenen Bedienweg nicht oder fehlen die benötigten Headerfelder, übertragen Sie keinen Menüpfad aus einem anderen Programm. Nutzen Sie die aktuelle Herstellerhilfe oder wechseln Sie zu Kapitel 8.

WICHTIG / PRÜFEN
Finden Sie den beschriebenen Bedienweg in Ihrer Oberfläche nicht wieder, übertragen Sie keinen Menüpfad aus einem anderen Programm. Nutzen Sie die aktuelle Herstellerhilfe oder brechen Sie die eigene Headeranalyse ab und wechseln Sie zu Kapitel 8.

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

Was bedeutet das?

Das ist die Adresse, die im sichtbaren Absenderfeld steht.

Was bedeutet es nicht?

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.

Was tun bei einer unerwarteten Domain?

Treffen Sie keine Betrugsentscheidung nur anhand dieser Abweichung. Prüfen Sie die Nachricht unabhängig über einen bekannten offiziellen Weg.

Erfolgssignal: Sie haben die Abweichung als Prüfhinweis eingeordnet, ohne daraus allein eine Echtheits- oder Betrugsentscheidung abzuleiten.

Fehlerweg: Können Sie die Domain nicht sicher einordnen, reagieren Sie nicht über die Nachricht und wechseln Sie zu einem unabhängig bekannten offiziellen Weg.

Return-Path:

Return-Path: enthält eine technische Rücksendeadresse aus dem SMTP-Umschlag.

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:

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.

Direkt nach Authentication-Results: steht normalerweise eine Kennung des prüfenden Systems. Diese Kennung heißt authserv-id.

Ein vertraut klingender Name reicht nicht.

Was tun, wenn Sie die Herkunft nicht sicher bestimmen können?

Brechen Sie die technische Bewertung ab und gehen Sie zu Kapitel 8.

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.

WICHTIG / PRÜFEN
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 angegebene Signing Domain gültig, und wurden die signierten Teile seit der Signierung 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.

Typische DMARC-Ergebnisse

  • dmarc=pass → Mindestens ein erfolgreich authentifizierter Identifier erfüllt das erforderliche Alignment.
  • dmarc=fail → Kein erfolgreich authentifizierter Identifier erfüllt das Alignment.
  • dmarc=none → Keine anwendbare DMARC-Richtlinie gefunden.
  • dmarc=temperror → Vorübergehender Auswertungsfehler.
  • dmarc=permerror → Dauerhafter Auswertungsfehler.

WICHTIG
Auch dmarc=pass bedeutet nicht „Nachricht sicher“. DMARC bewertet weder den Inhalt noch die Berechtigung einer Zahlung, Passwortänderung oder anderen Aufforderung.

Wie ordnen Sie technische Ergebnisse ohne Scheinsicherheit ein?

Beobachtung Einordnung und sicherer nächster Schritt
SPF, DKIM und DMARC zeigen pass[MEHRDEUTIG / PRÜFEN] Die technischen Prüfungen waren erfolgreich. Das ist noch kein Sicherheitsurteil über Inhalt, Link oder Aufforderung. [SICHERER SCHRITT] Prüfen Sie zusätzlich, welche Domain tatsächlich authentifiziert wurde und ob Sie diese Domain erwartet haben.
Ein Wert zeigt fail[ALARM / GEFAHR] Die betreffende technische Prüfung ist fehlgeschlagen. Das ist ein Warnsignal, aber für sich allein noch kein Phishing-Beweis. [SICHERER SCHRITT] Reagieren Sie nicht über die Nachricht und prüfen Sie den behaupteten Vorgang unabhängig.
Ein Wert zeigt none, neutral, temperror oder permerror[MEHRDEUTIG / PRÜFEN] Die Prüfung liefert keine klare positive Bestätigung beziehungsweise ist nicht eindeutig auswertbar. [SICHERER SCHRITT] 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[ALARM / GEFAHR] Auch eine fremde oder täuschend ähnliche Domain kann technisch korrekt SPF, DKIM und DMARC verwenden. [SICHERER SCHRITT] Verlassen Sie die Nachricht und prüfen Sie den Vorgang über einen unabhängig bekannten offiziellen Zugang.

4. Was kann eine Headeranalyse nicht beweisen?

Sie beweist nicht, dass die Nachricht harmlos ist

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,
  • eine konkrete Person die Nachricht geschrieben hat.

Sie beweist nicht automatisch die Identität des Absenders

Eine fremde Domain kann technisch sauber eingerichtet sein.

Deshalb ist eine erfolgreich authentifizierte Domain 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 aus Ihrer vertrauenswürdigen Empfangsumgebung stammt.

Received: ist kein Identitätsbeweis

Eine technisch plausibel wirkende Transportkette beweist nicht, dass die Nachricht von der behaupteten Organisation stammt.

5. 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 sehen mehrere technische Headerzeilen.

Fehlerweg: Funktioniert der belegte Weg nicht, wechseln Sie zu Kapitel 8.

Schritt 2: From: suchen

Suchen Sie die Zeile:

From:

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

Suchen Sie gezielt nach:

Authentication-Results:

Wenn mehrere solcher Zeilen vorhanden sind:

Das ist 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.

Wenn keine Zeile vorhanden ist:

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.

Das ist 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.

Erfolg erkennen: Sie können zuverlässig sagen, dass das ausgewertete Feld aus Ihrer vertrauenswürdigen Empfangsumgebung stammt.

Fehlerweg: 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=
  • dmarc=

Notieren Sie jeweils den exakten Wert dahinter.

Beispiel:

  • spf=pass
  • dkim=pass
  • dmarc=pass

Ordnen Sie unbekannte Werte nicht selbst um.

Schritt 6: Bewertete Domain prüfen

Suchen Sie nach Angaben wie:

  • header.from=
  • header.d=
  • smtp.mailfrom=

Für DMARC ist besonders header.from= wichtig.

Fragen Sie anschließend:

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

Alle drei zeigen pass?

Die technischen Prüfungen waren erfolgreich. Das ist keine Entwarnung.

Ein Wert zeigt fail?

Das ist ein technisches Warnsignal, aber allein kein Phishing-Beweis.

Ein Wert zeigt none?

Die betreffende Prüfung liefert keine entsprechende positive Authentifizierungsaussage.

Ein unbekannter Wert erscheint?

Nicht raten. Kapitel 8 nutzen.

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.

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

  1. From: zeigt support@sicher-bank.example.
  2. Return-Path: weicht ab. Das kann technisch legitim sein.
  3. spf=pass bedeutet: Der Server war für die geprüfte SPF-Domain autorisiert.
  4. dkim=pass bedeutet: Die DKIM-Signatur wurde erfolgreich geprüft.
  5. dmarc=pass bedeutet: Mindestens ein erfolgreich authentifizierter Identifier erfüllt das erforderliche Alignment.

Was dürfen Sie daraus schließen?

Nur:

Die dokumentierten technischen Prüfungen wurden für die jeweils geprüften Identitäten bestanden.

Was dürfen Sie daraus nicht schließen?

  • „Die Nachricht ist sicher.“
  • „Der Link ist sicher.“
  • „Die Zahlung ist berechtigt.“
  • „Die Person hat diese E-Mail wirklich geschrieben.“

7. Warum können auch bestandene Prüfungen täuschen?

Zweites 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.

ACHTUNG / SOFORT STOPPEN
Technische Authentifizierung bestätigt die tatsächlich verwendete Domain. Sie weiß nicht, welche Organisation Sie als Empfänger erwartet haben.

Deshalb gilt:

pass + falsche oder unerwartete Domain = keine Entwarnung.

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?

  1. Klicken Sie nichts in der verdächtigen Nachricht an.
  2. Verwenden Sie keine Telefonnummer, keinen QR-Code und keine Antwortadresse aus der Nachricht.
  3. Öffnen Sie den behaupteten Dienst über einen Weg, den Sie unabhängig von der Nachricht kennen.
  4. Nutzen Sie zum Beispiel:
    • eine bereits installierte offizielle App,
    • einen gespeicherten und vorher geprüften Zugang,
    • eine Internetadresse aus offiziellen Vertrags- oder Kontounterlagen,
    • eine Telefonnummer aus vorhandenen offiziellen Unterlagen.
  5. Prüfen Sie dort, ob die behauptete Aufforderung wirklich existiert.
  6. 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.

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

  1. Zahlen Sie nicht über den Link oder die Kontodaten aus der verdächtigen Nachricht.
  2. Öffnen Sie den bekannten offiziellen Dienst selbst oder nutzen Sie vorhandene Vertragsunterlagen.
  3. Bestätigen Sie die Änderung über einen bereits 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

  1. Verwenden Sie nicht den Link aus der E-Mail.
  2. Öffnen Sie die bereits installierte offizielle App oder einen Ihnen bekannten Zugang.
  3. 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

  1. Geben Sie keinen Code aufgrund der E-Mail-Aufforderung ein.
  2. Öffnen Sie den echten Dienst selbst.
  3. Prüfen Sie dort, 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

  1. Nutzen Sie einen bekannten internen Kontaktweg.
  2. Fragen Sie die zuständige IT, Sicherheitsstelle oder verantwortliche Person.
  3. Verwenden Sie nicht die in der verdächtigen 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.

SICHERER WEG
Ein technisches pass bestätigt eine technische Prüfung – nicht die Berechtigung einer Zahlung, eines Passwortwechsels oder einer anderen Handlung.

10. Wie kontrollieren Sie Ihre Mail-Header-Analyse systematisch Schritt für Schritt?

Nutzen Sie diese Checkliste nach Ihrer Headeranalyse:

Ihre Auswahl wird nur in diesem Browser auf diesem Gerät gespeichert.

Welche bereits veröffentlichten MySecureGuard-Anleitungen helfen Ihnen weiter?

Veröffentlichte MySecureGuard-Anleitungen für die weitere Prüfung
Ihre Situation / Frage Passende MySecureGuard-Anleitung
Sie möchten zuerst den sichtbaren E-Mail-Absender prüfen. Wie entlarven Sie gefälschte E-Mail-Absender?
Sie möchten einen Link oder eine Webadresse vor dem Öffnen prüfen. Wie prüfen Sie Links und Webadressen vor dem Klick?

ZUM SCHLUSS
Mail-Header können zusätzliche technische Hinweise liefern. Entscheidend ist aber nicht, möglichst viele Felder zu verstehen, sondern die wenigen relevanten Felder korrekt einzuordnen, rechtzeitig abzubrechen, wenn die Herkunft unklar ist, und wichtige Aufforderungen unabhängig über einen selbst gewählten offiziellen Weg zu bestätigen.

Quellen

Bundesamt für Sicherheit in der Informationstechnik (BSI): Newsletter „Einfach • Cybersicher“ vom 04.06.2025 – „E-Mail-Sicherheit: Mythen im Faktencheck“. Abrufdatum: 05.10.2026.
URL: https://www.bsi.bund.de/DE/Themen/Verbraucherinnen-und-Verbraucher/Informationen-und-Empfehlungen/Cyber-Sicherheitsempfehlungen/Sicherheitsirrtuemer/irrtuemer-e-mail-sicherheit.html

IETF / RFC Editor: RFC 5321 – Simple Mail Transfer Protocol (SMTP). Abrufdatum: 05.10.2026.
URL: https://www.rfc-editor.org/rfc/rfc5321.html

IETF / RFC Editor: RFC 5322 – Internet Message Format. Abrufdatum: 05.10.2026.
URL: https://www.rfc-editor.org/rfc/rfc5322.html

IETF / RFC Editor: RFC 8601 – Message Header Field for Indicating Message Authentication Status. Abrufdatum: 05.10.2026.
URL: https://www.rfc-editor.org/rfc/rfc8601.html

IETF / RFC Editor: RFC 7208 – Sender Policy Framework (SPF) for Authorizing Use of Domains in Email. Abrufdatum: 05.10.2026.
URL: https://www.rfc-editor.org/rfc/rfc7208.html

IETF / RFC Editor: RFC 6376 – DomainKeys Identified Mail (DKIM) Signatures. Abrufdatum: 05.10.2026.
URL: https://www.rfc-editor.org/rfc/rfc6376.html

IETF / RFC Editor: RFC 9989 – Domain-Based Message Authentication, Reporting, and Conformance (DMARC). Veröffentlichung: Mai 2026. Abrufdatum: 05.10.2026.
URL: https://www.rfc-editor.org/rfc/rfc9989.html

Google Gmail-Hilfe: Vollständigen E-Mail-Header lesen. Abrufdatum: 05.10.2026.
URL: https://support.google.com/mail/answer/29436?hl=de

Microsoft Support: Anzeigen von Internetnachrichtenheadern in Outlook. Abrufdatum: 05.10.2026.
URL: https://support.microsoft.com/de-de/outlook/view-internet-message-headers-in-outlook

Apple Support: Alle Header in einer E-Mail in „Mail“ auf iCloud.com anzeigen. Abrufdatum: 05.10.2026.
URL: https://support.apple.com/de-de/guide/icloud/mmcc887ce9/icloud

Mozilla Support: Keyboard shortcuts – perform common Thunderbird tasks quickly. Abrufdatum: 05.10.2026.
URL: https://support.mozilla.org/en-US/kb/keyboard-shortcuts-thunderbird

Polizeiliche Kriminalprävention der Länder und des Bundes / Initiative Sicher Handeln: Online-Betrug – Phishing. Abrufdatum: 05.10.2026.
URL: https://www.polizei-beratung.de/themen-und-tipps/sicher-handeln/onlinebetrug-maschen/phishing/

MySecureGuard
Zurück

Wie prüfen Sie Links und Webadressen vor dem Klick?
Weiter

Wie entlarven Sie gefälschte E-Mail-Absender?