Email-Header verstehen — Anatomie nach RFC 5322

Jede E-Mail trägt einen strukturierten Header mit Metadaten — Absender, Empfänger, Subject, Message-ID, Authentication-Results, DKIM-Signature, ARC-Seal. Standardisiert in RFC 5322 (Internet Message Format, Oktober 2008, Pete Resnick/Qualcomm) und ergänzt durch RFC 8601 (Authentication-Results, Mai 2019) und RFC 8617 (ARC, Juli 2019). Dieser Deep-Dive führt Sie durch jedes wichtige Header-Feld, erklärt die Header-Forensik bei Phishing-Verdacht und zeigt die wichtigsten Tools zur Header-Analyse.

Eigene Domain prüfen Plattform entdecken

Einführung · Trends + Verschlüsselung

Von Wolf-Agents Security Team · Aktualisiert: 18. Mai 2026

Definition

Was ist ein Email-Header und warum er wichtig ist

Ein Email-Header ist der Metadaten-Teil einer E-Mail — formal definiert in RFC 5322 (Internet Message Format, Oktober 2008, Pete Resnick/Qualcomm Incorporated). Er steht vor dem Body, getrennt durch eine Leerzeile, und enthält strukturierte Felder wie From, To, Subject, Date, Message-ID, Return-Path, Received und Authentication-Results. Jeder MTA (Mail Transfer Agent) auf dem Versand-Weg ergänzt eigene Header — die Header-Sektion wächst mit jedem Hop. Im Mail-Client ist der vollständige Header über „Original anzeigen“ / „Show Original“ / „View Source“ sichtbar.

Email-Header sind die zentrale forensische Beweisquelle bei Phishing-Verdacht, BEC-Fällen und Spoofing-Vorfällen. Sie zeigen die echte Versand-Infrastruktur (Received-Chain), das Authentifizierungs-Ergebnis (Authentication-Results nach RFC 8601) und die DKIM-Signatur (RFC 6376). Wer Header lesen kann, erkennt Spoofing-Versuche, gebrochene Authentifizierung und ungewöhnliche Versand-Pfade — unabhängig vom angeblichen Absender im From-Feld. Tools wie der Microsoft Message Header Analyzer und die Google Toolbox Messageheader visualisieren Header strukturiert und kennzeichnen Inkonsistenzen.

Header-Hierarchie nach Wichtigkeit für Forensik

Authentication-Results (RFC 8601): Liefert SPF/DKIM/DMARC-Verdikt — die wichtigste Einzelinformation bei Phishing-Verdacht.
Return-Path / Envelope-From: SMTP MAIL FROM aus RFC 5321 — geht meist mit From-Domain konform, abweichende Domains sind Spoofing-Indikator.
From (RFC 5322): Der sichtbare Absender im Mail-Client — kann gefälscht sein, wenn DMARC nicht greift.
Received-Chain: Trace-Information aller MTAs auf dem Versand-Weg, von unten (Ursprung) nach oben (Empfänger) gelesen.
DKIM-Signature (RFC 6376): Kryptografische Signatur über bestimmte Header-Felder und Body. Ungültig bei Modifikation.
ARC-Set (RFC 8617): ARC-Authentication-Results + ARC-Message-Signature + ARC-Seal — Kette der Authentifizierungs-Validierungen für Forwards/Listen.
Message-ID: Eindeutige Nachrichtenkennung — bei Fehlen oder Duplikaten verdächtig.

Anatomie

Die wichtigsten Header-Felder im Detail

Diese Tabelle zeigt die häufigsten Header-Felder mit RFC-Referenz, Funktion und forensischer Relevanz. Reihenfolge: Felder, die der Mail-Client zeigt, dann Trace- und Authentifizierungs-Felder.

Header-Feld	RFC	Funktion	Forensische Relevanz
`From`	5322	Autor der Nachricht — wird vom Mail-Client angezeigt	Hoch — Spoofing-Ziel
`Sender`	5322	Verantwortlich für die Übertragung (selten genutzt)	Mittel
`Reply-To`	5322	Adresse für Antworten — kann von From abweichen	Hoch — Phishing-Indikator
`To` / `Cc` / `Bcc`	5322	Primäre / Kopie / Blindkopie-Empfänger	Mittel
`Date`	5322	Ursprungs-Datum der Nachricht	Mittel — Timing-Forensik
`Subject`	5322	Betreff der Nachricht	Niedrig (rein Content)
`Message-ID`	5322	Eindeutige Nachrichtenkennung	Hoch — Duplikate verdächtig
`In-Reply-To` / `References`	5322	Thread-Verkettung	Mittel — Hijacking-Indikator
`Return-Path`	5321 + 5322	SMTP MAIL FROM — Bounce-Adresse	Hoch — Envelope-vs.-Header-Spoofing
`Received`	5322	Trace pro MTA — von unten nach oben	Sehr hoch — Pfad-Analyse
`Authentication-Results`	8601	SPF/DKIM/DMARC/ARC-Verdikte	Sehr hoch — direkte Auth-Aussage
`DKIM-Signature`	6376	Kryptografische Signatur Header+Body	Hoch — Integritäts-Beleg
`ARC-Authentication-Results`	8617	Authentifizierungs-Bewertung pro Hop	Hoch — Forward-Kette
`ARC-Message-Signature`	8617	DKIM-ähnliche Signatur pro Hop	Hoch — Custodian-Nachweis
`ARC-Seal`	8617	Schutz der ARC-Felder-Integrität	Hoch — Chain-Validierung
`List-Unsubscribe`	2369 + 8058	One-Click-Unsubscribe-URL	Mittel — Compliance-Indikator
`X-*`	experimentell	Spam-Score, IP-Reputation, Quarantäne-Grund	Variabel je Provider

Praxis

Beispiel-Header eines authentifizierten Versands

Dieses gekürzte Beispiel zeigt einen typischen Email-Header einer authentifizierten Mail von einer Gmail-Adresse an einen Microsoft 365-Empfänger. Alle drei Authentifizierungs-Mechanismen (SPF, DKIM, DMARC) sind passed, das DMARC-Alignment ist konsistent.

Authentication-Results: protection.outlook.com; spf=pass
  smtp.mailfrom=alice@example.com; dkim=pass header.d=example.com;
  dmarc=pass action=none header.from=example.com;
  arc=none
Return-Path: <alice@example.com>
Received: from mail-eu.example.com (mail-eu.example.com [203.0.113.10])
  by mx.protection.outlook.com (Postfix) with ESMTPS id ABC123;
  Mon, 18 May 2026 11:23:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
  s=20240501; h=from:to:subject:date:message-id;
  bh=BodyHash...; b=Signature...
From: "Alice Müller" <alice@example.com>
To: "Bob Schmidt" <bob@empfaenger-firma.de>
Date: Mon, 18 May 2026 13:23:45 +0200
Subject: Projekt-Update KW 21
Message-ID: <a1b2c3d4@example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8

Interpretation des Beispiel-Headers

Authentication-Results: SPF pass (Envelope-From example.com gegen SPF-Record geprüft), DKIM pass (Signatur valide), DMARC pass action=none (Policy ist p=none, Mail wird trotz Pass nur beobachtet).
Return-Path = alice@example.com, From = alice@example.com: Identische Domains — DMARC-Alignment OK.
Received: Eine Zeile (direkter Versand) — von mail-eu.example.com (Sending-Server) zu mx.protection.outlook.com (Empfänger Microsoft 365 MX).
DKIM-Signature: Selektor 20240501 unter _domainkey.example.com, Algorithmus rsa-sha256, kanonisierung relaxed/relaxed (Whitespace-tolerant).
Message-ID: Eindeutige ID — bei Duplikaten oder Mustern (z.B. „<timestamp@spammer>“) verdächtig.

Header-Forensik

Header-Forensik bei Phishing-Verdacht in 5 Schritten

Wenn Sie eine verdächtige Mail prüfen, gehen Sie diesen 5-Schritt-Workflow durch. Jeder Schritt baut auf dem vorherigen auf — und schließt Phishing-Indikatoren in Reihenfolge ihrer Diagnose-Stärke aus.

Authentication-Results lesen

Bei spf=fail oder dkim=fail oder dmarc=fail ist die Mail authentifizierungs-mäßig kompromittiert — entweder ein Konfigurations-Problem oder ein Spoofing-Versuch. Bei dmarc=fail action=reject wäre die Mail eigentlich abgelehnt worden — sie ist also wahrscheinlich von einer falsch konfigurierten Quelle.

Return-Path vs. From vergleichen

Identische Domains: gut. Abweichende Domains: bei legitimen Mailing-Listen (Listen-Domain im Return-Path) OK, sonst Spoofing-Indikator. Bei „on behalf of“-Konstruktionen (Sender-Header gesetzt) gleicht die Sender-Domain mit From — DMARC alignt typisch mit From.

Received-Chain analysieren

Von unten nach oben lesen — der unterste Received ist der Ursprung. Prüfen: Stimmt die Geolocation der Sending-IP zur erwarteten Absender-Region? Ist der Hostname plausibel (passend zum Provider)? Bei vielen Hops mit langen Latenzen: Routing-Anomalie. Bei nur einem Received: direkter Versand ohne Relay.

Reply-To vs. From prüfen

Wenn Reply-To eine andere Domain hat als From, ist das ein Hinweis auf Antwort-Hijacking — Angreifer setzen Reply-To auf eigene Adresse, damit Antworten dort ankommen. Legitim nur bei Newsletter-Plattformen oder „No-Reply“-Setups.

DKIM-Signature inhaltlich prüfen

Bei dkim=pass die Signing-Domain (d=) im DKIM-Signature-Header mit der From-Domain vergleichen. Identisch: DKIM-Alignment OK. Abweichend ohne Mailing-Liste: verdächtig. Selektor (s=) sollte zu einer existierenden DNS-Subdomain gehören.

Tools

Tools für die Header-Analyse

Microsoft Message Header Analyzer (MHA)

Kostenlos und ohne Login unter mha.azurewebsites.net. Visualisiert Authentication-Results, Received-Hops mit Latenz-Tabelle und Anti-Spam-Klassifikation. Besonders nützlich für Microsoft 365-Empfänger, da Defender-spezifische Header (X-Microsoft-Antispam, X-Forefront-Antispam-Report) erklärt werden.

Google Toolbox Messageheader

Kostenlos und ohne Login unter toolbox.googleapps.com/apps/messageheader. Zeigt eine ähnliche Aufschlüsselung wie MHA, mit Fokus auf Gmail-spezifische Header (Original-Authentication-Results, X-Gm-Message-State).

MXToolbox Email Header Analyzer + andere

MXToolbox (mxtoolbox.com/EmailHeaders.aspx) bietet zusätzlich Blacklist-Lookups pro Received-IP — direkt sichtbar, ob die Versand-IP auf Spamhaus/Barracuda/SpamCop gelistet ist. Ergänzend: PhishER (KnowBe4), Trustpath, Vanilla Forums Header-Analyse-Plugins.

Information-Gain

Header-Forensik-Toolchain — 3-Tool-Sequenz für DACH-Use-Cases

Header-Forensik bei Phishing-Verdacht oder BEC-Vorfall verlangt eine strukturierte Tool-Sequenz, weil keiner der verfügbaren Header-Analyzer alle Aspekte abdeckt. Die folgende 3-Tool-Sequenz hat sich in der DACH-Praxis bewährt — von Verdachts-Triage zu Beweissicherung mit konkreten Tool-Befehlen und Auswertungs-Schritten.

Schritt 1 — Schnell-Triage mit Microsoft MHA (60 s)

Header in Outlook über „Datei → Eigenschaften → Internetkopfzeilen“ kopieren oder via „Vollständigen Header anzeigen“ in Outlook Web App. Direkt in mha.azurewebsites.net einfügen — keine Anmeldung, keine Datenübertragung an Drittserver (Client-seitige JavaScript-Analyse). MHA visualisiert Authentication-Results, alle Received-Hops mit Latenz-Tabelle und Microsoft-spezifische Anti-Spam-Header (X-Microsoft-Antispam, X-Forefront-Antispam-Report mit SCL-Wert). Bei SCL ≥ 5 hat M365 die Mail bereits als verdächtig eingestuft.

Schritt 2 — Cross-Verifikation mit Google Toolbox (30 s)

Denselben Header in toolbox.googleapps.com/apps/messageheader einfügen. Vorteil: parallel-orthogonale Sicht auf dieselben Header, kann MHA-Fehlinterpretationen aufdecken. Zeigt Gmail-spezifische Header (Original-Authentication-Results, X-Gm-Message-State). Auswertung: Wenn beide Tools dieselben Probleme zeigen (z.B. SPF-Fail in beiden), ist der Befund robust.

Schritt 3 — IP-Reputation-Lookup pro Received-Hop (2-3 min)

Aus der Received-Chain die unterste IP (Ursprung) und die obersten IPs (Receiver) extrahieren. Pro IP check.spamhaus.org und talosintelligence.com/reputation_center abfragen. Bei Listung auf Spamhaus SBL/CSS oder Cisco Talos „Poor“ ist der Ursprung kompromittiert. MXToolbox Email Header Analyzer kombiniert beides automatisch — direkt verlinkter Blacklist-Check pro Received-IP. Zusätzlich für DACH-Compliance-Use-Cases: PhishER (KnowBe4) zur Speicherung und Eskalation an Operations-Team.

Beweissicherung für NIS2-Meldungen und DSGVO-Berichte

Original-Header unverändert sichern: Als .eml-Datei oder Text-Datei im Schreibgeschützten Speicher. Modifikationen (Whitespace-Normalisierung, Zeichenkodierung) brechen die DKIM-Signatur — Beweiskraft geht verloren.
Hash-Wert dokumentieren: SHA-256-Hash des Original-Headers + Timestamp + Hash-Wert separat in Tickets oder Wiki. Bei späterer Streitlage ist die Integrität des Beweismaterials nachweisbar.
NIS2-Art.-23-Meldung: 24-Stunden-Frühwarnung an BSI bei „erheblichem Sicherheitsvorfall“. Header-Forensik-Bericht als Anhang. Volle Vorfallsmeldung binnen 72 Stunden mit Schadenseinschätzung. Abschlussbericht binnen 1 Monat.
DSGVO-Art.-33-Meldung: bei Datenabfluss durch BEC oder Account-Takeover 72-Stunden-Frist an Aufsichts-Behörde. Header-Forensik dokumentiert den Angriffsweg und ist kritisch für die Risiko-Bewertung.

Wolf-Agents-USP

Authentifizierung auf Sender-Seite mit Wolf-Agents

Header-Forensik ist die Empfänger-Seite — Wolf-Agents Email Security Check ist die Sender-Seite. Beide Perspektiven ergänzen sich: Wer seine eigene SPF/DKIM/DMARC-Konfiguration sauber hält, sorgt dafür, dass Empfänger einen sauberen Authentication-Results-Header bekommen. Wer Phishing-Mails forensisch analysiert, hilft anderen Sendern bei der Lückenidentifikation.

165-Punkte Email Security Scanner — bewertet Ihre eigene Sender-Konfiguration so, wie Empfänger-Server sie sehen. SPF 22 Pkt, DKIM 22 Pkt (inkl. Selektor-Erreichbarkeit und Schlüssellängen-Prüfung), DMARC 35 Pkt (mit Alignment und Subdomain-Override), MTA-STS 15 Pkt.
DKIM-Selektor-Monitoring — Wolf-Agents prüft Erreichbarkeit aller DKIM-Selektoren alle 6 Stunden. Bei Rotation oder Drift sofortige Alarmierung.
DMARC-Subdomain-Override-Detection — viele Domains setzen sp= (Subdomain-Policy) nicht — Lücke für SubdoMailing-Angriffe. Wolf-Agents prüft und alarmiert.
Customer-Alert-Hub — Webhook-Integration mit Header-Anomalien aus M365 Defender (Authentication-Results-Trends) oder Postfix/Rspamd (Sender-Side-Anomalien).

Compliance

Compliance-Konsequenz: NIS2 Art. 23 + DSGVO Art. 33/34

NIS2 Art. 23 (Meldepflichten)

Bei erheblichen Sicherheitsvorfällen müssen Email-Header als Beweismittel erhalten und an die zuständige Behörde (in DE: BSI) übermittelt werden. Header-Forensik ist Teil der 24-Stunden-Frühwarnung und der 72-Stunden-Vorfallsmeldung.

DSGVO Art. 33/34 (Meldepflichten bei Datenschutzverletzung)

Bei BEC-Vorfällen mit Datenabfluss greifen die DSGVO-Meldepflichten (72h an Aufsichtsbehörde, „unverzüglich“ an Betroffene). Email-Header dokumentieren den Angriffsweg und sind kritisch für die Risikoabschätzung.

BSI TR-03182 + RFC 8601 + 8617

BSI TR-03182 definiert SPF/DKIM/DMARC als mandatory. Authentication-Results (RFC 8601) und ARC (RFC 8617) sind die Header-Mechanismen für Authentifizierungs-Nachweise — direkt prüfbar durch Aufsichts-Behörden.

Pillar-Cluster

Vertiefen Sie weiter

Hauptkapitel

Bedrohungen + Verifikation

Wie steht Ihre Domain bei Email-Header?

Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.

E-Mail Security Check starten

Häufig gestellte Fragen

Was ist ein Email-Header technisch?

Ein Email-Header ist der Metadaten-Teil einer E-Mail, definiert in RFC 5322 (Internet Message Format, Oktober 2008, Pete Resnick/Qualcomm). Er enthält strukturierte Felder wie From, To, Subject, Date, Message-ID, Return-Path, Received und Authentication-Results. Header und Body sind durch eine Leerzeile getrennt. Im SMTP-Dialog (RFC 5321) wird der Header im DATA-Befehl mit übertragen. Jeder MTA auf dem Weg ergänzt einen Received-Header, sodass die Header-Sektion mit jedem Hop wächst. Mail-Clients zeigen standardmäßig nur From/To/Subject — den vollen Header sieht man über „Original anzeigen“ oder „Show Original“.

Wie lese ich Email-Header für Phishing-Verdacht?

Drei zentrale Felder prüfen: (1) Authentication-Results (RFC 8601) — zeigt SPF-, DKIM-, DMARC- und optional ARC-Ergebnisse. Bei „spf=fail“, „dkim=fail“ oder „dmarc=fail“ liegt ein Authentifizierungs-Problem vor. (2) Return-Path vs. From — sollte zur selben Domain gehören, abweichende Domains sind Spoofing-Indikator. (3) Received-Header von unten nach oben lesen — zeigt den Pfad der Mail durch alle MTAs. Verdächtig: unbekannte Versand-IPs, fehlende oder gefälschte Hostnamen, ungewöhnliche Geolocation. Tools wie Microsoft Message Header Analyzer (mha.azurewebsites.net) und Google Toolbox Messageheader (toolbox.googleapps.com/apps/messageheader) visualisieren den Header strukturiert.

Wie sieht ein Authentication-Results-Header aus?

Beispiel: <code>Authentication-Results: mx.example.com; spf=pass smtp.mailfrom=sender.com; dkim=pass header.d=sender.com; dmarc=pass action=none header.from=sender.com</code>. RFC 8601 (Mai 2019) standardisiert das Format. Mögliche SPF-Werte: pass, fail, softfail, neutral, none, permerror, temperror. Mögliche DKIM-Werte: pass, fail, none, neutral, policy, temperror, permerror. DMARC: pass, fail, none, bestguesspass, temperror. ARC-Versions (RFC 8617) erweitern das Format mit ARC-Authentication-Results-Header pro Hop.

Was bedeutet der Return-Path?

Return-Path ist der SMTP Envelope-From — die Adresse, an die Bounces zurückgeschickt werden. Sie wird im MAIL FROM-Befehl des SMTP-Dialogs gesetzt (RFC 5321) und kann unabhängig vom From-Header im Body sein. SPF prüft den Envelope-From gegen autorisierte IPs. DMARC-Alignment vergleicht Envelope-From-Domain (für SPF-Alignment) und DKIM-Signing-Domain (für DKIM-Alignment) mit der Header-From-Domain. Abweichende Domains zwischen Return-Path und From ohne dazwischenliegende Mailing-Liste sind Spoofing-Indikator.

Wie funktionieren Received-Header?

Received-Header sind eine Trace-Information, die jeder MTA auf dem Weg ergänzt — neue Received-Header werden oben eingefügt, daher liest man Received von unten (Ursprung) nach oben (Empfänger). Jeder Received enthält Format: <code>Received: from sending-server (sending-ip) by receiving-server with protocol; date</code>. Bei Phishing-Verdacht: Wenn der unterste Received eine fremde Versand-IP zeigt (z.B. von einem geografisch unpassenden Provider), die nicht im SPF-Record steht, ist die Mail verdächtig. Headerflags wie „NOT“ oder „may be forged“ deuten auf Inkonsistenzen hin.

Welche Tools helfen bei der Header-Analyse?

Microsoft Message Header Analyzer (mha.azurewebsites.net, kostenlos, ohne Login) visualisiert Authentication-Results, Received-Hops mit Latenz, anti-spam-classification. Google Toolbox Messageheader (toolbox.googleapps.com/apps/messageheader, kostenlos) zeigt eine ähnliche Aufschlüsselung. MXToolbox Email Header Analyzer bietet zusätzlich Blacklist-Lookups pro Received-IP. Für DACH-Compliance-Use-Cases: PhishER (KnowBe4), Trustpath (Tutamen), Cyber Security Pulse. Wolf-Agents Email Security Check prüft die Sender-Seite (eigene SPF/DKIM/DMARC-Konfiguration) — die Header-Analyse ist die Empfänger-Seite.

Was ist ARC und wie sieht es im Header aus?

ARC (Authenticated Received Chain, RFC 8617, Juli 2019, experimentell) löst das Problem gebrochener DKIM-Signaturen bei Mailing-Listen und Weiterleitungen. ARC fügt drei Header-Felder pro Hop hinzu: ARC-Authentication-Results (AAR, dokumentiert die Authentifizierungs-Bewertung), ARC-Message-Signature (AMS, DKIM-ähnliche Signatur der Nachricht), ARC-Seal (AS, schützt die Integrität der AAR/AMS-Felder). Jeder ARC-Set wird mit einer Sequence-Number nummeriert. Empfänger-Server können ARC-Sets validieren und die ursprüngliche Authentifizierung wiederherstellen, selbst wenn DKIM durch Listen-Modifikationen gebrochen ist. Siehe Kapitel 10 ARC.