E-Mail-Header lesen: was er zeigt und was er beweist

Was der Header-Block eigentlich ist

Jede Nachricht besteht aus zwei Teilen, getrennt durch eine einzige Leerzeile: einem Block von Zeilen der Form Name: value, und dem Text, den Sie lesen. RFC 5322 nennt den ersten Teil den Header und jede Zeile darin ein Feld, und legt keine Grenze fest, wie viele es sein dürfen. Ihre Mail-App zeigt Ihnen vier oder fünf davon. Eine Nachricht, die drei Server durchlaufen hat, trägt meist zwischen dreißig und sechzig mit sich.

Return-Path: <bounces+2841@mail.example.com>
Delivered-To: signup-2026@example.org
Received: by mx.example.org (Postfix) with LMTP id 4c8f21
        for <signup-2026@example.org>; Fri, 5 Sep 2026 09:14:22 +0000 (UTC)
Received: from out-17.mail.example.com (out-17.mail.example.com [198.51.100.17])
        by mx.example.org (Postfix) with ESMTPS id 9a31b0
        for <signup-2026@example.org>; Fri, 5 Sep 2026 09:14:21 +0000 (UTC)
Authentication-Results: mx.example.org;
        spf=pass smtp.mailfrom=mail.example.com;
        dkim=pass header.d=example.com;
        dmarc=pass header.from=example.com
From: "Example Support" <support@example.com>
To: signup-2026@example.org
Subject: Confirm your email address
Date: Fri, 5 Sep 2026 09:14:19 +0000
Message-ID: <20260905091419.9a31b0@mail.example.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_4c8f21"

Von oben nach unten gelesen sieht es aus wie Maschinenrauschen, und das ist es größtenteils auch. Vier Felder tragen fast die gesamte Information, und das sind die vier, um die es in dieser Anleitung geht: Received, From, Return-Path und Authentication-Results.

Wo sich der vollständige Header versteckt

Nichts von dem, was folgt, braucht ein Tool, eine Erweiterung oder ein Konto. Jeder Mail-Client hält die Rohnachricht hinter einem Menüpunkt versteckt, und das Wort, nach dem Sie suchen sollten, ist immer irgendeine Form von Quelle, Original oder Rohtext.

Diese Menüpfade sind dort, wo sie am 5. September 2026 standen, und sie wandern etwa einmal im Jahr — weshalb der Satz oben wichtiger ist als die Tabelle: Wie auch immer der Eintrag diese Saison heißt, er wird Quelle, Original oder Rohtext enthalten.

Die Received-Kette, von unten gelesen

Jeder Server, der die Nachricht annimmt, schreibt eine Received:-Zeile und setzt sie ganz nach oben in den Block, über alles, was schon da steht. Diese eine Angewohnheit erzeugt die nützlichste Tatsache, die es über Header gibt: Der letzte Hop ist die erste Zeile, die Sie sehen, und die Reise der Nachricht steht rückwärts aufgeschrieben.

Received: by mx.example.org (Postfix) with LMTP id 4c8f21
        for <signup-2026@example.org>; Fri, 5 Sep 2026 09:14:22 +0000 (UTC)
Received: from out-17.mail.example.com (out-17.mail.example.com [198.51.100.17])
        by mx.example.org (Postfix) with ESMTPS id 9a31b0
        for <signup-2026@example.org>; Fri, 5 Sep 2026 09:14:21 +0000 (UTC)
Received: from app-3.internal (app-3.internal [192.0.2.53])
        by out-17.mail.example.com (Postfix) with ESMTP id 771c4e
        for <signup-2026@example.org>; Fri, 5 Sep 2026 09:11:58 +0000 (UTC)

Jede Zeile ist aus derselben Handvoll Wörter aufgebaut, und sobald Sie sie benennen können, hört die Kette auf, bloße Tapete zu sein.

from

Wie sich die verbindende Maschine selbst genannt hat, gefolgt in Klammern von dem, was sie tatsächlich war — der Reverse-DNS-Name und die IP-Adresse, die der empfangende Server bei der Verbindung gesehen hat. Der Name vor der Klammer ist eine Behauptung. Die Adresse darin wurde beobachtet.

by

Der Server, der diese Zeile geschrieben hat. Er ist die einzige Partei in der Zeile, die Sie für irgendetwas davon verantwortlich machen können.

with

Wie der Hop zustande kam: ESMTP, ESMTPS, wenn die Verbindung verschlüsselt war, LMTP für die letzte Übergabe in ein Postfach. Ein Hop, bei dem ESMTP ohne S steht, hat die Nachricht im Klartext befördert.

for

Der Envelope-Empfänger bei diesem Hop — an welche Ihrer Adressen die Nachricht wirklich geschickt wurde, bevor irgendeine Weiterleitungsregel etwas umgeschrieben hat. Bei einer Catch-all-Domain oder einem Plus-Tag ist das die Zeile, die die Adresse nennt, die durchgesickert ist.

der Zeitstempel am Ende

Wann dieser Server die Annahme der Nachricht abgeschlossen hat. Ziehen Sie die Zeit einer Zeile von der Zeile darüber ab, und Sie haben die Verzögerung an diesem Hop — so finden Sie heraus, wo eine langsame Nachricht tatsächlich hing, statt es zu raten.

Im Beispiel oben hat die Nachricht die Anwendung um 09:11:58 Uhr verlassen und den ausgehenden Server des versendenden Anbieters zwei Minuten und dreiundzwanzig Sekunden später erreicht; die beiden Hops danach brauchten zusammen eine Sekunde. Eine Nachricht, die eine Stunde zu spät ankommt, hat fast immer eine Zeile, in der diese Stunde steckt — und es ist selten die letzte.

Vier Felder, die alle behaupten, der Absender zu sein

„Wer hat das geschickt“ hat in einem Header vier Antworten, und die dürfen sich widersprechen. Meistens widersprechen sie sich aus banalen Gründen — eine Mailingliste, eine Marketing-Plattform, eine Weiterleitungsregel, die Sie selbst eingerichtet haben. Eine Unstimmigkeit ist kein Beweis für irgendetwas. Zu wissen, welche der vier Sie gerade vor sich haben, ist es schon.

From:

Die Adresse, die der Absender angezeigt haben möchte, dazu ein Anzeigename, der Freitext ist. Keines von beidem wird geprüft. Das ist das Feld, das Ihre Mail-App in die Nachrichtenliste setzt, und auf dem Handy ist die Adresse meist vollständig hinter dem Namen versteckt.

Return-Path:

Der Envelope-Absender, in den Header geschrieben von dem Server, der die Nachricht angenommen hat, nach dem, was während der SMTP-Konversation tatsächlich gesagt wurde. Dorthin geht ein Bounce, und gegen diese Adresse wird SPF geprüft — genau deshalb kann eine Nachricht SPF bestehen, während sie ein From: trägt, das damit nichts zu tun hat.

Reply-To:

Wohin Ihre Antwort adressiert wird, und das muss nicht dort sein, wo die Nachricht herkam. Gewöhnliche Absender nutzen es für den Support und für No-Reply-Adressen. Es ist außerdem der älteste Trick im Geschäft, denn ein aufmerksamer Leser prüft den Absender, hält ihn für unbedenklich, und drückt dann auf Antworten.

Delivered-To: und X-Original-To:

Welche Ihrer Adressen verwendet wurde. Auf einer Catch-all-Domain oder mit einem Plus-Tag ist das das Feld, das die Adresse nennt, die Sie tatsächlich herausgegeben haben — die Adresse, die verrät, wer sie hat durchsickern lassen.

From: "Example Support <support@example.com>" <billing@example.net>
         ^-- the display name, which is free text and is all a phone shows
                                              ^-- the address, which is not

Der Anzeigename ist beliebiger Text, er kann also eine vollständige Adresse enthalten, die jemand anderem gehört. Jeder Mail-Client der Welt zeigt den Teil in Anführungszeichen und versteckt den Teil in spitzen Klammern — das ist der gesamte Angriff: Er kostet nichts zu schreiben, und er funktioniert bei dem einen Feld, auf das ein Leser garantiert schaut.

SPF, DKIM und DMARC, in einer Zeile

Ein Feld unterscheidet sich von jedem anderen Feld im Block. Authentication-Results: wird von dem Server geschrieben, der die Nachricht angenommen hat — Ihrem —, und alles, was unter demselben Namen ankommt, wird entfernt oder umbenannt, bevor Sie es sehen. Es ist die einzige Zeile in einem Header, die ein Fälscher nicht schreiben kann.

Authentication-Results: mx.example.org;
        spf=pass (sender IP is 198.51.100.17) smtp.mailfrom=mail.example.com;
        dkim=pass header.d=example.com header.s=s1 header.b=Qk3vR2mA;
        dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

Drei Prüfungen stecken in dieser Zeile, und sie beantworten drei verschiedene Fragen. Die vierte Spalte ist die, die es wert ist, zweimal gelesen zu werden.

Diese letzte Spalte ist der eigentliche Punkt, und genau dort geht das Lesen von Headern meistens schief. dmarc=pass beweist, dass die Domain, die in From: steht, die Nachricht autorisiert hat. Es sagt absolut nichts darüber aus, ob diese Domain irgendetwas von Ihnen verdient hat — und die Einträge selbst zu veröffentlichen dauert etwa zehn Minuten, für jeden.

Fünf Dinge, die Ihnen ein Header nicht sagen kann

• Wo sich der Absender befindet. Die Adresse der Maschine, auf der jemand geschrieben hat, steht meist überhaupt nicht im Block. Die großen Webmail-Anbieter haben es vor Jahren eingestellt, das zu veröffentlichen, und übrig bleibt ihr eigener ausgehender Server, der in einem Rechenzentrum steht und Ihnen den Namen eines Hosting-Unternehmens verrät.
• Wer der Absender ist. Eine Domain ist keine Person. dmarc=pass für eine Domain, die vor vierzig Minuten gekauft wurde, ist ein vollkommen echtes Bestehen.
• Ob irgendetwas davon stimmt. Authentifizierung betrifft den Envelope und nie die Behauptung darin. Eine Rechnung kann korrekt signiert, korrekt ausgerichtet und vollständig erfunden sein.
• Ob irgendjemand sie gelesen hat. Nichts in einem Header hält das fest. Was das versucht, ist ein Tracking-Pixel im Nachrichtentext, ein anderer Mechanismus mit anderen Gegenmitteln.
• Wann sie geschrieben wurde. Date: stammt von der eigenen Maschine des Absenders und dessen eigener Uhr. Eine Nachricht, die drei Stunden in der Zukunft datiert ist, ist weit häufiger ein falsch eingestellter Computer als irgendetwas Interessantes; die Zeitstempel, auf die Sie sich verlassen können, stehen in den Received-Zeilen, die Ihr Anbieter geschrieben hat.

Und eine ganze Familie von Feldern beweist schon konstruktionsbedingt nichts. Alles, was mit X- beginnt, ist eine private Erweiterung, erfunden von demjenigen, der sie geschrieben hat, und ein Absender darf schreiben, was ihm beliebt: X-Spam-Status: No in einer Nachricht bedeutet, dass die Nachricht behauptet, kein Spam zu sein.

Wenn die Nachricht bei einer temporären Adresse gelandet ist

Machen Sie sich klar, was dieser Dienst zurückgibt und was nicht. Eine Nachricht, die Sie hier lesen, kommt geparst an statt roh: der Absender, der Betreff, das Datum, der Text, das HTML und die Liste der Anhänge — die Felder, für die ein Skript gekommen ist — und nicht der Header-Block. Das Lesen von oben machen Sie in dem Postfach, das Ihre echte Mail aufbewahrt.

{
  "id":           "m_7Kq2fV3xTn",
  "from":         "support@example.com",
  "from_name":    "Example Support",
  "to":           "signup-2026@grabmail.io",
  "subject":      "Confirm your email address",
  "date":         "2026-09-05T09:14:22+00:00",
  "expires_at":   "2026-09-10T09:14:22+00:00",
  "text":         "Confirm your address: <https://example.com/confirm/9a31b0>",
  "text_derived": true,
  "html":         "<!doctype html><html>…",
  "attachments":  []
}

Was Ihnen eine temporäre Adresse stattdessen gibt, ist ein Signal, dem kein Header-Feld das Wasser reichen kann, und es wirkt, bevor Sie auch nur eine einzige Zeile gelesen haben: Sie haben genau dieser einen Partei diese Adresse gegeben. Eine Nachricht, die dort ankommt und behauptet, von jemand anderem zu kommen, wurde entweder von der Partei weitergeleitet, der Sie sie gegeben haben, oder von demjenigen verschickt, an den diese sie weitergereicht hat. Es gibt keine dritte Erklärung, und es gibt nichts zu überprüfen.

Das ist dasselbe Argument, das ein Plus-Tag macht, nur ohne den Teil, in dem das Tag mit einer Zeile Code abgeschnitten werden kann — hier ist die Adresse selbst eine andere, es gibt also nichts zu entfernen. Das ist auch, warum ein Catch-all auf einer Domain, die Ihnen gehört die stärkste Version davon ist: eine Adresse pro Anmeldung, aufbewahrt so lange, wie Sie die Domain behalten, und Delivered-To: in Ihrem eigenen Postfach nennt die eine, die herausgekommen ist.

Die Prüfung, die Ihnen noch bleibt

Schauen Sie, wohin der Link führt, nicht darauf, was er sagt. Das Feld text ist entweder der eigene Klartextteil des Absenders oder eine Wiedergabe des HTML — text_derived sagt, welches von beiden —, und die Wiedergabe hält jedes Linkziel in spitzen Klammern fest. Die Adresse, zu der Sie ein Button gebracht hätte, liegt also offen in der Antwort, ohne dass die Seite, die Bilder oder der Pixel geladen werden.

Confirm your address: <https://example.com/confirm/9a31b0>

Not you? Ignore this message. <https://example.com/help>

Die Sechzig-Sekunden-Version

1. Öffnen Sie die Quelle. Original anzeigen, Nachrichtenquelltext anzeigen oder Rohquelle, je nachdem, in welchem Client Sie sind.
2. Suchen Sie zuerst Authentication-Results. Eine Zeile, geschrieben von Ihrem eigenen Anbieter, und die einzige, die niemand sonst hätte fälschen können. dmarc=pass, und die Domain in From: hat die Nachricht wirklich autorisiert; dmarc=fail, und sie hat es nicht.
3. Vergleichen Sie From: mit Return-Path: und Reply-To:. Sie widersprechen sich den ganzen Tag aus banalen Gründen. Sie widersprechen sich auch aus dem interessanten.
4. Lesen Sie die Received-Zeilen von unten nach oben, und hören Sie auf, ihnen zu glauben, sobald die erste Maschine auftaucht, die nicht die Ihres Anbieters ist.
5. Schauen Sie dann, wohin die Links zeigen — das ist der Teil, der entscheidet, was Ihnen tatsächlich passiert.

Alles oben beantwortet eine einzige, eng gefasste Frage: Hat die Domain in From: diese Nachricht autorisiert? Das ist eine kleinere Frage als „Ist das sicher“, und es lohnt sich trotzdem, sie zu beantworten — es ist die einzige, die ein Header überhaupt beantworten kann.

Fragen