# E-Mail-Header-Analyse

Füge die Roh-Header einer einzelnen E-Mail ein und sieh, wer sie geschickt hat, ob SPF, DKIM und DMARC bestanden haben und wie lange jeder Server sie unterwegs aufgehalten hat. Die Header werden in deinem Browser ausgewertet und nie hochgeladen.

## Kurz gesagt

Jeder Mailserver, der eine Nachricht weiterreicht, setzt eine Received-Zeile an den Anfang ihres Headers (RFC 5321, Abschnitt 4.4). Die Kette liest sich daher von unten nach oben: Die unterste Zeile ist der erste Hop. Der empfangende Server hält seine Prüfungen von SPF, DKIM und DMARC in Authentication-Results fest (RFC 8601), und DMARC besteht, wenn SPF oder DKIM für eine Domain besteht, die zur From-Adresse passt (RFC 9989, das RFC 7489 im Mai 2026 abgelöst hat).

### So wird es ermittelt

Der eingefügte Text wird entfaltet (Folgezeilen werden an ihre Kopfzeile angehängt) und bis zur ersten Leerzeile als Header-Felder gelesen. Die Received-Zeilen werden von alt nach neu sortiert, und aus der Zeitangabe nach dem jeweiligen Semikolon ergibt sich die Verzögerung zwischen den Hops. Für die Ergebnisse von spf, dkim und dmarc werden Authentication-Results und Received-SPF gelesen; jedes Ergebnis bleibt erhalten, sodass zwei DKIM-Signaturen, von denen eine besteht und eine scheitert, als „pass, fail“ erscheinen. Das Alignment wird zwischen der From-Domain und den Domains aus DKIM-`d=` und Return-Path geprüft. Nichts verlässt deinen Browser.

### Beispiel

Das eingebaute Beispiel hat zwei Received-Zeilen mit den Zeitstempeln 14:02:09 und 14:02:11 (+0000); es zeigt also 2 Hops und insgesamt 2,0 s. Seine Authentication-Results-Zeile verzeichnet dkim=pass für shop.example, spf=pass und dmarc=pass, und die DKIM-Domain shop.example ist identisch mit der From-Domain, stimmt also überein.

### Grenzen

- Die Ergebnisse werden so gelesen, wie der empfangende Server sie geschrieben hat; die Seite fragt kein DNS ab und prüft DKIM-Signaturen nicht erneut.
- Jeder Server, auch der des Absenders, kann eine gefälschte Received-Zeile einfügen; vertrauen kannst du nur den Zeilen, die dein eigener Anbieter hinzugefügt hat.
- Relaxed Alignment zwischen benachbarten Subdomains lässt sich nur mit der Public Suffix List bestätigen, die die Seite nicht lädt; solche Paare erscheinen daher als „stimmt möglicherweise überein“.

### Quellen

- [RFC 5321, section 4.4: Trace Information](https://www.rfc-editor.org/rfc/rfc5321#section-4.4): wie Received-Zeilen hinzugefügt werden.
- [RFC 8601: Authentication-Results Header Field](https://www.rfc-editor.org/rfc/rfc8601): wie Prüfungen festgehalten werden.
- [RFC 7208: Sender Policy Framework (SPF)](https://www.rfc-editor.org/rfc/rfc7208): SPF-Ergebnisse.
- [RFC 6376: DomainKeys Identified Mail (DKIM)](https://www.rfc-editor.org/rfc/rfc6376): DKIM-Signaturen und d=.
- [RFC 9989: DMARC](https://www.rfc-editor.org/rfc/rfc9989): Alignment und das DMARC-Ergebnis; ersetzt RFC 7489.

## Was das Tool macht

Jeder Mailserver, der eine Nachricht weiterreicht, fügt oben in ihrem Header Zeilen hinzu, und der Server, der sie schließlich annimmt, vermerkt, ob der Absender seine Prüfungen bestanden hat. Heraus kommt ein langer, mehrfach umbrochener Textblock, der sich mit bloßem Auge nur mühsam lesen lässt. Dieses Tool wertet die Roh-Header einer E-Mail aus und ordnet sie in fünf Teile:

- **Zusammenfassung**: From, To, Subject, Date, Message-ID, Return-Path und Reply-To.
- **Authentifizierung**: die Ergebnisse von SPF, DKIM und DMARC (pass, fail, none usw.) aus den Headern Authentication-Results und Received-SPF, dazu Domain (`d=`) und Selektor (`s=`) jedes DKIM-Signature-Headers.
- **Alignment**: ob die From-Domain mit der Domain aus DKIM-`d=` und mit der Return-Path-Domain übereinstimmt.
- **Received-Kette**: jeder Hop, nummeriert vom ältesten an, mit den Hosts aus from und by, dem Protokoll (etwa ESMTPS), dem Zeitstempel und der Verzögerung seit dem vorherigen Hop, dazu die gesamte Zustelldauer.
- **Warnungen**: ein Reply-To, das von From abweicht, Hops mit Zeitstempeln in falscher Reihenfolge oder mit Uhrabweichung sowie fehlende Authentifizierungsergebnisse.

Die Auswertung erledigt JavaScript in deinem Browser. Nichts wird hochgeladen oder irgendwohin gesendet, und einmal geladen funktioniert die Seite auch ohne Netzverbindung. Das Tool prüft DKIM-Signaturen nicht kryptografisch und fragt kein DNS ab; es gibt wieder, was die empfangenden Server in die Header geschrieben haben.

## So nutzt du das Tool

1. Öffne den Quelltext der Nachricht. In Gmail klickst du neben „Antworten“ auf das Dreipunkt-Menü und wählst „Original anzeigen“. Im klassischen Outlook für Windows öffnest du die Nachricht per Doppelklick in einem eigenen Fenster, wählst „Datei“ und dann „Eigenschaften“ und kopierst den Inhalt des Felds „Internetkopfzeilen“. In Outlook im Web und im neuen Outlook öffnest du das Dreipunkt-Menü „Weitere Aktionen“, dann „Anzeigen“ und dort „Nachrichtendetails anzeigen“. In Apple Mail wählst du „Darstellung“ > „E-Mail“ > „Reine Datei“.
2. Kopiere den Header-Block: alles bis zur ersten Leerzeile. Den Nachrichtentext darunter brauchst du nicht.
3. Füge ihn in das Feld auf dieser Seite ein.
4. Lies zuerst die Zusammenfassung und die Authentifizierungsergebnisse, dann die Warnungen und zum Schluss die Liste der Hops.

Beim Weiterleiten gehen die ursprünglichen Header verloren. Arbeite deshalb mit der Kopie im Postfach, das die Nachricht empfangen hat, oder bitte den Empfänger, sie *als Anhang* weiterzuleiten.

## Wofür du es brauchst

- **Eine verdächtige Nachricht prüfen.** Eine Zahlungsaufforderung eines Lieferanten zeigt `dmarc=fail`, eine DKIM-Domain in `d=`, die nichts mit der From-Domain zu tun hat, und ein abweichendes Reply-To. Das reicht, um sie zu melden, statt zu antworten.
- **Herausfinden, wo eine Verzögerung entstand.** Eine Mail zum Zurücksetzen des Passworts kommt 40 Minuten zu spät. Die meisten Hops brauchten ein, zwei Sekunden, aber ein Relay hielt sie 38 Minuten fest – damit weißt du, nach wessen Warteschlange du fragen musst.
- **Die eigene Domain testen.** Nachdem du einen Newsletter-Dienst angebunden hast, schick dir selbst eine Testmail und prüfe, ob SPF und DKIM bestehen und ob in `d=` deine Domain steht und nicht die gemeinsam genutzte Domain des Dienstes.
- **Eine Nachricht in Logs wiederfinden.** Gib deinem Mail-Administrator die Message-ID und den Zeitpunkt, zu dem dein Anbieter die Nachricht angenommen hat; nach beidem lässt sich in Zustellprotokollen suchen.
- **Transportverschlüsselung bestätigen.** ESMTPS bei einem Hop heißt, dieser Abschnitt lief über TLS; reines ESMTP oder SMTP heißt, er lief unverschlüsselt.

## Die Received-Kette lesen – und was sich fälschen lässt

Jeder Server setzt seine Received-Zeile über die bereits vorhandenen, der neueste Hop steht also oben. Von unten nach oben gelesen, folgst du der Nachricht in zeitlicher Reihenfolge; das Tool dreht die Reihenfolge für dich um.

```
Received: from mx-out.shop.example (mx-out.shop.example [198.51.100.25])
        by mx1.recipient.example with ESMTPS id 4f2ac81e
        for <you@recipient.example>; Tue, 6 Oct 2026 14:02:11 +0000
Received: from app01.internal (app01.internal [10.0.4.7])
        by mx-out.shop.example with ESMTP id 91c0d3;
        Tue, 6 Oct 2026 14:02:09 +0000
```

Wem du trauen kannst, hängt davon ab, wer die jeweilige Zeile geschrieben hat. Such den frühesten Hop, den dein eigener Anbieter hinzugefügt hat, hier den mit dem Stempel von `mx1.recipient.example`. Diese Zeile und alles danach sind verlässlich, und die IP-Adresse in eckigen Klammern darin gehört der Maschine, die die Nachricht tatsächlich übergeben hat. Alles, was davor festgehalten wurde – im Rohtext also darunter –, stammt von der Absenderseite und kann erfunden sein, auch gefälschte Received-Zeilen, die eine andere Herkunft vortäuschen. From, Reply-To, Subject, Date und Message-ID legt ebenfalls der Absender fest.

Jeder Zeitstempel stammt von der Uhr des jeweiligen Servers. Eine Verzögerung von ein paar Sekunden unter null bedeutet meist, dass eine Uhr leicht falsch geht. Lange Lücken deuten auf eine Warteschlange hin, auf einen erneuten Zustellversuch nach einer vorübergehenden Ablehnung oder auf eine Nachricht, die zur Prüfung zurückgehalten wurde.

## Was SPF, DKIM und DMARC jeweils belegen

**SPF** vergleicht die IP-Adresse der eingehenden Verbindung mit den Servern, die eine Domain im DNS aufführt. Geprüft wird die Domain des Envelope-Absenders, die später zum Return-Path wird, nicht die sichtbare From-Adresse. Ein „pass“ belegt nur, dass dieser Server für die Return-Path-Domain senden darf. Weiterleitungen bringen SPF oft zum Scheitern, weil der weiterleitende Server nicht auf der Liste steht.

**DKIM** ist eine Signatur über den Nachrichtentext und ausgewählte Header. `d=` nennt die signierende Domain, `s=` den Selektor, über den ihr öffentlicher Schlüssel gefunden wird. Ein „pass“ bedeutet, dass die signierten Teile nicht verändert wurden und die Domain in `d=` sich für sie verbürgt. Über From sagt das nichts, solange die Domains nicht übereinstimmen.

**DMARC** verknüpft beide Prüfungen mit der Adresse, die Leser sehen: Es besteht, wenn SPF oder DKIM besteht und die Domain der erfolgreichen Prüfung zur From-Domain passt. Eine Nachricht kann SPF und DKIM für die eigenen Domains eines Massenversenders bestehen, während in der From-Zeile eine Bank steht – DMARC besteht dann trotzdem nicht.

```
Authentication-Results: mx1.recipient.example;
       dkim=pass header.d=shop.example header.s=s2026;
       spf=pass smtp.mailfrom=bounce.shop.example;
       dmarc=pass header.from=shop.example
```

Im Standardmodus von DMARC (relaxed) passt `bounce.shop.example` zu `shop.example`, weil beide dieselbe Organisationsdomain haben. Prüfe, ob der erste Name in diesem Header der Server deines Anbieters ist: Ein Absender kann eine gefälschte Authentication-Results-Zeile einfügen, und sorgfältige Empfangsserver entfernen solche Zeilen.

Schau zum Schluss hinter den Anzeigenamen. Bei `PayDesk Billing <billing@paydesk-help.example>` zeigen die meisten Mailprogramme nur den freundlichen Namen, die Prüfungen oben betreffen aber die Adresse.

## Häufige Fragen

**Wird der eingefügte Header an iseeu.cc gesendet?**

Nein. Der Header wird von JavaScript in deinem Browser ausgewertet und weder hochgeladen noch sonst irgendwohin gesendet. Du kannst das selbst überprüfen: Schalte das WLAN aus, nachdem die Seite geladen ist, und starte die Analyse noch einmal – offline kommen dieselben Ergebnisse heraus. Unabhängig davon protokolliert iseeu.cc weder IP-Adressen noch Abfragen, führt keine Besucherdatenbank, setzt keine Cookies und zeigt keine Werbung.

**Heißt „dkim=pass“ hier, dass die Signatur gültig ist?**

Es heißt, dass der empfangende Server beim Eingang der Nachricht ein „pass“ vermerkt hat. Dieses Tool wiederholt die kryptografische Prüfung nicht und holt auch keinen öffentlichen Schlüssel aus dem DNS; es liest das Ergebnis aus dem Header Authentication-Results. Meist ist genau das sinnvoll, denn Absender wechseln ihre Schlüssel, und eine Signatur, die Wochen später geprüft wird, kann scheitern, obwohl sie bei der Zustellung gültig war.

**Warum scheitert SPF bei einer E-Mail, die garantiert echt ist?**

Die häufigste Ursache ist eine Weiterleitung. Wird eine Nachricht weitergeleitet oder über eine Mailingliste verschickt, verbindet sich der weiterleitende Server von seiner eigenen IP-Adresse aus, und die steht nicht im SPF-Eintrag des ursprünglichen Absenders. Dasselbe passiert, wenn ein Absender einen neuen Maildienst einbindet, ohne SPF anzupassen. Besteht DKIM weiterhin mit einer Domain, die zur From-Adresse passt, kann DMARC trotzdem bestehen.

**Warum haben manche Hops eine negative Verzögerung?**

Jeder Server schreibt den Zeitstempel seiner Received-Zeile nach seiner eigenen Uhr, und diese Uhren laufen nicht exakt synchron. Scheint ein Hop ein, zwei Sekunden vor dem vorherigen anzukommen, geht meist eine Uhr leicht falsch. Größere Sprünge rückwärts auf der Absenderseite der Kette können aber auch bedeuten, dass eine Received-Zeile erfunden wurde. Das Tool markiert Zeitstempel in falscher Reihenfolge und Uhrabweichungen, damit du entscheiden kannst, was zutrifft.

**Wie erkenne ich am Header eine Phishing-Mail?**

Vergleiche den Anzeigenamen mit der tatsächlichen From-Adresse und prüfe dann, ob DMARC bestanden hat und ob die DKIM-Domain zur From-Domain passt. Ein Reply-To, das von From abweicht, ist ein klassisches Warnzeichen: Antworten gehen dann an den Angreifer, auch wenn die From-Zeile echt aussieht. Sieh dir außerdem den ersten Hop an, den dein eigener Anbieter hinzugefügt hat: Die sendende IP-Adresse dort hat dein Anbieter festgehalten, nicht der Absender.

**Warum gibt es für meine E-Mail keine Authentifizierungsergebnisse?**

Nicht jedes empfangende System schreibt einen Authentication-Results-Header. Manche Firmenmailserver und ältere Systeme lassen ihn weg, und Mails zwischen Nutzern desselben internen Servers werden oft gar nicht geprüft. Auch Header aus einer weitergeleiteten Kopie haben die ursprünglichen Ergebnisse verloren. Findet das Tool keine, zeigt es eine Warnung; als Anhaltspunkte bleiben dann die Liste der Hops und die Domains aus DKIM-Signature.

**Was bedeuten ESMTP, ESMTPS und ESMTPSA bei einem Hop?**

Sie beschreiben die Verbindung, über die ein Server die Nachricht empfangen hat. ESMTP ist erweitertes SMTP ohne Verschlüsselung. RFC 3848 hat die Varianten ergänzt: ESMTPS heißt, die Verbindung lief über TLS, ESMTPA heißt, der sendende Client hat sich angemeldet, und ESMTPSA heißt beides. Jede Angabe gilt nur für diesen einen Hop; eine Nachricht kann also auf manchen Abschnitten verschlüsselt sein und auf anderen nicht. LMTP taucht oft beim letzten internen Zustellschritt auf.

**Kann ich mit dem Header beweisen, wer mir die E-Mail geschickt hat?**

Nein. Die Analyse gibt wieder, was die empfangenden Server in den Header geschrieben haben, und wendet einfache Heuristiken an. Verlassen kannst du dich nur auf die Zeilen, die dein eigener Anbieter hinzugefügt hat; alles, was im Rohtext darunter steht, kann die Absenderseite erfunden haben. Geht es um Geld oder Zugangsdaten, frag über einen Kanal nach, dem du bereits vertraust.

Die Analyse gibt wieder, was empfangende Server in die Header geschrieben haben, und wendet einfache Heuristiken an. Sie kann nicht beweisen, wer eine Nachricht geschickt hat; geht es um Geld oder Zugangsdaten, frag über einen Kanal nach, dem du bereits vertraust.

## Passende Tools

- [DNS-Abfrage](https://iseeu.cc/de/dns-abfrage/): A-, AAAA-, MX-, TXT-, NS-, CNAME-, CAA- und SOA-Einträge über DNS-over-HTTPS.
- [Whois-/RDAP-Abfrage](https://iseeu.cc/de/whois/): Registrierungsdaten zu Domains, IP-Adressen und AS-Nummern.
- [Security-Header-Check](https://iseeu.cc/de/security-header-check/): Ruft die Response-Header einer URL ab und bewertet HSTS, CSP und die übrigen.
- [Punycode-Konverter](https://iseeu.cc/de/punycode-konverter/): Wandelt Domains mit Umlauten und anderen Schriften in die xn--Form und zurück.
- [Wie ist meine IP?](https://iseeu.cc/de/): Deine IP-Adresse, Standort, Netzwerk, Header, TLS und Leak-Tests auf einer Seite.

[Alle Tools ansehen](https://iseeu.cc/de/tools/)

Zuletzt aktualisiert: 2026-10-11

Originalseite: https://iseeu.cc/de/e-mail-header-analysieren/