E-Mail-Header-Analyzer

Jeder Received-Header protokolliert einen Hop, die Übergabe von einem Mailserver an den nächsten. Lesen Sie sie von unten nach oben: Der unterste ist der erste Server, der die Nachricht berührt hat, der oberste ist der Server, der sie Ihnen übergeben hat. Die Zeile hält fest, welcher Host sie gesendet hat (from), welcher Host sie empfangen hat (by), welches Protokoll verwendet wurde (with), und einen Zeitstempel. Eine große Lücke zwischen zwei Zeitstempeln deutet auf eine Warteschlangen-Verzögerung an diesem Hop hin.

Der empfangende Server schreibt diesen Header, um festzuhalten, was seine eigenen Prüfungen ergeben haben. Er beginnt mit einer authserv-id (dem Namen des Servers, etwa mx.google.com) und listet dann jede Methode mit ihrem Ergebnis: spf=pass, dkim=pass, dmarc=pass. Jedes Ergebnis nennt die geprüfte Identität, geschrieben als ptype.property: smtp.mailfrom für SPF, header.d für die signierende DKIM-Domain, header.from für DMARC. Das ist der einzige Ort, an dem das SPF-, DKIM- und DMARC-Ergebnis tatsächlich steht. Der Analyzer zitiert es. Er führt die Prüfungen nicht erneut aus.

Der Absender fügt diesen Header hinzu und signiert einen Teil der Nachricht mit einem privaten Schlüssel. Der Empfänger verifiziert ihn gegen einen öffentlichen Schlüssel, der im DNS hinterlegt ist. Die maßgeblichen Tags: d= ist die signierende Domain, s= ist der Selektor (der öffentliche Schlüssel liegt damit unter s._domainkey.d), h= listet, welche Header die Signatur abdeckt, bh= ist der Hash des Texts und b= ist die Signatur selbst. Der Analyzer zeigt Ihnen die Tags. Die Signatur zu verifizieren erfordert eine DNS-Abfrage, die er nicht durchführt.

Ein lesbarer Vermerk, den manche Empfänger neben das SPF-Ergebnis setzen und der die verbindende IP (client-ip=) und den Envelope-Absender nennt, gegen den geprüft wurde. Behandeln Sie den spf=-Wert innerhalb von Authentication-Results als das maßgebliche Ergebnis. Received-SPF ist eine Komfort-Kopie.

Die Authenticated Received Chain (ARC) erlaubt es einem Weiterleiter, das gesehene Authentifizierungsergebnis festzuhalten, sodass ein späterer Empfänger Post noch vertrauen kann, deren SPF oder DKIM unterwegs zerbrochen ist. Jedes Glied trägt eine Instanznummer i= (1 für den ersten Hop, aufsteigend). Der ARC-Seal meldet einen Ketten-Gültigkeitswert cv=: none bedeutet, dies ist das erste Glied, pass bedeutet, die Kette hat bis hierher validiert, fail bedeutet, sie hat es nicht. Der Analyzer meldet das cv=, das jeder Seal angibt. Er validiert die Seals nicht selbst. Mehr zum DMARC-Alignment.

Vier Adressen, die in der Regel übereinstimmen. From ist der Absender, den die Nachricht angibt, und die Identität, die DMARC beurteilt. Return-Path ist der Envelope-Absender, wohin Bounces gehen, und die Identität, die SPF beurteilt. Reply-To ist die Adresse, an die eine Antwort geht. Sender nennt, wer die Nachricht tatsächlich eingeliefert hat, wenn das von From abweicht. Zeigen diese Adressen auf zusammenhanglose Domains, kann das ein Zeichen für Spoofing sein. Die Phishing-Triage-Karte oben vergleicht sie für Sie. Mehr zum DMARC-Alignment.

Eine weltweit eindeutige Kennung, die der sendende Server der Nachricht aufprägt. Ihr Domain-Teil passt in der Regel zum sendenden System, was eine schnelle Plausibilitätsprüfung ist, und es ist der Wert, nach dem Support-Teams fragen, um eine einzelne Nachricht durch die Protokolle zu verfolgen.

Der Zeitpunkt, zu dem die Nachricht verfasst wurde, wie ihn das System des Absenders gemeldet hat. Vergleichen Sie ihn mit den Zeitstempeln in den Received-Headern. Ein Date weit entfernt von der Zeit des ersten Hops kann auf eine falsch eingestellte Uhr oder eine wiederholte Nachricht hindeuten.

Microsoft 365 prägt diese Header eingehender Post auf, um festzuhalten, was sein Filter beobachtet hat: die verbindende IP und das Land, die Spam- und Bulk-Confidence-Level, das Filterergebnis und etwaige Sicherheitshinweise. Sie sind das Erste, was Sie lesen sollten, wenn legitime Post bei Microsoft 365 im Junk-Ordner landet. Die Codes werden im nächsten Abschnitt und in der Microsoft-365-Karte oben entschlüsselt.

Lädt dieses Tool meine Header hoch?

Nein. Der Analyzer lädt Ihre Header nicht hoch, das Parsen läuft vollständig in Ihrem Browser. Öffnen Sie die DevTools und beobachten Sie den Netzwerk-Tab, während Sie auf Analysieren klicken: Keine Anfrage enthält Ihren Header-Text. Die Seite selbst lädt die üblichen Site-Skripte (Analytics, Chat), bevor Sie etwas einfügen; diese Skripte sehen den Inhalt Ihrer Header nie.

Werden SPF, DKIM, DMARC und ARC unabhängig verifiziert?

Nein. Das Tool gibt wieder, was laut Authentication-Results-Header der empfangende Server verifiziert hat. Um eine DKIM-Signatur neu zu prüfen oder eine veröffentlichte DMARC-Richtlinie nachzuschlagen, wären DNS-Abfragen nötig, und damit wäre die Datenschutzzusage hinfällig. Jedes Ergebnis trägt seine Herkunft: laut Authentication-Results, Signatur vorhanden (nicht verifiziert) oder unbekannt.

Wie zeige ich Header in Gmail an?

Öffnen Sie die Nachricht, klicken Sie oben rechts auf das Drei-Punkte-Menü und wählen Sie Original anzeigen. Gmail öffnet einen neuen Tab mit der vollständigen Quelle. Kopieren Sie alles oberhalb der ersten Leerzeile, oder klicken Sie auf Original herunterladen, um die .eml-Datei zu speichern.

Wie zeige ich Header in Outlook an?

Outlook im Web: Nachricht öffnen, auf das Drei-Punkte-Menü klicken, Anzeigen wählen und dann Nachrichtenquelle anzeigen. Klassisches Outlook für Windows: Nachricht in einem eigenen Fenster öffnen, Datei > Eigenschaften wählen und das Feld Internetkopfzeilen kopieren. Neues Outlook und Outlook für Mac: Nachricht öffnen, auf das Drei-Punkte-Menü klicken und Quelle anzeigen wählen.

Wie zeige ich Header in Apple Mail an?

Öffnen Sie die Nachricht und wählen Sie in der Menüleiste Darstellung > E-Mail > Alle Header (oder drücken Sie Umschalt+Cmd+H). Die vollständigen Header erscheinen über dem Nachrichtentext.

Wie zeige ich Header in Thunderbird an?

Öffnen Sie die Nachricht und wählen Sie in der Menüleiste Ansicht > Kopfzeilen > Alle. Sie können die Nachricht auch über Datei > Speichern unter als .eml speichern und die Datei auf den Analyzer ziehen.

Was bedeutet X-Forefront-Antispam-Report?

Das ist ein Header von Microsoft 365, der festhält, was der Filter beim Empfang beobachtet hat. Der Analyzer entschlüsselt die enthaltenen Codes: CIP (verbindende IP), CTRY (Land), SCL (Spam Confidence Level, -1 bis 9), BCL (Bulk Complaint Level 0-9), SFV (Ergebnis des Spam-Filters), SFTY (Phishing-Sicherheitshinweis), IPV (Status der IP-Zulassungsliste) und die Override-Flags SOR / SOT / SOI. Jede Zeile im M365-Abschnitt zeigt den Rohwert und erklärt ihn in verständlichem Deutsch.

Ist es sicher, einen sensiblen Produktions-Header einzufügen?

Das Parsen passiert lokal, der Analyzer versendet Ihren Header-Text also nicht. Verbietet Ihre Organisation, Produktionsdaten in fremde Webseiten einzufügen, halten Sie sich an diese Vorgabe. Sie ist die sicherere Regel, und die Datenschutzzusage lässt sich trotzdem überprüfen: DevTools öffnen und beim Klick auf Analysieren den Netzwerk-Tab beobachten.

Lässt sich am Header erkennen, ob eine E-Mail gefälscht ist?

Oft, aber nicht immer mit Sicherheit. Der Header zeigt Anzeichen, keinen Beweis. Das stärkste Signal ist ein DMARC-Fehlschlag im Authentication-Results-Header: Die From-Domain hat sich nicht authentifiziert. Die Phishing-Triage-Karte liefert weitere Hinweise: ein Anzeigename in From, der eine Marke nennt, zu der die Adresse nicht passt, oder ein Reply-To und ein Return-Path auf zusammenhanglosen Domains. Jeder einzelne dieser Hinweise verdient einen zweiten Blick. Keiner allein beweist, dass die Nachricht bösartig ist, und eine gut gebaute Phishing-Nachricht kann die einfachen Prüfungen trotzdem bestehen. Behandeln Sie den Header daher als einen Anhaltspunkt, nicht als endgültiges Ergebnis. DMARC besteht, aber das Spoofing geht weiter.

Warum zeigt meine legitime E-Mail DMARC=fail?

Fast immer wegen des Alignments, nicht weil die Nachricht gefälscht ist. DMARC besteht nur, wenn SPF oder DKIM eine Domain authentifiziert, die zur From-Domain passt. Wenn Sie über einen Drittanbieter versenden (eine Marketing-Plattform, ein Helpdesk, ein Lohnabrechnungs-Tool) und Ihre eigene Domain dort nicht eingerichtet haben, besteht SPF für die Domain des Anbieters und DKIM signiert mit der Domain des Anbieters, sodass keines mit Ihrem From übereinstimmt. Ein Weiterleiter bricht das Alignment auf dieselbe Weise. Lesen Sie hier den Authentication-Results-Header und die Phishing-Triage-Karte, um zu sehen, welche Identität sich nicht ausrichten ließ, und korrigieren Sie das anschließend im sendenden Dienst. Post des Anbieters scheitert an DMARC: Lösungen je Anbieter.

Bedeutet ein bestandenes DMARC, dass die E-Mail sicher ist?

Nein. Ein bestandenes DMARC sagt Ihnen eines: Die Nachricht stammt tatsächlich von der Domain in der From-Adresse und wurde nicht gefälscht. Es sagt nichts darüber aus, ob diese Domain vertrauenswürdig ist oder ob der Inhalt sicher ist. Ein Angreifer, der eine Domain kontrolliert oder eine ähnlich aussehende Domain registriert hat, kann Post versenden, die DMARC für diese Domain besteht. Die Authentifizierung beantwortet „Kommt das wirklich von dieser Domain?“, nicht „Sollte ich dieser Domain vertrauen?“. Nehmen Sie das bestandene Ergebnis als Ausgangspunkt und beurteilen Sie Absender und Inhalt anschließend für sich.