E-Mail-Header verstehen: der komplette Leitfaden zum Lesen und Analysieren aller Felder

⚡TL;DR

• E-Mail-Header sind ein unsichtbares Logbuch, das jeden durchlaufenen Server, jede Authentifizierungsprüfung und jede Anti-Spam-Entscheidung aufzeichnet
• Received-Header werden von unten nach oben gelesen: der älteste Hop steht unten, der neueste oben
• Authentication-Results fasst die SPF-, DKIM- und DMARC-Ergebnisse in einer einzigen Zeile zusammen und ist das wichtigste Feld zur Problemdiagnose
• Die Felder From, Return-Path und Reply-To können auf drei verschiedene Adressen verweisen, ein potenzielles Zeichen für Spoofing
• Ein automatisiertes Analysetool verwandelt Dutzende technischer Zeilen in eine lesbare Diagnose in Sekunden

Du erhältst eine verdächtige E-Mail. Der Absender zeigt den Namen deiner Bank an, aber irgendetwas stimmt nicht. Oder deine eigenen E-Mails landen bei deinen Kunden im Spam, und du weißt nicht warum. In beiden Fällen liegt die Antwort am selben Ort: in den E-Mail-Headern. Wenn man bedenkt, dass 60 % der bestätigten Sicherheitsverletzungen eine menschliche Handlung beinhalten (Verizon DBIR 2025) und es durchschnittlich 207 Tage dauert, einen Phishing-Kompromiss zu erkennen (IBM 2025), ist das Lesen von Headern kein technischer Luxus mehr.

Jede E-Mail transportiert einen Block unsichtbarer Metadaten. Dieser Block enthält die vollständige Route der Nachricht (welche Server sie durchlaufen hat, in welcher Reihenfolge), die Ergebnisse der Authentifizierungsprüfungen (SPF, DKIM, DMARC) und Hinweise darauf, wie Anti-Spam-Filter die Nachricht verarbeitet haben. Es ist ein vollständiges Logbuch, aber du musst es lesen können.

Dieser Leitfaden zeigt dir, wie du diese Header extrahierst, jedes Feld verstehst, die Routing-Kette interpretierst und die häufigsten Probleme diagnostizierst. Ob du Systemadministrator, Marketing-Verantwortlicher oder einfach neugierig bist, ob eine E-Mail legitim ist: Vorkenntnisse sind nicht erforderlich, wir starten bei null.

Was ist ein E-Mail-Header und warum sollte es dich interessieren?

Die Analogie des Briefumschlags

Wenn du einen Brief versendest, trägt der Umschlag die Absenderadresse, die Empfängeradresse und die Poststempel. Der Inhalt des Briefs ist von diesen Routing-Informationen getrennt.

Eine E-Mail funktioniert genauso. Der Nachrichtentext (Text, Bilder, Anhänge) ist von den Headern getrennt, die die Metadaten transportieren. Der Unterschied: E-Mail-Header enthalten deutlich mehr Informationen als ein Briefumschlag. Jeder Server, den die Nachricht durchläuft, fügt eigene Anmerkungen hinzu, wie ein Poststempel mit Zeitstempel.

Sichtbare Header vs. technische Header

Dein E-Mail-Client zeigt einige Header in lesbarer Form an:

• Von (From): die Absenderadresse
• An (To): die Empfängeradresse
• Betreff (Subject): der Betreff der Nachricht
• Datum (Date): der Versandzeitstempel

Aber unter dieser Oberfläche bleiben Dutzende technischer Header verborgen. Die wichtigsten:

Header	Funktion
Received	Zeichnet den Weg der Nachricht von Server zu Server auf
Return-Path	Bounce-Adresse (SMTP-Envelope)
Authentication-Results	SPF-, DKIM- und DMARC-Ergebnisse
DKIM-Signature	Kryptografische Signatur der Nachricht
Message-ID	Eindeutige Nachrichten-ID
X-Spam-Score	Vom Anti-Spam-Filter vergebene Punktzahl

Vier Gründe, Header zu lesen

1. Ein Zustellbarkeitsproblem diagnostizieren. Deine E-Mails landen im Spam? Die Header der empfangenen Nachricht sagen dir genau warum: SPF-Fehler, ungültige DKIM-Signatur, DMARC-Richtlinie nicht erfüllt oder ein zu hoher Anti-Spam-Score.

2. Die Identität eines Absenders überprüfen. Eine E-Mail behauptet, von deinem Finanzvorstand zu kommen? Vergleiche das From-Feld mit dem Return-Path und prüfe, ob DKIM von der richtigen Domain signiert ist. Eine Abweichung zwischen diesen Feldern ist ein starkes Warnsignal.

3. Spoofing und Phishing erkennen. Angreifer fälschen das From-Feld, um eine legitime Domain zu imitieren. Die Authentifizierungs-Header zeigen, ob die Nachricht tatsächlich vom autorisierten Server gesendet wurde. Ein dmarc=fail kombiniert mit einem spf=fail bei einer E-Mail, die angeblich von deiner Bank kommt, ist ein zuverlässiger Betrugsindikator. Und das Problem ist massiv: 84,2 % der Phishing-Angriffe bestehen die DMARC-Prüfungen (Egress 2024), entweder weil die Domain keine DMARC-Richtlinie hat oder weil die Richtlinie zu freizügig ist (p=none).

4. Ein Latenzproblem verfolgen. Jeder Received-Header enthält einen Zeitstempel. Durch Vergleich der Zeitstempel jedes Hops kannst du den Server identifizieren, der eine abnormale Verzögerung in der Routing-Kette verursacht.

So extrahierst du die Header

Jeder E-Mail-Client blendet technische Header standardmäßig aus. So kannst du sie anzeigen lassen.

Gmail (Web)

1. Öffne die betreffende E-Mail
2. Klicke auf das Menü drei vertikale Punkte (⋮) oben rechts in der Nachricht
3. Wähle "Original anzeigen"
4. Ein neues Fenster zeigt die vollständigen Header mit einer SPF/DKIM/DMARC-Zusammenfassung oben

Gmail bietet einen "In die Zwischenablage kopieren"-Button, um alle Header auf einmal zu kopieren. Das ist der schnellste Weg, sie in ein Analysetool einzufügen.

Outlook Desktop (Windows/Mac)

1. Öffne die E-Mail in einem separaten Fenster (Doppelklick)
2. Gehe zu Datei > Eigenschaften
3. Die Header erscheinen im Feld "Internetkopfzeilen" am unteren Rand des Fensters

Das Feld ist klein: Alles auswählen (Strg+A) und dann kopieren (Strg+C), um bequemer in einem Texteditor zu arbeiten.

Outlook Web (OWA)

1. Öffne die betreffende E-Mail
2. Klicke auf das Menü drei Punkte (⋮) oben rechts
3. Wähle "Anzeigen" und dann "Nachrichtenquelle anzeigen"
4. Die Header werden in einem neuen Fenster angezeigt

Apple Mail (macOS)

1. Wähle die E-Mail in der Liste aus
2. Gehe in der Menüleiste zu Darstellung > E-Mail > Alle Header
3. Die technischen Header erscheinen über dem Nachrichtentext

Zum Zurücksetzen auf die normale Ansicht: Darstellung > E-Mail > Standard-Header.

Thunderbird

1. Wähle die E-Mail aus
2. Menü Ansicht > Nachrichtenquelltext (oder Tastenkombination Strg+U, Cmd+U auf Mac)
3. Der vollständige Quelltext öffnet sich in einem neuen Fenster, Header inklusive

Thunderbird zeigt auch eine Header-Zusammenfassung direkt im Lesebereich an, wenn du Ansicht > Kopfzeilen > Alle aktivierst.

Yahoo Mail

1. Öffne die betreffende E-Mail
2. Klicke auf das Menü drei Punkte (⋮) neben dem Antworten-Button
3. Wähle "Rohnachricht anzeigen"
4. Die vollständigen Header und der Nachrichtentext werden in einem neuen Tab angezeigt

ProtonMail

1. Öffne die betreffende E-Mail
2. Klicke auf das Menü drei Punkte (⋮) oben rechts in der Nachricht
3. Wähle "Header anzeigen"
4. ProtonMail zeigt die Header in einem Modalfenster an. Verwende den Kopieren-Button, um alles zu übernehmen

Hinweis: Da ProtonMail ein clientseitig verschlüsselter Dienst ist, sind die sichtbaren Header diejenigen, die während des SMTP-Transits hinzugefügt wurden. Interne ProtonMail-Infrastruktur-Header bleiben eingeschränkt.

Praktischer Tipp

Unabhängig von der Methode: Kopiere alle Header und füge sie in ein E-Mail-Header-Analysetool ein. Das Tool zerlegt automatisch jedes Feld, berechnet Verzögerungen zwischen den Hops und hebt Authentifizierungsprobleme hervor.

Kopiere ALLES. Die Header einer geschäftlichen E-Mail umfassen oft zwischen 50 und 200 Zeilen. Wenn du nur die ersten Zeilen kopierst, verlierst du die ältesten Received-Hops (die ganz unten stehen) und oft die aufschlussreichsten Informationen.

Häufiger Fehler: Verwechsle nicht "Quelltext anzeigen" (zeigt die vollständige Nachricht, Header + kodierten Body) mit "Header anzeigen" (nur Metadaten). Für eine vollständige Diagnose ist der gesamte Quelltext vorzuziehen, da er die überprüfbaren DKIM-Signaturen enthält.

Format und Struktur der Header (RFC 5322)

Das Format Schlüssel: Wert

Jeder Header folgt einem einfachen Format gemäß RFC 5322:

Feldname: Feldwert

Der Feldname ist nicht case-sensitiv (From und from sind identisch), gefolgt von einem Doppelpunkt und dem Wert. Beispiele:

From: contact@captaindns.com
To: support@captaindns.com
Subject: DNS Monitoring Report - March 2026
Date: Sat, 29 Mar 2026 10:15:00 +0100
Message-ID: <20260329101500.abc123@mail.captaindns.com>

Folding (Mehrzeilige Fortsetzung)

Wenn ein Wert zu lang für eine einzelne Zeile ist, wird er in der nächsten Zeile mit Einrückung (Leerzeichen oder Tab) fortgesetzt. Das nennt man Folding. Beispiel mit einem Received-Header:

Received: from mx-out.captaindns.com (mx-out.captaindns.com [203.0.113.10])
    by mx-in.captaindns.com (Postfix) with ESMTPS id ABC123DEF
    for <support@captaindns.com>; Sat, 29 Mar 2026 10:15:02 +0100

Diese drei Zeilen bilden einen einzelnen Received-Header. Die Regel: Jede Zeile, die mit einem Leerzeichen beginnt, ist die Fortsetzung des vorherigen Headers.

Lesereihenfolge: von unten nach oben bei Received

Hier ist das wichtigste Detail bei E-Mail-Headern: Received-Header werden von unten nach oben gelesen.

Jeder SMTP-Server, der die Nachricht verarbeitet, fügt seinen Received-Header über den bestehenden Headern ein. Das Ergebnis: Der erste Hop (Ursprungsserver) steht unten, der letzte Hop (Empfangsserver) steht oben.

Andere Header (From, To, Subject, Date, Message-ID) werden einmalig vom Ursprungsserver hinzugefügt. Ihre Position im Block ist fest.

Die wichtigsten Felder im Detail

From

From: Marie Dupont <contact@captaindns.com>

Beschreibung: Identifiziert den im E-Mail-Client angezeigten Absender. Das ist das Feld, das der Empfänger sieht.

Was es verrät: Das From-Feld ist der sichtbarste Header, aber auch der am leichtesten fälschbare. Jeder SMTP-Server kann eine E-Mail mit einem beliebigen From senden. Genau deshalb gibt es SPF, DKIM und DMARC: um zu überprüfen, dass das From mit dem Server übereinstimmt, der die Nachricht tatsächlich gesendet hat.

Achte auf den Anzeigenamen. Das From-Feld enthält zwei verschiedene Elemente: den Anzeigenamen (Display Name) und die tatsächliche Adresse in spitzen Klammern. Bei From: Marie Dupont <contact@captaindns.com> zeigt dein E-Mail-Client "Marie Dupont" fett an und die Adresse contact@captaindns.com kleiner. Das Problem: Der Anzeigename ist ein Freitext ohne jede Überprüfung. Ein Angreifer kann From: Finanzvorstand <angreifer@boesartiger-absender.com> schreiben, und viele mobile Clients zeigen nur den Namen, nicht die Adresse. Überprüfe immer die Adresse in den spitzen Klammern, nicht den Anzeigenamen.

To und Cc

To: support@captaindns.com
Cc: tech@captaindns.com

Beschreibung: To listet die Hauptempfänger auf. Cc (Kopie) listet die Empfänger in sichtbarer Kopie.

Was es verrät: Wenn deine Adresse weder in To noch in Cc erscheint, wurde dir die Nachricht als Blindkopie (Bcc) oder über einen Verteiler zugestellt. Massen-Phishing-Kampagnen verwenden oft ein generisches oder leeres To-Feld.

Subject

Subject: =?utf-8?B?UmFwcG9ydCBkZSBtb25pdG9yaW5n?=

Beschreibung: Der Betreff der Nachricht. Kann in Base64 oder Quoted-Printable kodiert sein, wenn er Nicht-ASCII-Zeichen enthält (Umlaute, Sonderzeichen).

Was es verrät: In seiner dekodierten Form ist es der Text, den du in deinem Posteingang siehst. Die Rohkodierung in den Headern ist normal und deutet auf kein Problem hin.

Date

Date: Sat, 29 Mar 2026 10:15:00 +0100

Beschreibung: Zeitstempel, der vom Client des Absenders zum Zeitpunkt des Versands gesetzt wird. Das Format folgt RFC 5322: Tag, Datum, Uhrzeit und UTC-Offset.

Was es verrät: Vergleiche dieses Datum mit den Zeitstempeln in den Received-Headern. Eine Abweichung von mehreren Stunden zwischen dem Date und dem ersten Received kann auf eine E-Mail hindeuten, die von einem falsch konfigurierten Skript gesendet wurde, oder auf einen Versuch der Zeitstempelmanipulation.

Return-Path

Return-Path: <bounces@mail.captaindns.com>

Beschreibung: Die Adresse, an die Bounce-Nachrichten (Rückläufer) gesendet werden. Das ist die SMTP-Envelope-Adresse (MAIL FROM), die vom finalen Empfangsserver hinzugefügt wird.

Was es verrät: Der Return-Path kann vom From abweichen. Das ist normal, wenn ein Drittanbieter-Dienst E-Mails in deinem Namen versendet. Zum Beispiel zeigt eine über SendGrid versendete E-Mail Return-Path: <bounces+12345@em.sendgrid.net> an, obwohl das From contact@captaindns.com lautet. Das Gleiche gilt für Mailgun (bounces@mailgun.org) oder Amazon SES (0123abcd@amazonses.com). Diese Dienste verwalten Bounces über ihre eigene Infrastruktur.

Es ist abnormal, wenn eine E-Mail behauptet, von contact@captaindns.com zu stammen, aber einen Return-Path zu einer unbekannten Domain hat, die keinen Bezug zu einem legitimen Versanddienstleister hat. DMARC prüft die Übereinstimmung zwischen der From-Domain und der Return-Path-Domain (oder der DKIM-Domain). Eine fehlende Übereinstimmung ohne gültiges DKIM verursacht einen DMARC-Fehler.

Reply-To

Reply-To: antworten@captaindns.com

Beschreibung: Die Adresse, an die der E-Mail-Client die Antwort sendet, wenn der Empfänger auf "Antworten" klickt. Optional.

Was es verrät: Ein Reply-To, das vom From abweicht, ist bei Newslettern üblich (Versand über einen Marketing-Dienst, Antworten an den Support). Es ist verdächtig, wenn das Reply-To auf eine völlig andere Domain als das From verweist, typisch für CEO-Fraud (Business Email Compromise).

Message-ID

Message-ID: <20260329101500.abc123@mail.captaindns.com>

Beschreibung: Eindeutige Nachrichten-ID, die vom Versandserver generiert wird. Das übliche Format ist ein Zeitstempel oder eine zufällige Kennung, gefolgt vom Hostnamen des Servers, alles in spitzen Klammern.

Was es verrät: Die Domain in der Message-ID zeigt, welcher Server die Nachricht tatsächlich erstellt hat. Wenn eine E-Mail behauptet, von captaindns.com zu stammen, aber eine Message-ID mit einer anderen Domain hat, ist das ein Hinweis auf Spoofing. Es ist auch ein wertvoller Indikator für den tatsächlichen Versanddienst: Eine Message-ID mit @amazonses.com verrät einen Versand über Amazon SES, @smtpservice.net deutet auf SendGrid hin, @mail.gmail.com auf Google Workspace. Die Message-ID ist einer der am schwersten überzeugend fälschbaren Header, da sie automatisch vom SMTP-Server generiert wird.

MIME-Version und Content-Type

MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="boundary123abc"

Beschreibung: MIME-Version zeigt an, dass die Nachricht das MIME-Format verwendet (fast immer 1.0). Content-Type beschreibt das Body-Format: text/plain (Klartext), text/html (HTML), multipart/alternative (beide Versionen), multipart/mixed (mit Anhängen).

Was es verrät: Eine E-Mail, die vorgibt, reiner Text zu sein, aber einen Content-Type: multipart/mixed mit einem ausführbaren Anhang enthält, ist verdächtig. Der Content-Type hilft dir, die tatsächliche Struktur der Nachricht zu verstehen.

Received

Received: from mx-out.captaindns.com (mx-out.captaindns.com [203.0.113.10])
    by mx-in.captaindns.com (Postfix) with ESMTPS id ABC123DEF
    for <support@captaindns.com>; Sat, 29 Mar 2026 10:15:02 +0100

Beschreibung: Jeder SMTP-Server, der die Nachricht verarbeitet, fügt einen Received-Header hinzu. Das ist die Routing-Spur der Nachricht.

Was es verrät: Die vollständige Route der Nachricht, Server für Server. Die Details jedes Hops (Serveridentität, verwendetes Protokoll, Zeitstempel) ermöglichen die Überprüfung der Legitimität des Routings. Eigener Abschnitt weiter unten.

Das Protokoll nach with ist ein wichtiges Sicherheitssignal. with ESMTPS bedeutet, dass die Verbindung zwischen den beiden Servern per TLS verschlüsselt war: Das ist der erwartete Standard in 2026. with ESMTP (ohne das S) bedeutet, dass die Nachricht unverschlüsselt übertragen wurde. Wenn du with ESMTP bei einem externen Hop (zwischen zwei verschiedenen Organisationen) siehst, ist das ein Problem: Der Nachrichteninhalt, einschließlich Anhänge, war für jeden lesbar, der den Netzwerkverkehr abfängt. with ESMTPSA zeigt eine authentifizierte und verschlüsselte Verbindung an (typischerweise ein E-Mail-Client, der sich mit Login/Passwort + TLS am SMTP-Server anmeldet).

DKIM-Signature

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=captaindns.com; s=s202603; t=1743238500;
    h=from:to:subject:date:message-id;
    bh=LjIq2t4u3qH0OwZ1E4fDn5t3nVz2Ay+KqR0kbD1XXXA=;
    b=dGVzdCBzaWduYXR1cmUgZXhhbXBsZQ==...

Beschreibung: Kryptografische Signatur, die vom Versandserver hinzugefügt wird. Der Empfangsserver überprüft diese Signatur anhand des im DNS veröffentlichten öffentlichen Schlüssels.

Was es verrät: Die wichtigsten Tags sind d= (signierende Domain), s= (Schlüsselselektor), a= (Algorithmus, rsa-sha256 ist Standard), h= (von der Signatur abgedeckte Header), bh= (Body-Hash) und b= (die Signatur selbst). Wenn d=captaindns.com und Authentication-Results dkim=pass zeigt, ist die Nachricht durch die Domain authentifiziert.

Das bh=-Tag (Body-Hash) ist ein kryptografischer Fingerabdruck des Nachrichtentexts. Der Empfangsserver berechnet diesen Hash neu und vergleicht ihn mit dem Wert im Header. Wenn der Body während des Transits geändert wurde (z. B. durch eine Mailingliste, die eine Fußzeile hinzufügt), stimmt der Hash nicht mehr überein und DKIM schlägt fehl. Das c=-Tag (Canonicalization) definiert die Toleranz für geringfügige Änderungen: relaxed/relaxed ist am nachsichtigsten (ignoriert überflüssige Leerzeichen), simple/simple ist strikt.

Authentication-Results

Authentication-Results: mx.captaindns.com;
    spf=pass (sender IP is 203.0.113.10) smtp.mailfrom=mail.captaindns.com;
    dkim=pass (2048-bit key) header.d=captaindns.com header.s=s202603;
    dmarc=pass (p=reject dis=none) header.from=captaindns.com

Beschreibung: Zusammenfassung der vom Empfangsserver durchgeführten Authentifizierungsprüfungen. Ein einzelner Header, der die SPF-, DKIM- und DMARC-Ergebnisse zusammenfasst.

Was es verrät: Das ist das wichtigste Feld zur Diagnose von E-Mail-Authentifizierungsproblemen. Eigener Abschnitt weiter unten.

X-Mailer und User-Agent

X-Mailer: CaptainDNS Mailer 2.1

Beschreibung: Identifiziert die zum Senden der Nachricht verwendete Client-Software. Optionales und nicht standardisiertes Feld.

Was es verrät: Eine geschäftliche E-Mail, die von einem ungewöhnlichen X-Mailer gesendet wurde (ein einfaches Python-Skript, ein Massenversand-Tool), kann verdächtig sein. Es ist ein ergänzender Hinweis, aber kein entscheidendes Kriterium.

X-MS-Exchange-Organization-SCL

X-MS-Exchange-Organization-SCL: 1

Beschreibung: Spam Confidence Level, vergeben von Microsoft Exchange. Skala von -1 (vertrauenswürdige Nachricht) bis 9 (sicherer Spam). Der Standard-Quarantäne-Schwellenwert ist 5.

Was es verrät: Wenn du Exchange oder Microsoft 365 verwendest, sagt dir dieser Score direkt, wie der Anti-Spam-Filter von Microsoft die Nachricht bewertet hat. Ein SCL von 5 oder höher erklärt, warum eine E-Mail als Junk eingestuft wurde.

Die ARC-Header

ARC-Seal: i=1; a=rsa-sha256; d=captaindns.com; s=arc202603; cv=none; ...
ARC-Message-Signature: i=1; a=rsa-sha256; d=captaindns.com; ...
ARC-Authentication-Results: i=1; mx.captaindns.com;
    spf=pass; dkim=pass; dmarc=pass

Beschreibung: ARC (Authenticated Received Chain) bewahrt Authentifizierungsergebnisse, wenn eine Nachricht Zwischenstationen durchläuft (Mailinglisten, automatische Weiterleitungen). Drei Header arbeiten zusammen: ARC-Authentication-Results (Ergebnisse am Relais-Punkt), ARC-Message-Signature (Nachrichtensignatur an diesem Punkt) und ARC-Seal (Kettensiegel).

Was es verrät: Wenn eine E-Mail weitergeleitet wird und SPF/DKIM aufgrund von Änderungen während des Transits fehlschlagen, ermöglicht ARC dem finalen Server zu überprüfen, ob die Authentifizierung ursprünglich gültig war. Das cv=-Feld (Chain Validation) zeigt an, ob die Kette intakt ist: none (erster Hop), pass (gültige Kette) oder fail (unterbrochene Kette). Mehr über die Funktionsweise von ARC erfährst du in unserem Leitfaden zu Authenticated Received Chain.

Header, die einen Drittanbieter-Dienst verraten

Wenn ein Unternehmen eine E-Mail über einen Drittanbieter-Dienst versendet (Marketing-Plattform, CRM, transaktionales Tool), bewahren die Header die Spuren der tatsächlichen Versandinfrastruktur. Das ist ein leistungsfähiges Werkzeug, um zu identifizieren, wer eine E-Mail wirklich gesendet hat, selbst wenn das From eine Unternehmensdomain anzeigt.

Signaturtabelle nach Anbieter

Anbieter	Verräterische Header	Typischer Return-Path	Message-ID / DKIM
SendGrid	X-SG-EID, X-SG-ID	@sendgrid.net oder @em.sendgrid.net	DKIM d=sendgrid.net (ohne Custom-DKIM)
Amazon SES	X-SES-Outgoing	@amazonses.com	Message-ID: @amazonses.com, DKIM d=amazonses.com
Mailgun	X-Mailgun-Sid, X-Mailgun-Variables	@mailgun.org	DKIM d=mailgun.org
Google Workspace	Received: from mail-*.google.com	@*.google.com	Message-ID: @mail.gmail.com
Microsoft 365	X-MS-Exchange-Organization-*, X-MS-Has-Attach	@*.outlook.com	DKIM d=*.onmicrosoft.com
Brevo (ex-Sendinblue)	X-Mailin-EID, X-Mailin-*	@mail-sib.com	DKIM d=sendinblue.com oder Custom
Postmark	X-PM-Message-Id	@pm.mtasv.net	DKIM d=pm.mtasv.net
Mailchimp	X-MC-User, X-Mailer: MailChimp Mailer	@mcsv.net oder @mail*.suw*.mcdlv.net	DKIM d=*.mcsv.net

Wie du diese Tabelle verwendest

Wenn du eine verdächtige E-Mail analysierst, suche nach nicht standardmäßigen X-*-Headern und der Domain des Return-Path. Wenn eine E-Mail behauptet, von contact@captaindns.com zu stammen, und die Header X-SG-EID mit einem Return-Path in @sendgrid.net enthalten, weißt du, dass die E-Mail über SendGrid lief. Das ist nicht zwangsläufig verdächtig: Du musst nur überprüfen, ob captaindns.com tatsächlich SendGrid als Versanddienstleister nutzt.

Wenn dagegen eine E-Mail behauptet, von deiner Bank zu stammen, aber die Header einen Versand über einen kleinen, unbekannten SMTP-Anbieter zeigen, mit DKIM signiert durch eine unverwandte Drittanbieter-Domain, ist das ein Warnsignal.

Die Received-Kette lesen (von unten nach oben)

Die Kette der Received-Header ist das Rückgrat des E-Mail-Routings. Jeder Server, der die Nachricht berührt, hinterlässt seine Spur.

Das Prinzip: Jeder Server fügt oben hinzu

Stelle dir einen Stapel Poststempel vor. Das Ursprungspostamt drückt den ersten Stempel auf. Jedes Zwischenpostamt fügt seinen darüber hinzu. Das Zielpostamt landet ganz oben auf dem Stapel.

Genau das passiert mit Received-Headern: Der finale Empfangsserver fügt seinen Header ganz oben ein. Der Ursprungsserver steht ganz unten. Um den chronologischen Weg der Nachricht zu rekonstruieren, lies die Received-Header von unten nach oben.

Anatomie eines Hops

Jeder Received-Header enthält vier Schlüsselinformationen:

Element	Bedeutung	Beispiel
from	Server, der die Nachricht übermittelt hat	mx-out.captaindns.com
by	Server, der die Nachricht empfangen hat	mx-in.captaindns.com
with	Verwendetes Protokoll	ESMTPS (SMTP verschlüsselt mit TLS)
Zeitstempel	Datum und Uhrzeit des Empfangs	Sat, 29 Mar 2026 10:15:02 +0100

Das with-Protokoll ist aufschlussreich:

• ESMTPS: SMTP mit TLS (verschlüsselt, das ist der erwartete Standard)
• ESMTP: SMTP ohne TLS (unverschlüsselt, potenzielles Problem)
• LMTP: Lokales Zustellprotokoll (letzter Hop, normal)

Konkretes Beispiel mit 4 Hops

Hier ist eine realistische Received-Kette für eine von captaindns.com empfangene E-Mail, die von einem externen Mitarbeiter über Gmail gesendet und von Mimecast gefiltert wurde. Die Header werden in der Reihenfolge gezeigt, wie sie in der Rohnachricht erscheinen (neueste zuerst):

(1) Received: from mx2.captaindns.com (10.0.0.5)
        by exchange.captaindns.com (10.0.0.10) with ESMTP;
        Fri, 29 Mar 2026 10:42:15 +0100

(2) Received: from gateway.mimecast.com (91.220.42.50)
        by mx2.captaindns.com with ESMTPS id A1B2C3D4;
        Fri, 29 Mar 2026 10:42:13 +0100

(3) Received: from mail-sor-f41.google.com (209.85.220.41)
        by gateway.mimecast.com with ESMTPS id E5F6G7H8;
        Fri, 29 Mar 2026 10:42:11 +0100

(4) Received: from [192.168.1.100] by smtp.gmail.com with ESMTPSA
        id I9J0K1L2; Fri, 29 Mar 2026 10:42:09 +0100

Leserichtung von unten nach oben (chronologische Reihenfolge):

1. Hop 4 (10:42:09, der älteste, unten): Der Absender sendet von seinem PC (private IP 192.168.1.100) über den SMTP-Server von Gmail. Das Protokoll ESMTPSA bestätigt eine authentifizierte und verschlüsselte Verbindung
2. Hop 3 (10:42:11): Gmail leitet die Nachricht an das Mimecast-Gateway weiter. ESMTPS zeigt eine TLS-Verbindung zwischen Google und Mimecast (Anti-Spam-/Sicherheitsfilter des Empfängers)
3. Hop 2 (10:42:13): Mimecast leitet die Nachricht nach Analyse an den MX-Server von captaindns.com weiter. ESMTPS-Verbindung, Verschlüsselung beibehalten
4. Hop 1 (10:42:15, der neueste, oben): Der interne MX leitet an den finalen Exchange-Server zur Zustellung in das Postfach des Empfängers weiter. ESMTP ohne TLS zwischen internen Servern, akzeptabel in einem privaten Netzwerk

Gesamte Transitzeit: 6 Sekunden. Das ist normal. Bei mehr als 30 Sekunden zwischen zwei aufeinanderfolgenden Hops liegt wahrscheinlich ein Leistungsproblem auf dem verantwortlichen Server vor.

Anomalien in der Kette erkennen

Inkonsistente Zeitstempel. Hop 3 datiert vor Hop 2? Das ist entweder eine desynchronisierte Uhr (häufig bei falsch konfigurierten Servern) oder ein manuell von einem Angreifer eingefügter Received-Header. Prüfe, ob der betreffende Server legitim ist.

Fehlende Hops. Die Nachricht geht von deinem Server direkt an einen unbekannten Server, ohne dein Gateway zu passieren? Ein nicht autorisierter Vermittler hat die Nachricht möglicherweise weitergeleitet, oder ein Server in der Kette erzeugt keinen Received-Header (selten, aber möglich).

Unbekannte Server. Ein Hostname oder eine IP, die du nicht in der Kette erkennst? Prüfe den Reverse-DNS der IP. Ein legitimer Server hat einen PTR-Eintrag, der mit seinem Hostnamen übereinstimmt. Ein kompromittierter Server oder ein offenes Relay hat oft einen generischen oder nicht vorhandenen PTR.

Private IPs in der Mitte der Kette. Adressen in 10.x.x.x oder 192.168.x.x sind beim ersten Hop normal (internes Netzwerk des Absenders). Sie sind verdächtig, wenn sie weiter hinten in der Kette auftauchen, da sie auf abnormales Routing hindeuten.

Authentication-Results: SPF, DKIM, DMARC

Der Authentication-Results-Header ist das Dashboard der E-Mail-Sicherheit. Er fasst in einer Zeile die Ergebnisse der drei Authentifizierungsprotokolle zusammen. Es ist der erste Header, den du bei der Diagnose eines Problems prüfen solltest.

Feldstruktur

Authentication-Results: mx.captaindns.com;
    spf=pass (sender IP is 203.0.113.10) smtp.mailfrom=mail.captaindns.com;
    dkim=pass (2048-bit key) header.d=captaindns.com header.s=s202603;
    dmarc=pass (p=reject dis=none) header.from=captaindns.com

Das erste Element (mx.captaindns.com) identifiziert den Server, der die Prüfungen durchgeführt hat. Jedes Ergebnis ist durch ein Semikolon getrennt.

Feld	Ergebnis	Bedeutung
spf=pass	✓	Der Versandserver ist durch den SPF-Eintrag autorisiert
dkim=pass	✓	Die kryptografische Signatur ist gültig (Selektor: s202603)
dmarc=pass	✓	SPF und DKIM sind mit der From-Domain abgeglichen (Richtlinie: reject)

SPF: Ist der Server autorisiert?

SPF (Sender Policy Framework) prüft, ob die IP-Adresse des Versandservers durch den DNS-SPF-Eintrag der Domain autorisiert ist.

Ergebnis	Bedeutung	Typische Aktion
pass	Die IP ist explizit autorisiert	Akzeptiert
fail	Die IP ist explizit verboten (-all)	Abgelehnt oder Spam
softfail	Die IP ist nicht autorisiert, aber nicht explizit verboten (~all)	Mit Vorbehalt akzeptiert
neutral	Die Domain äußert sich nicht (?all)	Keine Auswirkung
none	Kein SPF-Eintrag veröffentlicht	Keine Prüfung möglich
temperror	Temporärer DNS-Fehler	Späterer Versuch
permerror	Syntaxfehler im SPF-Eintrag	Variiert nach Server

Das Detail in Klammern (sender IP is 203.0.113.10) zeigt die geprüfte IP. Das Feld smtp.mailfrom gibt die SMTP-Envelope-Domain an.

DKIM: Ist die Nachricht unverändert?

DKIM überprüft die kryptografische Signatur der Nachricht. Wenn die Signatur gültig ist, wurde der Inhalt beim Transit nicht verändert und die signierende Domain ist authentifiziert.

Ergebnis	Bedeutung	Typische Aktion
pass	Signatur gültig	Authentifiziert
fail	Signatur ungültig (Nachricht verändert oder falscher Schlüssel)	Verdächtig
none	Keine DKIM-Signatur vorhanden	Keine Prüfung möglich
neutral	Signatur vorhanden, aber nicht überprüfbar	Keine Auswirkung
temperror	Temporärer DNS-Fehler beim Abrufen des Schlüssels	Erneuter Versuch
permerror	Fehler im DKIM-Eintrag	Variiert

Die wichtigen Details: header.d= gibt die signierende Domain an, header.s= den verwendeten Selektor. Diese Informationen ermöglichen dir zu überprüfen, welche Domain die Nachricht tatsächlich signiert hat und mit welchem Schlüssel.

DMARC: Stimmt die Ausrichtung?

DMARC überprüft, ob die From-Domain (für den Empfänger sichtbar) mit den durch SPF und/oder DKIM authentifizierten Domains übereinstimmt. Es ist die Schicht, die das Fälschen des From-Felds verhindert.

Ergebnis	Bedeutung	Typische Aktion
pass	SPF- oder DKIM-Ausrichtung verifiziert	Akzeptiert
fail	Keine gültige Ausrichtung	Wendet die p=-Richtlinie an
bestguesspass	Keine DMARC-Richtlinie veröffentlicht, aber der Server hält die Nachricht für legitim	Akzeptiert
none	Keine DMARC-Richtlinie veröffentlicht	Keine Aktion

DMARC-Details umfassen:

• p=: die von der Domain veröffentlichte Richtlinie (none, quarantine, reject)
• dis=: die vom Server tatsächlich angewandte Disposition
• header.from=: die geprüfte From-Domain

Kombiniertes Beispiel: Vollständige Analyse

Hier ist ein problematisches Authentication-Results:

Authentication-Results: mx.captaindns.com;
    spf=softfail (sender IP is 198.51.100.42) smtp.mailfrom=notifications.captaindns.com;
    dkim=fail (signature verification failed) header.d=captaindns.com header.s=s202603;
    dmarc=fail (p=quarantine dis=quarantine) header.from=captaindns.com

Diagnose:

• SPF softfail: Die IP 198.51.100.42 ist nicht im SPF-Eintrag von notifications.captaindns.com. Möglicherweise ein neuer Versandserver, der noch nicht eingetragen wurde
• DKIM fail: Die Signatur ist ungültig. Mögliche Ursachen: veralteter DNS-Schlüssel, Nachricht während des Transits verändert oder Schlüsselrotation nicht korrekt synchronisiert
• DMARC fail: Weder SPF noch DKIM bestehen mit Ausrichtung. Die quarantine-Richtlinie wird angewandt: Die Nachricht landet im Spam

Dieses Ergebnis deutet auf ein Konfigurationsproblem auf Absenderseite hin, nicht auf einen Angriff. Die Behebung umfasst die Aktualisierung des SPF-Eintrags und die Überprüfung des DKIM-Schlüssels.

Anti-Spam-Header

Über SPF/DKIM/DMARC hinaus fügen Anti-Spam-Filter eigene Header hinzu, um ihre Entscheidungen zu begründen.

X-Spam-Score und X-Spam-Status

X-Spam-Status: No, score=-2.1 required=5.0
    tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_PASS
X-Spam-Score: -2.1

SpamAssassin verwendet ein kumulatives Punktesystem. Jeder Test addiert oder subtrahiert Punkte. Ein Score über dem Schwellenwert (typischerweise 5,0) klassifiziert die Nachricht als Spam.

Häufige Tests:

Test	Typischer Score	Bedeutung
BAYES_00	-1,9	Inhalt ähnelt Ham (kein Spam) laut Bayes-Filter
DKIM_VALID_AU	-0,1	DKIM gültig und mit der Autordomain abgeglichen
SPF_PASS	-0,0	SPF bestanden
HTML_MESSAGE	+0,0	Nachricht enthält HTML (neutral)
URIBL_BLOCKED	+0,0	URI-Blocklisten konnten nicht abgefragt werden
BAYES_99	+3,5	Inhalt ähnelt stark Spam
MISSING_MID	+0,5	Keine Message-ID (verdächtig)

Der SCL-Score von Exchange

Der Header X-MS-Exchange-Organization-SCL vergibt einen Score von 0 bis 9:

SCL	Klassifizierung	Standardaktion
-1	Vertrauenswürdiger Absender (Positivliste)	Direkte Zustellung
0-1	Kein Spam	Posteingang
2-4	Wahrscheinlich kein Spam	Posteingang
5-6	Wahrscheinlich Spam	Junk-Ordner
7-9	Sicherer Spam	Ablehnung oder Quarantäne

Google-Header

Gmail zeigt in den Roh-Headern keinen Anti-Spam-Score an. Allerdings findest du:

• X-Google-DKIM-Signature: eine von Google zusätzlich zur Absendersignatur hinzugefügte DKIM-Signatur
• X-Gm-Message-State: interner Nachrichtenstatus in der Google-Infrastruktur (kodiert, nicht interpretierbar)
• X-Google-Smtp-Source: Kennung des Google-Servers, der die Nachricht verarbeitet hat

Die "Original anzeigen"-Ansicht von Gmail zeigt oben auf der Seite eine SPF/DKIM/DMARC-Zusammenfassung an, die besser lesbar ist als die Roh-Header.

Wie du die Ergebnisse interpretierst

Wenn ein Anti-Spam-Filter eine Nachricht als Spam einstuft, suche zuerst nach dem Authentication-Results-Header. Wenn SPF, DKIM und DMARC alle pass zeigen, liegt das Problem wahrscheinlich am Inhalt (verdächtige Schlüsselwörter, Text-zu-Bild-Verhältnis, gekürzte Links). Wenn eines der drei fehlschlägt, behebe zuerst die Authentifizierung, bevor du den Inhalt änderst.

Um zu verstehen, wie Angreifer Schwachstellen in Headern ausnutzen, um Filter zu umgehen, lies unseren Artikel über Warnsignale in E-Mail-Headern, die auf Filterumgehung hindeuten.

6 praktische Diagnoseszenarien

Szenario 1: Meine E-Mail landet im Spam

Zu prüfende Header: Authentication-Results, X-Spam-Score (oder SCL)

Methode:

1. Bitte den Empfänger, die Header der im Spam empfangenen Nachricht zu extrahieren
2. Prüfe Authentication-Results: Wenn spf=fail oder dkim=fail, ist das die wahrscheinliche Ursache
3. Wenn SPF/DKIM/DMARC alle pass zeigen, schaue auf den Anti-Spam-Score. Ein X-Spam-Score über 5,0 oder ein SCL von 5+ deutet auf inhaltsbasierte Filterung hin
4. Prüfe die Reputation deiner Versand-IP mit einem Blocklist-Checker

Konkretes Beispiel: Hier ist der Header, der erklärt, warum eine legitime E-Mail im Spam landet.

Authentication-Results: mx.empfaenger.com;
    spf=pass smtp.mailfrom=mail.captaindns.com;
    dkim=pass header.d=captaindns.com;
    dmarc=fail (p=quarantine dis=quarantine) header.from=captaindns.com

Hier bestehen SPF und DKIM, aber DMARC schlägt fehl. Die wahrscheinliche Ursache: Die SPF-Domain (mail.captaindns.com) ist nicht mit der From-Domain (captaindns.com) abgeglichen und DMARC verlangt eine strikte Ausrichtung (aspf=s). Die Disposition dis=quarantine bestätigt, dass die Nachricht in den Spam verschoben wurde.

Schnelle Behebung: Veröffentliche oder korrigiere deinen SPF-Eintrag, überprüfe deine DKIM-Signatur und richte eine DMARC-Richtlinie mindestens auf p=none ein, um Berichte zu empfangen.

Szenario 2: Kommt diese E-Mail wirklich von meinem Geschäftsführer?

Zu prüfende Header: From, Return-Path, DKIM-Signature, Authentication-Results

Konkretes Beispiel: Eine E-Mail, die scheinbar von deinem CEO stammt, aber ein CEO-Fraud ist.

From: Jean-Marc Duval - CEO <jm.duval@captaindns.com>
Return-Path: <jmduval.ceo@gmail.com>
Reply-To: jmduval.urgent@protonmail.com
Authentication-Results: mx.captaindns.com;
    spf=pass smtp.mailfrom=gmail.com;
    dkim=pass header.d=gmail.com;
    dmarc=fail header.from=captaindns.com

Der Anzeigename zeigt "Jean-Marc Duval - CEO" und die From-Adresse zeigt captaindns.com. Aber der Return-Path verweist auf ein Gmail-Konto, das Reply-To auf ProtonMail, und DMARC schlägt fehl, da DKIM von gmail.com signiert ist, nicht von captaindns.com. Das ist ein klassischer CEO-Fraud-Angriff (Business Email Compromise).

Methode:

1. Vergleiche das From mit dem Return-Path. Wenn sie auf verschiedene Domains verweisen ohne legitimen Grund (kein bekannter Drittanbieter-Versanddienst), ist das ein Warnsignal
2. Prüfe Authentication-Results: Ein dmarc=fail bei einer E-Mail, die angeblich von der Domain deines Unternehmens stammt, bestätigt Spoofing
3. Untersuche DKIM-Signature: Das d= sollte mit der Domain deines Unternehmens übereinstimmen
4. Schaue auf das Reply-To: Wenn es auf eine externe Domain verweist (gmail.com, protonmail.com), handelt es sich um einen klassischen CEO-Fraud

Goldene Regel: Wenn From eine Sache sagt und Authentication-Results eine andere, vertraue den Authentifizierungsergebnissen. Nur 4 % der Domains erzwingen eine DMARC-Richtlinie p=reject (Valimail 2025), was die Tür für diese Art von Spoofing bei der großen Mehrheit der Domains offen lässt.

Szenario 3: Wie lange war meine E-Mail unterwegs?

Zu prüfende Header: die Zeitstempel jedes Received-Headers

Methode:

1. Liste alle Received-Header von unten nach oben auf
2. Notiere den Zeitstempel jedes Hops
3. Berechne die Verzögerung zwischen jedem Paar aufeinanderfolgender Hops
4. Der Hop mit der größten Verzögerung ist der Engpass

Richtwerte:

• Weniger als 5 Sekunden zwischen zwei Hops: normal
• 5 bis 30 Sekunden: akzeptabel für einen ausgelasteten Server
• Mehr als 30 Sekunden: Greylisting, eine überlastete Warteschlange oder langsames DNS
• Mehr als 5 Minuten: Der Server hat die Nachricht wahrscheinlich in die Warteschlange gestellt und erneut versucht

Szenario 4: Ist mein DKIM korrekt signiert?

Zu prüfende Header: DKIM-Signature, Authentication-Results

Methode:

1. Finde den DKIM-Signature-Header in der Rohnachricht
2. Überprüfe, dass d= mit deiner Versanddomain übereinstimmt
3. Notiere den s=-Selektor und überprüfe, dass der entsprechende DNS-Eintrag veröffentlicht ist
4. Prüfe das DKIM-Ergebnis in Authentication-Results: dkim=pass bestätigt, dass alles funktioniert

Häufige Ursachen für DKIM-Fehler:

• DNS-Schlüssel gelöscht oder falsch veröffentlicht
• Schlüsselrotation ohne Aktualisierung des Versandservers
• Nachricht während des Transits verändert (durch eine Mailingliste oder ein URL-Rewriting-Tool)
• h=-Tag, das nicht alle geänderten Header abdeckt

Szenario 5: Ist dieser Link ein Phishing-Versuch?

Zu prüfende Header: From, Reply-To, Return-Path, Authentication-Results, ARC-*

Methode:

1. Prüfe das From: Ist die Domain genau die erwartete? Achte auf Homoglyphen (captaindns.com vs captaindnss.com vs captaindns.co)
2. Vergleiche mit dem Return-Path: Eine völlig andere Domain ist verdächtig
3. Prüfe Authentication-Results: spf=fail + dkim=fail + dmarc=fail bei einer angeblich legitimen E-Mail ist ein starkes Phishing-Signal
4. Wenn die Nachricht weitergeleitet wurde, prüfe die ARC-Authentication-Results-Header, um zu sehen, ob die Authentifizierung am Ursprungspunkt gültig war
5. Ein Reply-To zu einer kostenlosen E-Mail-Domain (gmail.com, yahoo.com) bei einer geschäftlichen E-Mail ist ein Phishing-Klassiker

Um tiefer in Spoofing-Techniken beim E-Mail-Routing einzutauchen, lies unsere Analyse zu Spoofing über E-Mail-Routing und die Microsoft-Warnung.

Szenario 6: Ein Lieferant behauptet, eine nie erhaltene E-Mail gesendet zu haben

Zu prüfende Header: Received-Zeitstempel, Authentication-Results

Kontext: Dein Lieferant behauptet, am 15. März eine Rechnung gesendet zu haben. Du hast sie nie erhalten. Wer hat recht?

Methode:

1. Bitte den Lieferanten, dir die vollständigen Header der Originalnachricht zu übermitteln (nicht eine Weiterleitung, sondern die Header der gesendeten Nachricht)
2. Prüfe den ersten Received-Header (ganz unten): Er enthält den Zeitstempel des ursprünglichen Versands. Wenn der Zeitstempel dem 15. März entspricht, wurde die Nachricht tatsächlich dem SMTP-Server übergeben
3. Folge der Received-Kette Hop für Hop. Wenn der letzte Hop eine Zustellung an deinen MX-Server zeigt, wurde die Nachricht von deiner Infrastruktur empfangen und das Problem liegt bei der Filterung
4. Wenn die Kette vor deinem MX endet, prüfe Authentication-Results: Ein spf=fail oder dmarc=fail könnte eine stille Ablehnung durch deinen Server ausgelöst haben

Tipp: Die Zeitstempel in den Received-Headern sind ein technisch zeitgestempelter Nachweis des Nachrichtentransits. Im Streitfall dokumentieren sie objektiv, ob die E-Mail gesendet wurde, wann, und wie weit sie in der Routing-Kette kam.

Aktionsplan: 5 Schritte zur Beherrschung der E-Mail-Header

Du hast jetzt das theoretische Wissen. So setzt du es in die Praxis um.

Schritt 1: Eine erste E-Mail extrahieren und analysieren

Wähle eine E-Mail, die du selbst gesendet hast (oder eine Test-E-Mail). Extrahiere die Header mit der für deinen E-Mail-Client passenden Methode. Füge sie in das E-Mail-Header-Analysetool ein und vergleiche das automatisierte Ergebnis mit deiner manuellen Analyse.

Schritt 2: Deine Authentifizierung überprüfen

Sende eine E-Mail von deiner Domain an eine Gmail-Adresse. Öffne die Header und überprüfe, dass SPF, DKIM und DMARC alle pass zeigen. Wenn eines der drei fehlschlägt, identifiziere und behebe die Ursache, bevor du zum nächsten Schritt übergehst.

Schritt 3: Anomalien erkennen lernen

Übe an legitimen E-Mails, um dein Gespür für Normalität zu kalibrieren. Wenn du weißt, wie eine "gesunde" E-Mail aussieht, werden Anomalien in einer verdächtigen E-Mail offensichtlich: unbekannte Server in der Received-Kette, Domains die zwischen From und Return-Path nicht übereinstimmen, ungültige DKIM-Signaturen.

Schritt 4: Überwachung automatisieren

Prüfe nicht bei jeder E-Mail manuell die Header. Konfiguriere DMARC mit rua=, um tägliche aggregierte Berichte zu erhalten. Diese Berichte warnen dich automatisch, wenn E-Mails die Authentifizierung für deine Domain nicht bestehen.

Schritt 5: Deine Versandflüsse dokumentieren

Erstelle eine Liste aller Dienste, die in deinem Namen E-Mails versenden (CRM, Marketing-Tool, Ticketing, Rechnungswesen). Für jeden einzelnen: Überprüfe, dass SPF und DKIM korrekt konfiguriert sind. Ein vergessener Versandfluss ist die häufigste Ursache für unerwartete DMARC-Fehler.

Pflege ein gemeinsames Dokument mit deinem Team, das jeden Dienst, die Versand-IP oder -Domain, den verwendeten DKIM-Selektor und das Datum der letzten Überprüfung auflistet. Dieses Nachschlagewerk erspart dir stundenlange Suche nach der Ursache eines DMARC-Fehlers, wenn ein Kollege ein neues Versandtool hinzufügt, ohne das technische Team zu informieren.

FAQ

Was ist ein E-Mail-Header?

Ein E-Mail-Header ist eine Metadatenzeile im Format "Name: Wert", die jede Nachricht begleitet. Header enthalten Routing-Informationen (durchlaufene Server), Authentifizierungsergebnisse (SPF, DKIM, DMARC), Absender- und Empfängeridentität sowie Anmerkungen von Anti-Spam-Filtern. Der Nachrichtentext (Text, Bilder, Anhänge) ist von den Headern durch eine Leerzeile getrennt.

Wie zeige ich Header in Gmail an?

Öffne die betreffende E-Mail, klicke auf das Menü mit den drei vertikalen Punkten oben rechts in der Nachricht und wähle dann "Original anzeigen". Gmail öffnet eine neue Seite mit den vollständigen Headern und einer Zusammenfassung der SPF-, DKIM- und DMARC-Ergebnisse oben. Du kannst alle Header mit dem Button "In die Zwischenablage kopieren" kopieren.

Warum werden Received-Header von unten nach oben gelesen?

Jeder SMTP-Server, der eine E-Mail verarbeitet, fügt seinen Received-Header über den bestehenden Headern hinzu. Der erste Server (Ursprung) steht daher unten und der letzte Server (Empfang) oben. Um den chronologischen Weg der Nachricht zu rekonstruieren, musst du die Received-Header von unten nach oben lesen. Das ist ein in RFC 5321 definierter Mechanismus.

Was bedeutet spf=softfail in Authentication-Results?

Ein spf=softfail-Ergebnis bedeutet, dass die IP-Adresse des Versandservers nicht explizit durch den SPF-Eintrag der Domain autorisiert ist, aber auch nicht explizit verboten. Das entspricht dem ~all-Mechanismus (Tilde) im SPF-Eintrag. Der Empfangsserver akzeptiert die Nachricht in der Regel, behandelt sie aber mit Vorbehalt. Es deutet oft auf einen vergessenen Versandserver in der SPF-Konfiguration hin.

Wie erkenne ich eine gefälschte E-Mail anhand der Header?

Vergleiche drei Elemente: das From-Feld (angezeigte Adresse), den Return-Path (Bounce-Adresse) und die Domain in DKIM-Signature (d=). Wenn das From eine legitime Domain zeigt, aber der Return-Path auf eine andere Domain verweist und Authentication-Results dmarc=fail zeigt, ist die Nachricht wahrscheinlich gefälscht. Ein SPF-Fail kombiniert mit einem DKIM-Fail bestätigt, dass der Versandserver nicht von der angezeigten Domain autorisiert ist.

Können E-Mail-Header gefälscht werden?

Einige Header können vom Absender gefälscht werden: From, Reply-To, Subject und sogar bestimmte Received-Header. Header, die vom Empfangsserver hinzugefügt werden (Authentication-Results, der Received-Header des finalen Servers, X-Spam-Score), sind jedoch zuverlässig, da sie von deiner eigenen Infrastruktur generiert werden. Deshalb solltest du dich immer auf die Authentifizierungsergebnisse des Empfangsservers verlassen, nicht auf die vom Absender gesetzten Header.

Was ist der Unterschied zwischen From und Return-Path?

From ist die im E-Mail-Client angezeigte Adresse, die vom Absender in den Nachrichten-Headern gesetzt wird. Return-Path ist die SMTP-Envelope-Adresse (MAIL FROM), die für Bounce-Benachrichtigungen verwendet wird. Sie können legitimerweise unterschiedlich sein, wenn ein Drittanbieter-Dienst E-Mails in deinem Namen versendet. DMARC prüft die Übereinstimmung zwischen diesen beiden Adressen: Wenn die Domains ohne triftigen Grund zu stark abweichen, kann die Nachricht die DMARC-Prüfung nicht bestehen.

Wie kann ich die Header-Analyse automatisieren?

Füge deine Roh-Header in ein Analysetool wie das von CaptainDNS ein. Das Tool zerlegt jedes Feld, berechnet Verzögerungen zwischen den Received-Hops, prüft Authentifizierungsergebnisse und hebt Anomalien hervor. Für eine kontinuierliche Überwachung konfiguriere DMARC mit einer rua=-Adresse, um tägliche aggregierte Berichte über die Authentifizierung aller von deiner Domain gesendeten E-Mails zu erhalten.

Glossar

• E-Mail-Header: eine Metadatenzeile im Format "Name: Wert", die jede Nachricht begleitet und Routing-, Authentifizierungs- und Verarbeitungsinformationen enthält.
• Received: ein Header, der von jedem SMTP-Server hinzugefügt wird, den die Nachricht durchläuft, und die Routing-Spur bildet. Wird von unten nach oben gelesen, um die chronologische Reihenfolge zu rekonstruieren.
• Return-Path: die SMTP-Envelope-Adresse (MAIL FROM), an die Bounce-Nachrichten gesendet werden. Wird vom finalen Empfangsserver hinzugefügt.
• Authentication-Results: ein vom Empfangsserver hinzugefügter Header, der die SPF-, DKIM- und DMARC-Prüfungsergebnisse zusammenfasst.
• SPF (Sender Policy Framework): ein Protokoll, das prüft, ob die IP-Adresse des Versandservers durch den DNS der Absenderdomain autorisiert ist (RFC 7208).
• DKIM (DomainKeys Identified Mail): ein kryptografisches Signatur-Authentifizierungsprotokoll, das die Integrität und Herkunft einer Nachricht überprüft (RFC 6376).
• DMARC (Domain-based Message Authentication, Reporting and Conformance): ein Protokoll, das die Übereinstimmung der From-Domain mit den durch SPF und DKIM authentifizierten Domains prüft (RFC 7489).
• ARC (Authenticated Received Chain): ein Mechanismus, der Authentifizierungsergebnisse bewahrt, wenn eine Nachricht Zwischenstationen wie Mailinglisten durchläuft.
• Folding: eine Technik zur Fortsetzung eines Headers über mehrere Zeilen, erkennbar an einer Einrückung (Leerzeichen oder Tab) am Anfang der Folgezeile.
• SCL (Spam Confidence Level): ein von Microsoft Exchange vergebener Spam-Score, von -1 (vertrauenswürdig) bis 9 (sicherer Spam).
• Hop: der Übergang einer Nachricht von einem SMTP-Server zu einem anderen in der Routing-Kette. Jeder Hop wird durch einen Received-Header dokumentiert.
• ESMTPS: Extended SMTP mit TLS, zeigt eine verschlüsselte Übertragung zwischen zwei Servern an.

Quellen

• RFC 5322 - Internet Message Format
• RFC 7601 - Message Header Field for Indicating Message Authentication Status
• RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures
• RFC 7208 - Sender Policy Framework (SPF)
• Google Support - View full message headers
• Verizon 2025 Data Breach Investigations Report (DBIR)
• IBM Cost of a Data Breach Report 2025
• Egress Email Security Risk Report 2024
• Valimail Email Authentication Report 2025