# Mail Header Analyzer — Manual

> Vollständige Funktionsbeschreibung des Mail Header Analyzer: alle fünf Tabs, Received-Routen, SPF/DKIM/DMARC, Spam-Analyse, Upload und Datenschutz.

Source: https://www.jpkc.com/db/tools/mail-header/manual/

Zurück zur Übersicht: [Mail Header Analyzer](https://www.jpkc.com/db/tools/mail-header/) · Tool live öffnen: [www.jpkc.com/tools/mail-header/](https://www.jpkc.com/tools/mail-header/)

Dieses Manual beschreibt den **Mail Header Analyzer** vollständig: wie die Oberfläche aufgebaut ist, was jeder der fünf Tabs anzeigt, wie das Tool die Header intern zerlegt und welche Grenzen der reine Browser-Betrieb mit sich bringt. Die Oberfläche des Tools ist auf Englisch — die Labels werden hier deshalb in ihrer englischen Original-Schreibweise genannt (mit deutscher Erläuterung), damit du dich im echten Interface zurechtfindest.

## Aufbau der Oberfläche

Das Tool besteht aus einer Karte mit fünf Reitern (Tabs):

1. **Parse** — die Eingabe-Ansicht, in der du die Header einfügst und die Analyse startest.
2. **Overview** — Zusammenfassung der wichtigsten Felder.
3. **Route** — der Zustellweg als Zeitachse.
4. **Security** — SPF/DKIM/DMARC und Spam-Analyse.
5. **All Headers** — durchsuchbare Tabelle aller Header.

Beim Start ist **nur der Parse-Tab aktiv**; die vier Auswertungs-Tabs sind ausgegraut und werden erst freigeschaltet, sobald du erfolgreich analysiert hast. Nach einem Klick auf **Analyze** springt das Tool automatisch zum Overview-Tab. Ein erneutes **Clear** deaktiviert die vier Tabs wieder und bringt dich zurück zur Eingabe.

## Ablauf

Der typische Ablauf hat drei Schritte:

1. **Header beschaffen** — die rohen Kopfzeilen aus deinem Mail-Programm holen (siehe [Header beziehen](#header-beziehen)).
2. **Einfügen oder hochladen** — in das große Textfeld einfügen, eine Datei über **Upload** wählen oder sie per Drag-and-drop ablegen.
3. **Analyze** klicken (oder <kbd>Strg</kbd>+<kbd>Enter</kbd> im Textfeld). Die vier Auswertungs-Tabs füllen sich, und du landest in der Übersicht.

### Parse-Tab

Der Parse-Tab ist die Kommandozentrale. Oben steht ein großes, dunkles **Textfeld in Monospace-Schrift** (`Raw Email Headers`), in das du die Kopfzeilen einfügst. Darüber sitzt eine Knopfgruppe:

- **Upload** — öffnet einen Datei-Dialog und akzeptiert `.eml`- und `.txt`-Dateien. Die Datei wird lokal gelesen, der Header-Teil extrahiert (siehe [Datei-Upload](#datei-upload)) und sofort analysiert.
- **Example** — füllt das Feld mit einem realistischen Beispiel-Header (eine über Postfix und Google zugestellte Mail mit SPF-, DKIM-, DMARC- und Spam-Headern). Ideal zum Kennenlernen; danach noch einmal selbst **Analyze** drücken.
- **Clear** — leert das Feld, setzt alle Ansichten zurück und deaktiviert die Auswertungs-Tabs.

Darunter liegt der **Analyze**-Knopf, der die eigentliche Analyse auslöst. Ein Tastaturkürzel <kbd>Strg</kbd>+<kbd>Enter</kbd> im Textfeld tut dasselbe. Du kannst eine Datei außerdem direkt **auf das Textfeld ziehen** — beim Drüberziehen hebt es sich optisch hervor, beim Loslassen wird der Inhalt geladen und analysiert.

Ganz unten erklärt eine Hilfe-Karte (`How to get email headers`), wie du an die Header kommst — siehe [Header beziehen](#header-beziehen).

Fügst du nichts ein und klickst **Analyze**, weist dich ein Hinweis darauf hin („Please paste email headers first."). Lässt sich aus dem Text keine einzige Kopfzeile herauslesen, kommt „Could not parse any headers." mit dem Hinweis auf das `Key: Value`-Format.

### Overview-Tab

Die Übersicht zeigt zwei Blöcke. Zuoberst — falls vorhanden — eine **Authentication Summary**: kompakte Badges für SPF, DKIM und DMARC mit ihrem jeweiligen Status. Darunter die Karte **Key Fields**, eine Tabelle mit den zentralen Kopfzeilen, sofern sie in den Headern vorkommen:

`From`, `To`, `CC`, `Subject`, `Date`, `Reply-To`, `Return-Path`, `Message-ID`, `MIME-Version`, `Content-Type`, `X-Mailer` und `User-Agent`.

Jeder Wert hat ein kleines **Kopier-Symbol**, mit dem du ihn einzeln in die Zwischenablage legst. Felder, die in der Mail nicht vorkommen, werden weggelassen; fehlen alle, erscheint „No common header fields found.". Kommt ein Feld mehrfach vor, zeigt die Übersicht den **ersten** Treffer — die vollständige Liste inklusive Dubletten findest du im All-Headers-Tab.

### Route-Tab

Der Route-Tab rekonstruiert den **Zustellweg** aus den `Received`-Headern. Mailserver schreiben diese Zeilen beim Empfang von oben nach unten in umgekehrter Reihenfolge (neueste zuerst); das Tool dreht sie um, sodass die Zeitachse vom **Absender (Hop 1, grün)** zum **Empfänger (letzter Hop, blau)** läuft. Zwischenstationen sind grau nummeriert.

Pro Hop zeigt eine Karte:

- **from** und **by** — der absendende und der annehmende Server, aus der `Received`-Zeile extrahiert.
- **Protokoll** — das Übertragungsprotokoll hinter `with` (z. B. `ESMTP`, `ESMTPS`, `SMTP`; „Microsoft SMTP Server" wird als `Microsoft SMTP` ausgewiesen).
- **TLS-Status** — wurde der Hop verschlüsselt übertragen? Erkennt das Tool Hinweise auf Transportverschlüsselung (`ESMTPS`/`ESMTPSA`, `STARTTLS`, `SSL`, `version=TLS…`, `TLSv1.x`, `with HTTPS`), zeigt es ein grünes Schloss samt TLS-Version (z. B. `TLS 1.3`); andernfalls ein gelbes „No TLS".
- **Zeitstempel** — wann dieser Server die Nachricht annahm, **umgerechnet in deine lokale Zeitzone**. Daneben steht die **ursprüngliche Zeitzone**, die der Server protokolliert hat (z. B. `UTC+01:00` oder `UTC-08:00 (PST)`).

Zwischen zwei Hops zeigt das Tool die **Wartezeit** als Lücke an: „Held at *Server X* for *2m 14s* before *Server Y* accepted it". Der Zeitstempel markiert immer, wann ein Server die Nachricht **annahm** — die Differenz gehört also zur Wartezeit beim vorherigen Server (Queue, Greylisting), nicht zu einem einzelnen Hop. Die Lücken sind nach Dauer eingefärbt: bis 10 Sekunden „fast", bis 1 Minute „normal", bis 5 Minuten „langsam", darüber „sehr langsam". Ist eine Differenz **negativ**, gehen die Server-Uhren auseinander; das Tool meldet dann ehrlich einen **Clock-Skew** statt einer erfundenen Wartezeit.

Am Ende fasst eine Zeile die **Gesamt-Laufzeit** (Total transit time) und die Zahl der Hops zusammen — und benennt, falls eine Station heraussticht, die **längste Wartezeit** und wo sie auftrat. Fehlen `Received`-Header, erscheint stattdessen „No Received headers found.".

### Security-Tab

Der Security-Tab bündelt die Authentifizierung in drei Karten — **SPF**, **DKIM** und **DMARC** — mit je einem farbigen Status-Badge und dem rohen Ergebnis-String:

- **SPF** wird aus dem `Authentication-Results`-Header gelesen (`spf=…`); fehlt er dort, fällt das Tool auf den `Received-SPF`-Header zurück. Erkannte Status: `pass`, `fail`, `softfail`, `neutral`, `none`, `temperror`, `permerror`.
- **DKIM** ebenfalls aus `Authentication-Results` (`dkim=…`; Status `pass`, `fail`, `neutral`, `none`, `temperror`, `permerror`). Findet sich kein Ergebnis, aber ein `DKIM-Signature`-Header, weist das Tool das als „DKIM-Signature header present (no verification result found)" mit Status *neutral* aus — die Mail wurde signiert, ob die Signatur stimmt, hat aber niemand geprüft.
- **DMARC** aus `Authentication-Results` (`dmarc=…`; Status `pass`, `fail`, `none`, `bestguesspass`).

Fehlt eine Prüfung ganz, zeigt die Karte „NOT FOUND". Darunter folgt die Karte **Spam Analysis**, gespeist aus `X-Spam-Score`, `X-Spam-Status`, `X-Spam-Flag` und `X-Spam-Level`. Ein vorhandener **Score** wird eingefärbt: bis 0 grün, unter 5 gelb, ab 5 rot — denn bei SpamAssassin-artigen Filtern bedeutet ein höherer Wert mehr Spam-Verdacht. Ganz unten zeigt die Karte **Raw Authentication-Results** den oder die ungefilterten Original-Header, damit du nichts verpasst, was die Karten nicht ausgewertet haben.

### All-Headers-Tab

Hier siehst du **jede** geparste Kopfzeile in der Reihenfolge, in der sie in der Mail stand — durchnummeriert, mit Header-Name und Wert. Jeder Wert hat ein Kopier-Symbol. Über der Tabelle:

- ein **Suchfeld** (`Search headers…`), das die Tabelle live filtert (Treffer in Name *oder* Wert; Groß-/Kleinschreibung egal);
- **Copy All** — legt den kompletten Roh-Header-Text in die Zwischenablage;
- **Download** — speichert die Header als Textdatei `email-headers.txt`.

Eine Zeile unter der Tabelle nennt die Gesamtzahl gefundener Header. Anders als die Übersicht zeigt dieser Tab auch **Dubletten** (mehrfach vorkommende Header wie mehrere `Received`-Zeilen) vollständig an.

## Header beziehen

Die Hilfe-Karte im Parse-Tab fasst zusammen, wie du an die rohen Header kommst:

- **Gmail** — Mail öffnen → **More** (Drei-Punkte-Menü) → **Show original** → Header kopieren.
- **Outlook** — Mail öffnen → **File** → **Properties** → aus **Internet Headers** kopieren.
- **Thunderbird** — Mail öffnen → <kbd>Strg</kbd>+<kbd>U</kbd> → Header (oberhalb der Leerzeile) kopieren.

Wichtig ist immer nur der **Header-Teil** — alles bis zur ersten Leerzeile. Den Body brauchst du nicht; lädst du eine ganze `.eml`-Datei hoch, schneidet das Tool den Body ohnehin selbst ab.

## Wie geparst wird

### Header-Format und Unfolding

Das Tool zerlegt den Text zeilenweise in `Key: Value`-Paare. Zuvor führt es das **RFC-5322-Unfolding** durch: Zeilen, die mit einem Leerzeichen oder Tab beginnen, sind Fortsetzungen der vorherigen Kopfzeile und werden wieder an sie angehängt — so bleiben lange, umgebrochene Header (etwa `Received`- oder `DKIM-Signature`-Zeilen) als Einheit erhalten. Leerzeilen markieren das Ende der Header und werden übersprungen. Reihenfolge und **Dubletten bleiben erhalten** — wichtig, weil `Received` mehrfach vorkommt.

### Datei-Upload

**Upload** und Drag-and-drop akzeptieren `.eml`- und `.txt`-Dateien. Das Tool liest die Datei lokal als Text und trennt den Header-Teil am **ersten Leerzeilen-Umbruch** ab (erst `\r\n\r\n`, ersatzweise `\n\n`). Findet sich keine Leerzeile, wird der gesamte Inhalt als Header behandelt. Der Body wird verworfen; eine Meldung nennt die Zahl der geladenen Header-Zeilen und ob ein Body entfernt wurde. Anschließend startet die Analyse automatisch.

## Betriebsgrenzen und Datenschutz

- **Vollständig clientseitig:** Parsen, Routen-Berechnung, Authentifizierungs- und Spam-Auswertung sowie das Datei-Lesen laufen ausschließlich im Browser. Es gibt **kein Backend, kein API, keinen Upload-Endpunkt** — deine Header verlassen den Rechner nicht.
- **Lokaler Verlauf:** Analysierte Header werden in einem browser-lokalen Verlauf des Tools abgelegt und lassen sich nach einem Reload wiederherstellen. Das bleibt auf deinem Gerät, ist aber auf einem geteilten Rechner einen Gedanken wert.
- **Heuristisches Parsen:** Die Auswertung von `Received`-Zeilen, TLS-Hinweisen und Zeitstempeln ist auf gängige Formate (Postfix, Exchange/Microsoft, Google) ausgelegt. Exotische oder fehlerhaft formatierte Header können unvollständig erkannt werden — der All-Headers-Tab zeigt dann immer noch den Rohwert.
- **Keine DNS-Live-Prüfung:** Das Tool liest nur, was in den Headern steht. Es fragt **keine** DNS-Einträge ab und verifiziert keine DKIM-Signatur kryptografisch — es zeigt die Ergebnisse, die der empfangende Mailserver bereits in `Authentication-Results` notiert hat.

Für den Einstieg und die Zielgruppen siehe die [Übersichtsseite](https://www.jpkc.com/db/tools/mail-header/). Konkrete Durchläufe stehen in den [Beispielen](https://www.jpkc.com/db/tools/mail-header/examples/), Strategie und Stolperfallen in den [Tipps & Tricks](https://www.jpkc.com/db/tools/mail-header/tips/). Ausprobieren kannst du alles direkt im [Tool](https://www.jpkc.com/tools/mail-header/).

