Source: https://once-email.com/de/blog/read-received-headers Zustellung und Authentifizierung · 3. Aug. 2026Aktualisiert 9. Aug. 2026 # So lesen Sie empfangene Header und verfolgen einen E-Mail-Zustellungspfad Folgen Sie den empfangenen Header-Feldern in der richtigen Reihenfolge, vergleichen Sie Zeitstempel sicher und erkennen Sie die Grenzen von Hostnamen, IP-Adressen und nicht vertrauenswürdigen Trace-Daten. [Once Email Redaktion, Once Email author Once Email Redaktion]() Geprüft von Once Email Fachredaktion Dabei hilft dieser Leitfaden Leser können einen Lieferpfad mit Zeitstempel erstellen, plausible Verzögerungspunkte erkennen und die Grenzen von Hostnamen, Adressen und nicht synchronisierten Uhren beschreiben. Artikelleitfaden Warum sich dieser Artikel lohnt **Eigene Analyse** Die Trace-Methode liest Hops von der vertrauenswürdigen Empfangsgrenze rückwärts und trennt beobachtete Relay-Beweise von Zeilen, die ein nicht vertrauenswürdiger Absender fabrizieren könnte. **Trendkontext** Cloud-Relays, Filter-Gateways und Datenschutz-Proxys fügen mehr Hops und Umschreibungen hinzu, aber jeder vertrauenswürdige Empfänger, der seinen eigenen Trace voranstellt, bleibt der nützliche Anker. **Praktischer Nutzen** Leser können einen Lieferpfad mit Zeitstempel erstellen, plausible Verzögerungspunkte erkennen und die Grenzen von Hostnamen, Adressen und nicht synchronisierten Uhren beschreiben. Eine E-Mail kann einen Anwendungsserver, ein ausgehendes Relay, einen Filterdienst und den Mail-Exchanger des Empfängers durchlaufen, bevor sie einen Posteingang erreicht. Jeder empfangende SMTP-Server fügt normalerweise ein ` Received `-Feld hinzu. Das Lesen dieser Felder kann dabei helfen, eine Verzögerung zu lokalisieren, den Server zu identifizieren, der die E-Mails an Ihren Anbieter weitergeleitet hat, und einen Zeitplan für die Zustellung zu erstellen. Bei den Feldern handelt es sich um diagnostische Beweise, nicht um eine vollständige Überwachungskette. Ein Absender kann vor der Übertragung gefälschte Zeilen hinzufügen, Uhren können nicht übereinstimmen und private Infrastruktur kann Details verbergen oder umschreiben. Verwenden Sie die Ablaufverfolgung zusammen mit Anbieterprotokollen, Authentifizierungsergebnissen und dem Kontext der Nachricht. ## [Was für ein empfangenes Feld ist es?]() [RFC 5321 Abschnitt 4.4]() erfordert einen SMTP-Server, der eine Nachricht zur Zustellung oder Weiterverarbeitung empfängt, um Trace-Informationen voranzustellen. Ein typisches Feld sieht so aus: „` text Received: from outbound.example.com (outbound.example.com [192.0.2.10]) by mx.example.net with ESMTPS id ABC123 for ; Mon, 03 Aug 2026 10:30:04 +0000 `“. Gemeinsame Klauseln beantworten unterschiedliche Fragen: - ` from ` beschreibt den von der sendenden Seite präsentierten Host und kann die auf der Netzwerkverbindung beobachtete Adresse enthalten; – ` by ` identifiziert den Server, der diesen Hop akzeptiert und das Feld geschrieben hat; - ` with ` beschreibt die Transport- oder Protokollvariante, z. B. ESMTP oder verschlüsseltes SMTP; – ` id ` ist eine Warteschlangen- oder Transaktionskennung, die nützlich ist, wenn ein Administrator die Protokolle dieses Servers durchsuchen kann; - ` for ` kann einen Umschlagempfänger identifizieren, obwohl dies optional ist und aus Datenschutzgründen entfernt werden kann; – Das Datum nach dem Semikolon gibt an, wann der empfangende Server die Nachricht angenommen hat, einschließlich eines numerischen Zeitzonenversatzes. Nicht jedes Feld enthält jede Klausel. Gateways und Nicht-SMTP-Systeme können unbekannte Formate erzeugen. RFC 5321 weist empfangende Systeme explizit an, mit unerwarteten Trace-Formatierungen robust umzugehen, anstatt eine Nachricht nur deshalb abzulehnen, weil eine Trace-Zeile ungewöhnlich aussieht. ## [Lesen Sie die Route von unten nach oben]() SMTP-Server stellen neue ` Received `-Felder über den vorhandenen voran. Der neueste Empfangs-Hop befindet sich daher oben im Header-Block. Der früheste aufgezeichnete Hopfen befindet sich normalerweise am unteren Ende. Betrachten Sie diese vereinfachte Spur: „` text Received: from filter.example.net by mx.recipient.example; Mon, 03 Aug 2026 10:30:07 +0000 Received: from outbound.sender.example by filter.example.net; Mon, 03 Aug 2026 10:30:04 +0000 Received: from app.internal.example by outbound.sender.example; Mon, 03 Aug 2026 10:29:59 +0000 `“. Lesen Sie es als: 1. ` app.internal.example ` hat die Nachricht an ` outbound.sender.example ` übergeben. 2. Der ausgehende Server hat es an ` filter.example.net ` übergeben. 3. Der Filter übergab es an den ` mx.recipient.example `-Server des Empfängers. Sortieren Sie die Felder nicht nach ihren sichtbaren Zeitstempeln. Die protokolldefinierte Feldreihenfolge ist nützlicher, da die Serveruhren möglicherweise falsch oder nicht synchronisiert sind. Konvertieren Sie jeden Zeitstempel nur in eine Zeitzone, wenn Sie die Verzögerung schätzen, und behalten Sie den Originalwert in allen Beweisdatensätzen bei. ## [Berechnen Sie die Verzögerung sorgfältig]() Subtrahieren Sie für jedes benachbarte Paar die frühere Empfangszeit von der späteren, nachdem Sie die numerischen Offsets angewendet haben. Eine große positive Lücke kann auf eine Warteschlange, eine Ratenbegrenzung, einen vorübergehenden Netzwerkausfall oder eine Verarbeitung beim nächsten Dienst hinweisen. Es identifiziert die Ursache nicht selbst. Eine negative Lücke deutet in der Regel auf einen Zeitversatz, einen Parsing-Fehler oder ein nicht vertrauenswürdiges Feld hin – keine Zeitreise und kein automatischer Fälschungsbeweis. Überprüfen Sie, ob die Offsets korrekt verarbeitet wurden und ob die beiden Zeilen von Systemen geschrieben wurden, die Sie steuern. Wenn Sie Ihre eigene Anwendung untersuchen, korrelieren Sie die Ablaufverfolgung mit Folgendem: – die UTC-Zeit, zu der die Anwendung die Nachricht angefordert hat; – die Warteschlangen-ID und das Zustellungsprotokoll des Absenders; - das erste ` Received `-Feld, das von einer vertrauenswürdigen Infrastruktur geschrieben wurde; - der Zeitpunkt, zu dem der Empfängeranbieter die Annahme oder Anzeige meldet; - alle vom sendenden System aufgezeichneten Wiederholungsstatus oder SMTP-Antworten. Die [Entwickler-E-Mail-Test-Checkliste]() erklärt, wie man die Zeitachse von der Anfrage bis zum Eingang aufzeichnet, ohne eine einzelne Posteingangsbeobachtung als das gesamte Zustellungssystem zu behandeln. ## [Entscheiden Sie, welchem ​​Hopfen Sie vertrauen können]() Das oberste ` Received `-Feld wurde von dem Server hinzugefügt, der dem von Ihnen angezeigten Postfach am nächsten liegt. Wenn dieser Postfachanbieter vertrauenswürdig ist, ist dieses Feld normalerweise der stärkste Ausgangspunkt: Es kann die Netzwerkadresse melden, von der der Anbieter die Nachricht tatsächlich angenommen hat. Arbeiten Sie nur so weit nach unten, bis die Felder mit der Ihnen bekannten Infrastruktur übereinstimmen. Zeilen, die angeblich erstellt wurden, bevor die Nachricht bei einem vertrauenswürdigen Anbieter einging, können vom Absender gefälscht sein. Ein böswilliger Absender kann normalerweise keine später von den Systemen des Empfängers hinzugefügten Felder umschreiben, kann aber plausibel aussehenden Trace-Text in die Nachricht einfügen, bevor diese Systeme ihn sehen. Hostnamen erfordern auch Kontext. Ein ` from `-Name kann aus einer SMTP-Begrüßung, einem Reverse-DNS oder einer lokalen Konfiguration stammen. Eine private Adresse wie ` 10.0.0.0/8 ` kann einen internen Hop beschreiben, kann jedoch nicht direkt über das öffentliche Internet verfolgt werden. Das Ergebnis der IP-Geolokalisierung ist ein ungefährer Wert und gibt keinen Rückschluss auf die Identität oder den physischen Standort des Autors. ## [Empfangene Felder ersetzen keine Authentifizierung]() ` Received `-Felder beschreiben Transport-Hops. SPF, DKIM und DMARC werten unterschiedliche Erkenntnisse zu Domänenautorisierung, Signaturen und Ausrichtung aus. Eine Route, die normal aussieht, kann eine bösartige Nachricht übertragen, und eine legitime weitergeleitete Nachricht kann eine komplizierte Route haben. Verwenden Sie den [SPF-, DKIM- und DMARC-Leitfaden]() , um die Authentifizierungsergebnisse separat zu interpretieren. Daraus sollte nicht geschlossen werden, dass die sichtbare ` From `-Adresse jeden Host in der Route kontrolliert oder dass ein bekanntes Relay den Inhalt sicher macht. ## [Verwenden Sie den lokalen Header-Analysator ohne Oversharing]() Der Once Email [E-Mail-Header-Analyser]() extrahiert ` Received ` Hops, Authentifizierungsergebnisse und wiederholte Felder im Browser. Fügen Sie nur Header-Felder ein – niemals ein Passwort, einen Bestätigungscode, einen Nachrichtentext oder einen Anhang. Das Tool kontaktiert die aufgelisteten Server nicht, überprüft deren Protokolle nicht und beweist nicht, dass ein Feld echt ist. Ersetzen Sie vor dem Teilen von Ergebnissen persönliche Adressen, öffentliche IP-Adressen, Warteschlangen-IDs und interne Hostnamen und behalten Sie dabei die Reihenfolge und die Zeitversätze bei, die zur Reproduktion des Problems erforderlich sind. Der [Test Evidence Redaction Guide]() bietet ein sichereres Berichtsmuster. ## [Eine zuverlässige Checkliste für die Interpretation]() Beginnen Sie oben, um das endgültige Empfangssystem zu identifizieren, und rekonstruieren Sie dann den Pfad von unten nach oben. Vertrauen Sie der Feldreihenfolge vor den Uhren. Normalisieren Sie Zeitzonen, kennzeichnen Sie negative oder ungewöhnlich lange Intervalle und markieren Sie die Grenze zwischen vertrauenswürdiger und vom Sender kontrollierter Infrastruktur. Korrelieren Sie Warteschlangen-IDs mit autorisierten Serverprotokollen, sofern verfügbar. Geben Sie vor allem die Grenze der Schlussfolgerung an. Eine Ablaufverfolgung könnte „Der Empfängeranbieter hat diese Verbindung zu diesem Zeitpunkt von diesem Relay akzeptiert“ unterstützen. Es kann in der Regel nicht nachweisen, wer die Nachricht geschrieben hat, ob jeder frühere Sprung echt ist oder ob seine Links und Anhänge sicher sind. ## Verwandte Leitfäden Bestätigungs-E-Mail kommt nicht an? Eine Checkliste zur sicheren Fehlerbehebung Bewältigen Sie Adressfehler, Absenderverzögerungen, Wiederholungsversuche, Filterung und Postfachbeschränkungen, ohne wiederholt Codes anzufordern oder die Kontosicherheit zu schwächen. [Bestätigungs-E-Mail kommt nicht an? Eine Checkliste zur sicheren Fehlerbehebung]() So lesen Sie SPF-, DKIM- und DMARC-Ergebnisse in einem E-Mail-Header Verstehen Sie, was SPF, DKIM und DMARC authentifizieren, warum Ausrichtung wichtig ist und warum ein bestandenes Ergebnis eher ein nützlicher Beweis als ein Beweis dafür ist, dass eine Nachricht sicher ist. [So lesen Sie SPF-, DKIM- und DMARC-Ergebnisse in einem E-Mail-Header]() Postfix vs. Dovecot: verschiedene Aufgaben beim E-Mail-Empfang Ordnen Sie Postfix, Dovecot, LMTP, Queue und IMAP im Eingangsweg ein und lokalisieren Sie Zustellfehler anhand von Belegen. [Postfix vs. Dovecot: verschiedene Aufgaben beim E-Mail-Empfang]() ## Datenschutzorientierte E-Mail-Werkzeuge E-Mail-Header-Analysator Erklärt Zustellstationen und fasst SPF-, DKIM- und DMARC-Hinweise zusammen, ohne absolute Echtheit zu behaupten. [E-Mail-Header-Analysator]() [Warum einige Websites Wegwerf-E-Mail-Adressen ablehnen Verstehen Sie die Kontowiederherstellungs-, Missbrauchs-, Support- und Risikogründe hinter den Beschränkungen für Wegwerf-E-Mails – und was legitime Benutzer tun sollten, anstatt sie zu umgehen.]() [Eine sichere Checkliste vor dem Herunterladen eines E-Mail-Anhangs Überprüfen Sie die Anfrage, den Absender, den Dateinamen, den Typ und die Verarbeitungsumgebung, bevor Sie einen Anhang herunterladen – und wissen Sie, was E-Mail-Vorschauen und Scanner nicht nachweisen können.]()