Ein Support-Ingenieur verbrachte zwei Tage damit herauszufinden, warum E-Mails eines bestimmten Kunden 6 Stunden verspätet ankamen. Der Kunde beteuerte, er habe sie sofort gesendet. Der Empfänger beteuerte, sie seien erst Stunden später angekommen. Jeder gab dem E-Mail-System der jeweils anderen Seite die Schuld.
Die Antwort steckte in den Headern. Beim Lesen der Received-Header zeigte sich, dass die Nachricht 5 Stunden und 47 Minuten in der Warteschlange eines zwischengeschalteten Relay-Servers lag. Das Relay war ein Legacy-System, dessen Existenz der Kunde vergessen hatte, falsch konfiguriert und unter Last überfordert. Zehn Minuten Header-Analyse lösten ein zweitägiges Rätsel.
E-Mail-Header sind der Flugschreiber jeder Nachricht. Sie dokumentieren die komplette Reise vom Absender zum Empfänger, jeden berührten Server, jede durchgeführte Prüfung. Sie lesen zu lernen ist eine der wertvollsten Debugging-Fähigkeiten im E-Mail-Bereich.
Die Struktur von E-Mail-Headern
E-Mail-Header stehen am Anfang jeder Nachricht, vor dem Nachrichtentext. Es handelt sich um eine Reihe von Feld-Wert-Paaren, jeweils in einer eigenen Zeile, nach einem einfachen Format: "Feldname: Feldwert".
Header erfüllen mehrere Zwecke. Einige identifizieren die Nachricht: From, To, Subject, Date, Message-ID. Einige zeichnen den Zustellpfad auf: Received-Header von jedem Server. Einige dokumentieren Sicherheitsprüfungen: Authentication-Results, DKIM-Signature. Einige steuern das Verhalten: Reply-To, List-Unsubscribe.
Die Reihenfolge der Header ist für manche Zwecke wichtig. Received-Header werden in umgekehrter chronologischer Reihenfolge hinzugefügt — die aktuellsten oben, die ersten ganz unten. Liest man sie von unten nach oben, folgt man der Reise der Nachricht vorwärts durch die Zeit.
Die meisten E-Mail-Clients blenden Header standardmäßig aus und zeigen nur From, To, Subject und Date. Um alle Header zu sehen, müssen Sie je nach E-Mail-Client Optionen wie "view source", "show original" oder Ähnliches öffnen.
Received-Header: die Zustellspur
Jeder Mailserver, der eine Nachricht verarbeitet, fügt einen Received-Header hinzu, der seine Beteiligung dokumentiert. Diese Header erzeugen eine Audit-Spur des vollständigen Pfads der Nachricht.
Ein typischer Received-Header enthält mehrere Informationen: den Server, der die Nachricht empfangen hat (der den Header hinzufügt), den Server, von dem sie empfangen wurde, das verwendete Protokoll (SMTP, ESMTP, etc.) und einen Zeitstempel.
Von unten nach oben gelesen können Sie die Reise der Nachricht nachvollziehen. Der unterste Received-Header zeigt den ersten Server, der die Nachricht nach dem Verlassen des Mail-Clients des Absenders verarbeitet hat. Jeder nachfolgende Header zeigt den nächsten Hop. Der oberste Received-Header zeigt die endgültige Zustellung in das Postfach des Empfängers.
Zeitstempel in Received-Headern helfen, Verzögerungen zu identifizieren. Wenn zwischen zwei aufeinanderfolgenden Headern eine Lücke von 3 Stunden besteht, lag die Nachricht 3 Stunden auf diesem Server. Das zeigt genau, wo Verzögerungen auftreten.
Die Felder "from" und "by" identifizieren Server. "From" zeigt, woher die Nachricht kam; "by" zeigt den Server, der den Header hinzufügt. Unstimmigkeiten oder verdächtige Einträge können auf Weiterleitungen, Relaying oder potenzielles Spoofing hinweisen.
Authentifizierungs-Header
Moderne E-Mails enthalten Header, die Authentifizierungsprüfungen dokumentieren. Sie zeigen, ob SPF, DKIM und DMARC bestanden oder fehlgeschlagen haben.
Der Authentication-Results-Header wird von empfangenden Servern nach der Durchführung der Authentifizierungsprüfungen hinzugefügt. Er fasst die Ergebnisse in einem strukturierten Format zusammen: welche Checks durchgeführt wurden, ob sie bestanden oder fehlgeschlagen sind und relevante Details wie welche Domain geprüft wurde oder welcher Schlüssel verwendet wurde.
Ein positives Authentifizierungsergebnis kann SPF pass mit verifizierter IP-Adresse, DKIM pass mit der signierenden Domain und DMARC pass mit angewendeter Policy zeigen. Fehler enthalten Gründe, die erklären, was schiefgelaufen ist.
Der DKIM-Signature-Header enthält die tatsächliche kryptografische Signatur, die vom sendenden Server hinzugefügt wurde. Er gibt den Signaturalgorithmus an, die verantwortliche Domain, den Selector für den Schlüssellookup, welche Header signiert sind, und die Signatur selbst.
Beim Debuggen von Authentifizierungsfehlern zeigen diese Header genau, was passiert ist. "DKIM signature verification failed" in Authentication-Results, kombiniert mit der Prüfung des DKIM-Signature-Headers, zeigt oft, ob die Signatur fehlerhaft war, der Schlüssel fehlte oder die Nachricht unterwegs verändert wurde.
Den tatsächlichen Absender identifizieren
Mehrere Header beziehen sich auf die Absenderidentität, und ihre Unterschiede zu verstehen ist für Debugging und Sicherheit wichtig.
Der From-Header ist das, was Empfänger sehen — die Anzeigeadresse in ihrem E-Mail-Client. Er ist leicht zu fälschen; jeder kann beliebige Adressen in den From-Header schreiben.
Der Return-Path (oder Envelope-From) ist die Adresse, an die Bounces gesendet werden. Diese wird während der SMTP-Transaktion gesetzt, nicht in den Nachrichten-Headern, wird aber häufig von empfangenden Servern in den Headern protokolliert. SPF prüft diese Adresse, nicht die From-Adresse.
Der Sender-Header zeigt, wenn vorhanden, wer die Nachricht tatsächlich im Namen der From-Adresse gesendet hat. Er wird verwendet, wenn jemand für eine andere Person E-Mails versendet, etwa eine Assistenz im Namen einer Führungskraft.
Reply-To gibt an, wohin Antworten gehen sollen, was von From abweichen kann. Legitime Verwendungen sind z. B. der Versand von einer no-reply-Adresse, während Antworten in ein überwachtes Postfach gehen. Illegitime Verwendungen sind Phishing-E-Mails, die eine vertrauenswürdige From-Adresse anzeigen, aber Antworten woanders abfangen.
Für die Sicherheitsanalyse sollten Sie diese Header vergleichen. Abweichungen sind nicht immer böswillig — es gibt legitime Gründe dafür — aber sie verdienen Aufmerksamkeit.
Zeitstempel und Verzögerungen
Jeder Received-Header enthält einen Zeitstempel. Der Vergleich dieser Zeitstempel zeigt, wo Nachrichten Zeit verbracht haben.
Der Date-Header zeigt, wann die Nachricht verfasst wurde (gemäß der Uhr des Absenders). Der Zeitstempel des ersten Received-Headers zeigt, wann sie in das Mailsystem eingetreten ist. Weitere Zeitstempel zeigen jeden Hop. Der letzte Zeitstempel zeigt die Zustellung.
Große Lücken zwischen aufeinanderfolgenden Received-Headern deuten auf Queuing hin. Die Nachricht ist auf einem Server angekommen, wurde aber nicht sofort weitergeleitet. Das kann beabsichtigt sein (Greylisting verzögert neue Absender) oder problematisch (überlasteter Server, Netzwerkprobleme).
Zeitzonenunterschiede können die Analyse von Zeitstempeln verwirren. Header können Zeiten in unterschiedlichen Zonen anzeigen. Konvertieren Sie alles in eine einzige Zeitzone (UTC ist üblich), bevor Sie Intervalle berechnen.
Uhrzeitabweichungen zwischen Servern können scheinbare Anomalien erzeugen — eine Nachricht scheint anzukommen, bevor sie gesendet wurde. Kleine Abweichungen (Sekunden bis Minuten) sind normal. Große Abweichungen deuten auf falsch konfigurierte Serveruhren hin.
Spam- und Filter-Header
Viele Mailserver fügen Header hinzu, die ihre Spam-Bewertung anzeigen. Diese sind nicht standardisiert, folgen aber gängigen Mustern.
X-Spam-Status zeigt typischerweise, ob die Nachricht als Spam eingestuft wurde und welchen Score sie bekommen hat. X-Spam-Score zeigt nur den numerischen Score. X-Spam-Flag ist ein einfacher Ja/Nein-Indikator.
SpamAssassin, ein verbreiteter Spamfilter, fügt detaillierte Header hinzu, die zeigen, welche Regeln ausgelöst wurden und welche Punktwerte sie haben. Diese Aufschlüsselung ist unschätzbar, um zu verstehen, warum eine Nachricht gefiltert wurde. "MISSING_SUBJECT: 2.5 points" sagt Ihnen genau, was zu beheben ist.
Manche Server fügen Header hinzu, die anzeigen, welche Blacklists geprüft wurden und ob der Absender darauf erschien. Das hilft bei der Diagnose blacklist-bedingter Zustellprobleme.
Provider-spezifische Header variieren. Gmail fügt Header hinzu, die mit ihrem Kategorisierungssystem zusammenhängen. Microsoft fügt Header zu ihren Filterentscheidungen hinzu. Diese wiederzuerkennen hilft bei der Fehlersuche für bestimmte Provider.
Praktische Header-Analyse
Bei der Fehlersuche rund um E-Mails hilft ein systematischer Ansatz für die Header-Analyse.
Beginnen Sie mit dem Authentication-Results-Header. Haben SPF, DKIM und DMARC bestanden? Wenn nicht, haben Sie Ihren Fehler wahrscheinlich gefunden. Die Details erklären, was und warum etwas fehlgeschlagen ist.
Verfolgen Sie als Nächstes die Received-Header von unten nach oben. Ergibt der Pfad Sinn? Gibt es unerwartete Server? Gibt es lange Verzögerungen zwischen Hops? Auffälligkeiten hier erklären oft Zustellprobleme.
Prüfen Sie auf spambezogene Header. Wurde die Nachricht als Spam bewertet? Welche Regeln wurden ausgelöst? Das zeigt, was dem empfangenden Server an der Nachricht nicht gefallen hat.
Überprüfen Sie, ob die Absender-Header konsistent sind. Stimmt die From-Domain mit der Return-Path-Domain überein (für DMARC-Alignment)? Zeigt Reply-To auf etwas Unerwartetes? Inkonsistenzen können Filterung erklären oder auf Spoofing hinweisen.
Schauen Sie sich die Zeitstempel an. Wann wurde die Nachricht gesendet? Wann wurde sie zugestellt? Wo hat sie Zeit verbracht? Verzögerungen werden in der Zeitstempelspur sichtbar.
Werkzeuge für die Header-Analyse
Sie können Header zwar manuell lesen, doch Tools machen die Analyse schneller und finden Dinge, die Ihnen entgehen könnten.
Googles Message Header Analyzer (in der Google Admin Toolbox) parst Header und stellt sie in einem lesbaren Format dar, hebt Verzögerungen und Authentifizierungsergebnisse hervor.
Der Header Analyzer von MXToolbox parst und formatiert Header ebenfalls und liefert zusätzlichen Kontext dazu, was jedes Feld bedeutet.
Die integrierten Tools von E-Mail-Clients sind unterschiedlich gut. Manche zeigen nur rohe Header; andere bieten eine Basisanalyse. Für ernsthafte Fehlersuche lohnen sich dedizierte Analysetools.
Für die programmatische Analyse gibt es in den meisten Sprachen Bibliotheken zum Parsen von E-Mail-Headern. So können Sie automatisiertes Monitoring und Alerting auf Basis von Header-Inhalten umsetzen.
Frequently asked questions
Können E-Mail-Header gefälscht werden?
Header, die vom Absender hinzugefügt werden (From, Subject, etc.), können gefälscht werden. Header, die von empfangenden Servern hinzugefügt werden (Received, Authentication-Results), sind vertrauenswürdig, weil sie erst nach dem Eintreffen der Nachricht hinzugefügt werden. Deshalb sind Authentifizierungsergebnisse des empfangenden Servers wichtig.
Warum sehe ich mehrere Received-Header?
Jeder Server, der die Nachricht verarbeitet, fügt seinen eigenen Received-Header hinzu. Eine Nachricht, die über 5 Server läuft, hat 5 Received-Header. Das ist normal und erzeugt die Audit-Spur, die Debugging möglich macht.
Wie sehe ich Header in Gmail?
Öffnen Sie die Nachricht, klicken Sie auf das Drei-Punkte-Menü oben rechts und wählen Sie 'Show original'. Dadurch wird der vollständige Nachrichtenquelltext inklusive aller Header angezeigt.
Was bedeutet 'with ESMTPS' in Received-Headern?
Es zeigt an, dass die Nachricht per SMTP mit TLS-Verschlüsselung übertragen wurde (das S steht für Secure). 'ESMTP' ohne S bedeutet unverschlüsselte Übertragung. Moderne E-Mail sollte verschlüsselte Transfers zwischen Servern zeigen.