E-Mail-Header lesen und Spoofing erkennen

Jede E-Mail trägt in ihren Headern eine vollständige Spur: die Server, die sie passiert hat, die Authentifizierungsergebnisse und den echten Envelope-Absender. Wer sie flüssig liest, bestätigt oder widerlegt einen vermuteten Spoof am schnellsten — eine Kernfähigkeit beim Sichten gemeldeter Phishing-Mails.

Wo die rohen Header stehen

Die dargestellte Nachricht verbirgt alles Nützliche. Holen Sie sich die Rohquelle:

• Gmail — Original anzeigen.
• Outlook — Datei → Eigenschaften → Internetkopfzeilen (oder Nachrichtenquelle anzeigen).
• Apple Mail — Darstellung → E-Mail → Rohformat.
• Kommandozeile — die .eml-Datei direkt ansehen.

Für den Zustellweg liest man Header von unten nach oben: der älteste Sprung steht unten, das Received: des empfangenden Servers ganz oben.

Die Identitäten, auf die es ankommt

Es gibt zwei „From“-Werte, und Phishing nutzt genau die Lücke dazwischen:

• Envelope-Absender (Return-Path / MAIL FROM) — für Routing und Bounces; von SPF geprüft.
• Header-From (From:) — das, was die Nutzerin im Programm sieht.

Ein Spoof zeigt typischerweise ein vertrauenswürdiges From:, während der Return-Path irgendwo anders hinzeigt.

Return-Path: <[email protected]>
From: "IT Helpdesk" <[email protected]>

Der Anzeigename (IT Helpdesk) ist vollständig vom Angreifer bestimmt und beweist nichts.

Authentication-Results lesen

Der mit Abstand wichtigste Header ist Authentication-Results, hinzugefügt von Ihrem empfangenden Server (vertrauen Sie nur dem Ihrer eigenen Domain, ganz oben):

Authentication-Results: mx.yourcompany.example;
  spf=pass (sender IP is 198.51.100.10) [email protected];
  dkim=fail header.d=yourbank.example;
  dmarc=fail (p=reject) header.from=yourbank.example

Sorgfältig auslegen:

• spf=pass ist hier eine Falle — es bestand für sketchy-host.ru, nicht für das sichtbare yourbank.example. SPF prüft den Envelope, nicht das From:.
• dkim=fail — keine gültige Signatur, die zur From:-Domain ausgerichtet ist.
• dmarc=fail (p=reject) — das ist das Urteil, das zählt: die Authentifizierung der sichtbaren Domain richtet sich nicht aus. Eine Nachricht, die trotz dmarc=fail im Postfach landet, verdient genaue Prüfung.

Vergleichen Sie stets die Domain, die jeder Mechanismus tatsächlich authentifiziert hat (smtp.mailfrom, header.d), mit der From:-Domain. Authentifizierung ohne Ausrichtung bedeutet nichts.

Den Weg über Received nachverfolgen

Jeder Sprung stellt eine Received:-Zeile voran. Von unten nach oben lesen:

Received: from mail.evilrelay.ru (mail.evilrelay.ru [203.0.113.7])
    by mx.yourcompany.example ...; Tue, 08 Jul 2026 09:14:22 +0000
Received: from unknown (HELO localhost) (185.220.101.5)
    by mail.evilrelay.ru ...

Warnzeichen:

• Die IP des ersten Sprungs liegt geografisch weit von dort, wo der Absender zu sein behauptet.
• Ein gefälschtes HELO (localhost oder ein Hostname, der nicht zum Reverse-DNS passt).
• Verdächtige Lücken oder Zeitzonensprünge in den Zeitstempeln.
• Der erste vertrauenswürdige Sprung ist Ihr eigener MX — alles darunter stammt vom Angreifer und ist fälschbar, also entsprechend gewichten.

Weitere Hinweise in den Headern

• Abweichendes Reply-To — From: sieht aus wie eine Kollegin, doch Reply-To lenkt Antworten an eine externe Adresse. Klassiker bei BEC und CEO-Betrug.
• Message-ID-Domain, die nicht zur sendenden Domain passt.
• X-Mailer / X-PHP-Script-Header, die ein Massenwerkzeug oder ein PHP-Skript auf einem kompromittierten Host verraten.
• Unicode/Punycode in der From:-Domain (xn--) — ein Homograph-Angriff.

Eine schnelle Prüfliste

1. Ist die From:-Domain == Return-Path-Domain?        (Abweichung = verdächtig)
2. Authentication-Results: dmarc=pass und ausgerichtet? (fail = verdächtig)
3. Welche Domain hat SPF/DKIM tatsächlich authentifiziert? (muss zu From: passen)
4. Weicht Reply-To von From: ab?                       (ja = verdächtig)
5. Woher stammt der unterste Received-Sprung?          (unerwartete Geo = verdächtig)
6. Punycode / Homoglyphen in der From:-Domain?         (ja = verdächtig)

Ein einzelner Header beweist selten allein einen Spoof. Das Urteil kommt aus der Ausrichtung: Passt die Domain, die authentifiziert hat, zu der, die der Mensch sieht? Genau dafür gibt es DMARC — bei eingehender Post von fremden Domains müssen Sie das aber weiterhin von Hand lesen.

Wie GottaPhish hilft

Header zu lesen ist reaktiv und Expertensache; die meisten Nutzenden sehen sie nie. GottaPhish und sein Expertenteam schlagen diese Brücke: realistisches simuliertes Phishing — Ausrichtungslücken, Reply-To-Tausch, ähnlich aussehende Domains — plus Dashboards, die genau zeigen, wer gemeldet, geklickt oder Zugangsdaten eingegeben hat. Unsere Fachleute unterstützen bei der Einrichtung, entwerfen Szenarien, die genau die Header-Tricks echter Angreifer durchspielen, und helfen beim Deuten der Ergebnisse — so schärfen technische Teams ihre Triage-Playbooks, während die Schulung allen anderen die sichtbaren Warnzeichen hinter diesen Headern beibringt.