Das Support-Ticket war frustrierend vage: "Ich erhalte keine E-Mails aus Ihrem System." Die Logs zeigten, dass die E-Mail erfolgreich gesendet wurde. Der ESP meldete, sie sei zugestellt worden. Doch der Kunde bestand darauf, dass sie nie angekommen sei.
Die Antwort steckte in den E-Mail-Headern—eine Spur aus Zeitstempeln, Servernamen und Authentifizierungsergebnissen, die die Reise der Nachricht vom Versand bis zur (Nicht-)Zustellung nachzeichnete. Irgendwo auf dieser Reise ging etwas schief. Aber Roh-Header zu lesen ist wie Assemblercode zu lesen: technisch möglich, aber schmerzhaft langsam.
E-Mail-Header-Analysetools parsen die kryptischen Header-Daten in verständliche Informationen. Sie zeigen dir den Pfad, den eine E-Mail genommen hat, wie lange jeder Hop dauerte, ob die Authentifizierung bestand und wo Probleme auftraten. Beim Debuggen von Zustellproblemen sind sie unverzichtbar.
So erhältst du Header
Bevor du Header analysieren kannst, musst du sie extrahieren. Jeder E-Mail-Client versteckt sie anders.
In Gmail öffne die E-Mail, klicke auf das Drei-Punkte-Menü und wähle "Original anzeigen." Du siehst die Rohnachricht einschließlich aller Header. Kopiere alles oberhalb des eigentlichen Nachrichteninhalts.
In Outlook öffne die E-Mail, klicke auf Datei > Eigenschaften und suche unten im Dialog nach "Internet-Header". Das Textfeld ist klein und etwas umständlich, aber die Header sind da.
In Apple Mail wähle die E-Mail und dann Darstellung > Nachricht > Rohquelle. Die Header stehen oben in der Rohnachricht.
Für den programmatischen Zugriff geben die meisten E-Mail-APIs Header als Teil der Nachrichtendaten zurück. Wenn du dein eigenes System debuggst, kannst du Header beim Verarbeiten eingehender E-Mails loggen.
Die Analysetools
Google Admin Toolbox enthält einen Header-Analyzer, der simpel und effektiv ist. Füge deine Header ein, und er parst sie zu einer lesbaren Timeline mit jedem Server-Hop, Zeitstempeln, Verzögerungen und Authentifizierungsergebnissen. Die Visualisierung macht es leicht, Verzögerungen oder fehlgeschlagene Authentifizierungen zu erkennen.
Er ist kostenlos, erfordert kein Konto und kommt mit den meisten gängigen Header-Formaten zurecht. Für eine schnelle Analyse ist er oft das erste Tool der Wahl.
MXToolbox Header Analyzer bietet ähnliche Funktionalität mit zusätzlichem Kontext. Über das reine Parsen hinaus erklärt er, was jedes Feld bedeutet, und markiert potenzielle Probleme. Wenn SPF fehlgeschlagen ist, sagt er dir warum. Bei ungewöhnlichen Verzögerungen hebt er sie hervor.
MXToolbox bietet außerdem verwandte Tools—Blacklist-Checks, DNS-Lookups, SMTP-Diagnosen—die die Header-Analyse ergänzen. Beim Debuggen von Zustellproblemen brauchst du oft mehrere Tools, und sie an einem Ort zu haben, ist bequem.
Mail Header Analyzer von WhatIsMyIPAddress ist unkompliziert und schnell. Header einfügen, eine aufgeschlüsselte Auswertung erhalten. Die Oberfläche ist ohne Schnickschnack, erledigt den Job aber zuverlässig. Die Hop-by-Hop-Aufschlüsselung zeigt den Pfad klar, und Authentifizierungsergebnisse sind hervorgehoben.
Messageheader von Google ist ein weiteres Google-Tool (separat von Admin Toolbox), das sich auf Authentifizierungsanalyse konzentriert. Es ist besonders gut darin, DMARC-, SPF- und DKIM-Ergebnisse in einfacher Sprache zu erklären. Wenn du speziell Authentifizierungsfehler debuggst, ist die fokussierte Analyse hilfreich.
Tools mit Fokus auf Authentifizierung
Das Header-Tool von DMARC Analyzer konzentriert sich speziell auf Authentifizierungsergebnisse. Es parst die Resultate von SPF, DKIM und DMARC und erklärt nicht nur pass/fail, sondern auch warum. Wenn DKIM wegen einer Modifikation des Nachrichtentexts während der Übertragung fehlschlug, sagt es dir das. Wenn SPF fehlschlug, weil die sendende IP nicht in deinem Record war, identifiziert es die IP.
Für Authentifizierungs-Debugging sparen die detaillierten Erklärungen im Vergleich zur manuellen Interpretation von Authentication-Results-Headern erheblich Zeit.
Dmarcians Header-Analyzer fokussiert ähnlich auf Authentifizierung, mit klaren Visualisierungen der Authentifizierungskette. Ihr Tool zeigt, wie die DMARC-Auswertung ablief—welche Identifikatoren übereinstimmten, welche Prüfungen bestanden haben und was das Endergebnis war.
Wenn du DMARC implementierst oder Fehler behebst, bieten ihre Tools (inklusive des Header-Analyzers) die klarsten verfügbaren Erklärungen.
Entwickler-Tools
Für Entwickler, die Header programmatisch analysieren müssen, gibt es Bibliotheken in den meisten Sprachen. Pythons Modul email.parser übernimmt das Parsen von Headern. Node.js hat mailparser. Damit kannst du Header-Analyse in deine eigenen Debugging-Tools oder dein automatisiertes Monitoring einbauen.
Der Vorteil programmatischer Analyse ist Automatisierung. Wenn du große Mengen E-Mails verarbeitest und Muster in Zustellproblemen identifizieren musst, skaliert skriptgesteuerte Analyse besser als die Nutzung manueller Tools.
Haraka, der Node.js-SMTP-Server, enthält Header-Analyse in seinem Plugin-Ökosystem. Wenn du Haraka für die E-Mail-Verarbeitung betreibst, kannst du Header als Teil deines Mail-Flows analysieren, anstatt als separaten Debugging-Schritt.
Worauf du achten solltest
Header-Analysetools präsentieren die Daten, aber du musst wissen, was zählt.
Zeitstempel sagen etwas über Verzögerungen aus. Jeder Server, der die E-Mail verarbeitet, fügt einen Received-Header mit einem Zeitstempel hinzu. Ein Vergleich der Zeitstempel zeigt, wie lange jeder Hop dauerte. Eine Nachricht, die insgesamt 30 Sekunden brauchte, davon aber 25 Sekunden bei einem Hop verbrachte, hat einen Flaschenhals, der Untersuchung verdient.
Authentifizierungsergebnisse zeigen, ob SPF, DKIM und DMARC bestanden haben. Achte auf den Authentication-Results-Header, den der empfangende Server hinzufügt. Fehler hier erklären oft, warum E-Mails im Spam landen. Die Analyzer parsen diese Ergebnisse, aber zu verstehen, was sie bedeuten, erfordert Wissen darüber, wie E-Mail-Authentifizierung funktioniert.
Der Pfad zeigt, welche Server die E-Mail verarbeitet haben. Unerwartete Server im Pfad können auf Weiterleitung (die Authentifizierung aushebeln kann) oder Routing-Probleme hindeuten. Der Pfad sollte zu deiner E-Mail-Infrastruktur passen.
Spam-Scores, sofern vorhanden, zeigen, wie der empfangende Server die Nachricht bewertet hat. Einige Server fügen X-Spam-Score oder ähnliche Header hinzu. Hohe Scores deuten auf Inhalts- oder Reputationsprobleme hin.
Return-Path und Envelope-Informationen zeigen den technischen Absender, der sich vom sichtbaren From unterscheiden kann. Abweichungen hier können auf Weiterleitung oder potenzielles Spoofing hinweisen.
Wenn Header nicht ausreichen
Header sagen dir, was passiert ist—nicht immer warum. Wenn eine E-Mail abgelehnt wurde, zeigen Header möglicherweise die Ablehnung, aber nicht den detaillierten Grund. Dafür brauchst du SMTP-Logs des sendenden Servers, die die tatsächlichen Fehlermeldungen erfassen, die während der Zustellung zurückgegeben wurden.
Header können auch nichts über E-Mails sagen, die nie gesendet wurden. Wenn dein System vor der Übergabe der E-Mail an den Mailserver scheitert, gibt es keine Header zu analysieren. Anwendungs-Logs sind das Debugging-Werkzeug für Fehler vor dem Senden.
Bei Zustellbarkeitsproblemen, die über einzelne E-Mails hinausgehen—Reputationsprobleme, Blacklisting, systematische Spam-Filterung—liefern Header Datenpunkte, aber kein vollständiges Bild. Tools zur Überwachung der Zustellbarkeit ergänzen die Header-Analyse bei breiteren Problemen.
Frequently asked questions
Warum zeigen Header mehrere Received-Einträge?
Jeder Server, der eine E-Mail verarbeitet, fügt seinen eigenen Received-Header hinzu. Die E-Mail kann über deinen Anwendungsserver, die Server deines ESP, Zwischen-Relays und die Mailserver des Empfängers laufen. Jeder Hop fügt einen Header hinzu und erzeugt so eine Spur der Reise der Nachricht.
Was bedeutet 'softfail' in SPF-Ergebnissen?
SPF softfail (~all in deinem SPF-Record) bedeutet, dass die sendende IP nicht autorisiert ist, du aber nicht sicher genug bist, eine Zurückweisung zu verlangen. Empfangende Server akzeptieren die E-Mail in der Regel, behandeln sie aber möglicherweise mit Skepsis. Es ist ein schwächeres Signal als hardfail (-all), das eine Zurückweisung anfordert.
Können Header gefälscht werden?
Von Servern, die du nicht kontrollierst, hinzugefügte Header sind vertrauenswürdig (sie werden von der empfangenden Infrastruktur hinzugefügt). Header, die bereits beim Versand vorhanden waren, können vom Absender potenziell gefälscht werden. Deshalb ist Authentifizierung (SPF, DKIM, DMARC) wichtig—sie liefert verifizierte Informationen, die nicht gefälscht werden können.
Wie finde ich Header für eine E-Mail, die nicht zugestellt wurde?
Wenn die E-Mail nie zugestellt wurde, hat der Empfänger keine Header, die er teilen könnte. Du musst die Logs deines sendenden Servers für die SMTP-Transaktion prüfen; sie zeigen etwaige Fehlermeldungen des empfangenden Servers. Die Logs des sendenden Servers sind deine Debugging-Ressource für fehlgeschlagene Zustellungen.