E-Mail-Header-Analyzer

Was sind E-Mail-Header?

Jede E-Mail enthält eine Reihe versteckter Metadatenfelder, die sogenannten Header. Sie werden von jedem Mailserver auf dem Übertragungsweg eingetragen und dokumentieren den vollständigen Weg der Nachricht vom Absender bis zum Empfänger. Die meisten E-Mail-Clients blenden sie standardmäßig aus — sichtbar sind normalerweise nur Von, An, Betreff und Datum — doch die Rohdaten enthalten deutlich mehr Informationen.

Header folgen dem RFC 5322-Format: ein Feld pro Zeile, bestehend aus Feldname, Doppelpunkt und Wert. Mehrzeilige Werte werden mit führendem Leerzeichen (Folding) fortgesetzt. Der neueste Header steht oben, ältere darunter.

Jeder Received:-Header wird von einem Mailserver hinzugefügt, der die Nachricht weiterleitet. Von unten nach oben gelesen ergibt sich der vollständige Zustellungsweg.

Was dieses Tool besonders macht

Die meisten Header-Analyzer zeigen die Rohwerte in einer Tabelle oder als flache Liste an. Dieses Tool geht weiter: Es löst DNS-Einträge in Echtzeit auf, verfolgt Authentifizierungsketten und dekodiert proprietäre Microsoft 365-Header — um nicht nur was passiert ist zu zeigen, sondern warum und an welcher genauen Stelle etwas schiefgelaufen ist.

Referenz: Standard-Headerfelder

Die häufigsten Felder, denen Sie in E-Mail-Headern begegnen:

SPF, DKIM, DMARC — Kurzreferenz

SPF (Sender Policy Framework)

SPF ermöglicht es einem Domain-Inhaber, in DNS zu veröffentlichen, welche Mailserver berechtigt sind, E-Mails im Namen dieser Domain zu versenden. Der empfangende Server vergleicht die sendende IP mit dem TXT-Eintrag der Domain, die im SMTP-Befehl MAIL FROM (Envelope-Absender) angegeben ist. Häufige Mechanismen:

• ip4:1.2.3.0/24 — eine IPv4-Adresse oder einen Adressbereich autorisieren
• ip6:2001:db8::/32 — eine IPv6-Adresse oder einen Adressbereich autorisieren
• a: / mx: — IPs aus A- oder MX-Einträgen autorisieren
• include:andere.domain — SPF-Record einer anderen Domain einbinden (verwendet von ESPs wie Microsoft 365, Google, SendGrid)
• ~all — Softfail: nicht aufgeführte IPs sind wahrscheinlich nicht autorisiert (zugestellt, aber markiert)
• -all — Hardfail: nicht aufgeführte IPs sind nicht autorisiert (sollte abgelehnt werden)

SPF-Alignment für DMARC: Die Envelope-From-Domain (die SPF prüft) muss auf organisatorischer Ebene mit der From:-Header-Domain übereinstimmen. Viele ESPs verwenden standardmäßig ihre eigene Return-Path-Domain, was das SPF-Alignment bricht — sofern kein benutzerdefinierter Return-Path-CNAME konfiguriert ist.

DKIM (DomainKeys Identified Mail)

DKIM versieht die Nachricht mit einer kryptografischen Signatur. Der sendende Server signiert ausgewählte Header und den Nachrichtenkörper mit einem privaten Schlüssel; der öffentliche Schlüssel wird in DNS unter selektor._domainkey.domain veröffentlicht. Empfangende Server verifizieren die Signatur. DKIM übersteht Weiterleitungen und Relaying (solange die signierten Header und der Körper unverändert bleiben) — anders als SPF, das an die sendende IP gebunden ist.

DKIM-Alignment für DMARC: Die Signatur-Domain (d=-Tag) muss auf organisatorischer Ebene mit der From:-Header-Domain übereinstimmen. Signiert der ESP mit seiner eigenen Domain, schlägt das DKIM-Alignment fehl — auch wenn die Signatur kryptografisch gültig ist.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC verbindet SPF und DKIM. Eine Domain veröffentlicht eine DMARC-Richtlinie in DNS unter _dmarc.domain und legt fest, was Empfänger mit Nachrichten tun sollen, die sowohl SPF-Alignment als auch DKIM-Alignment nicht bestehen: p=none (nur überwachen), p=quarantine (als Spam markieren) oder p=reject (ablehnen). DMARC gilt als bestanden, wenn mindestens eines von SPF oder DKIM mit korrektem Alignment bestanden wird.

ARC (Authenticated Received Chain)

Wenn eine Mailingliste oder ein Weiterleitungsdienst eine Nachricht erneut versendet, bricht das SPF (neue sendende IP) und oft auch DKIM (veränderter Betreff oder Fußzeilen). ARC erlaubt diesen Zwischenstellen, einen signierten Snapshot der ursprünglichen Authentifizierungsergebnisse zu hinterlegen. Jeder Zwischenserver fügt drei Header hinzu (ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results) mit einer Instanznummer. Der finale Empfänger kann die ARC-Kette auswerten und entscheiden, ob er der ursprünglichen Authentifizierung vertraut — auch wenn SPF und DKIM jetzt fehlschlagen.

So verwenden Sie das Tool

1. Header kopieren. In den meisten E-Mail-Clients: Nachricht öffnen, „Original anzeigen", „Quelltext" oder „Nachrichtendetails" suchen (je nach Client — nach „Roh", „Header" oder einer Tastenkombination wie Strg+U suchen). Den gesamten Text markieren und kopieren.
2. In den Analyzer einfügen. Die kopierten Header in das Textfeld auf der Hauptseite einfügen. Sie können auch eine .eml-Datei direkt per Drag & Drop einfügen.
3. Analysieren klicken. Das Tool parst die Header und fragt live DNS-Einträge für SPF- und DKIM-Verifizierung ab. Die Ergebnisse erscheinen sofort.
4. Abschnitte durchgehen. Mit der Abschnittsnavigation können Sie direkt zu Mailflow, Authentifizierung (SPF/DKIM/DMARC/ARC), Exchange-Analyse, Standard-Headern oder Validierungswarnungen springen. DNS-Record-Blöcke und DKIM-Signatur-Blöcke lassen sich aufklappen.

Die gesamte Verarbeitung findet ausschließlich in Ihrem Browser statt. Keine Header-Daten werden an einen Server übermittelt. Die einzigen externen Anfragen sind DNS-Abfragen über den DoH-Endpunkt von Cloudflare (cloudflare-dns.com), der Domain-Namen auflöst, aber keine Header-Inhalte überträgt.