E-Mail-Header-Forensik & Authentifizierungsprüfung

Ein E-Mail-Header ist ein strukturierter Metadatenblock vor dem eigentlichen Nachrichtentext, der Absender, Empfänger, Betreff, Datum, Weiterleitungsserver (Received-Zeilen) und kryptografische Authentifizierungsergebnisse (SPF, DKIM, DMARC) dokumentiert.

Ein Received-Header ist ein Trace-Feld, das von jedem beteiligten Mail Transfer Agent (MTA) oben auf den Header gesetzt wird. Der unterste Eintrag entspricht daher dem ersten Absenderserver, der oberste dem finalen Empfängerserver.

Öffnen Sie die E-Mail in Gmail im Desktop-Browser, klicken Sie auf das Dreipunkt-Menü neben der Antworten-Schaltfläche und wählen Sie 'Original anzeigen'. Der vollständige Header öffnet sich in einem neuen Tab.

Öffnen Sie die E-Mail in der Desktop-Version von Outlook in einem separaten Fenster, klicken Sie auf Datei > Eigenschaften und prüfen Sie das Feld 'Internetkopfzeilen'. In Outlook Web klicken Sie im Drei-Punkte-Menü der Nachricht auf Ansicht > Nachrichtendetails anzeigen.

Der Return-Path bezeichnet die Envelope-Sender-Adresse (MAIL FROM), an die Unzustellbarkeitsnachrichten (Bounces) gesendet werden. Bei Versand über Drittanbieter unterscheidet sich diese oft von der sichtbaren From-Adresse.

Reply-To legt fest, an welche Adresse Antworten gesendet werden, wenn der Empfänger auf 'Antworten' klickt. Weicht diese Domain von From ab, gehen Antworten an eine andere Adresse – üblich bei Support-Systemen, aber auch potenziell für Betrug nutzbar.

Die Message-ID ist eine weltweit eindeutige Kennung, die vom absendenden Mailsystem für eine Nachricht vergeben wird, typischerweise im Format '<eindeutige-zeichenfolge@absendeserver>'.

SPF (RFC 7208) ermöglicht es Domaininhabern, autorisierte Server-IPs in ihren DNS-Einträgen zu veröffentlichen. Der Empfängerserver prüft, ob die IP des sendenden Servers für die Envelope-Sender-Domain autorisiert ist.

DKIM (RFC 6376) fügt dem E-Mail-Header eine kryptografische Signatur hinzu. Der empfangende Server prüft diese anhand des im DNS hinterlegten öffentlichen Schlüssels, um die Unverfälschtheit von Headern und Nachrichtentext sicherzustellen.

DMARC prüft, ob die sichtbare Absenderdomain (From) mit SPF oder DKIM übereinstimmt (Alignment), und definiert Richtlinien für Fehlversuche (none, quarantine, reject). Im Jahr 2026 gelten RFC 9989 (Kernspezifikation), RFC 9990 und RFC 9991 (die veraltete RFC 7489 wurde abgelöst).

ARC (RFC 8617) bewahrt vorangegangene Authentifizierungsergebnisse über Zwischenstationen (wie Mailinglisten oder automatische Weiterleitungen) hinweg, die Nachrichteninhalte verändern und so SPF- oder DKIM-Prüfungen ungültig machen würden.

Authentication-Results (RFC 8601) ist ein strukturierter Header, den empfangende Gateways erzeugen, um ihre lokalen Prüfungsergebnisse für SPF, DKIM, DMARC und ARC festzuhalten.

Ein SPF PASS bedeutet, dass die IP-Adresse des einliefernden Servers im SPF-DNS-Eintrag der Envelope-Sender-Domain (Return-Path) explizit autorisiert ist.

Ein DKIM PASS bestätigt, dass die digitale Signatur im DKIM-Signature-Header erfolgreich mit dem öffentlichen Schlüssel der Unterzeichner-Domain verifiziert wurde und der Inhalt unverändert ist.

Ein DMARC PASS bedeutet, dass die Domain im sichtbaren From-Header mit einer erfolgreich verifizierten SPF- oder DKIM-Domain übereinstimmt (Alignment erfüllt) und die Basiskontrolle bestanden wurde.

Domain Alignment ist das Grundprinzip von DMARC: Die dem Nutzer im From-Header angezeigte Domain muss mit der durch SPF geprüften Envelope-Domain oder der DKIM-Signaturdomain (d=-Tag) übereinstimmen (strikt oder organisatorisch).

Received-Header werden chronologisch von unten nach oben gelesen. Die unterste Zeile markiert den Ursprungsserver, während jede darüber liegende Zeile eine weitere Weiterleitungsstufe bis zum finalen Postfach dokumentiert.

E-Mails durchlaufen meist mehrere Server (Client, interner Relay, Cloud-Spamfilter, Perimeter-Gateway, Postfachserver). Jeder Server protokolliert dabei die IP des jeweils vorherigen Servers, der die Nachricht übergeben hat.

Nein. Die forensische Header-Analyse liefert objektive technische Belege über Routing, Signaturen und Domain-Ausrichtung. Sie kann jedoch keine psychologischen Täuschungsabsichten im Nachrichtentext bewerten, weshalb stets eine menschliche Gesamtprüfung nötig ist.

Nein, keinesfalls. Solasu läuft zu 100% lokal in der JavaScript-Umgebung Ihres Browsers. Keine Header-Inhalte, E-Mail-Adressen oder IPs werden an Server übertragen oder in Cookies/Datenbanken persistiert.

Nein. Um absoluten Datenschutz zu gewährleisten und Netzwerkabflüsse zu verhindern, analysiert das Tool ausschließlich die im übergebenen Header vorhandenen Daten ohne externe DNS-Lookups.

Die Schwärzungsfunktion maskiert sensible personenbezogene Daten wie E-Mail-Adressen, IP-Adressen und Message-IDs unumkehrbar (z. B. 'b***e@example.com'), sodass Header sicher in Support-Tickets oder öffentlichen Berichten geteilt werden können.