E-Mail-Header-Analyse

Was es tut

Der Email Header Analyzer parst die rohen Header einer E-Mail-Nachricht (RFC 5322) und macht daraus einen lesbaren Forensik-Bericht: ein Verdict-Banner, das alle Befunde zu einem einzigen Aufruf auf einen Blick zusammenfasst (Spoofing-Indikatoren gefunden / verdächtige Zeichen / sauber), eine Zustell-Timeline Hop für Hop über jeden Received-Server, den die Nachricht passiert hat, inklusive der Verzögerung zwischen den Hops, die SPF- / DKIM- / DMARC-Authentifizierungsurteile und die vollständige Liste der Anomalien - Spoofing-Signale wie eine From-Adresse, die nicht zu Return-Path passt, ein Reply-To, das irgendwo Unerwartetes hinzeigt, verdächtige Mailer-Strings oder Zeitstempel, die rückwärts laufen.

Das Layout ist zweigeteilt: Rohe-Header-Eingabe links, der Live-Analysebericht rechts in einem Sticky-Panel, das im Blick bleibt, während du durch die Befunde scrollst. Das ist das Tool, nach dem du greifst, wenn eine Nachricht nach Phishing aussieht und du Belege statt eines Bauchgefühls willst.

So verwendest du es

1. Besorge die rohen Header: In Gmail öffne die Nachricht → ⋮ → Original anzeigen, und kopiere alles oberhalb des Nachrichtentexts. Outlook: Datei → Eigenschaften → Internetkopfzeilen.
2. Füge sie in Rohe E-Mail-Header ein (oder drücke Beispiel, um eine eingebaute Demonstrationsnachricht zu laden).
3. Drücke Header analysieren. Der Bericht erscheint rechts unter dem Verdict-Banner.
4. Lies zuerst das Verdict-Banner: Rot (Gefahr) = mindestens ein kritischer Spoofing-Indikator, Amber = nur Warnungen, Grün = keine Anomalien. Die Severity-Zähler sitzen rechts im Banner (critical × 1, warnings × 2, notices × 1).
5. Arbeite die Abschnitte durch: Zustellpfad (ältester Hop zuerst, Delay-Badges farbcodiert), Authentifizierung (SPF/DKIM/DMARC-Zeilen), Anomalien (jeder Befund mit seinem Beweis) und Alle Header (die vollständige entfaltete Header-Tabelle).
6. Drücke Teilen-Link kopieren für eine URL, die deine exakte Eingabe trägt - wer sie öffnet, sieht dieselbe Analyse.

Die Authentifizierungszeilen lesen. Jede Zeile zeigt den Mechanismusnamen, sein Ergebniswort und die Beweisklausel, aus der es stammt:

• SPF - Hat die IP des sendenden Servers eine Autorisierung von der Domain im Envelope (smtp.mailfrom)? pass = autorisiert; softfail = nicht autorisiert, aber die Domain bittet Empfänger nur, es als verdächtig zu behandeln; fail = ausdrücklich nicht autorisiert, Spoofing wahrscheinlich; neutral = die Domain macht keine Aussage; none = keine Richtlinie publiziert; temperror = transienter DNS-Fehler; permerror = defekter oder fehlerhaft geformter Record. Der Zusatztext der Zeile zeigt die Envelope-Adresse, die geprüft wurde.
• DKIM - Ist die Nachricht kryptografisch signiert, und verifiziert sich die Signatur? pass = Signatur gültig (die Zeile zeigt den signierenden selector und, wenn publiziert, die signierende Domain aus header.d); fail = Signatur vorhanden, aber defekt - Header oder Body wurden unterwegs verändert; none = unsigniert; temperror/permerror = der öffentliche Schlüssel ließ sich nicht abrufen. Die Detailzeile zeigt die rohe Klausel, z. B. dkim=pass header.s=sel2026 header.b=AbCdEf.
• DMARC - Hat die Richtlinie der sichtbaren From:-Domain diese Nachricht akzeptiert? pass = Alignment erfüllt und die zugrundeliegenden Checks bestanden (die Zeile zeigt die ausgewertete header.from-Domain und die p=-Richtlinie der Domain: none, quarantine oder reject); fail = die Nachricht beansprucht eine Identität, deren eigene Richtlinie sie nicht akzeptiert; none = die From-Domain publiziert keinen DMARC-Record.

Ein entscheidender Vorbehalt, den das Beispiel demonstriert: Alle drei können durchgehen, und die Nachricht kann trotzdem ein Phishing-Köder sein. SPF/DKIM/DMARC verifizieren, dass die sendende Domain diese Nachricht wirklich gesendet hat - nicht, dass der Absender vertrauenswürdig ist, und nicht, dass Reply-To dorthin geht, wohin du denkst. Deshalb zählt die Anomalien-Liste selbst bei einem komplett “grünen” Authentifizierungs-Panel.

Die Received-Kette lesen. Mailserver stellen jeden Received-Header voran, deshalb parst das Tool sie von unten nach oben: Hop 1 ist der Ursprungsserver, der letzte Hop ist dein Postfach. Zwischen aufeinanderfolgenden Hops zeigt es ein Delay-Badge - die vergangene Zeit, berechnet aus den Zeitstempeln der beiden Hops:

• Grün, unter 1 Sekunde (in Millisekunden dargestellt): normales Relay.
• Amber, 1-60 s: etwas Queuing oder Greylisting - meist unproblematisch.
• Orange, über 60 s: langsames Relay, Drosselung durch den Mail-Provider oder eine Nachricht, die in einer Queue lag.
• Grau “unbekannte Verzögerung”: der Hop hat keinen parsbaren Zeitstempel, dieses Bein lässt sich also nicht messen (wird zusätzlich als Info-Anomalie gemeldet).

Zeitstempel, die rückwärts laufen (Hop N datiert vor Hop N−1), bekommen eine eigene Warnung: Entweder widersprechen sich die Uhren zweier Server, oder jemand hat einen Received-Header gefälscht.

Beispiele

Lade das eingebaute Beispiel und drücke Header analysieren, um alle Features auf einmal zu sehen. Verifizierte Ausgabe für das Beispiel:

• Zustellpfad - 3 Hops, ältester zuerst: sender.evil.example → mail.relay.example (ESMTP), dann mail-sor-f41.google.com → mx.google.com (ESMTPS, +7.0 s), dann mx.google.com (SMTP, +3.0 s).
• Authentifizierung - alles pass: SPF pass für billing@legit-shop.com, DKIM pass mit Selector sel2026, DMARC pass mit Richtlinie quarantine für legit-shop.com.
• Verdict-Banner - rot: critical × 1, warnings × 2, weil die Anomalien sind:

From: "Legit Shop Support" <support@legit-shop.com>
Reply-To: billing@evil.example
Return-Path: bounce@evil.example
X-Mailer: SuperBulk Mass Mailer 4.2

→ Kritisch: Return-Path (bounce@evil.example) passt nicht zu From (support@legit-shop.com) - der Envelope-Absender weicht vom angezeigten Absender ab. Dazu Warnungen für das umgeleitete Reply-To und den Bulk-Mailer X-Mailer. Die Authentifizierung ging durch, weil legit-shop.com die Nachricht wirklich gesendet hat - die Nachricht ist trotzdem darauf gebaut, als etwas anderes auszusehen, als sie ist.

Eine saubere Nachricht (Envelope passt zu From, signiert, authentifiziert):

Received: from mail.example.com by mx.google.com with ESMTPS; Tue, 12 Aug 2026 10:15:42 -0700
Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=billing@legit-shop.com; dkim=pass header.s=sel2026; dmarc=pass (p=quarantine) header.from=legit-shop.com
From: Billing <billing@legit-shop.com>
Return-Path: <billing@legit-shop.com>

→ Grünes Verdict, “Keine Spoofing-Indikatoren gefunden”, null Anomalien.

Ein rotes Panel - alle drei Mechanismen rendern rot:

Authentication-Results: mx.example.com; spf=softfail smtp.mailfrom=spoof@wrong.example; dkim=fail header.s=sel1; dmarc=fail (p=reject) header.from=bank.example

→ SPF softfail für spoof@wrong.example, DKIM fail (Selector sel1), DMARC fail mit Richtlinie reject - eine Nachricht, die ein strenger Empfänger hätte abweisen sollen.

Ein gefälschter Hop - Zeitstempel, die rückwärts laufen:

Received: by mx.example.com; Tue, 12 Aug 2026 10:15:40 -0700
Received: from a.example by b.example; Tue, 12 Aug 2026 10:15:50 -0700

→ Warnung: Hop 2 trägt einen Zeitstempel 10.0 s VOR Hop 1 - Uhrabweichung zwischen Servern oder ein gefälschter Received-Header.

Gut zu wissen

Jedes Signal, das der Analyzer prüft (Severity in Klammern):

1. Return-Path vs. From-Mismatch (critical) - der Envelope-Absender (Return-Path, wohin Bounces gehen), nutzt eine andere Adresse als das angezeigte From. Klassisches Spoofing; auch bei legitimer Mailinglisten-Weiterleitung häufig.
2. Reply-To weicht von From ab (warning) - Antworten würden an eine dritte Adresse umgeleitet. Legitim bei Support-Desks, belastend, wenn das From deine Bank ist.
3. Verdächtiger Mailer-String (warning) - X-Mailer oder User-Agent enthält ein Token, das mit Bulk-Versand-Werkzeugen assoziiert ist: bulk, mass mail, massmail, storm, flood, bomber, grabber, harvest, spambot, stealth, anonymous, dark, crack (case-insensitiv als Substrings gematcht).
4. Hop ohne parsbaren Zeitstempel (info) - die Verzögerung dieses Beins lässt sich nicht berechnen; als “unbekannte Verzögerung”-Badge dargestellt.
5. Zeit läuft rückwärts (warning) - ein Hop, der vor dem vorherigen Hop datiert ist: Uhrabweichung oder ein gefälschter Received-Header.
6. Kein Authentication-Results-Header (info) - der SPF/DKIM/DMARC-Status lässt sich aus dieser Nachricht gar nicht verifizieren.

Parser-Details, die man kennen sollte:

• Privat: Alles Parsen läuft zu 100 % clientseitig - deine Header verlassen den Browser nie.
• Header werden gemäß RFC 5322 entfaltet (Fortsetzungszeilen beginnen mit Whitespace); das Parsen stoppt an der ersten Leerzeile (dem Body-Separator); Zeilen ohne Header-Form werden übersprungen.
• Trägt eine Nachricht mehrere Authentication-Results-Header, gewinnt das erste Verdict je Mechanismus; der Rest wird ignoriert.
• Hop-Zeitstempel werden nach dem letzten ; jeder Received-Zeile gelesen (mit Fallback auf das erste datumähnliche Token), und nachgestellte Zonen-Kommentare wie (PDT) werden ignoriert.
• Ein fehlendes Teil wird gemeldet, nie geraten: unbekannte Verzögerungen, unverifizierbare Authentifizierung und Kettenlücken tauchen alle als explizite Befunde auf statt als stille Leerstellen.
• Verwandte Tools: PII Redactor, Defang / Refang,

  Base64Base64An encoding representing binary data as 64 safe ASCII characters, so it survives transport through text-only channels. It encodes — it does not encrypt.

  .