E-Mail-Header lesen und Phishing erkennen
Was hinter Absender, Betreff und Datum steckt: Received-Kette, SPF/DKIM/DMARC und die Warnsignale, die Phishing-Mails verraten.
Der E-Mail-Header zeigt den technischen Weg einer Nachricht: Received-Zeilen verraten die Serverstationen, Authentication-Results die Prüfungen SPF, DKIM und DMARC. Warnsignale für Phishing sind fehlgeschlagene Prüfungen, widersprüchliche Absenderangaben in From, Return-Path und Reply-To sowie eine Received-Kette, die nicht zur behaupteten Absenderdomain passt.
Jede E-Mail besteht aus zwei Teilen: dem sichtbaren Inhalt – und einem unsichtbaren technischen Vorspann, dem Header. Dort steht, welchen Weg die Mail genommen hat, ob der Absender echt ist und welche Prüfungen sie bestanden hat. Ihr Mailprogramm zeigt Ihnen davon nur Absender, Betreff und Datum – der Rest bleibt verborgen. Genau dort aber verstecken sich die Spuren von Phishing und Fälschung.
Dieser Ratgeber zeigt, wie Sie den Header einblenden, die wichtigsten Zeilen lesen und die Warnsignale deuten. Sie brauchen dafür kein Technikstudium – nur ein paar Minuten und die Bereitschaft, genauer hinzusehen.
Was ist ein E-Mail-Header?
Der Header ist der technische Begleitschein jeder E-Mail – vergleichbar mit den Poststempeln auf einem Briefumschlag. Er enthält unter anderem:
- From: den angezeigten Absender (leicht fälschbar!)
- To, Date, Subject: Empfänger, Datum, Betreff
- Received: die Stationen, die die Mail durchlaufen hat – von unten nach oben gelesen
- Return-Path: die Adresse für Unzustellbarkeits-Nachrichten (Bounces)
- Authentication-Results: die Ergebnisse der Echtheitsprüfungen SPF, DKIM und DMARC
- Message-ID: eine weltweit eindeutige Kennung der Nachricht
So blenden Sie den Header ein: In Gmail öffnen Sie die Mail, klicken auf die drei Punkte und wählen „Original anzeigen“. In Outlook (Desktop) öffnen Sie die Nachricht in einem eigenen Fenster und wählen Datei → Eigenschaften → Internetkopfzeilen. In Thunderbird: Ansicht → Kopfzeilen → Alle. Wer die Analyse nicht von Hand machen will, kann den kompletten Header in unsere E-Mail-Header-Analyse einfügen – sie zerlegt ihn automatisch in lesbare Abschnitte.
Die Received-Kette lesen: Wo kam die Mail wirklich her?
Das Herzstück des Headers ist die Kette der Received-Zeilen. Jeder Mailserver, der die Nachricht weiterleitet, stempelt oben eine neue Zeile dazu. Deshalb liest man die Kette von unten nach oben: Ganz unten steht der erste Server (nahe beim Absender), ganz oben der letzte (Ihr Postfachanbieter).
Eine typische (verkürzte) Kette sieht so aus:
Received: from mail.bank-beispiel.de (mail.bank-beispiel.de [203.0.113.10])← AbsenderserverReceived: from mx.example-provider.de by mx.ihre-domain.de ...← ZwischenstationReceived: from mx.ihre-domain.de by postfach.ihr-anbieter.de ...← Ihr Anbieter (ganz oben)
Worauf Sie achten: Passt der Absenderserver zur behaupteten Absenderdomain? Eine Mail, die angeblich von Ihrer Bank kommt, aber von einem Server namens srv-random-hosting.ru oder einer dynamischen IP eingeliefert wurde, ist so gut wie sicher gefälscht. Auch Zeitstempel helfen: Liegen zwischen den Stationen Stunden, obwohl die Mail „dringend“ sein soll, passt etwas nicht.
Ehrlicherweise: Die untersten Received-Zeilen kann ein Angreifer selbst schreiben – sie sind nur so vertrauenswürdig wie der erste fremde Server in der Kette. Verlassen Sie sich deshalb nie auf eine einzelne Zeile, sondern auf das Gesamtbild inklusive der Authentifizierungsprüfungen.
SPF, DKIM und DMARC verstehen
Drei Verfahren schützen vor Absenderfälschung – und ihr Ergebnis steht in der Zeile Authentication-Results. Kurz erklärt:
| Verfahren | Was es prüft | Im Header zu finden als |
|---|---|---|
| SPF (Sender Policy Framework) | Darf dieser Server überhaupt Mails für die Absenderdomain verschicken? (Liste im DNS der Domain) | spf=pass bzw. spf=fail |
| DKIM (DomainKeys Identified Mail) | Trägt die Mail eine gültige kryptografische Signatur der Absenderdomain – und wurde sie unterwegs verändert? | dkim=pass bzw. dkim=fail |
| DMARC | Stimmen Absenderdomain und geprüfte Domain überein – und was soll bei Verstoß passieren (ablehnen, Quarantäne)? | dmarc=pass bzw. dmarc=fail |
Die Daumenregel: Alle drei „pass“ bei einer Mail Ihrer Bank oder Ihres Arbeitgebers ist ein gutes Zeichen. SPF- oder DKIM-„fail“ bei angeblich wichtigen Absendern ist ein starkes Warnsignal – dann wurde entweder gefälscht oder schlampig konfiguriert. Beides ist Grund zur Vorsicht.
Ob eine Domain diese Schutzverfahren überhaupt eingerichtet hat, prüfen Sie mit unserem MX/SPF-Check: Er zeigt die Mailserver-Einträge (MX) sowie SPF-, DKIM- und DMARC-Records einer Domain an. Eine Bank ganz ohne SPF-Record wäre 2026 ein Armutszeugnis – und ein Hinweis, genauer hinzusehen.
From vs. Return-Path vs. Reply-To: drei Absender, drei Wahrheiten
Eine E-Mail kennt nicht einen Absender, sondern mehrere – und genau das nutzen Phisher aus:
- From: Was Ihr Mailprogramm als Absender anzeigt. Frei erfunden – hier kann „Ihre Bank“ stehen, obwohl nichts davon stimmt. Auch der angezeigte Name („Max Mustermann <rechnung@fremde-domain.de>“) täuscht: Viele lesen nur den Namen.
- Return-Path (Envelope-From): Die technische Absenderadresse, an die Bounces gehen. Sie wird beim Einliefern gesetzt und ist schwerer zu fälschen – SPF prüft genau diese Adresse.
- Reply-To: Wohin Ihre Antwort geht, wenn Sie auf Antworten klicken. Phisher setzen hier gern ihre eigene Adresse ein – Sie antworten dann direkt dem Betrüger.
Der entscheidende Vergleich: Stimmen angezeigte From-Domain, Return-Path-Domain und Reply-To-Domain überein? Eine „Bank-Mail“ mit From: service@meine-bank.de, aber Return-Path: bounce@billig-mailer.xyz und Reply-To: support@meine-bank-support.com ist ein Lehrbuchfall für Phishing.
Warnsignale im Überblick
Fassen wir zusammen – diese Punkte sollten Sie stutzig machen:
- SPF/DKIM/DMARC schlagen fehl – besonders bei Banken, Behörden, Arbeitgebern.
- Received-Kette passt nicht zur Absenderdomain (fremder Server, seltsames Land, dynamische IP).
- From, Return-Path und Reply-To widersprechen sich oder zeigen auf Lookalike-Domains (meine-bankk.de, paypaI.com mit großem i).
- Message-ID-Domain passt nicht zum Absender (z. B.
@fremder-server.netstatt@bank.de). - Datum in der Zukunft oder weit in der Vergangenheit – manche Phishing-Tools setzen es falsch.
- Verdächtige X-Header wie Massenversand-Tools, die nicht zum Absender passen.
- Inhaltliche Klassiker parallel dazu: Zeitdruck („Ihr Konto wird in 24 Stunden gesperrt“), Links mit abweichendem Ziel (mit der Maus darüberfahren!), Aufforderung zu Passwort- oder TAN-Eingabe.
Ein einzelnes Warnsignal beweist noch nichts – seriöse Newsletter scheitern auch mal an DKIM. Aber zwei oder mehr Treffer, besonders in Kombination mit Zeitdruck im Text, bedeuten: Finger weg von Links und Anhängen, Absender über einen unabhängigen Kanal verifizieren.
Quellen: RFC 5322 (Header-Format), RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 (DMARC); BSI-Empfehlungen zu Phishing-Abwehr. Stand: Oktober 2026. Alle Angaben ohne Gewähr.
Etwas stimmt nicht? Fehler melden
Die Meldung wird in Ihre Zwischenablage kopiert – senden Sie sie dem Betreiber (Kontaktadresse im Impressum).