E-Mail-Header und Transportweg analysieren
Fügen Sie Mail-Header für eine Transportzeitleiste ein. Authentifizierungsergebnisse werden aus dem Text übernommen, nicht unabhängig verifiziert.
Läuft lokal in deinem BrowserFügen Sie Mail-Header für eine Transportzeitleiste ein. Authentifizierungsergebnisse werden aus dem Text übernommen, nicht unabhängig verifiziert.
Läuft lokal in deinem BrowserFügen Sie den Headerblock einer Nachricht ein — den Text hinter „Original anzeigen“ in Gmail, „Nachrichtenquelle anzeigen“ in Outlook oder „Alle Header“ in Apple Mail — und klicken Sie auf Lokal analysieren. Das Werkzeug listet jede Received-Zeile als einen Hop, schreibt die Zeit zwischen aufeinanderfolgenden Hops in die Spalte Verzögerung und liest die Authentifizierungsergebnisse, die die Nachricht selbst angibt.
Alles wird im Tab ausgewertet: keine Anfrage wird gesendet, nichts wird gespeichert, und die Header verlassen Ihr Gerät nicht. Darin liegt auch die Grenze der Antwort. VoriTools zeigt, was in den Headern steht; es kontaktiert keinen Mailserver, fragt keine DNS-Einträge ab und prüft keine Signatur.
Jeder Mailserver setzt seine eigene Received-Zeile an den Anfang der Nachricht, der Block ist also von neu nach alt geordnet: Die Received-Zeile direkt über dem Body stammt vom ersten Server, der die Nachricht bearbeitet hat, und die oberste Zeile vom Server, der sie ins Postfach übergeben hat. Der Analyzer liest den Block von unten nach oben; deshalb ist Hop 1 der älteste und die letzte Zeile die Zustellung ins Postfach.
Die Verzögerung ist die Differenz zweier Zeitstempel, und jeder Zeitstempel stammt von der Uhr des Servers, der ihn geschrieben hat, in dessen eigener Zeitzone. Eine lange Verzögerung heißt, dass die Nachricht irgendwo gewartet hat — Greylisting, Spamfilter, Wiederholungswarteschlange —, deshalb markiert das Panel den Hop und nicht den Grund. Verzögerungen über fünf Minuten (300 s) werden zu Befunden, und ein Hop, dessen Zeitstempel vor dem des Hops darüber liegt, wird als rückwärts laufende Zeitstempel gemeldet: Das ist eine nachgehende Uhr, keine negative Verzögerung.
Die Übersicht ist eine Auswertung des Header-Textes, keine Verifikation. Jedes Paar Mechanismus=Ergebnis wird in der Reihenfolge aufgeführt, bestguesspass wird so angezeigt und nicht als Fehler gewertet, neutral und none bleiben unmarkiert. fail, softfail, temperror und permerror werden mit dem jeweiligen Mechanismus unter den Befunden wiederholt.
Derselbe Mechanismus erscheint häufig mehrfach: Eine Nachricht über eine Mailingliste trägt eine Signatur der Liste und eine des Absenders, deshalb kann ein dkim=pass neben einem dkim=fail stehen. Ergebnisse, die ein Zwischenserver in ARC-Authentication-Results festgehalten hat, tragen die Markierung ARC und stehen neben denen des empfangenden Servers; existieren nur ARC-Ergebnisse, sagt das Panel das, weil sie nicht vom Provider stammen, der die Nachricht empfangen hat. Zum Bestätigen bleibt der Blick in den DKIM-Selektor, den SPF-Eintrag oder die DMARC-Richtlinie mit einem DNS-Werkzeug nötig.
Die Befunde decken einen fehlenden Message-ID- oder Date-Header ab, eine Reply-To-Domain, die von der From-Domain abweicht, verzögerte Hops und Zeitstempel, die rückwärts laufen. Ein fehlender Authentication-Results-Header wird anders gemeldet als ein vorhandener Header ohne SPF-, DKIM-, DMARC- oder ARC-Ergebnis, und ein Text ganz ohne Header-Zeilen bekommt einen klaren Fehler statt einer Liste fehlender Felder.
Zwei Grenzen sind wichtig. Header sind Text, den der Absender kontrolliert: Ein gefälschter Block wird genau so angezeigt, wie er geschrieben wurde, und eine pass-Zeile beweist für sich nichts. Und gelesen wird nur der Headerblock — die erste Leerzeile beendet ihn —, X-Received-Zeilen und andere Trace-Header mit anderem Namen sind also keine Hops, und ein älterer Headerblock, der im Body einer weitergeleiteten Nachricht zitiert wird, trägt nichts bei.