Kostenloser E-Mail-Header-Analysator
Was eine Nachricht wirklich über ihren Absender sagt.
Eine Nachricht zeigt einen Absender; ihre Header sagen, wer sie tatsächlich zugestellt hat. Dieser Analysator liest die SPF-, DKIM- und DMARC-Verdikte des empfangenden Servers, berechnet die Ausrichtung neu und rekonstruiert den Weg Schritt für Schritt.
- Kostenlos
- Ohne Konto
- Sofortiges Ergebnis
- Analyse im Browser
Eine Nachricht analysieren
So funktioniert es
- 1
Kopieren Sie die Originalnachricht
In Gmail „Original anzeigen“; in Outlook „Eigenschaften“ und dann „Internetkopfzeilen“. Der Header-Block allein genügt.
- 2
Fügen Sie ihn in das Feld ein
Die Analyse läuft im Browser: die Header werden an keinen Server gesendet, und der Nachrichtentext wird nie gelesen.
- 3
Sofortiges Verdikt
Die SPF-, DKIM- und DMARC-Verdikte erscheinen mit ihrer Ausrichtung, der ARC-Kette und dem Weg über alle durchlaufenen Server.
Warum das wichtig ist
Eine Phishing-Nachricht zeigt einen glaubwürdigen Absender; nur die vom empfangenden Server ergänzten Header sagen, woher sie wirklich stammt. Umgekehrt hinterlässt eine legitime Nachricht, die im Spam gelandet ist, die Ursache in genau diesen Headern: fehlende Signatur, durch einen Drittanbieter gebrochene Ausrichtung oder ein Relais, das SPF bricht.
Unsichtbare Fälschung
Ein Feld „From:“ ist in einer Zeile gefälscht. Ohne die Authentifizierungsverdikte zu lesen, trennt auf dem Bildschirm nichts das Echte vom Falschen.
Gebrochene Ausrichtung
SPF kann für den Envelope eines Drittanbieters gültig sein, ohne die angezeigte Domain abzudecken — DMARC scheitert dann trotz „pass“.
Ungeklärter Spam-Ordner
Ohne ihre Header gibt eine gefilterte Nachricht ihre Ursache nicht preis: fehlende Signatur, zwischengeschaltetes Relais oder verzögerte Zustellung.
Was Header enthalten
Eine Nachricht trägt Dutzende technischer Felder, die E-Mail-Programme verbergen. „Authentication-Results“ (RFC 8601) enthält die SPF-, DKIM- und DMARC-Verdikte des Servers, der die Nachricht angenommen hat. „DKIM-Signature“ nennt die signierende Domain und ihren Selektor. Die Felder „Received:“, von jedem Relais vorangestellt, zeichnen den Weg rückwärts nach. „ARC-Seal“ (RFC 8617) bezeugt die ursprünglichen Verdikte, wenn ein Relais die Nachricht unterwegs verändert hat.
Zum Merken — Ein „Authentication-Results“-Header lässt sich vom Absender frei schreiben: maßgeblich ist nur der vom empfangenden Server gesetzte. Der Analysator zeigt dessen authserv-id, damit die Frage gestellt bleibt.
Wie der Analysator arbeitet
Die Analyse ist eine Textverarbeitung im Browser: Felder trennen, Fortsetzungszeilen entfalten, Verdikte lesen und anschließend die Ausrichtung zwischen signierender Domain, Envelope-Domain und dem Feld „From:“ neu berechnen. Keine Netzanfrage, keine Speicherung. Im Gegenzug wird keine Signatur neu berechnet: da der Nachrichtentext nicht vorliegt, liest der Analysator vorhandene Verdikte, statt sie zu wiederholen.
Häufige Fragen
- Werden die eingefügten Header irgendwohin gesendet?
- Nein. Die Analyse übernimmt der Browser, auf der Seite selbst. Nichts wird an einen Server übertragen, nichts gespeichert, und das Schließen des Tabs löscht alles.
- Prüft der Analysator die DKIM-Signatur wirklich?
- Nein, und diese Grenze ist gewollt: eine Signatur zu prüfen erfordert den vollständigen Nachrichtentext. Der Analysator liest das Verdikt des empfangenden Servers, dem die ganze Nachricht vorlag.
- Warum scheitert DMARC, obwohl SPF besteht?
- Weil SPF die Envelope-Domain prüft, nicht die im Feld „From:“ angezeigte. Versendet ein Drittanbieter mit eigenem Envelope, besteht SPF ohne ausgerichtet zu sein — DMARC verlangt dann eine DKIM-Signatur der angezeigten Domain.
Lesen, was eine Nachricht nicht zeigt
Eine Nachricht analysierenKostenlos und sofort — die Analyse bleibt im Browser, kein Konto erforderlich.