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.
Zurück zur Übersicht: Mail Header Analyzer · Tool live öffnen: 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.
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 Strg+U. 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 — 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 — eine verdächtige Sende- oder Relay-IP aus den
Received-Zeilen nachschlagen und geografisch einordnen. - Hash-Generator — eine über Download gesicherte Header-Datei mit einer Prüfsumme versehen, etwa für ein Beweis-Archiv.
Die vollständige Funktionsbeschreibung steht im Manual, konkrete Durchläufe in den Beispielen. Ausprobieren kannst du alles im Tool.