E-Mail-Header-Analysator

Was der E-Mail-Header verrät

Der E-Mail-Header ist der Kopf einer Nachricht: eine Folge von Feldern im Format Name: Wert, die vor dem eigentlichen Text steht und bis zur ersten Leerzeile reicht (RFC 5322). Mailprogramme zeigen davon nur wenige Felder an, etwa Absender, Betreff und Datum. Im vollständigen Header stehen zusätzlich der Weg der Mail über alle beteiligten Server, die Ergebnisse von SPF, DKIM und DMARC und oft die Bewertung des Spamfilters. Damit klären Sie drei typische Fragen aus dem Admin-Alltag: Ist die Mail echt, wo hat sie sich verzögert, und warum landete sie im Spam-Ordner?

Das Tool oben entfaltet umbrochene Zeilen, dekodiert Betreffzeilen mit Umlauten und ordnet die Felder für Sie. Es arbeitet nur mit dem eingefügten Text und fragt kein DNS ab. Ob ein SPF-Record oder DKIM-Schlüssel heute noch so veröffentlicht ist, sehen Sie damit nicht, wohl aber, was der empfangende Server bei der Zustellung festgestellt hat.

Header kopieren: so geht es in gängigen Programmen

Kopieren Sie den Header immer aus der Originalnachricht im Postfach des Empfängers. Eine weitergeleitete Mail trägt einen neuen Header, der über die ursprüngliche Zustellung nichts mehr aussagt. Lassen Sie sich die verdächtige Nachricht deshalb bei Bedarf als Anlage weiterleiten, nicht als normale Weiterleitung.

Auf dem Smartphone bieten viele Mail-Apps keine Header-Ansicht. Öffnen Sie die Nachricht dann in der Webversion des Postfachs oder am Rechner. Sie dürfen auch die komplette Quelltext-Mail einfügen; das Tool schneidet den Text ab der ersten Leerzeile ab und wertet nur den Header aus.

Die Received-Kette von unten nach oben lesen

Jeder Mailserver, der eine Nachricht annimmt, setzt eine eigene Received-Zeile oben auf den Header (RFC 5321, Abschnitt 4.4). Der unterste Eintrag stammt deshalb vom ersten Server, der oberste von Ihrem eigenen Empfangsserver. Wer den Weg der Mail verfolgen will, liest die Kette von unten nach oben. Das Tool zeigt sie bereits in dieser Reihenfolge: Hop 1 ist der unterste Eintrag.

Eine typische Zeile enthält diese Teile:

• from: der Name, mit dem sich der einliefernde Server gemeldet hat, und in Klammern meist dessen Reverse-DNS-Name und IP-Adresse,
• by: der Server, der die Mail angenommen und die Zeile geschrieben hat,
• with: das Protokoll, zum Beispiel ESMTP, ESMTPS (mit TLS), ESMTPSA (mit TLS und Anmeldung) oder LMTP für die Übergabe ans Postfach (RFC 3848),
• id und for: die Warteschlangen-ID des Servers und der Empfänger,
• nach dem letzten Semikolon der Zeitstempel der Annahme.

Vertrauen können Sie nur den Zeilen, die Ihre eigenen Server und Ihr Provider geschrieben haben. Alles darunter kann der Absender frei erfinden. Die wichtigste IP-Adresse ist deshalb die im obersten from-Teil, den Ihr Server selbst vermerkt hat: Das ist der Rechner, der die Mail tatsächlich bei Ihnen eingeliefert hat. Private Adressen wie 10.0.0.0/8 oder 192.168.0.0/16 und Loopback-Adressen kennzeichnet das Tool, weil sie nur interne Stationen beschreiben.

Authentication-Results: SPF, DKIM, DMARC und ARC

Das Feld Authentication-Results (RFC 8601) fasst zusammen, was der empfangende Server geprüft hat. Es beginnt mit der Kennung dieses Servers, danach folgen die Methoden mit ihrem Ergebnis, etwa spf=pass, dkim=pass header.d=example.com und dmarc=pass header.from=example.com.

• SPF (RFC 7208) prüft, ob die einliefernde IP für die Domain des Umschlag-Absenders (smtp.mailfrom, sichtbar als Return-Path) zugelassen ist. Ergänzend schreiben manche Server ein Feld Received-SPF.
• DKIM (RFC 6376) prüft die Signatur im Feld DKIM-Signature. Wichtig sind dort die Tags d= (signierende Domain), s= (Selektor), a= (Algorithmus), h= (signierte Felder) sowie t= und x= (Zeitpunkt und Ablauf).
• DMARC (RFC 7489) ist bestanden, wenn SPF oder DKIM erfolgreich ist und die geprüfte Domain zur sichtbaren From-Domain passt. Bei der üblichen entspannten Ausrichtung genügt dieselbe Organisationsdomain, also zum Beispiel mail.example.com zu example.com.
• ARC (RFC 8617) bewahrt Prüfergebnisse über Weiterleitungen und Mailinglisten hinweg. Jede Station versiegelt ihre Ergebnisse in ARC-Seal, ARC-Message-Signature und ARC-Authentication-Results.

Maßgeblich ist der oberste Authentication-Results-Eintrag mit der Kennung Ihres eigenen Servers. Ein Eintrag weiter unten kann vom Absender stammen und beweist nichts. Microsoft 365 ergänzt zusätzlich compauth, eine eigene zusammengesetzte Bewertung.

Phishing-Merkmale im Header

Kein einzelnes Feld beweist eine Fälschung, aber mehrere Auffälligkeiten zusammen sind ein deutliches Signal. Achten Sie besonders auf:

• dmarc=fail oder fehlende DMARC-Prüfung bei einer Domain, die eigentlich DMARC einsetzt,
• einen Reply-To mit fremder Domain: Antworten landen dann beim Angreifer, typisch bei gefälschten Zahlungsaufforderungen,
• einen Anzeigenamen, der selbst eine E-Mail-Adresse enthält, etwa "chef@example.com" <x@example.org>,
• eine DKIM-Signatur, deren d= nicht zur From-Domain passt, und eine Return-Path-Domain ohne Bezug zum Absender,
• ein Datum in der Zukunft oder weit vor dem ersten Received-Eintrag sowie eine fehlende Message-ID.

Newsletter- und Ticketsysteme versenden oft mit eigenem Return-Path. Das ist harmlos, solange DKIM für die From-Domain signiert und DMARC besteht. Wie Sie Ihr Team auf solche Mails vorbereiten, beschreibt Phishing erkennen und melden: Kurzleitfaden fürs Team.

Zustellverzögerungen finden

Die Verzögerung eines Hops ist der Abstand zwischen seinem Zeitstempel und dem des vorigen Hops. Sie zeigt, wie lange die Mail beim vorigen Server lag. Das Tool rechnet alle Zeitzonen auf UTC um und markiert Pausen über fünf Minuten. Häufige Ursachen sind:

• Greylisting: Der Empfänger lehnt den ersten Versuch vorübergehend ab, der Absender stellt nach einigen Minuten erneut zu.
• Warteschlange: Der Zielserver war nicht erreichbar oder hat mit einem 4xx-Fehler geantwortet.
• Inhaltsprüfung: Spam- und Virenfilter oder Sandboxen für Anhänge halten die Mail kurz zurück.
• Uhren: Läuft ein Server nicht per NTP synchron, entstehen scheinbare Pausen oder Zeitsprünge zurück.

Liegt die Pause auf einem fremden Server, können Sie selbst wenig ausrichten. Liegt sie bei Ihnen, helfen die Warteschlangen-ID aus dem id-Teil und das Mail-Log des betreffenden Servers weiter.

Spam-Bewertungen lesen

Felder wie X-Gm-Message-State von Google sind nicht öffentlich dokumentiert und lassen sich nicht sinnvoll auswerten. Wie Sie die Filter in Microsoft 365 selbst einstellen, zeigt Microsoft Defender for Office 365: Phishing-Schutz einrichten.

Häufige Fragen

Ist es unbedenklich, einen E-Mail-Header in ein Online-Tool einzufügen?

Ein Header enthält Namen, Adressen und interne Servernamen. Dieses Tool verarbeitet ihn vollständig in Ihrem Browser, sendet nichts an einen Server und speichert nichts. Sie können das im Netzwerk-Tab der Entwicklerwerkzeuge prüfen. Für Tickets empfiehlt sich der kurze Textbericht statt des kompletten Headers.

Warum fehlt bei mir das Feld Authentication-Results?

Nicht jeder Mailserver schreibt es, und manche Programme zeigen nur einen Teil des Headers. Kopieren Sie den Header über die Quelltext-Ansicht. Fehlt das Feld dort ebenfalls, prüft Ihr Empfangsserver SPF, DKIM und DMARC vermutlich nicht oder vermerkt das Ergebnis nicht.

SPF ist fehlgeschlagen, DMARC aber bestanden. Wie passt das zusammen?

DMARC verlangt nur, dass SPF oder DKIM besteht und zur From-Domain passt. Nach einer Weiterleitung scheitert SPF oft, weil der weiterleitende Server nicht im SPF-Record steht. Eine unveränderte DKIM-Signatur trägt das DMARC-Ergebnis dann allein.

Kann ich aus dem Header den echten Absender ermitteln?

Sie sehen die IP-Adresse, die bei Ihrem Server eingeliefert hat, und die Domain, für die DKIM signiert wurde. Bei Mails über große Anbieter ist das der Server des Anbieters, nicht der Rechner der Person. Für eine Zuordnung zu einer Person brauchen Sie die Logs des Anbieters.

Was bedeuten SCL und BCL bei Microsoft 365?

SCL ist die Spam-Einstufung von Exchange Online. Werte von 0 und 1 gelten als kein Spam, ab 5 als Spam, und der Wert -1 bedeutet, dass der Filter übersprungen wurde. BCL bewertet Massenmails von 0 bis 9; je höher der Wert, desto mehr Beschwerden gibt es über den Absender.

Warum liegen zwischen zwei Received-Einträgen mehrere Minuten?

Häufige Gründe sind Greylisting beim Empfänger, eine Warteschlange nach einem vorübergehenden Fehler, Spam- und Virenprüfungen oder Server, deren Uhr nicht per NTP synchron läuft. In dieser Zeit lag die Mail in der Regel beim Server des vorigen Hops.