Header lesen: Woher kam diese E-Mail wirklich?

Modul 1: Wie E-Mail funktioniert · Lesezeit: 11 Minuten

Lernziel: Nach dieser Lektion können Sie die Header einer E-Mail öffnen, die Received-Zeilen in der richtigen Reihenfolge lesen und aus Authentication-Results ablesen, ob SPF, DKIM und DMARC korrekt waren.

Kernbegriffe: Header (Kopfzeilen), RFC 5322, Received, Return-Path, From, Reply-To, Message-ID, DKIM-Signature (d=, s=), Authentication-Results, ARC, X-Header, Quelle bzw. Originalnachricht

Was Sie normalerweise nicht sehen

Ihr E-Mail-Programm zeigt von einer Nachricht nur wenige Zeilen an: Absender, Betreff, Datum, Empfänger. In Wirklichkeit hat jede E-Mail Dutzende Header (Kopfzeilen) oben, vor dem eigentlichen Text. Sie werden vom Programm des Absenders hinzugefügt und von jedem Server, den die Nachricht unterwegs berührt. Zusammen bilden sie das Reiseprotokoll der E-Mail.

Wer Header lesen kann, kann viele Fragen selbst beantworten: Ist diese E-Mail wirklich von meiner Bank? Warum kam sie erst nach zwei Stunden an? Warum landete sie im Spam? Stimmt mein eigenes DKIM? Viele Aufgaben dieses Kurses verlangen von Ihnen, Header zu untersuchen. In dieser Lektion lernen Sie, wie das geht.

Header öffnen

Jedes Programm hat dafür eine andere Schaltfläche:

Auf einem Telefon geht das meistens nicht. Leiten Sie die E-Mail dann als Anhang an sich selbst weiter, oder öffnen Sie sie im Webmail.

Ein Beispiel

Jan erhält eine E-Mail von Anna. So sehen die wichtigsten Header aus (gekürzt):

Return-Path: <anna@example.com>
Delivered-To: jan@example.net
Received: from mx1.mailprovider.example (localhost [127.0.0.1])
        by mailbox3.mailprovider.example with LMTP; Sun, 08 Nov 2026 10:15:09 +0100
Received: from out.hosting.example (out.hosting.example [192.0.2.25])
        by mx1.mailprovider.example with ESMTPS id 4F2A1B
        for <jan@example.net>; Sun, 08 Nov 2026 10:15:07 +0100
Received: from [198.51.100.77] (helo=[10.0.0.12])
        by out.hosting.example with ESMTPSA (TLS1.3)
        (authenticated as anna@example.com); Sun, 08 Nov 2026 10:15:04 +0100
Authentication-Results: mx1.mailprovider.example;
        spf=pass smtp.mailfrom=example.com;
        dkim=pass header.d=example.com header.s=x;
        dmarc=pass header.from=example.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=x;
        h=From:To:Subject:Date:Message-ID; bh=...; b=...
From: Anna <anna@example.com>
To: Jan <jan@example.net>
Subject: Offerte
Date: Sun, 8 Nov 2026 10:15:00 +0100
Message-ID: <a1b2c3@example.com>

Received-Zeilen: von unten nach oben

Jeder Server, der die E-Mail weiterleitet, setzt eine Received:-Zeile oben ein. Die älteste steht also unten, die neueste oben. Lesen Sie sie von unten nach oben, um die Reise zu verfolgen:

1. Unterste Zeile: Annas Laptop (IP 198.51.100.77, ihr häuslicher Internetanschluss) liefert an out.hosting.example aus, mit ESMTPSA (das A steht für authenticated: sie hat sich angemeldet) und TLS 1.3. Um 10:15:04 Uhr.
2. Mittlere Zeile: out.hosting.example (192.0.2.25) liefert an mx1.mailprovider.example, den MX von example.net. Um 10:15:07 Uhr.
3. Oberste Zeile: Der Mailserver stellt die Nachricht intern in Jans Postfach zu (LMTP). Um 10:15:09 Uhr.

Eine Received-Zeile hat stets die Form from <wer es anbot> by <wer es annahm> with <Protokoll>; <Zeit>. In Klammern hinter from steht, was der empfangende Server selbst festgestellt hat: der tatsächliche Name (PTR) und die tatsächliche IP-Adresse. Dieser Teil ist zuverlässig, soweit Sie diesem empfangenden Server vertrauen. Was der Absender selbst angab (helo=), lässt sich nicht überprüfen.

Zwei praktische Tricks:

• Verzögerung finden: Vergleichen Sie die Zeiten. Liegen zwischen zwei Zeilen zwei Stunden, dann hat die E-Mail dort so lange in einer Warteschlange gestanden. Achten Sie auf Zeitzonen (+0100, +0000).
• Den echten Absenderserver finden: Suchen Sie die oberste Received-Zeile, die von einem Server des Empfängers selbst geschrieben wurde, und schauen Sie, was dort hinter from steht. Alles darunter hat die versendende Seite geschrieben und kann theoretisch frei erfunden sein. Im Beispiel ist 192.0.2.25 der Server, der beim Empfänger zugestellt hat; danach werden SPF und die Reputation beurteilt.

Die Adressen

Ein bekannter Trick von Betrügern: ein From, das wie Ihre Bank aussieht, mit einem Reply-To zu einer ganz anderen Adresse. Schauen Sie im Zweifel immer auf die Domain in From und in Return-Path, sowie auf Authentication-Results.

Authentication-Results: das Urteil des Empfängers

Der empfangende Server trägt in Authentication-Results (RFC 8601) ein, was seine Prüfungen ergaben:

• spf=pass smtp.mailfrom=example.com: Die IP des Servers, der zugestellt hat, steht im SPF-Record der Domain in Return-Path.
• dkim=pass header.d=example.com header.s=x: Die DKIM-Signatur der Domain example.com, mit Schlüssel (Selector) x, stimmt.
• dmarc=pass header.from=example.com: Die Domain in From ist mit einem erfolgreichen SPF oder DKIM ausgerichtet (Alignment), DMARC ist also erfolgreich.

Andere Ergebnisse, die Sie sehen können: fail (stimmt nicht), softfail (SPF endet auf ~all und die IP steht nicht darin), neutral, none (kein Record), temperror (vorübergehender DNS-Fehler) und permerror (Record defekt, zum Beispiel zwei SPF-Records). Was diese genau bedeuten und wie Sie sie beheben, steht in Modul 4.

Achtung: Vertrauen Sie nur dem Authentication-Results des Servers des Empfängers selbst (der Name vorne, hier mx1.mailprovider.example). Eine gefälschte E-Mail kann ein eigenes, erfundenes Authentication-Results mitschicken. Gute Server entfernen das, aber nicht alle.

DKIM-Signature: die Signatur

Der Header DKIM-Signature ist die Signatur selbst. Zwei Felder benötigen Sie häufig:

• d= die Domain, die signiert (hier example.com);
• s= der Selector, der Name des Schlüssels (hier x).

Damit finden Sie den öffentlichen Schlüssel im DNS: x._domainkey.example.com. In Aufgaben und bei Problemen müssen Sie oft genau diese beiden Werte nachschlagen. Eine E-Mail kann mehrere DKIM-Signaturen haben, zum Beispiel eine von Ihrer Domain und eine vom Versanddienst. In Lektion 4.3 gehen wir darauf näher ein.

Manchmal sehen Sie auch ARC-Seal, ARC-Message-Signature und ARC-Authentication-Results. ARC (RFC 8617) ist eine Methode, mit der Zwischenstationen, wie eine Mailingliste oder ein Weiterleitungsserver, festhalten, was die Prüfungen ergaben, bevor sie die E-Mail veränderten. Sie müssen das jetzt noch nicht lesen können.

X-Header

Header, die mit X- beginnen, sind nicht standardisiert. Spamfilter tragen dort ihre Bewertung ein, wie X-Spam-Status: No, score=1.2 oder X-Spam-Flag: YES. Das hilft zu erkennen, warum etwas im Spam gelandet ist. Sie unterscheiden sich je nach Anbieter.

Zusammenfassung

• Header sind das Reiseprotokoll einer E-Mail. Öffnen Sie sie mit "Original anzeigen", "Nachrichtenquelltext" oder etwas Vergleichbarem.
• Lesen Sie Received-Zeilen von unten nach oben. Die Zeile, die der Server des Empfängers geschrieben hat, verrät, welche IP zugestellt hat.
• Return-Path ist der Envelope-Absender (SPF), From der sichtbare Absender (DMARC), Reply-To gibt an, wohin Antworten gehen.
• Authentication-Results gibt das Urteil über SPF, DKIM und DMARC wieder; vertrauen Sie nur dem des empfangenden Servers.
• In DKIM-Signature stehen d= (Domain) und s= (Selector); zusammen ergeben sie den Ort des Schlüssels: s._domainkey.d.

Quiz

Aufgabe

Aufgabe Z1.5: Header analysieren lassen. Senden Sie sich selbst eine E-Mail von einer anderen Adresse (zum Beispiel von Ihrer dienstlichen an Ihre private Adresse, oder umgekehrt), öffnen Sie die Header und fügen Sie sie in das Formular ein. Haben Sie keine zweite Adresse, verwenden Sie die Beispieldatei kopregels-1.txt, die bei der Aufgabe liegt. Tragen Sie anschließend selbst ein: die IP-Adresse des Servers, der beim Empfänger zugestellt hat, die Domain in Return-Path, die Domain und den Selector der DKIM-Signatur, sowie das Ergebnis von SPF, DKIM und DMARC. Das Programm analysiert dieselben Header, schlägt den DKIM-Schlüssel live nach und stellt sein Ergebnis Ihrem gegenüber. Ihre Header werden nicht gespeichert.

Weiterführende Links

Die Schritte in diesen Artikeln gelten für die Panels von WebOké; bei anderen Anbietern funktioniert es ähnlich.

• Mit Email Tracking in DirectAdmin prüfen, ob eine E-Mail angekommen ist
• DirectAdmin Anleitung 9.3: E-Mail-Verfolgung: wo ist meine Mail geblieben?
• Ist diese E-Mail wirklich von WebOké? Phishing erkennen und den Aktionscode verwenden
• Kostenloser DNS-Kurs 4.4: DKIM: die Unterschrift unter Ihrer Mail
• RFC 5322 (Aufbau einer E-Mail), RFC 8601 (Authentication-Results), RFC 6376 (DKIM), RFC 8617 (ARC)