Was das Tool macht
Jeder Mailserver, der eine Nachricht weiterreicht, fügt oben in ihrem Header Zeilen hinzu, und der Server, der sie schließlich annimmt, vermerkt, ob der Absender seine Prüfungen bestanden hat. Heraus kommt ein langer, mehrfach umbrochener Textblock, der sich mit bloßem Auge nur mühsam lesen lässt. Dieses Tool wertet die Roh-Header einer E-Mail aus und ordnet sie in fünf Teile:
- Zusammenfassung: From, To, Subject, Date, Message-ID, Return-Path und Reply-To.
- Authentifizierung: die Ergebnisse von SPF, DKIM und DMARC (pass, fail, none usw.) aus den Headern Authentication-Results und Received-SPF, dazu Domain (
d=) und Selektor (s=) jedes DKIM-Signature-Headers. - Alignment: ob die From-Domain mit der Domain aus DKIM-
d=und mit der Return-Path-Domain übereinstimmt. - Received-Kette: jeder Hop, nummeriert vom ältesten an, mit den Hosts aus from und by, dem Protokoll (etwa ESMTPS), dem Zeitstempel und der Verzögerung seit dem vorherigen Hop, dazu die gesamte Zustelldauer.
- Warnungen: ein Reply-To, das von From abweicht, Hops mit Zeitstempeln in falscher Reihenfolge oder mit Uhrabweichung sowie fehlende Authentifizierungsergebnisse.
Die Auswertung erledigt JavaScript in deinem Browser. Nichts wird hochgeladen oder irgendwohin gesendet, und einmal geladen funktioniert die Seite auch ohne Netzverbindung. Das Tool prüft DKIM-Signaturen nicht kryptografisch und fragt kein DNS ab; es gibt wieder, was die empfangenden Server in die Header geschrieben haben.
So nutzt du das Tool
- Öffne den Quelltext der Nachricht. In Gmail klickst du neben „Antworten“ auf das Dreipunkt-Menü und wählst „Original anzeigen“. Im klassischen Outlook für Windows öffnest du die Nachricht per Doppelklick in einem eigenen Fenster, wählst „Datei“ und dann „Eigenschaften“ und kopierst den Inhalt des Felds „Internetkopfzeilen“. In Outlook im Web und im neuen Outlook öffnest du das Dreipunkt-Menü „Weitere Aktionen“, dann „Anzeigen“ und dort „Nachrichtendetails anzeigen“. In Apple Mail wählst du „Darstellung“ > „E-Mail“ > „Reine Datei“.
- Kopiere den Header-Block: alles bis zur ersten Leerzeile. Den Nachrichtentext darunter brauchst du nicht.
- Füge ihn in das Feld auf dieser Seite ein.
- Lies zuerst die Zusammenfassung und die Authentifizierungsergebnisse, dann die Warnungen und zum Schluss die Liste der Hops.
Beim Weiterleiten gehen die ursprünglichen Header verloren. Arbeite deshalb mit der Kopie im Postfach, das die Nachricht empfangen hat, oder bitte den Empfänger, sie als Anhang weiterzuleiten.
Wofür du es brauchst
- Eine verdächtige Nachricht prüfen. Eine Zahlungsaufforderung eines Lieferanten zeigt
dmarc=fail, eine DKIM-Domain ind=, die nichts mit der From-Domain zu tun hat, und ein abweichendes Reply-To. Das reicht, um sie zu melden, statt zu antworten. - Herausfinden, wo eine Verzögerung entstand. Eine Mail zum Zurücksetzen des Passworts kommt 40 Minuten zu spät. Die meisten Hops brauchten ein, zwei Sekunden, aber ein Relay hielt sie 38 Minuten fest – damit weißt du, nach wessen Warteschlange du fragen musst.
- Die eigene Domain testen. Nachdem du einen Newsletter-Dienst angebunden hast, schick dir selbst eine Testmail und prüfe, ob SPF und DKIM bestehen und ob in
d=deine Domain steht und nicht die gemeinsam genutzte Domain des Dienstes. - Eine Nachricht in Logs wiederfinden. Gib deinem Mail-Administrator die Message-ID und den Zeitpunkt, zu dem dein Anbieter die Nachricht angenommen hat; nach beidem lässt sich in Zustellprotokollen suchen.
- Transportverschlüsselung bestätigen. ESMTPS bei einem Hop heißt, dieser Abschnitt lief über TLS; reines ESMTP oder SMTP heißt, er lief unverschlüsselt.
Die Received-Kette lesen – und was sich fälschen lässt
Jeder Server setzt seine Received-Zeile über die bereits vorhandenen, der neueste Hop steht also oben. Von unten nach oben gelesen, folgst du der Nachricht in zeitlicher Reihenfolge; das Tool dreht die Reihenfolge für dich um.
Received: from mx-out.shop.example (mx-out.shop.example [198.51.100.25])
by mx1.recipient.example with ESMTPS id 4f2ac81e
for <you@recipient.example>; Tue, 6 Oct 2026 14:02:11 +0000
Received: from app01.internal (app01.internal [10.0.4.7])
by mx-out.shop.example with ESMTP id 91c0d3;
Tue, 6 Oct 2026 14:02:09 +0000Wem du trauen kannst, hängt davon ab, wer die jeweilige Zeile geschrieben hat. Such den frühesten Hop, den dein eigener Anbieter hinzugefügt hat, hier den mit dem Stempel von mx1.recipient.example. Diese Zeile und alles danach sind verlässlich, und die IP-Adresse in eckigen Klammern darin gehört der Maschine, die die Nachricht tatsächlich übergeben hat. Alles, was davor festgehalten wurde – im Rohtext also darunter –, stammt von der Absenderseite und kann erfunden sein, auch gefälschte Received-Zeilen, die eine andere Herkunft vortäuschen. From, Reply-To, Subject, Date und Message-ID legt ebenfalls der Absender fest.
Jeder Zeitstempel stammt von der Uhr des jeweiligen Servers. Eine Verzögerung von ein paar Sekunden unter null bedeutet meist, dass eine Uhr leicht falsch geht. Lange Lücken deuten auf eine Warteschlange hin, auf einen erneuten Zustellversuch nach einer vorübergehenden Ablehnung oder auf eine Nachricht, die zur Prüfung zurückgehalten wurde.
Was SPF, DKIM und DMARC jeweils belegen
SPF vergleicht die IP-Adresse der eingehenden Verbindung mit den Servern, die eine Domain im DNS aufführt. Geprüft wird die Domain des Envelope-Absenders, die später zum Return-Path wird, nicht die sichtbare From-Adresse. Ein „pass“ belegt nur, dass dieser Server für die Return-Path-Domain senden darf. Weiterleitungen bringen SPF oft zum Scheitern, weil der weiterleitende Server nicht auf der Liste steht.
DKIM ist eine Signatur über den Nachrichtentext und ausgewählte Header. d= nennt die signierende Domain, s= den Selektor, über den ihr öffentlicher Schlüssel gefunden wird. Ein „pass“ bedeutet, dass die signierten Teile nicht verändert wurden und die Domain in d= sich für sie verbürgt. Über From sagt das nichts, solange die Domains nicht übereinstimmen.
DMARC verknüpft beide Prüfungen mit der Adresse, die Leser sehen: Es besteht, wenn SPF oder DKIM besteht und die Domain der erfolgreichen Prüfung zur From-Domain passt. Eine Nachricht kann SPF und DKIM für die eigenen Domains eines Massenversenders bestehen, während in der From-Zeile eine Bank steht – DMARC besteht dann trotzdem nicht.
Authentication-Results: mx1.recipient.example;
dkim=pass header.d=shop.example header.s=s2026;
spf=pass smtp.mailfrom=bounce.shop.example;
dmarc=pass header.from=shop.exampleIm Standardmodus von DMARC (relaxed) passt bounce.shop.example zu shop.example, weil beide dieselbe Organisationsdomain haben. Prüfe, ob der erste Name in diesem Header der Server deines Anbieters ist: Ein Absender kann eine gefälschte Authentication-Results-Zeile einfügen, und sorgfältige Empfangsserver entfernen solche Zeilen.
Schau zum Schluss hinter den Anzeigenamen. Bei PayDesk Billing <billing@paydesk-help.example> zeigen die meisten Mailprogramme nur den freundlichen Namen, die Prüfungen oben betreffen aber die Adresse.
Häufige Fragen
Wird der eingefügte Header an iseeu.cc gesendet?
Nein. Der Header wird von JavaScript in deinem Browser ausgewertet und weder hochgeladen noch sonst irgendwohin gesendet. Du kannst das selbst überprüfen: Schalte das WLAN aus, nachdem die Seite geladen ist, und starte die Analyse noch einmal – offline kommen dieselben Ergebnisse heraus. Unabhängig davon protokolliert iseeu.cc weder IP-Adressen noch Abfragen, führt keine Besucherdatenbank, setzt keine Cookies und zeigt keine Werbung.
Heißt „dkim=pass“ hier, dass die Signatur gültig ist?
Es heißt, dass der empfangende Server beim Eingang der Nachricht ein „pass“ vermerkt hat. Dieses Tool wiederholt die kryptografische Prüfung nicht und holt auch keinen öffentlichen Schlüssel aus dem DNS; es liest das Ergebnis aus dem Header Authentication-Results. Meist ist genau das sinnvoll, denn Absender wechseln ihre Schlüssel, und eine Signatur, die Wochen später geprüft wird, kann scheitern, obwohl sie bei der Zustellung gültig war.
Warum scheitert SPF bei einer E-Mail, die garantiert echt ist?
Die häufigste Ursache ist eine Weiterleitung. Wird eine Nachricht weitergeleitet oder über eine Mailingliste verschickt, verbindet sich der weiterleitende Server von seiner eigenen IP-Adresse aus, und die steht nicht im SPF-Eintrag des ursprünglichen Absenders. Dasselbe passiert, wenn ein Absender einen neuen Maildienst einbindet, ohne SPF anzupassen. Besteht DKIM weiterhin mit einer Domain, die zur From-Adresse passt, kann DMARC trotzdem bestehen.
Warum haben manche Hops eine negative Verzögerung?
Jeder Server schreibt den Zeitstempel seiner Received-Zeile nach seiner eigenen Uhr, und diese Uhren laufen nicht exakt synchron. Scheint ein Hop ein, zwei Sekunden vor dem vorherigen anzukommen, geht meist eine Uhr leicht falsch. Größere Sprünge rückwärts auf der Absenderseite der Kette können aber auch bedeuten, dass eine Received-Zeile erfunden wurde. Das Tool markiert Zeitstempel in falscher Reihenfolge und Uhrabweichungen, damit du entscheiden kannst, was zutrifft.
Wie erkenne ich am Header eine Phishing-Mail?
Vergleiche den Anzeigenamen mit der tatsächlichen From-Adresse und prüfe dann, ob DMARC bestanden hat und ob die DKIM-Domain zur From-Domain passt. Ein Reply-To, das von From abweicht, ist ein klassisches Warnzeichen: Antworten gehen dann an den Angreifer, auch wenn die From-Zeile echt aussieht. Sieh dir außerdem den ersten Hop an, den dein eigener Anbieter hinzugefügt hat: Die sendende IP-Adresse dort hat dein Anbieter festgehalten, nicht der Absender.
Warum gibt es für meine E-Mail keine Authentifizierungsergebnisse?
Nicht jedes empfangende System schreibt einen Authentication-Results-Header. Manche Firmenmailserver und ältere Systeme lassen ihn weg, und Mails zwischen Nutzern desselben internen Servers werden oft gar nicht geprüft. Auch Header aus einer weitergeleiteten Kopie haben die ursprünglichen Ergebnisse verloren. Findet das Tool keine, zeigt es eine Warnung; als Anhaltspunkte bleiben dann die Liste der Hops und die Domains aus DKIM-Signature.
Was bedeuten ESMTP, ESMTPS und ESMTPSA bei einem Hop?
Sie beschreiben die Verbindung, über die ein Server die Nachricht empfangen hat. ESMTP ist erweitertes SMTP ohne Verschlüsselung. RFC 3848 hat die Varianten ergänzt: ESMTPS heißt, die Verbindung lief über TLS, ESMTPA heißt, der sendende Client hat sich angemeldet, und ESMTPSA heißt beides. Jede Angabe gilt nur für diesen einen Hop; eine Nachricht kann also auf manchen Abschnitten verschlüsselt sein und auf anderen nicht. LMTP taucht oft beim letzten internen Zustellschritt auf.
Kann ich mit dem Header beweisen, wer mir die E-Mail geschickt hat?
Nein. Die Analyse gibt wieder, was die empfangenden Server in den Header geschrieben haben, und wendet einfache Heuristiken an. Verlassen kannst du dich nur auf die Zeilen, die dein eigener Anbieter hinzugefügt hat; alles, was im Rohtext darunter steht, kann die Absenderseite erfunden haben. Geht es um Geld oder Zugangsdaten, frag über einen Kanal nach, dem du bereits vertraust.
Die Analyse gibt wieder, was empfangende Server in die Header geschrieben haben, und wendet einfache Heuristiken an. Sie kann nicht beweisen, wer eine Nachricht geschickt hat; geht es um Geld oder Zugangsdaten, frag über einen Kanal nach, dem du bereits vertraust.