Ratgeber · E-Mail & Domains

So liest du E-Mail-Header und erkennst Phishing

Geschrieben von Aldo · Threat Hunter im Blue Team
Zuletzt aktualisiert am 9. November 2026 · 5 Min. Lesezeit

Eine Mail gibt vor, von deiner Bank, deiner Chefin oder deinem Lieferanten zu kommen. Die sichtbare From-Zeile ist nur Text, den der Absender eingetippt hat. Die Header darunter halten fest, was die Mailserver tatsächlich gesehen haben, und die sind viel schwerer zu fälschen.

Die vollständigen Header öffnen

Jedes Mailprogramm versteckt sie standardmäßig. Hier findest du sie (Menünamen ändern sich zwischen Versionen, aber diese sind seit einer Weile stabil):

• Gmail (Web): Mail öffnen, auf die drei Punkte neben Antworten klicken, dann Original anzeigen.
• Outlook im Web und das neue Outlook: Mail öffnen, die drei Punkte wählen, dann Ansicht → Nachrichtendetails anzeigen.
• Klassisches Outlook für Windows: Mail in einem eigenen Fenster öffnen, dann Datei → Eigenschaften; die Header stehen unter Internetkopfzeilen.
• Apple Mail auf dem Mac: Darstellung → E-Mail → Alle Header.
• Thunderbird: Ansicht → Quelltext der Nachricht (Strg+U).
• Mail-Apps auf iPhone und Android zeigen meist keine vollständigen Header. Öffne dasselbe Postfach am Computer.

Kopier alles vom Anfang bis zur ersten Leerzeile. Dieser Block ist der Header.

Ein Praxisbeispiel: die überfällige Rechnung

Das ist das Beispiel aus der Header-Analyse von iplover. Die Domains sind Dokumentationsdomains (example.com, .org, .net) und die Absenderadresse ist ein öffentlicher Tor-Exit, also ist kein echtes Unternehmen und keine echte Person beteiligt, aber jede Zeile ist von der Art, der du in echtem Phishing begegnest:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.org header.s=s1 header.b=Xy12;
       spf=pass (google.com: domain of bounce@mailer.example.org designates 198.51.100.25 as permitted sender) smtp.mailfrom=bounce@mailer.example.org;
       dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE) header.from=example.com
Return-Path: <bounce@mailer.example.org>
Received: from relay.mailer.example.org (relay.mailer.example.org. [198.51.100.25])
        by mx.google.com with ESMTPS id 5a1b2c3d4e
        for <you@example.net>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 03 Nov 2026 10:14:04 -0800 (PST)
Received: from webmail.example.org (unknown [185.220.101.7])
        by relay.mailer.example.org (Postfix) with ESMTPSA id 7C1A2B3;
        Tue,  3 Nov 2026 16:11:58 +0000 (UTC)
Received: from [10.0.0.12] (localhost [127.0.0.1])
        by webmail.example.org with ESMTP;
        Tue,  3 Nov 2026 16:11:55 +0000 (UTC)
From: "Example Billing" <billing@example.com>
Reply-To: payments-desk@example.net
Subject: Invoice 4471 is overdue
Message-ID: <20261103161152.4471@mailer.example.org>
X-Originating-IP: [185.220.101.7]

(Gekürzt; das vollständige Beispiel enthält auch ARC-Header, die Prüfungen von Servern unterwegs festhalten.) Das Urteil der Analyse:

So liest du ihn, Zeile für Zeile

1. Authentication-Results: das Urteil des empfangenden Servers

Der empfangende Server (hier der von Google) hat die Nachricht geprüft und die Ergebnisse notiert. Lies die oberste Authentication-Results-Zeile: Sie hat dein eigener Mailanbieter hinzugefügt. Alles weiter unten könnte jeder geschrieben haben, auch der Absender.

Der Trick an diesem Beispiel: SPF und DKIM haben beide bestanden, nur nicht für die richtige Domain. SPF bestand für mailer.example.org und DKIM für example.org, aber die From-Adresse lautet example.com. DMARC ist die Prüfung, die das Ergebnis an die From-Domain bindet, und sie ist gescheitert. Der Inhaber von example.com hatte sogar eine Policy veröffentlicht, solche Mails abzulehnen. Dieses Muster, alles bestanden außer DMARC, ist das typische Bild gefälschter Mails.

2. From, Reply-To und Return-Path: wer sie zu sein behauptet, und wohin Antworten gehen

Die From-Zeile zeigt „Example Billing“ bei example.com. Reply-To schickt deine Antwort dagegen an example.net. Helpdesks und Mailinglisten machen das legitim, aber bei einer unerwarteten Rechnung heißt es: Wer das geschrieben hat, will deine Antwort an einem Ort, den die echte Firma nicht kontrolliert. Return-Path ist das Ziel für Unzustellbarkeitsmeldungen; die Domain eines Versanddienstes ist dort normal.

3. Received: der Zustellweg, von unten nach oben gelesen

Jeder Server, der eine Nachricht weiterreicht, setzt oben eine Received-Zeile dazu, die älteste steht also unten. Lies nach oben: Ein Gerät in einem privaten Netz (10.0.0.12) gab die Mail an das Webmail, das sie von 185.220.101.7 bekam, einem Tor-Exit, bevor sie an das Relay und weiter an Google ging. Diese erste öffentliche Adresse ist das Nächste, was du vom Absender sehen kannst, und hier ist sie bewusst anonym. X-Originating-IP, das manche Webmail-Dienste setzen, sagt dasselbe.

Auch die Zeiten erzählen etwas: zwei Stunden zwischen dem Relay und Google. Verzögerungen haben oft harmlose Gründe, aber sie fallen auf.

Wenn du das siehst, tu das

Was Header nicht verraten

Header beweisen, woher eine Nachricht kam, nicht was sie will. Eine Nachricht von einem gehackten, aber echten Konto besteht jede Prüfung. Eine Doppelgänger-Domain besteht DMARC für sich selbst. Und über den Link oder den Anhang, in denen meist der Schaden steckt, sagen Header nichts. Header sind also ein Test unter mehreren: Eine unerwartete Bitte um Geld, Passwörter oder schnelle Entscheidungen verdient Misstrauen, egal was die Header sagen.

Die Analyse von iplover liest die Ergebnisse, die dein Anbieter festgehalten hat; sie prüft DKIM-Signaturen nicht selbst nach und ruft nicht für jede Station die SPF-Einträge ab. Das sagt sie am Ende jedes Berichts, und es ist gut, das bei jedem Werkzeug im Hinterkopf zu behalten.