# Mail Header Analyzer — Tipps & Tricks

> Tipps zum Mail Header Analyzer: Header richtig kopieren, Zeitzonen und Clock-Skew, Authentifizierung deuten, Datenschutz und Kombination mit anderen Tools.

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

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/)

Header lesen ist schnell gelernt — sie richtig zu deuten, ist die eigentliche Kunst. Diese Seite sammelt, worauf es in der Praxis ankommt. Die technischen Grundlagen dazu stehen im [Manual](https://www.jpkc.com/db/tools/mail-header/manual/).

## Kopiere wirklich nur die Header

Die häufigste Stolperfalle ist die Quelle der Daten. Kopiere immer den **Roh-Header-Block** — bei Gmail über „Show original", bei Outlook über `File → Properties → Internet Headers`, bei Thunderbird über <kbd>Strg</kbd>+<kbd>U</kbd>. Was die normale Weiterleitung einer Mail produziert, sind **nicht** die Original-Header, sondern eine neue Nachricht — damit verlierst du genau die Informationen (Zustellweg, Authentifizierung), die du analysieren willst. Lädst du eine ganze `.eml`-Datei hoch, ist das egal: Das Tool trennt den Body selbst an der ersten Leerzeile ab.

## Die Route liest sich von oben nach unten — aber die Header stehen umgekehrt

In der rohen Mail steht der **neueste** `Received`-Header ganz oben (der letzte Server schreibt zuerst). Der Mail Header Analyzer dreht das um, sodass die Zeitachse von Hop 1 (Absender, grün) zum letzten Hop (Empfänger, blau) läuft. Wenn dir die Reihenfolge im Rohtext und im Route-Tab gegensätzlich vorkommt — das ist genau richtig so.

## Wo die Mail wartete: die Lücke gehört zum vorherigen Server

Der Zeitstempel eines `Received`-Headers markiert, wann dieser Server die Nachricht **annahm**. Die Differenz zwischen zwei Hops ist deshalb die Zeit, die die Mail beim **vorherigen** Server in der Warteschlange lag (Queue, Greylisting), bevor der nächste sie annahm. Genau so beschriftet das Tool die Lücke („Held at … before … accepted it"). Eine rote Lücke (ab 5 Minuten) ist dein erster Verdächtiger bei einer verspäteten Zustellung — meist Greylisting beim empfangenden System.

## Negative Wartezeit heißt nicht „schnell", sondern Clock-Skew

Wenn das Tool zwischen zwei Hops einen **Clock-Skew** statt einer Wartezeit meldet, gehen die Uhren der beteiligten Server auseinander: Der spätere Server hat einen früheren Zeitstempel protokolliert als der vorherige. Die echte Wartezeit lässt sich dann nicht berechnen. Wundere dich also nicht über „unmögliche" Reihenfolgen — das ist eine Aussage über die Server-Uhren, nicht über die Geschwindigkeit der Zustellung.

## Zeiten siehst du lokal, der Offset verrät die Herkunft

Alle Zeitstempel im Route-Tab sind in **deine lokale Zeitzone** umgerechnet — bequem für den direkten Vergleich. Daneben steht der **ursprüngliche Offset**, den der Server protokolliert hat (z. B. `UTC+01:00` oder `UTC-08:00 (PST)`). Dieser Offset ist oft aufschlussreicher als die Zeit selbst: Er deutet an, in welcher Region ein Relay steht. Verlasse dich für forensische Schlüsse aber nicht allein darauf — Offsets lassen sich fälschen.

## „NOT FOUND" ist kein Versagen

Steht im Security-Tab bei SPF, DKIM oder DMARC „NOT FOUND", heißt das nicht, dass die Mail durchgefallen ist — sondern dass in den Headern **kein Ergebnis** steht. Das Tool prüft nichts selbst nach: Es zeigt nur, was der empfangende Server bereits in `Authentication-Results` (bzw. `Received-SPF`) notiert hat. Interne Mails, sehr alte Nachrichten oder Mails von Servern ohne Authentifizierungs-Prüfung haben diese Header schlicht nicht. Für eine echte Prüfung der DNS-Seite brauchst du ein DNS-Tool (siehe unten).

## DKIM „neutral" ist ein Sonderfall

Findet das Tool keinen DKIM-*Ergebnis*-Eintrag, aber einen `DKIM-Signature`-Header, meldet es Status *neutral* mit dem Hinweis „DKIM-Signature header present (no verification result found)". Lies das wörtlich: Die Mail **wurde** signiert, aber ob die Signatur gültig ist, hat (sichtbar) niemand verifiziert. Das ist etwas anderes als ein hartes `pass` oder `fail`.

## Spam-Score: höher ist schlechter

Bei SpamAssassin-artigen Filtern bedeutet ein **höherer** Score mehr Spam-Verdacht. Die Farbgebung der Spam-Analyse folgt dem: bis 0 grün, unter 5 gelb, ab 5 rot. Ein negativer Wert wie `-2.1` ist also gut. Der konkrete Schwellenwert (`required=…`) steht oft im `X-Spam-Status` daneben und kann je nach Server abweichen.

## Datenschutz: alles bleibt lokal — fast

Der ganze Reiz des Tools ist, dass deine Header **den Browser nicht verlassen** — kein Server sieht IP-Adressen, Empfänger oder Betreff. Eine Einschränkung gibt es: Analysierte Header landen in einem **lokalen Verlauf** des Tools und lassen sich nach einem Reload wiederherstellen. Das bleibt auf deinem Gerät, ist aber auf einem geteilten oder fremden Rechner ein Gedanke wert — analysiere fremde Phishing-Header dort lieber auf deinem eigenen System.

## Kombination mit anderen JPKCom-Tools

- **[DNS, SSL, Redirect & URL](https://www.jpkc.com/db/tools/dns-ssl-redirect-url/)** — der natürliche nächste Schritt, wenn der Security-Tab ein SPF- oder DMARC-Problem zeigt: die zugehörigen DNS-Einträge (TXT-Records) der Absender-Domain prüfen.
- **[IP-Tools](https://www.jpkc.com/db/tools/ip/)** — eine verdächtige Sende- oder Relay-IP aus den `Received`-Zeilen nachschlagen und geografisch einordnen.
- **[Hash-Generator](https://www.jpkc.com/db/tools/hash/)** — eine über **Download** gesicherte Header-Datei mit einer Prüfsumme versehen, etwa für ein Beweis-Archiv.

---

Die vollständige Funktionsbeschreibung steht im [Manual](https://www.jpkc.com/db/tools/mail-header/manual/), konkrete Durchläufe in den [Beispielen](https://www.jpkc.com/db/tools/mail-header/examples/). Ausprobieren kannst du alles im [Tool](https://www.jpkc.com/tools/mail-header/).