Mail Header Analyzer — Tipps & Tricks

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 die Original-Header, keine Weiterleitung

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. Ob du dabei nur den Header oder die ganze Nachricht erwischst, ist dagegen egal: Das Tool liest nur bis zur ersten Leerzeile und meldet einen mitkopierten Body als Hinweis.

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

In der rohen Mail steht der neueste Received-Header ganz oben (jeder Server setzt seine Zeile oben auf). Der Mail Header Analyzer dreht das um, sodass die Zeitachse mit Written (dem Date-Feld) beginnt und von Hop 1 (grün) zum letzten Hop (blau) läuft. Wenn dir die Reihenfolge im Rohtext und im Route-Tab gegensätzlich vorkommt — das ist genau richtig so.

Unten im Header beginnt der fälschbare Teil

Jeder Server kann nur für seine eigene Received-Zeile bürgen. Die obersten Zeilen hat dein eigener Provider geschrieben, die unteren stammen von Servern auf dem Weg — und die allerersten kann der Absender frei erfinden. Lies die Received-Zeilen im Roh-Header deshalb von oben nach unten (im Route-Tab also vom letzten Hop rückwärts) bis zu dem Punkt, an dem die Mail in die Infrastruktur deines Providers kam: Der Server, der sie dort abgegeben hat, ist der belastbare Absender. Die Sending server-Angabe in der Overview hilft beim Einstieg — sie nennt den ältesten Hop mit einer nicht internen IP —, ist aber bei gefälschten unteren Zeilen nicht mehr als ein Startpunkt.

Nur das oberste Authentication-Results zählt

Mails können mehrere Authentication-Results-Felder tragen: eines von deinem Provider und weitere von Stationen unterwegs — oder vom Absender selbst hineingeschrieben. Der Security-Tab zeigt deshalb jedes Feld einzeln und markiert nur das oberste grün als „topmost — from your provider"; alle anderen tragen orange „added on the way — can be forged". Ein dkim=pass in einer orange markierten Karte beweist nichts. Die Badges in der Overview und die Befunde stützen sich ausschließlich auf das oberste Feld.

„pass" heißt nicht „vertrauenswürdig"

SPF, DKIM und DMARC belegen nur, dass die Mail wirklich von der Domain kommt, die sie nennt — nicht, dass diese Domain zu der Firma gehört, die sie zu sein vorgibt. Ein Betrüger mit eigener, sauber eingerichteter Domain besteht alle drei Prüfungen. Achte deshalb auf die Warnungen in den Findings: ein Anzeigename mit fremder Adresse („service@bank…" vor einer ganz anderen Absender-Adresse), ein Reply-To auf eine andere Domain oder eine DKIM-Signatur, die nicht zur Absender-Domain passt. Umgekehrt ist ein abweichender Return-Path meist harmlos — Newsletter-Dienste und Versandplattformen setzen ihn routinemäßig auf ihre eigene Domain.

Befunde sind Hinweise, kein Urteil

Die Karte Findings sammelt Auffälligkeiten nach festen Regeln — rot für Fehler, orange für Warnungen, violett für Hinweise. Manche lösen auch legitime Mails aus: Eine Message-ID kann bei schlicht konfigurierten Skripten fehlen, ein Clock-Skew geht auf falsch gestellte Server-Uhren zurück. Und der grüne Haken bei einer Mail ohne Befund sagt ausdrücklich nur, dass keine bekannten Warnzeichen auftauchen — er ist kein Echtheitsnachweis.

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 („waited … at …"). 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. Ab einer Abweichung von mehr als einer Minute taucht das zusätzlich als Hinweis in den Befunden auf. 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 und die Zeile Date (local) in der Overview 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). 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. Steht im Date-Feld -0000 oder eine unbekannte Zone, liest das Tool die Zeit als UTC und sagt es dir in den Befunden.

Fehlende Ergebnisse sind kein Versagen

Meldet der Security-Tab, dass es kein Authentication-Results-Feld gibt, oder fehlt darin eine DMARC-Prüfung, 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 die empfangenden Server bereits in Authentication-Results (bzw. Received-SPF) notiert haben. 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).

Eine DKIM-Signatur ist noch kein DKIM-Ergebnis

Die Tabelle DKIM signatures zeigt, wer die Mail signiert hat (d=), mit welchem Selektor und welche Felder die Signatur abdeckt. Ob die Signatur gültig ist, steht dort nicht — das prüft allein der empfangende Server, und sein Ergebnis findest du im obersten Authentication-Results. Aussagekräftig ist die Spalte Matches From: Ein orangefarbenes no heißt, dass zwar jemand signiert hat, aber nicht die Domain des Absenders — etwa ein Versanddienst. Für den DKIM-Teil von DMARC zählt nur eine Signatur, die zur Absender-Domain passt.

Spam-Score: höher ist schlechter

Bei SpamAssassin und Rspamd bedeutet ein höherer Score mehr Spam-Verdacht; ein negativer Wert wie -2.1 ist also gut. Entscheidend ist der Abstand zur Schwelle, die der jeweilige Server gesetzt hat — bei SpamAssassin required=… im X-Spam-Status, bei Rspamd die zweite Zahl in X-Spamd-Result. Bei Rspamd vergleicht das Tool Score und Schwelle selbst, bei SpamAssassin übernimmt es das Yes/No des Servers am Anfang von X-Spam-Status; das Urteil zeigt es jeweils als Badge (spam/ham). Bei Microsoft gilt eine eigene Skala: Eine SCL von −1 steht für vertrauenswürdig (trusted), ab 5 wertet das Tool sie als spam; den BCL-Wert für Massenmails ab 7 als bulk.

Kodierte Betreffzeilen: dekodiert lesen, roh weitergeben

Betreff und Absendernamen mit Umlauten stehen in der Mail als =?UTF-8?B?…?= oder =?UTF-8?Q?…?=. Overview und All Headers zeigen sie dekodiert, damit du lesen kannst, was der Empfänger gesehen hat. Brauchst du den exakten Originalwert — etwa für einen Filter-Regel-Test oder einen Bug-Report an den Absender —, schalte im All-Headers-Tab Show raw values ein und kopiere den Wert von dort.

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. Gespeichert wird standardmäßig gar nichts. Erst wenn du Remember analysed headers in this browser einschaltest, legt das Tool bis zu zehn Header-Abschnitte im localStorage ab. Auf einem geteilten oder fremden Rechner lässt du den Schalter besser aus — oder klickst nach getaner Arbeit auf Forget.

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 weiter einordnen: Subnetz berechnen, Sonderbereich erkennen, Adressformat umrechnen.
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.