So verwenden Sie es
- Öffnen Sie die Nachricht in Ihrem Mailprogramm, suchen Sie die Original- oder vollständigen Header und kopieren Sie sie von der ersten Zeile bis zur Leerzeile.
- Fügen Sie sie in Rohheader ein. Die Seite liest sie in Ihrem Browser.
- Lesen Sie Stationen in Reihenfolge von der ersten bis zur letzten Station und die Spalte Verzögerung für die Zeit jedes Schritts.
- Lesen Sie SPF-Ergebnis, DKIM-Ergebnis und DMARC-Ergebnis. Ein pass ist grün; jedes andere Ergebnis ist rot.
Wie eine Mail ihren Weg aufzeichnet
Jeder Server, der eine Nachricht bearbeitet, fügt oben in den Headern eine Received-Zeile hinzu (RFC 5321, Abschnitt 4.4). Die Zeile nennt den Host, von dem er empfangen hat (from), den Host, an den er die Mail weitergegeben hat (by), das Protokoll (with) und hinter dem Semikolon ein Datum (RFC 5322, Abschnitt 3.6.7). Von unten gelesen ergeben die Zeilen den Weg in Reihenfolge.
- Die Verzögerung einer Station ist ihre Zeit minus die Zeit der Station davor, von unten nach oben gelesen.
- Die Uhr eines Servers kann falsch gehen. Eine negative oder lange Verzögerung sagt daher ebenso viel über die Uhr wie über das Netz.
Adressen und Ausrichtung
From ist die Adresse des Verfassers. Return-Path ist der Ort für Unzustellbarkeitsmeldungen; es ist die Adresse, die SPF prüft (RFC 5322, Abschnitte 3.6.2 und 3.6.7). DMARC vergleicht die From-Domain mit der Domain, die SPF oder DKIM geprüft hat. Bei der lockeren Ausrichtung, dem Standard, müssen beide nur dieselbe Organisationsdomain teilen; bei der strikten Ausrichtung müssen sie gleich sein (RFC 7489, Abschnitte 3.1 und 3.1.1). Reply-To ist der Ort, an den Antworten gehen, wenn das Feld gesetzt ist (RFC 5322, Abschnitt 3.6.2).
Authentifizierungsergebnisse
Ein empfangender Server hält seine Prüfungen in einem Authentication-Results-Header fest. Dessen erstes Wort ist die authserv-id dieses Servers. Jedes Ergebnis ist ein Verfahren mit einem Wert, etwa spf=pass, dkim=pass oder dmarc=pass (RFC 8601, Abschnitte 2.2 und 2.7). Received-SPF ist der ältere Header, der eine SPF-Prüfung festhält (RFC 7208, Abschnitt 9.1).
Beispiel: eine Nachricht über drei Server
Die Standardheader zeigen eine Nachricht von client.example.net, die über relay.example.net und mx.example.org lief, bevor sie mail.example.net erreichte. Von unten gelesen sind die drei Received-Zeilen auf 09:59:21, 10:00:03 und 10:02:14 datiert. Der zweite Schritt dauerte also 42 Sekunden, der dritte 2 Minuten 11 Sekunden.
Der Authentication-Results-Header meldet für example.net spf=pass, dkim=pass und dmarc=pass. Antworten gehen an [email protected], eine andere Domain. Die Seite markiert das, weil eine Antwort, die die Domain des Absenders verlässt, eine Prüfung wert ist.
| Messwert | Wert |
|---|---|
| Received-Zeilen | 3 |
| Zeit von der ersten bis zur letzten Station | 2 min 53 s |
| SPF | pass (example.net) |
| Reply-To | Antworten gehen an example.org, nicht an example.net. Prüfen Sie, ob das so gewollt ist (RFC 5322, Abschnitt 3.6.2). |
Häufig gestellte Fragen
Warum stehen die Stationen in umgekehrter Reihenfolge zu den Received-Zeilen?
Jeder Server setzt seine Received-Zeile nach oben, daher steht die neueste Station zuerst in den Headern (RFC 5321, Abschnitt 4.4). Die Seite kehrt die Reihenfolge um, sodass die erste Zeile der Server ist, den die Mail zuerst verlassen hat.
Kann ich den Received-Zeilen vertrauen?
Jeder Server schreibt seine eigene Zeile. Die Namen und Adressen darin sind jedoch das, was dieser Server gemeldet hat, und der Absender kann eigene Zeilen hinzufügen. Die obersten Zeilen wurden zuletzt von den Servern hinzugefügt, die Ihnen am nächsten sind, und verdienen die meiste Aufmerksamkeit.
Was bedeutet eine negative Verzögerung?
Eine Station, die früher datiert ist als die davor, bedeutet, dass die Uhren zweier Server nicht übereinstimmen oder eine Zeitzone falsch gelesen wurde. Es ist ein Zeichen für einen Uhrenfehler, nicht für ein schnelleres Netz.
Was ist Authentication-Results?
Ein Header, den ein empfangender Server hinzufügt, um festzuhalten, was er geprüft hat, etwa SPF, DKIM und DMARC, und das Ergebnis jeder Prüfung (RFC 8601). Sein erstes Wort nennt diesen Server; nur dem Header Ihres eigenen Empfangsservers sollte man vertrauen (Abschnitt 2.5).
Warum ist die Reply-To-Domain wichtig?
Antworten gehen an Reply-To, wenn es gesetzt ist, sonst an From (RFC 5322, Abschnitt 3.6.2). Nennt es eine andere Domain, verlassen Antworten die Domain, von der die Nachricht kam. Das ist an sich nicht falsch, lohnt aber eine Prüfung.
Sendet dieses Werkzeug meine Header irgendwohin?
Nein. Die Header werden in Ihrem Browser gelesen. Nichts wird gesendet oder gespeichert.
Quellen
- RFC 5322 (englisch): Internet Message Format
- RFC 5321 (englisch): Simple Mail Transfer Protocol, Ablaufinformationen
- RFC 8601 (englisch): Message Header Field for Indicating Message Authentication Status
- RFC 7208 (englisch): Sender Policy Framework (SPF)
- RFC 7489 (englisch): DMARC
Zahlen und Text zuletzt geprüft: Dienstag, 10. November 2026.