Eingaben
Beispiel
Füge vollständige RFC-5322-Header ein, um rohe und chronologische Hops, aufgezeichnete SPF/DKIM/DMARC-Ergebnisse, Vertrauensklassifikation und Parserbefunde zu prüfen.
E-Mail-Header-Analyzer
Analysiert vollständige Message-Header lokal, erhält die rohe Received-Reihenfolge und klassifiziert aufgezeichnete Authentication-Results ohne Kryptografie- oder Reverse-DNS-Versprechen.
Nützlich, wenn ein Zustellproblem die rohe Received-Reihenfolge und klar bezeichnete aufgezeichnete Authentication-Results statt einer vermeintlich frischen Verifikation braucht.
Mail-Header in der richtigen Richtung lesen
Vollständige Message-Header beantworten die meisten Fragen zu einer verdächtigen oder fehlgeleiteten Mail: Wer hat sie wirklich eingeliefert, welche Systeme hat sie durchlaufen, was hat die Empfangsseite zu SPF, DKIM und DMARC festgehalten, wo ging Zeit verloren. Der Haken: Header sind für Maschinen geschrieben, neueste zuerst gestapelt, von Zwischensystemen umgeschrieben und mit Feldern gespickt, die bedeutsam aussehen, aber trivial fälschbar sind. Naiv gelesen führen sie öfter in die Irre, als dass sie informieren.
Dieser Analyzer verwandelt einen eingefügten RFC-5322-Headerblock in strukturierte aufgezeichnete Evidenz: Received-Felder in roher Neueste-zuerst-Reihenfolge plus separater chronologischer Sicht, Authentication-Results mit authserv-id, Methodenversionen, Properties und vom Aufrufer gesetzter Vertrauensklassifikation, vorhandene DKIM-/ARC-Felder, List-Header und Parserbefunde. Aufgezeichnetes pass oder fail ist kein frisch verifiziertes Authentifizierungsergebnis. Alles bleibt lokal im Browser.
Von der Zusammenfassung zur Hop-für-Hop-Evidenz
Beginne mit der Zusammenfassung, dann lies Authentication-Results und Received-Kette nebeneinander. Jedes Relay stellt seinen Eintrag voran; deshalb zeigt das Tool rohe Neueste-zuerst-Reihenfolge und chronologische Sicht getrennt. Konfiguriere nur authserv-id-Werte, denen du tatsächlich vertraust. Ohne expliziten Vertrauensanker bleibt selbst der nächste Kandidat als ungeprüft markiert; tiefer liegende Behauptungen können vom Absender eingefügt sein.
Nutze die Timeline-Hinweise, um zu sehen, wo Latenz wirklich entstand — Queueing an einem Relay sieht anders aus als langsames DNS an einem anderen. Bei Authentifizierungsfragen vergleiche die Aussagen der Authentication-Results mit den tatsächlich vorhandenen DKIM- und ARC-Feldern: Eine fehlende Signatur, eine gebrochene Kette oder ein Resultat für eine andere Domain als erwartet ist meist schon die ganze Antwort. Bei weitergeleiteten oder listenverarbeiteten Mails sind Umschreibungen normal — lies Befunde mit diesem Kontext.
Ein bewusst lokaler Parser
Der eingefügte Headerblock wird vollständig im Browser geparst und von diesem Tool an keinen Server gesendet — relevant, weil Header oft persönliche Daten, interne Hostnamen, Relay-IPs und Message-IDs tragen. Der Parser extrahiert und ordnet; er holt keine DKIM-Schlüssel, verifiziert Signaturen nicht kryptografisch und ist kein forensisches Mail-Gateway. Seine Aussagen sind Lesarten aufgezeichneter Evidenz, keine frische Validierung.
Häufige Fragen
Warum ist die Received-Kette manchmal verwirrend?
Jedes Relay stellt seinen eigenen Header voran, und manche Systeme schreiben Details um oder lassen sie aus Datenschutz- oder Architekturgründen weg. Die Kette ist eine Sammlung unterschiedlich vertrauenswürdiger Behauptungen — deshalb kombiniert der Parser sie mit Zeitstempeln und Befunden, statt sie für bare Münze zu nehmen.
Was genau sagen mir die Authentication-Results?
Was eine benannte authserv-id bei der Zustellung zu SPF, DKIM, DMARC oder ARC aufgezeichnet hat. Zur Empfänger-Evidenz wird der Wert erst, wenn authserv-id und Headerposition zu einer von dir kontrollierten Vertrauensgrenze gehören; sonst bleibt er eine ungeprüfte Behauptung. Das Tool führt weder frische DNS-Authentifizierung noch kryptografische Verifikation durch.
Verifiziert das Tool DKIM-Signaturen kryptografisch?
Nein. Es parst DKIM- und ARC-Felder und bewertet Form und Konsistenz, holt aber keine öffentlichen Schlüssel und rechnet keine Signaturen nach. Kryptografische Verifikation leistet nur die Validierung des Empfangssystems.
Kann ich sensible Header gefahrlos einfügen?
Das Tool lädt sie nicht hoch — das Parsing bleibt in dieser Browser-Session. Die Abwägung betrifft deinen Bildschirm und dein Gerät, nicht einen Server: Behandle Header als die privaten Routingdaten, die sie sind.
Welche Headerfelder sind vertrauenswürdig?
Nur Felder, die in Systemen und Headergrenzen verankert sind, die du kontrollierst. Setze die vertrauenswürdige authserv-id explizit; nur scheinbar oberste Authentication-Results sind sonst Kandidaten, nicht automatisch vertrauenswürdig. From, Subject, Date, Message-ID, tiefere Received-Felder und unverankerte Authentifizierungsbehauptungen können gefälscht sein.
Wozu dienen ARC-Header?
ARC konserviert Authentifizierungsergebnisse über Weiterleitungsschritte, die SPF oder DKIM sonst brechen würden — Mailinglisten sind der Klassiker. Der Analyzer zeigt die Kette, sodass sichtbar wird, ob ein Zwischensystem für früher beobachtete Ergebnisse gebürgt hat.