Mail-Header und Spoofing

Wo der Header zu finden ist

Mail-Clients zeigen den Header standardmäßig nicht. Wo du ihn siehst:

Du siehst dann den Rohtext der Mail: zuerst die Header-Zeilen (eine pro Information), dann eine Leerzeile, dann der Mail-Body. Die Header sind oft mehrere Bildschirm-Seiten lang.

Wer Header strukturiert analysieren will, ohne sie selbst zu lesen: Online-Analyzer wie MXToolbox Email Header Analyzer oder Microsoft Message Header Analyzer zeigen alle relevanten Felder strukturiert.

Die wichtigsten Header-Felder

Ein Header enthält Dutzende Felder; sechs sind für Sicherheit besonders relevant:

From: — Sichtbarer Absender. Was du im Mail-Client siehst. Frei wählbar, im SMTP-Protokoll. Kein Authentizitäts-Garant. Beispiel:

From: "Sparkasse Berlin" <info@spk-berlin-security.cc>

Der Display-Name suggeriert die Bank, die Mail-Adresse ist eine fremde Domain. Klassischer Spoof.

Return-Path: und Envelope-From: — der echte Versand-Absender. Im SMTP-Protokoll der Absender, der für Bounces zuständig ist. Wird vom Empfangs-Server gesetzt. Ist oft anders als From: — und ist ein häufiges Spoofing-Indiz.

Received: — der Versand-Pfad. Pro Hop ein Received:-Eintrag, chronologisch von unten nach oben. Du siehst die Server-Kette: wer hat die Mail wann wem übergeben? Eine seriöse Mail von der Sparkasse hat einen Pfad, der Sparkassen-Server enthält. Eine Phishing-Mail hat oft Pfade über VPS-Anbieter, fremde IPs in Drittländer.

Authentication-Results: — die SPF/DKIM/DMARC-Auswertung des Empfangs-Servers. Eine Zeile, die kompakt zeigt: hat der Empfangs-Server die Mail als authentisch eingestuft? Zentral für Spoofing-Erkennung. Beispiel:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@sparkasse.de header.s=selector1;
       spf=pass (google.com: domain of bounce@sparkasse.de designates 1.2.3.4 as permitted sender);
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=sparkasse.de

Drei pass — Mail authentisch. fail oder none wäre Hinweis auf Spoof.

Reply-To: — wohin sollen Antworten gehen? Kann vom From: abweichen. Bei Phishing oft genutzt: legitimer-wirkender From:-Header, aber Reply-To: zeigt auf eine fremde Adresse.

Message-ID: — eindeutiger Identifier der Mail. Vom sendenden Server vergeben. Eine ungewöhnliche oder fehlende Message-ID kann ein Hinweis auf eine selbstgebaute Phishing-Mail sein.

Authentication-Results lesen

Diese eine Zeile ist das wichtigste Signal. Sie zeigt die Ergebnisse der drei großen Authentizitäts-Prüfungen, die der Empfangs-Server ausgeführt hat.

SPF-Werte:

• spf=pass — der sendende Server ist im SPF der angegebenen Domain autorisiert.
• spf=fail — der sendende Server ist nicht autorisiert. Starkes Spoof-Indiz.
• spf=softfail — wahrscheinlich nicht autorisiert, aber Domain hat ~all statt -all.
• spf=neutral — Domain hat keine klare Aussage.
• spf=none — die Absender-Domain hat überhaupt keinen SPF-Record.

DKIM-Werte:

• dkim=pass — die Mail hat eine gültige Signatur des im header.i=-Feld genannten Domains.
• dkim=fail — Signatur ungültig (Manipulation oder falsche Konfiguration).
• dkim=none — keine DKIM-Signatur vorhanden.

DMARC-Werte:

• dmarc=pass — SPF oder DKIM passt UND ist mit dem sichtbaren From: aligned.
• dmarc=fail — Authentifizierung fehlgeschlagen; Policy entscheidet (p=reject → Mail wird abgelehnt; p=quarantine → Spam; p=none → trotzdem durchgelassen).
• dmarc=none — Absender-Domain hat keinen DMARC-Record.

Interpretation für Nutzer:innen:

• Alle drei pass — sehr starke Authentizität.
• DKIM pass allein ist meist genug, weil DKIM die Mail-Inhalte kryptographisch signiert.
• DMARC fail bei Mail von angeblicher Bank/Behörde — sehr verdächtig. Banken haben in der Regel p=reject.
• Alle none — keine Authentizität gegeben. Bei privater Korrespondenz oft normal, bei angeblichen Banken/Behörden ein Warnsignal.

Den Received-Pfad lesen

Der Received:-Pfad zeigt die Server-Kette, die die Mail durchlaufen hat. Lies chronologisch von unten nach oben.

Beispiel einer typischen Mail:

Received: by 2002:a17:907:7619:b0:abc:def0::: with SMTP id …
        for <empfaenger@example.de>; Mon, 05 May 2025 14:23:11 +0200 (CEST)
Received: from mx.sparkasse.de (mx.sparkasse.de [4.3.2.1])
        by mx.example.de (Postfix) with ESMTPS id ABC123
        for <empfaenger@example.de>; Mon, 05 May 2025 14:23:08 +0200 (CEST)
Received: from internal.sparkasse.de ([10.0.0.5])
        by mx.sparkasse.de (Postfix); Mon, 05 May 2025 14:23:05 +0200 (CEST)

Lies von unten nach oben:

1. Mail entsteht intern bei Sparkasse (internal.sparkasse.de).
2. Geht an den Sparkassen-Outbound-Server (mx.sparkasse.de).
3. Wird an den Empfangs-Server (mx.example.de) übergeben.

Diese Kette ist plausibel für eine Sparkassen-Mail.

Phishing-Pfad sieht oft anders aus:

Received: by mx.example.de from mail.cheaphosting.tk ([198.51.100.42])
Received: from win-server-vps.cheaphosting.tk by relay.cheaphosting.tk;

• VPS-Anbieter als Versand-Server.
• IP-Adresse nicht zur angegebenen Marke passend.
• Keine Sparkassen-Domains in der Kette, obwohl From: von Sparkasse spricht.

Was du beim Lesen prüfen kannst:

• Passt die unterste „Received:"-Quelle zur sichtbaren Absender-Domain?
• Sind die IPs aus Ländern, die Sinn ergeben? Eine deutsche Bank-Mail aus IPs in Vietnam ist verdächtig.
• Wie viele Hops? Sehr viele Hops über fremde Provider können ein Spoof-Indiz sein.

---

Spoofing-Erkennungs-Workflow

Wenn dir eine Mail verdächtig vorkommt, ein 60-Sekunden-Check:

1. Mail-Header öffnen (siehe Tabelle in Abschnitt 1).

2. Header in einen Online-Analyzer kopieren (MXToolbox, Microsoft Header Analyzer).

3. Authentication-Results prüfen:

• Drei pass → höchstwahrscheinlich authentisch.
• Ein oder mehrere fail → wahrscheinlich Spoof.
• Alle none und Absender ist angebliche Bank/Behörde/Konzern → sehr verdächtig.

4. From-Adresse mit Return-Path vergleichen:

• Domain identisch → ok.
• Verschiedene Domains, vor allem ähnlich-klingende → Phishing-Verdacht.

5. Received-Pfad scannen:

• Endet die unterste „Received from"-Zeile bei einem Server, der zur angeblichen Absender-Marke passt?
• Gibt es VPS-Anbieter oder Drittland-Hosts in der Kette, die nicht zur Marke passen?

6. Bei klarem Verdacht: Mail melden (siehe phishing-meldungen-und-reports). Nicht auf Links klicken oder Anhänge öffnen.

Das ist kein Anfänger-Workflow für jede Mail — aber bei wichtigem Verdacht (Banken-Mail, Behörden-Mail, ungewöhnliche Geschäfts-Mail) lohnen sich die 60 Sekunden.

Typische Spoofing-Spuren

Was Spoofing-Versuche im Header verraten:

Wichtig: kein Einzel-Indiz beweist Spoofing. Aber zwei oder mehr zusammen geben hohe Gewissheit.

Was bedeutet das alles für dich?

Die meisten Mail-Nutzer:innen lesen nie einen Header. Das ist auch okay — moderne Mail-Provider machen die wichtigsten Prüfungen automatisch und zeigen Warnungen, wenn DMARC fehlschlägt.

Wann lohnt es sich, selbst zu prüfen:

• Bei kritischen Mails (Geld-Transfer-Aufforderung, „dein Account wird gesperrt", Lieferanten-IBAN-Wechsel, ungewöhnliche CEO-Anweisung).
• Bei Mails, die zu gut wirken (Gewinn-Benachrichtigung, plötzliche Erstattung).
• Bei beruflichen Spear-Phishing-Vorbereitungen in IT-Abteilungen.
• Aus reiner Neugier — Mail-Header zu lesen ist eines der lehrreichsten Sicherheits-Skills.

Was Mail-Provider für dich tun:

• Spam-Filter prüfen Header automatisch und sortieren verdächtige Mails aus.
• „Diese Mail kommt von außerhalb"-Banner zeigen viele Office-Mail-Setups bei DMARC-Fehlern oder externen Absendern.
• BIMI-Logos (Marken-Logos in der Inbox) sind ein zusätzliches Authentizitäts-Signal bei Großmarken.
• Smart-Filter (Microsoft, Google) erkennen Spoofing-Muster oft, bevor du die Mail siehst.

Was du daraus mitnimmst: Wenn eine Mail trotz aller Schutz-Schichten Verdacht erzeugt, ist der Header der schnellste Weg zur Klarheit. Und wenn du eigene Mails schickst (für berufliche Korrespondenz, eigene Domain): SPF, DKIM, DMARC ordentlich konfigurieren — sonst gehst du in fremden Empfänger-Filtern verloren.

FAQ

Warum sehe ich oft `dmarc=none`?

Viele kleine und mittlere Domains haben kein DMARC konfiguriert. Bei privater Korrespondenz ist das normal — auch wenn es nicht ideal ist. Bei Banken oder großen Konzernen sollte DMARC immer aktiv sein; ein dmarc=none bei angeblicher Bank ist verdächtig.

Was tut MXToolbox genau?

Der MXToolbox Email Header Analyzer nimmt einen kopierten Header und visualisiert Versand-Pfad, Authentication-Results, geografische Lage der Server. Sehr nützlich für Anfänger und Profis. Achte aber: deine Header werden hochgeladen — bei sensitiven beruflichen Mails datenschutz-bewusst handhaben oder lokale Tools (grep, eigene Skripte) nutzen.

Was ist mit ARC?

ARC (Authenticated Received Chain) ist eine Erweiterung, die hilft, wenn Mails über mehrere Mittelstationen geleitet werden (z. B. Mailing-Listen). Jeder Mittelstation kann eine ARC-Signatur ergänzen, sodass der finale Empfänger nicht durch die Mittelstation in der Authentifizierungs-Prüfung verwirrt wird. Selten ein direkter Sicherheits-Hinweis für Endnutzer:innen, aber im Header oft sichtbar.

Wie zuverlässig sind diese Indikatoren?

Bei Massen-Phishing sehr zuverlässig — die Angreifer haben keine Zeit für perfekte Spoofing-Vorbereitung. Bei gezielten Spear-Phishing-Angriffen ist die technische Schicht oft makellos: Angreifer registrieren echte Domains, konfigurieren SPF/DKIM/DMARC ordentlich. In diesen Fällen müssen andere Signale (URL-Domain, Kontext, Rückbestätigung über zweiten Kanal) übernehmen — Header allein reicht nicht.

Sind die Header rechtssicherer Beweis?

In Deutschland werden Mail-Header in Strafverfahren als Beweismittel anerkannt — sie sind Teil des automatisch protokollierten Mail-Verkehrs. Bei Verdacht auf strafbare Mail-Inhalte (Phishing, BEC, Erpressung): Mail mit allen Headern als .eml-Datei sichern und der Strafverfolgung übergeben. Mail einfach weiterleiten verfälscht die Header und reduziert den Beweiswert.

Wie lese ich Mail-Header auf dem Smartphone?

Auf iOS und Android ist die Header-Anzeige in Standard-Mail-Apps oft sehr eingeschränkt. Empfehlung: Mail an einen Desktop-Client weiterleiten oder per Webmail im Mobile-Browser öffnen und dort die Header-Funktion nutzen. Manche Apps (Mailbox.org, Proton) zeigen Header direkt — viele andere nicht.

Wer schon einmal DMARC-Reports bekommen hat

Wer eine eigene Domain hat und in den DMARC-Record eine rua=mailto:reports@…-Adresse einträgt, bekommt täglich aggregierte XML-Reports — zeigt, wer im Namen der Domain Mails versendet (eigene Server, legitime Drittanbieter, Spoofing-Versuche). Aufschlussreich. Tools wie dmarcian.com oder Postmark DMARC Digest visualisieren die Reports.

Weiterführende Ressourcen

Externe Quellen

• MXToolbox – Email Header Analyzer
• Microsoft – Message Header Analyzer
• Google – Anzeigen vollständiger Mail-Header (Hilfe)
• RFC 5322 – Internet Message Format
• RFC 7489 – DMARC
• dmarcian – DMARC Reports verstehen
• Postmark – DMARC Digests
• BSI – Phishing erkennen

Verwandte Artikel

• E-Mail-Sicherheit Grundlagen
• Mail-Aliase und Wegwerfadressen
• PGP und S/MIME
• Phishing erkennen
• Spear-Phishing und CEO-Fraud
• Phishing melden und nach Klick reagieren