E-Mail-Header-Analyzer für SPF, DKIM, DMARC und Phishing-Hinweise
Eine verdächtige E-Mail kann schnell für Unsicherheit sorgen: besonders dann, wenn Absendername, Inhalt und Gestaltung zunächst glaubwürdig wirken.
Der E-Mail-Header-Analyzer hilft Ihnen, technische Spuren wie SPF, DKIM, DMARC, Reply-To, Return-Path und den Zustellweg genauer zu prüfen. So erkennen Sie mögliche Auffälligkeiten schneller und erhalten eine verständliche Grundlage für die weitere Einschätzung, ohne den vollständigen Header an einen externen Dienst übertragen zu müssen:
Lokale technische Prüfung im Browser
E-Mail-Header analysieren
Fügen Sie den vollständigen Quelltext beziehungsweise Internet-Header einer E-Mail ein. Der E-Mail-Header-Analyzer wertet Absenderangaben, SPF, DKIM, DMARC, Reply-To, Return-Path, Message-ID, Zustellweg, Zeitstempel und mögliche technische Phishing-Hinweise aus.
Wichtige Sicherheitsgrenze: Das Tool kann technische Auffälligkeiten erkennen, aber niemals zuverlässig bestätigen, dass eine Nachricht sicher, echt oder ungefährlich ist. Ein unauffälliger Header schließt Betrug, Schadsoftware oder gefährliche Links nicht aus.
- SPF-, DKIM-, DMARC- und ARC-Ergebnisse verständlich einordnen
- Absender-, Antwort-, Rücksende- und Message-ID-Domains vergleichen
- Zustellweg, Mailserver und mögliche Verzögerungen untersuchen
- Weiterleitungen, fehlende Felder und widersprüchliche Angaben erkennen
- Technische Zusammenfassung für Support oder IT-Abteilung erstellen
- E-Mail-Header ohne Upload oder externe Serveranfrage lokal verarbeiten
So funktioniert die Header-Analyse
- Öffnen Sie in Ihrem E-Mail-Programm die Funktion für den vollständigen Header, Nachrichtenquelltext oder Internetkopf.
-
Kopieren Sie den gesamten Header einschließlich aller
Received-,Authentication-Results-,From-,Reply-To- undMessage-ID-Zeilen. - Fügen Sie den kopierten Inhalt in das Eingabefeld ein und starten Sie die lokale Analyse.
- Prüfen Sie die erkannten Abweichungen gemeinsam mit Inhalt, Links, Anhängen und dem Anlass der Nachricht.
Kopieren Sie möglichst nicht nur den sichtbaren Nachrichtentext. Die technisch relevanten Angaben befinden sich im vollständigen Nachrichtenkopf und sind in der normalen E-Mail-Ansicht häufig verborgen.
Technische Auswertung
Ergebnisse der E-Mail-Header-Analyse
Die folgenden Bereiche zeigen Authentifizierung, Absenderbeziehungen, Zustellweg und technische Auffälligkeiten getrennt an. Einzelne Hinweise müssen immer im Zusammenhang betrachtet werden.
Noch keine individuelle Analyse durchgeführt. Die Felder zeigen, welche Informationen der Analyzer auswertet.
Schnellüberblick
- Technische Hinweisstufe
- Erkannte Auffälligkeiten
- Authentifizierung
- Domain-Übereinstimmung
- Erkannte Mailserver-Stationen
- Geschätzte Zustelldauer
- Mögliche Weiterleitung
- Qualität der Datengrundlage
Keine Sicherheitsfreigabe: Auch eine niedrige technische Hinweisstufe bedeutet nicht, dass die E-Mail sicher ist. Inhalte, Links, Anhänge, Zahlungsaufforderungen und der geschäftliche Zusammenhang werden durch eine reine Headeranalyse nicht zuverlässig bewertet.
Absenderidentität und beteiligte Domains
| Headerfeld | Erkannter Wert | Technische Bedeutung |
|---|---|---|
| Sichtbarer Absendername | Der Anzeigename kann frei gewählt und daher leicht imitiert werden. | |
| From-Adresse | Diese Adresse erscheint in vielen E-Mail-Programmen als Absender. | |
| From-Domain | Sie ist die wichtigste Bezugsdomain für die DMARC-Bewertung. | |
| Reply-To-Adresse | Antworten können an eine andere Adresse als den sichtbaren Absender gehen. | |
| Reply-To-Domain | Eine unerwartete Abweichung kann ein technischer Warnhinweis sein. | |
| Return-Path | Diese Adresse wird unter anderem für unzustellbare Nachrichten verwendet. | |
| Return-Path-Domain | Sie kann für die SPF- und DMARC-Zuordnung relevant sein. | |
| Message-ID | Die Kennung sollte normalerweise innerhalb einer Nachricht eindeutig sein. | |
| Message-ID-Domain | Eine Abweichung ist allein kein Beweis, kann aber zusätzlichen Kontext liefern. | |
| Betreff | Der Betreff wird nur angezeigt und nicht inhaltlich als sicher oder gefährlich bewertet. | |
| Angegebenes Versanddatum | Dieses Datum stammt häufig vom absendenden Programm und kann manipuliert sein. |
SPF, DKIM, DMARC und ARC
| Verfahren | Ergebnis | Erkannte Domain oder Identität | Einordnung |
|---|---|---|---|
| SPF | |||
| DKIM | |||
| DMARC | |||
| ARC |
- From- und Reply-To-Domain
- From- und Return-Path-Domain
- From- und DKIM-Domain
- From- und Message-ID-Domain
Chronologischer Zustellweg
Received-Zeilen werden normalerweise von jedem beteiligten
Mailserver ergänzt. Der unterste Eintrag ist häufig der älteste,
während der oberste Eintrag meist den letzten Zustellschritt beschreibt.
Nicht jede Zeile ist automatisch vertrauenswürdig.
- Frühester erkannter Zeitstempel
- Letzter erkannter Zeitstempel
- Längste Verzögerung zwischen zwei Stationen
- Mögliche Ursprungs-IP-Adresse
| Station | Von | An | Zeitstempel | Verzögerung |
|---|---|---|---|---|
| 1 | ||||
| 2 | ||||
| 3 | ||||
| 4 | ||||
| 5 | ||||
| 6 | ||||
| 7 | ||||
| 8 | ||||
| 9 | ||||
| 10 | ||||
| 11 | ||||
| 12 |
Bei mehr als zwölf Stationen zeigt die Tabelle eine begrenzte Auswahl. Die Gesamtzahl wird im Schnellüberblick genannt.
Erkannte technische Auffälligkeiten
Die Liste unterscheidet technische Warnsignale von Beweisen. Eine Abweichung kann legitime Ursachen haben, beispielsweise einen Newsletter-Dienst, ein Ticketsystem, eine Mailingliste oder eine automatische Weiterleitung.
- SPF-, DKIM- oder DMARC-Fehler werden hier eingeordnet.
- Eine abweichende Reply-To-Domain wird hier bewertet.
- Eine abweichende Return-Path-Domain wird hier bewertet.
- Eine ungewöhnliche oder fehlende Message-ID wird hier bewertet.
- Auffällige Domains, IP-Adressen als Domain oder Punycode werden hier bewertet.
- Widersprüchliche oder unplausible Zeitstempel werden hier bewertet.
- Ungewöhnlich lange Zustellverzögerungen werden hier bewertet.
- Fehlende wichtige Headerfelder werden hier aufgeführt.
- Hinweise auf Weiterleitungen, Mailinglisten oder Umschreibungen werden hier eingeordnet.
- Mehrfach vorhandene oder widersprüchliche Identitätsfelder werden hier bewertet.
- Nicht eindeutig lesbare oder fehlerhaft aufgebaute Headerzeilen werden hier aufgeführt.
Positive technische Signale
- Erfolgreiche Authentifizierungsergebnisse werden hier aufgeführt.
- Übereinstimmende Absender- und Signaturdomains werden hier aufgeführt.
- Ein zeitlich nachvollziehbarer Zustellweg wird hier aufgeführt.
- Vorhandene Standardfelder und eine lesbare Headerstruktur werden hier aufgeführt.
Positive technische Signale beweisen nicht, dass der tatsächliche Absender vertrauenswürdig ist. Auch kompromittierte oder eigens für Betrug eingerichtete Domains können SPF, DKIM und DMARC korrekt verwenden.
Technische Zusammenfassung für Support oder IT
Prüfen Sie die Zusammenfassung vor der Weitergabe. Abhängig von den gewählten Optionen werden E-Mail-Adressen und IP-Adressen maskiert.
So entsteht der technische Phishing-Indikator
Der Analyzer sucht nach festen, nachvollziehbaren Merkmalen im E-Mail-Header. Er verwendet keine künstliche Intelligenz, keine externe Reputationsdatenbank und keine DNS-Abfrage. Die Auswertung bezieht sich ausschließlich auf die Angaben, die im eingefügten Header vorhanden sind.
Geprüfte Merkmalsgruppen
- Headerstruktur: Erkennung und Zusammenführung von mehrzeiligen Headerfeldern sowie Prüfung auf fehlende oder mehrfach vorhandene Standardfelder.
- Absenderbeziehungen: Vergleich von From, Reply-To, Return-Path, Message-ID und DKIM-Signaturdomain.
-
Authentifizierung:
Interpretation vorhandener SPF-, DKIM-, DMARC- und ARC-Ergebnisse aus
Feldern wie
Authentication-ResultsundReceived-SPF. -
Zustellweg:
Auswertung der
Received-Zeilen, beteiligten Server, IP-Adressen, Zeitstempel und Verzögerungen. - Weiterleitungshinweise: Suche nach ARC-Feldern, Mailinglistenmerkmalen, Sender Rewriting Scheme, Resent-Feldern und typischen Weiterleitungsangaben.
- Domainauffälligkeiten: Hinweise auf IP-Literale, Punycode, ungewöhnliche Abweichungen und offensichtlich nicht zusammenpassende Identitäten.
Einordnung der Hinweisstufe
| Hinweisstufe | Bedeutung | Empfohlene Reaktion |
|---|---|---|
| Wenige technische Auffälligkeiten | Der Header enthält keine oder nur schwache erkennbare Warnsignale. | Inhalt, Links, Anhänge und Absender trotzdem unabhängig prüfen. |
| Mehrere technische Auffälligkeiten | Mehrere Identitäten, Zeitangaben oder Authentifizierungsergebnisse passen nicht eindeutig zusammen. | Nicht über die E-Mail antworten oder handeln, bevor der Absender über einen bekannten Kontaktweg bestätigt wurde. |
| Erhöhte technische Auffälligkeit | Der Header enthält gewichtige oder mehrere kombinierte Warnsignale. | Links und Anhänge nicht öffnen und die Nachricht bei Bedarf an IT-Support oder Sicherheitsverantwortliche weitergeben. |
| Nicht zuverlässig auswertbar | Der Header ist unvollständig, beschädigt oder enthält keine ausreichenden technischen Prüfangaben. | Vollständigen Nachrichtenquelltext erneut kopieren oder eine manuelle Prüfung durchführen lassen. |
Die Hinweisstufe ist keine statistische Betrugswahrscheinlichkeit. Die Anzahl und Gewichtung der Merkmale dient nur dazu, auffällige Kombinationen übersichtlich darzustellen.
Beispiel eines vollständigen E-Mail-Headers
Das folgende synthetische Beispiel verwendet reservierte Testdomains und eine für Dokumentationen vorgesehene IP-Adresse. Es enthält keine echten Empfänger- oder Absenderdaten.
Delivered-To: empfaenger@example.test
Received: by mx.example.test with SMTP id example123;
Tue, 14 Jul 2026 10:16:05 +0200
Received: from mail.example-shop.test (mail.example-shop.test. [198.51.100.25])
by mx.example.test with ESMTPS id example456
for <empfaenger@example.test>;
Tue, 14 Jul 2026 10:16:03 +0200
Authentication-Results: mx.example.test;
spf=pass smtp.mailfrom=bounce@example-shop.test;
dkim=pass header.d=example-shop.test header.s=mail;
dmarc=pass header.from=example-shop.test
Return-Path: <bounce@example-shop.test>
DKIM-Signature: v=1; a=rsa-sha256; d=example-shop.test; s=mail;
h=from:to:subject:date:message-id;
bh=examplebodyhash;
b=examplesignature
From: "Beispiel-Shop" <rechnung@example-shop.test>
Reply-To: support@example-shop.test
To: empfaenger@example.test
Subject: Ihre Beispielrechnung
Date: Tue, 14 Jul 2026 10:15:59 +0200
Message-ID: <invoice-20260714-12345@example-shop.test>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8Mögliche Beispielauswertung
- SPF, DKIM und DMARC sind im Beispiel mit „pass“ angegeben.
- From-, Reply-To-, Return-Path-, DKIM- und Message-ID-Domain stimmen überein.
- Der Zustellweg enthält zwei zeitlich nachvollziehbare Stationen.
- Die technische Analyse würde nur wenige Auffälligkeiten melden.
- Die Nachricht dürfte trotzdem nicht automatisch als sicher bezeichnet werden.
Wichtige Felder eines E-Mail-Headers erklärt
- From
- Enthält den sichtbaren Absendernamen und die sichtbare Absenderadresse. Beide Angaben können vom Absenderprogramm eingetragen und imitiert werden.
- Reply-To
- Legt fest, an welche Adresse eine Antwort gesendet werden soll. Diese Adresse kann von der From-Adresse abweichen.
- Return-Path
- Enthält häufig den technischen Envelope-Absender, an den Unzustellbarkeitsmeldungen geschickt werden.
- Received
- Dokumentiert einzelne Transportstationen. Neue Einträge werden normalerweise oben ergänzt, weshalb der zeitliche Weg häufig von unten nach oben gelesen wird.
- Authentication-Results
- Enthält Prüfergebnisse des empfangenden Mailservers, beispielsweise für SPF, DKIM, DMARC und ARC.
- SPF
- Prüft anhand der Envelope-Absenderdomain, ob ein bestimmter Server zum Versand berechtigt war. SPF authentifiziert nicht automatisch die sichtbare From-Adresse.
- DKIM
- Verwendet eine digitale Signatur, um ausgewählte Bestandteile der Nachricht einer Domain zuzuordnen und Veränderungen erkennbar zu machen.
- DMARC
- Verknüpft die sichtbare From-Domain mit SPF und DKIM. Mindestens eines der Verfahren muss erfolgreich und passend ausgerichtet sein.
- ARC
- Kann frühere Authentifizierungsergebnisse über legitime Weiterleitungen und Mailinglisten hinweg dokumentieren.
- Message-ID
- Ist eine Nachrichtenkennung, die häufig eine Domain enthält. Eine fehlende oder ungewöhnliche Message-ID kann ein Hinweis sein, ist aber allein kein Betrugsnachweis.
Häufige Fragen zur E-Mail-Header-Analyse
Wo finde ich den vollständigen E-Mail-Header?
Je nach Programm heißt die Funktion beispielsweise „Original anzeigen“, „Nachrichtenquelle anzeigen“, „Internetkopfzeilen“, „Raw Message“, „Quelltext“ oder „Alle Header“. Sie befindet sich häufig im Drei-Punkte-Menü oder unter den Nachrichteneigenschaften.
Kann ein E-Mail-Header gefälscht werden?
Einige Felder wie Anzeigename, From, Reply-To, Date und Message-ID können frei gesetzt oder manipuliert werden. Received- und Authentication-Results-Zeilen, die von vertrauenswürdigen empfangenden Servern hinzugefügt wurden, sind meist aussagekräftiger. Auch sie müssen jedoch im richtigen Zusammenhang gelesen werden.
Bedeutet SPF „pass“, dass die E-Mail echt ist?
Nein. SPF bestätigt nur, dass der sendende Server für eine bestimmte technische Absenderdomain autorisiert war. Diese Domain kann von der sichtbaren From-Domain abweichen oder selbst von Betrügern kontrolliert werden.
Bedeutet DKIM „pass“, dass der Inhalt ungefährlich ist?
Nein. DKIM bestätigt eine Signatur und kann Veränderungen an signierten Nachrichtenteilen erkennbar machen. Eine gültig signierte Nachricht kann trotzdem betrügerische Inhalte, gefährliche Links oder Schadsoftware enthalten.
Warum kann eine legitime Nachricht unterschiedliche Domains verwenden?
Unternehmen nutzen häufig Newsletter-Plattformen, Ticketsysteme, Zahlungsdienstleister, CRM-Systeme oder externe Versanddienste. Unterschiedliche Domains können daher legitim sein. Entscheidend ist, ob die Kombination technisch und geschäftlich plausibel ist.
Warum scheitert SPF manchmal bei einer Weiterleitung?
Bei einer Weiterleitung sieht der empfangende Server häufig die IP-Adresse des weiterleitenden Systems statt des ursprünglichen Versandservers. Dadurch kann SPF fehlschlagen. Verfahren wie SRS und ARC können helfen, solche Fälle technisch einzuordnen.
Kann das Tool eine Phishing-Mail sicher erkennen?
Nein. Das Tool erkennt nur technische Hinweise im Header. Social Engineering, manipulierte Webseiten, gefährliche Anhänge, kompromittierte echte Konten und inhaltlich glaubwürdige Betrugsversuche können dadurch nicht zuverlässig ausgeschlossen werden.
Warum führt der Analyzer keine DNS-Abfragen durch?
Externe DNS-Abfragen würden zusätzliche Netzwerkzugriffe und eine komplexere technische sowie datenschutzrechtliche Verarbeitung erfordern. Dieses Tool interpretiert deshalb nur Ergebnisse, die bereits im E-Mail-Header dokumentiert sind.
Was sollte ich bei einer verdächtigen E-Mail tun?
Öffnen Sie keine unerwarteten Links oder Anhänge und antworten Sie nicht über die angegebenen Kontaktdaten. Bestätigen Sie den Absender über eine bereits bekannte Telefonnummer, offizielle Webseite oder einen unabhängigen Kommunikationsweg. In Unternehmen sollte die Nachricht gegebenenfalls an den IT-Support weitergegeben werden.
Werden meine eingefügten Headerdaten gespeichert?
Die Toolfunktion ist für eine lokale Verarbeitung im Browser vorgesehen. Der Header muss nicht an einen externen Analysedienst übertragen werden. Beim Neuladen oder Schließen der Seite steht die Eingabe ohne zusätzliche Speicherfunktion nicht mehr zur Verfügung.
Mehr Tools & Rechner:
- Passwort-Sicherheitscheck mit 2FA-Planer
- IT-Fähigkeiten Selbsttest
- Backup-Strategie-Rechner für Datenverlust Risiko
- Datenverbrauchskosten-Rechner
- Hardware Übertaktungsrechner
- Software Lizenzkosten-Rechner
- WEB3-Entwicklungsressourcen-Rechner
- Webdesign Webentwicklung Vertrags-Generator
- IT-Schulungsressourcen-Katalog
- User QR-Code-Generator
- Datenbank-Normalisierungs-Checker
- Website-CO2- und Stromkosten-Rechner für Green IT
- Datenbank-Größen- und Wachstumsrechner
Übersicht:
Fachartikel
Verzeichnis
Über uns
- Was besagt das neue Energielabel für Smartphones und Tablets? - 8. August 2025
- Warum vertrauen wir Chatbots? - 8. Juli 2025
- Die Rückkehr des analogen Computers - 7. Juni 2025