Wie man die Header einer E-Mail liest

Von Thomas · virtueller CISO · 22. August 2026

Eine Nachricht zeigt einen Absender, einen Betreff, ein Datum. All das ist Text, und all das lässt sich fälschen. Was sich nicht ebenso leicht fälschen lässt, steht anderswo: in den Dutzenden technischer Felder, die E-Mail-Programme standardmäßig verbergen und die der empfangende Server bei der Ankunft selbst geschrieben hat. Diese Felder — die Header — beantworten die beiden Fragen, die sich vor einer verdächtigen E-Mail stellen, oder vor einer legitimen, die im Spam-Ordner gelandet ist: woher kommt sie wirklich, und was ist unterwegs gescheitert.

Der vorliegende Leitfaden beschreibt die Anatomie dieser Header, die Reihenfolge, in der ihre Lektüre sich lohnt, und die Grenze — oft falsch gezogen — zwischen dem, was sie belegen, und dem, was sie lediglich behaupten.

Wo die Header zu finden sind

Jedes E-Mail-Programm vergräbt die Information an einer anderen Stelle, und das Vokabular schwankt stärker als die Sache selbst.

Gmail (Web): das Menü „⋮" einer geöffneten Nachricht, dann „Original anzeigen". Eine Seite öffnet sich mit den Headern oben und der Rohnachricht darunter.
Outlook (Desktop): „Datei" → „Eigenschaften", Feld „Internetkopfzeilen" am unteren Rand des Fensters. Der Bereich ist klein, sein Inhalt lässt sich vollständig kopieren.
Outlook.com / Microsoft 365 (Web): das Menü „⋯" → „Anzeigen" → „Nachrichtenquelle anzeigen".
Apple Mail: „Darstellung" → „E-Mail" → „Alle Header".
Thunderbird: „Ansicht" → „Nachrichten-Quelltext", oder Strg+U.

Ein Punkt gehört vor jede Lektüre gesagt: Header überstehen keine Weiterleitung. Eine verdächtige Nachricht an eine Kollegin weiterzuleiten erzeugt eine neue Nachricht mit neuen Headern — denen der weiterleitenden Person. Das Original wird zum Anhang oder zu zitiertem Text, und seine Authentifizierung ist nicht mehr lesbar. Deshalb verlangen Sicherheitsteams die Übermittlung „als Anhang" (.eml) statt einer einfachen Weiterleitung.

Die Lesereihenfolge: drei Blöcke, nicht vierzig Felder

Eine gewöhnliche Nachricht trägt zwischen dreißig und hundert Header. Nahezu keiner davon lehrt etwas: interne Kennungen, herstellereigene Antispam-Fingerabdrücke, Warteschlangenmarker. Drei Blöcke bündeln den Wert.

Der erste ist der der Identitäten. From: ist die angezeigte Adresse, die der Empfänger liest und die einzige, die DMARC schützt. Return-Path: trägt die Envelope-Adresse, an die Unzustellbarkeitsmeldungen gehen — häufig eine andere, und dieser Unterschied ist normal, sobald ein Drittanbieter versendet. Reply-To: sagt, sofern vorhanden, wohin eine Antwort geht: eine Lücke zwischen From: und Reply-To: ist ein Klassiker des Chefbetrugs.

Der zweite ist der der Urteile: Authentication-Results und die begleitenden Signatur-Header.

Der dritte ist der des Wegs: der Stapel der Received:-Felder.

`Authentication-Results`: das Urteil und seine Falle

Das ist der entscheidende Header, normiert in RFC 8601. Der Server, der die Nachricht annimmt, verzeichnet darin das Ergebnis der soeben durchgeführten Prüfungen:

Authentication-Results: mx.beispiel.de;
       dkim=pass header.d=beispiel.de header.s=s2026;
       spf=pass smtp.mailfrom=bounces.versender.example;
       dmarc=pass header.from=beispiel.de

Drei Methoden, drei Ergebnisse, und an jedes geknüpfte Eigenschaften. header.d= nennt die Domain, die mit DKIM signiert hat; header.s= gibt den Selektor, der auf den öffentlichen Schlüssel zeigt; smtp.mailfrom= gibt die von SPF geprüfte Envelope-Domain.

Und hier liegt die Falle, die den meisten Lektüren entgeht: dieser Header lässt sich frei schreiben. Nichts hindert einen Angreifer daran, in die von ihm versandte Nachricht eine Zeile Authentication-Results einzufügen, die dkim=pass für die nachgeahmte Bank verkündet. Nur der vom empfangenden Server des Adressaten gesetzte Header hat Gewicht — der Rest ist vom Absender geliefertes Textmaterial.

Zwei Anhaltspunkte entscheiden. Zunächst das erste Segment, die authserv-id: sie nennt den Server, der die Prüfung durchgeführt haben will, und sie muss zur tatsächlichen Empfangsdomain passen. Dann die Reihenfolge: jedes Relais stellt seinen Header voran, der oberste in der Nachricht ist also der jüngste, der der letzten Grenze. Eine Nachricht mit drei Authentication-Results hat drei Grenzen passiert — oder transportiert zwei, die anderswo geschrieben wurden.

Die Ausrichtung, der Schritt, den das Urteil nicht zeigt

Ein isoliertes spf=pass sagt fast nichts. SPF prüft die Envelope-Domain, nicht die vom Empfänger gesehene. Geht ein Newsletter über einen Drittanbieter hinaus, gehört der Envelope diesem Anbieter, und SPF besteht zu Recht — ohne die in From: angezeigte Domain abzudecken. DMARC verlangt mehr: dass die bestehende Methode auf die From:-Domain ausgerichtet ist.

Die Lektüre besteht also im Vergleich zweier Zeichenketten. Deckt die Domain aus header.d= die aus From: ab? Deckt die Domain aus smtp.mailfrom= sie ab? Es genügt, dass eine der beiden mit Ja antwortet, damit DMARC erfüllt ist. Im obigen Beispiel besteht SPF ohne Ausrichtung, DKIM besteht mit Ausrichtung, und die Nachricht ist damit konform. Dieser Fall — ein gültiges SPF, das DMARC dennoch scheitern lässt — ist das häufigste Missverständnis des Protokolls, und in den Headern ist er in drei Sekunden erkennbar.

`DKIM-Signature`: was die Signatur abdeckt

Der Signatur-Header reist in der ursprünglichen Nachricht mit, unabhängig von jedem Urteil:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=beispiel.de; s=s2026; h=from:to:subject:date;
        bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=Xk9dQ2mF...

d= und s= bezeichnen den im DNS abzufragenden öffentlichen Schlüssel. h= listet die von der Signatur abgedeckten Felder auf — und diese Liste verdient Aufmerksamkeit, denn was dort fehlt, lässt sich ändern, ohne die Signatur ungültig zu machen. bh= ist der Hash des Nachrichtentexts, b= die Signatur selbst.

Daraus folgt ein praktischer Punkt: das Vorhandensein eines DKIM-Signature beweist für sich genommen nichts. Eine Signatur zu prüfen heißt, diese Hashes neu zu berechnen, wozu der vollständige Nachrichtentext und eine DNS-Abfrage nötig sind. Das ist Aufgabe des empfangenden Servers, und das Vorgehen zur eigenhändigen Prüfung einer DKIM-Signatur führt es aus. Eine Header-Lektüre stellt nur fest, dass die Signatur existiert, welche Domain sie beansprucht und was der Server daraus geschlossen hat.

`Received:`: der Weg, rückwärts gelesen

Jeder Server, der die Nachricht übernimmt, stellt dem Stapel ein Received:-Feld voran. Die Folge ist widersinnig: das erste Received: der Nachricht ist der letzte Schritt in der Zeit, und der Weg liest sich von unten nach oben.

Received: from relais.beispiel.de (relais.beispiel.de [198.51.100.24])
        by mx.empfaenger.example with ESMTPS id 4Wx1Yz;
        Wed, 5 Aug 2026 09:14:50 -0700 (PDT)

Jede Zeile nennt den angekündigten Host (from), den empfangenden Host (by), das Protokoll (with), meist die IP-Adresse in Klammern und den Zeitstempel. Drei Lesarten ergeben sich daraus.

Die erste ist der wahre Ursprung: die IP-Adresse des ältesten Schritts, die des Servers, der tatsächlich versandt hat. Sie widersteht jeder Fälschung des From:, und sie ist die Adresse, die eine Missbrauchsmeldung an einen Hoster nennen muss.

Die zweite ist die Verzögerung. Der Vergleich der Zeitstempel zweier aufeinanderfolgender Schritte ergibt die je Etappe verbrachte Zeit. Wenige Sekunden sind normal. Mehrere Minuten deuten auf eine Warteschlange, auf Greylisting oder auf zwischengeschaltete Filterung — und erklären oft, warum eine Nachricht „verspätet ankam", ohne dass jemand sie blockiert hätte. Diese Spur gehört zu den ersten, wenn legitime Nachrichten im Spam landen.

Die dritte ist die Zahl der passierten Grenzen. Eine direkte Nachricht macht zwei oder drei Schritte. Ein Dutzend verrät eine Kette von Umleitungen und damit einen Kontext, in dem SPF mit hoher Wahrscheinlichkeit gebrochen ist.

ARC, Mailinglisten und Weiterleitungen

Verändert ein Zwischenglied eine Nachricht — eine Mailingliste, die eine Fußzeile anfügt, ein System, das den Betreff umschreibt —, verifiziert die ursprüngliche DKIM-Signatur nicht mehr, und die Weiterleitung bricht die SPF-Autorisierung. Die legitime Nachricht wird von einer Fälschung ununterscheidbar.

ARC beantwortet dieses Problem, indem es das Zwischenglied bezeugen lässt. Drei Header erscheinen dann, nach Instanz nummeriert: ARC-Authentication-Results bewahrt die Momentaufnahme der vor der Änderung festgestellten Urteile, ARC-Message-Signature signiert die Nachricht so, wie sie weitergereicht wird, und ARC-Seal versiegelt das Ganze. Das Tag cv= des höchstnummerierten Siegels gibt den Zustand der Kette an: pass für eine intakte Kette, none für ein erstes Glied, fail für eine gebrochene. Die Funktionsweise der ARC-Kette im Detail verdient einen eigenen Artikel; für eine Header-Lektüre genügt ihr bloßes Vorhandensein, um eine ohne jeden Betrug zusammenbrechende Authentifizierung zu erklären.

Die Felder List-Id und List-Unsubscribe erzählen dieselbe Geschichte schlichter: die Nachricht stammt von einer Liste, und eine Liste schreibt den Absender bereitwillig um.

Was Header niemals sagen werden

Eine Nachricht ist ein Fall. Sie belegt, was dieser Nachricht widerfahren ist, und sonst nichts. Header sagen nicht, wie viele weitere Nachrichten an jenem Tag unter derselben Domain versandt wurden, wie viele scheiterten oder von welchen IP-Adressen. Eine Domain kann eine tadellos authentifizierte Nachricht vorweisen und anderswo einen ganzen Strom an Fälschungen durchlassen.

Das ist die strukturelle Grenze der Übung und der Grund, warum es Aggregatberichte gibt. Wo der Header einen Fall zeigt, zeigt die Lektüre der DMARC-Aggregatberichte sämtliche Absender einer Domain, Tag für Tag, und erlaubt es, Spoofing in den Berichten zu erkennen, das sonst niemand gemeldet hätte. Beide Lektüren ergänzen einander: die eine beantwortet „warum diese Nachricht", die andere „was geschieht auf dieser Domain".

Um das händische Zerlegen zu sparen, liefert ein kostenloser Header-Analysator dieselben Feststellungen in einem Durchgang: Urteile je Methode, neu berechnete Ausrichtung, ARC-Kette und rekonstruierter Weg. Und für den Gesamtblick auf eine Domain setzt der kostenlose DMARC-Analyzer am anderen Ende an — bei der veröffentlichten Konfiguration statt bei einer empfangenen Nachricht.

Häufige Fragen

Lässt sich ein Header vollständig fälschen? Alles, was der Absender schreibt, schon: From:, Reply-To:, Date:, und selbst gefälschte Received:- oder Authentication-Results-Zeilen, vor dem Versand eingefügt. Nicht fälschbar sind die Felder, die nach dem Versand von den durchlaufenen Servern ergänzt werden — sie stapeln sich obenauf. Daher die Regel: das Vertrauen nimmt ab, je weiter man im Stapel nach unten liest.

Warum weicht der Return-Path: vom From: ab? Weil es zwei verschiedene Identitäten des Protokolls sind. Der Envelope dient dem Routing und den Rückläufern; die angezeigte Adresse dient dem Menschen. Ein Drittanbieter nutzt fast immer seinen eigenen Envelope, und die Abweichung ist für sich genommen nicht anormal — sie wird erst zum Problem, wenn keine ausgerichtete DKIM-Signatur sie ausgleicht.

Enthalten Header personenbezogene Daten? Ja: E-Mail-Adressen, IP-Adressen, mitunter interne Servernamen. Ein in ein öffentliches Ticket eingefügter oder an einen fremden Dienst gesandter Header-Block legt all das offen. Die Vorsicht lohnt sich, bevor eine Nachricht im Klartext geteilt wird.

Zusammenfassung

Die Header sind der einzige Teil einer E-Mail, der eine Spur ihrer Vergangenheit bewahrt. Drei Blöcke genügen: die Identitäten, um zu wissen, wer die Nachricht zu sein vorgibt; Authentication-Results, um zu wissen, was der empfangende Server geschlossen hat — stets mit der Prüfung, welcher Server spricht —; und der Received:-Stapel, um zu rekonstruieren, woher sie kommt und wie lange sie gebraucht hat. Der Rest ist technisches Rauschen. Und an dem Tag, an dem die Frage von „diese Nachricht" zu „diese Domain" wechselt, liegt die Antwort in den Aggregatberichten.