Füge die rohen Header einer beliebigen E-Mail ein, um ihren Zustellweg Hop für Hop nachzuvollziehen, zu sehen, wo Zeit verloren ging, und die SPF-, DKIM- und DMARC-Ergebnisse zu lesen, die der empfangende Server festgehalten hat. Die Auswertung läuft komplett in deinem Browser, nichts, was du einfügst, wird hochgeladen oder gespeichert.
Erstelle ein kostenloses Unspam-Konto, um deine Ergebnisse zu speichern und diese Checks jederzeit zu wiederholen. So fällt dir ein kaputtes Setup auf, bevor es dich etwas kostet. Ohne Kreditkarte.
Jede E-Mail trägt einen Block aus Headern, der festhält, wie sie unterwegs war und wie sie authentifiziert wurde. Diese Analyse wertet den Block lokal aus und stellt ihn übersichtlich dar: die Received-Hops vom Ursprungsserver bis zu deinem Postfach, die Verzögerung bei jedem Schritt, die Authentication-Results, die der Empfänger für SPF, DKIM und DMARC gestempelt hat, und wichtige Felder wie From, Return-Path, Subject und Message-ID. Das ist der schnellste Weg, um zu klären, warum eine Nachricht im Spam-Ordner landete, woher eine Verzögerung kam oder ob sich eine Nachricht, die angeblich von einer Marke stammt, wirklich authentifiziert hat. Öffne in deinem E-Mail-Client die Option Rohansicht oder Original anzeigen, kopiere alles oberhalb des Nachrichtentexts und füge es hier ein.
Die SPF-, DKIM- und DMARC-Urteile, die der empfangende Server festgehalten hat. pass ist das Ziel. Ein fail, softfail oder none bei der Domain, die sich authentifizieren sollte, ist ein Warnsignal für die Zustellbarkeit, dem du nachgehen solltest.
Jede Received-Zeile steht für einen Server, der die Nachricht verarbeitet hat. In den rohen Headern stehen sie mit der neuesten zuerst, daher dreht die Analyse sie um und zeigt die echte Reihenfolge, vom Ursprung bis zu deinem Postfach.
Die Zeit zwischen aufeinanderfolgenden Hops. Wenn ein einzelner Hop die Nachricht viele Sekunden oder Minuten festhält, deutet das meist auf Greylisting, eine Warteschlange oder ein langsames Relay hin, eine häufige Ursache für zu spät ankommende Post.
From ist der sichtbare Absender, Return-Path ist der Envelope-Absender, den SPF prüft. Unterscheiden sie sich, ist die Ausrichtung für DMARC entscheidend, und eine Abweichung kann einen Authentifizierungsfehler erklären.
Die eindeutige Kennung, die beim Versand vergeben wird, und der Zeitpunkt der Erstellung. Beide helfen, wenn du eine bestimmte Nachricht in Server-Logs oder mit dem Support eines Anbieters zurückverfolgst.
Die Analyse braucht den ganzen Header-Block oberhalb des Nachrichtentexts, samt der Received- und Authentication-Results-Zeilen. Nutze in deinem Client die Option Original anzeigen oder Quelltext anzeigen und kopiere alles.
Manche interne, weitergeleitete oder an sich selbst gesendete Post bekommt nie einen Authentication-Results-Header gestempelt. Fehlt er, hat der empfangende Server keinen festgehalten, oder er blieb bei dem, was du eingefügt hast, außen vor.
Zeigt ein Schritt eine lange Lücke, wurde die Nachricht dort festgehalten. Greylisting verzögert Erstabsender absichtlich, und eine überlastete Warteschlange tut dasselbe. Wiederholte Verzögerungen beim selben Hop lohnt es zu untersuchen.
Das ist meist eine Frage der Ausrichtung: SPF ist für die Return-Path-Domain durchgegangen, aber diese Domain unterscheidet sich von der sichtbaren From-Domain, also zählt DMARC sie nicht. Ein zur From-Domain ausgerichtetes DKIM behebt das.
Das Weiterleiten schreibt den Zustellweg um, was oft SPF bricht und DKIM brechen kann, wenn die Nachricht verändert wird. Eine Header-Spur zeigt, wo die Weiterleitung passierte und welche Prüfungen sie überstanden haben.
