Email Header Analyzer

Jede E-Mail trägt in ihrem Header die vollständige Zustellhistorie: über welche Server sie lief, wie lange jeder Schritt dauerte und wie das empfangende System SPF, DKIM und DMARC bewertet hat. Dieser Analyzer macht aus dem rohen, oft hunderte Zeilen langen Header eine lesbare Übersicht und hilft bei Fragen wie warum wurde diese Mail als Spam einsortiert oder ist diese Nachricht wirklich vom angegebenen Absender.

Was dieses Werkzeug prüft

Eingabe ist der Roh-Header, eingefügt als Text. Es findet keine Netzwerkabfrage statt, alles wird lokal ausgewertet. Angezeigt werden: die Received-Kette chronologisch mit dem Zeitverzug je Station und der einliefernden öffentlichen IP, die Authentication-Results mit SPF, DKIM, DMARC, ARC, iprev und compauth im Klartext, die DKIM-Signature-Header mit signierender Domain, Selektor, Algorithmus und Ablaufzeit, die Absender-Identität (From, Return-Path, Reply-To, Message-ID) und die Spam-Header des Empfängers (X-Spam-*, SCL).

Das Ergebnis lesen

Die Received-Kette liest sich von unten nach oben: die unterste Zeile ist die erste Station, die oberste die letzte. Ein grüner Haken je Authentifizierungsmethode heißt pass, eine Warnung fail oder softfail. Als Fehler markiert werden mehrere From-Header (RFC-Verstoß und ein klassisches Phishing-Muster), ein Widerspruch zwischen From und Return-Path und ein abgelaufenes DKIM-Ablaufdatum. Auffällige Zeitsprünge zwischen Stationen (eine lange Verzögerung oder eine rückwärts laufende Uhr) und eine Spam-Einstufung des empfangenden Systems erscheinen als Hinweis.

Grundlagen

Der Aufbau des Headers folgt RFC 5322 (unter anderem genau ein From). Die Received-Trace-Felder beschreibt RFC 5321 §4.4, das Format von Authentication-Results RFC 8601, die ARC-Header-Kette RFC 8617. Die einzelnen Ergebnisse stammen aus SPF (RFC 7208), DKIM (RFC 6376) und DMARC (RFC 9989). Eine kryptografische Prüfung der DKIM-Signatur ist nicht möglich, dafür bräuchte es die vollständige Roh-Mail inklusive Body; der Analyzer zeigt das Ergebnis, das der empfangende Server eingetragen hat.

Typische Fehlerbilder und wie man sie behebt

• dmarc=fail in den Authentication-Results. Entweder ist die Mail tatsächlich gefälscht, oder ein legitimer Versandweg hat weder SPF-Alignment noch eine ausgerichtete DKIM-Signatur. Die signierende d=-Domain der DKIM-Signature mit der From-Domain vergleichen; weichen sie ab, beim Versanddienst DKIM für die eigene Domain einrichten.
• spf=softfail oder spf=fail, DKIM aber pass. Häufig nach einer Weiterleitung: SPF bricht, DKIM übersteht sie. Solange DMARC über DKIM besteht, ist die Zustellung gerettet; der SPF-Record der Ursprungsdomain sollte trotzdem alle direkten Versandwege abdecken.
• Große Verzögerung zwischen zwei Received-Stationen. Zeigt, wo die Mail hing: Greylisting (typisch 5 bis 30 Minuten), eine überlaufende Warteschlange oder ein langsamer Viren-/Spam-Scanner. Die Station mit dem Sprung benennt den zuständigen Server.
• Return-Path und From aus verschiedenen Domains. Bei Newslettern und Ticketsystemen normal (Bounce-Adresse des Dienstleisters). Bei persönlicher Post ein Warnzeichen, dann die Received-Kette und die Authentication-Results genau prüfen.
• Mehrere From-Header. Kein gültiges Setup erzeugt das. Die Nachricht mit Vorsicht behandeln; viele Clients zeigen nur den ersten oder letzten From an, was gezielt zur Täuschung genutzt wird.