E-Mail-Header-Felder erklärt: Received, From, Return-Path und mehr

Die Kurzfassung

1. Wo Sie die Header finden. Jede Mail-App kann die vollständigen Header anzeigen, oft unter Namen wie Original anzeigen, Quelltext anzeigen oder Nachrichtendetails.
2. Die sichtbaren Felder: From, To, Subject, Date. From, To, Subject und Date sind die Felder, die eine Mail-App anzeigt.
3. Received: die Route. Jeder Server, der eine Nachricht bearbeitet, fügt oben eine Received-Zeile hinzu.
4. Return-Path, Reply-To und Message-ID. Return-Path enthält den Envelope-Sender, also die Adresse, an die Bounces gehen und gegen die SPF geprüft wird.
5. Authentication-Results. Der empfangende Server hält seine Ergebnisse für SPF, DKIM und DMARC in einer Authentication-Results-Zeile fest, zusammen mit den geprüften Kennungen wie smtp.mailfrom und header.d.
6. DKIM-Signature. Ein DKIM-Signature-Feld enthält die signierende Domain in d=, den Selector in s=, den Signaturalgorithmus in a= und die Liste der signierten Felder in h=.

Wo Sie die Header finden

Jede Mail-App kann die vollständigen Header anzeigen, oft unter Namen wie Original anzeigen, Quelltext anzeigen oder Nachrichtendetails. Kopieren Sie alles von der ersten Zeile bis zur ersten Leerzeile, denn dort enden die Header und beginnt der Nachrichtentext.

Sie können sie in unseren E-Mail-Header-Analyzer einfügen, der Route, Verzögerungen und Authentifizierungsergebnisse übersichtlich ordnet.

Die sichtbaren Felder: From, To, Subject, Date

From, To, Subject und Date sind die Felder, die eine Mail-App anzeigt. Sie werden vom Absender gesetzt und können beliebige Angaben enthalten, sind also für sich genommen kein Beweis dafür, woher eine Nachricht stammt. Ein Anzeigename kann eine andere Adresse enthalten als die echte, ein verbreiteter Spoofing-Trick.

Das Feld Date hält fest, wann der Absender die Nachricht verfasst hat. Vergleichen Sie es mit den Zeiten in den Received-Zeilen, um lange Verzögerungen zu erkennen.

Received: die Route

Jeder Server, der eine Nachricht bearbeitet, fügt oben eine Received-Zeile hinzu. Jede hält fest, von welchem Server er die Nachricht erhalten hat, welcher Server er selbst ist, das Protokoll und einen Zeitstempel. Lesen Sie sie von unten nach oben, um die Route in der richtigen Reihenfolge zu verfolgen.

Received: from mail.example.net (mail.example.net [203.0.113.5])
        by mx.example.org with ESMTPS id abc123
        for <you@example.org>; Tue, 13 Oct 2026 16:14:12 +0000

Der Abstand zwischen zwei Zeitstempeln ist die Zeit, die die Nachricht an einer Station verbracht hat. Große Abstände deuten meist auf eine Warteschlange, Greylisting oder einen erneuten Versuch hin. Zeilen unterhalb des ersten Servers, dem Sie vertrauen, können vom Absender geschrieben worden sein; gehen Sie damit vorsichtig um.

Return-Path, Reply-To und Message-ID

Return-Path enthält den Envelope-Sender, also die Adresse, an die Bounces gehen und gegen die SPF geprüft wird. Der empfangende Server fügt es hinzu. Reply-To gibt an, wohin Antworten gehen sollen, und wenn es sich von From unterscheidet, verdient es einen zweiten Blick. Message-ID ist eine eindeutige Kennung der Nachricht und endet meist auf die Domain des sendenden Systems.

Eine Message-ID, deren Domain sich von der From-Domain unterscheidet, ist üblich, wenn ein Dienst für Sie versendet, und für sich genommen kein Fehler.

Authentication-Results

Der empfangende Server hält seine Ergebnisse für SPF, DKIM und DMARC in einer Authentication-Results-Zeile fest, zusammen mit den geprüften Kennungen wie smtp.mailfrom und header.d. Diese Zeile lesen Sie zuerst, wenn Mails scheitern, und sie ist nur vertrauenswürdig, wenn Ihr eigener empfangender Server sie geschrieben hat.

Authentication-Results: mx.example.org;
 spf=pass smtp.mailfrom=bounce.example.net;
 dkim=pass header.d=example.net header.s=s1;
 dmarc=fail header.from=example.com

Pass, fail, softfail, neutral, none, temperror und permerror sind die üblichen Werte. Ein DMARC-fail bei bestandenem SPF und DKIM bedeutet fast immer, dass die bestandenen Domains nicht mit From aligned sind.

DKIM-Signature

Ein DKIM-Signature-Feld enthält die signierende Domain in d=, den Selector in s=, den Signaturalgorithmus in a= und die Liste der signierten Felder in h=. Der Empfänger nutzt d= und s=, um den öffentlichen Schlüssel im DNS zu finden und die Signatur zu prüfen.

Prüfen Sie, ob d= Ihre eigene Domain ist und h= das Feld From enthält. Eine mit a=rsa-sha1 erzeugte Signatur ist veraltet und schwach, und das Tag l=, das begrenzt, wie viel vom Nachrichtentext signiert wird, erlaubt es, nach der Signierung Text anzuhängen.

List-Unsubscribe und andere nützliche Felder

Marketing-Mails sollten List-Unsubscribe enthalten, und für die Ein-Klick-Abmeldung List-Unsubscribe-Post, was Gmail und Yahoo von Massenversendern verlangen. Manche Empfänger fügen Spamfilter-Felder hinzu, etwa X-Spam-Status, die zeigen, wie die Nachricht bewertet wurde.

ARC-Felder zeigen, dass ein Weiterleiter oder eine Mailingliste das Authentifizierungsergebnis festgehalten hat, das er gesehen hat. Das erklärt, warum SPF am Ende einer weitergeleiteten Nachricht fehlschlagen kann.

Weiterführende Literatur und Quellen

• RFC 5322: Internet Message Format
• RFC 8601: Message Header Field for Indicating Message Authentication Status
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 5321: Simple Mail Transfer Protocol

In MigoSMTP umsetzen: Artikel im Help-Center

• E-Mail-Header lesen, um die Authentifizierung zu debuggen
• SMTP-Bounce-Codes erklärt
• Eigene Return-Path- und Tracking-Domains

Verwandte Leitfäden und Tools

• E-Mail-Header-Analyzer: Header einfügen, Route und Ergebnisse erhalten.
• SPF-, DKIM- und DMARC-Checker: Die aktiven Records prüfen.
• SPF-, DKIM- und DMARC-Fehler beheben: Eine Fehlermeldung lesen und beheben.
• DMARC-Policy erklärt: Was Alignment bedeutet.