E-Mail-Header-Prüftool – Hinweise auf Fake-Mails erkennen

From, Reply-To, Return-Path und Sender: vier Rollen, keine vier Identitätsnachweise

From enthält die Absenderadresse, die Ihr Mailprogramm gewöhnlich anzeigt. Vor der Adresse kann ein frei gewählter Anzeigename stehen. „Kundenservice“ beweist daher ebenso wenig wie ein Firmenlogo, dass die genannte Firma die Nachricht verschickt hat. Schauen Sie auf die vollständige Adresse und besonders auf die Domain hinter dem @.

Reply-To legt fest, wohin Ihre Antwort gehen soll. Eine andere Domain kann zu einem legitimen Dienstleister gehören. Wenn eine angebliche Bank-Mail Antworten an ein unbekanntes Privatpostfach lenkt, sollten Sie die Abweichung jedoch klären, bevor Sie reagieren. Return-Path enthält bei der finalen Zustellung typischerweise den technischen Envelope-Absender beziehungsweise die Rücksendeadresse für Zustellfehler; Versandplattformen verwenden dafür häufig eigene Domains. Sender kann einen Versand im Auftrag eines anderen Absenders kennzeichnen. Keine dieser Angaben belegt für sich allein die Identität einer Person oder Organisation. Das Internet Message Format nach RFC 5322 beschreibt die Rollen dieser Felder.

Received und IP-Adressen: den sichtbaren Transportweg richtig lesen

Mailserver ergänzen beim Weitertransport Received-Zeilen. Neue Trace-Einträge werden dabei oberhalb bereits vorhandener Einträge eingefügt, sodass die jüngste Station im Rohheader normalerweise oben steht. Für die Analyse zählt jedoch nicht nur die Reihenfolge, sondern auch die Vertrauensgrenze: Beginnen Sie bei den Stationen Ihres eigenen Postfachanbieters und arbeiten Sie von dort rückwärts. Angaben, die bereits vor dem Eintritt in eine vertrauenswürdige Infrastruktur vorhanden waren, können vom Absender oder von vorgeschalteten Systemen beeinflusst worden sein. RFC 5321 beschreibt diese SMTP-Trace-Felder und ihre Einfügung.

Eine IP-Adresse in einer solchen Zeile gehört häufig zu einem Versanddienst, Gateway oder Zwischenserver. Sie verrät normalerweise weder den Standort noch den Computer des Menschen, der auf „Senden“ geklickt hat. Das Widget bietet für öffentliche IP-Adressen Links zu RIPEstat, AbuseIPDB und VirusTotal. Solche Portale liefern Recherchekontext; ein dortiger Eintrag beweist nicht, wer diese konkrete Mail geschrieben hat oder ob genau diese Nachricht schädlich ist.

Date, Message-ID und MIME: nützlich für den Zusammenhang, schwach als Echtheitsbeweis

Date nennt die vom sendenden System gesetzte Zeit. Message-ID kennzeichnet eine Nachricht und kann bei der technischen Zuordnung helfen; Beziehungen innerhalb einer Unterhaltung werden zusätzlich über Felder wie In-Reply-To und References hergestellt. Subject enthält den Betreff, Content-Type beschreibt das Format von Nachrichtenteilen und Anhängen. Diese Felder erklären Aufbau und Zusammenhang. Ein plausibles Datum, eine professionell wirkende Kennung oder ein harmlos klingender Dateityp machen die Nachricht nicht vertrauenswürdig.

SPF prüft einen Versandweg, nicht den sichtbaren Firmennamen

SPF vergleicht den einliefernden Mailserver mit den Regeln einer technischen Versandidentität. Geprüft wird typischerweise die Domain des SMTP-Envelope-Absenders, also RFC5321.MailFrom; je nach Situation kann auch die HELO– beziehungsweise EHLO-Identität relevant sein. Diese Domain muss nicht mit der sichtbaren From-Domain übereinstimmen. Deshalb beweist spf=pass allein nicht, dass der Name oder die sichtbare Absenderadresse im Posteingang echt ist. Eine Weiterleitung kann SPF zudem scheitern lassen, obwohl die ursprüngliche Nachricht legitim war. Die Einzelheiten legt RFC 7208 fest.

DKIM bestätigt eine geprüfte Signaturdomain und die signierten Nachrichtenteile

Bei DKIM fügt der Absender beziehungsweise sein Versanddienst eine kryptografische Signatur hinzu. Der Parameter d= benennt die Signaturdomain; geprüft werden der signierte Nachrichtenkörper und die in der Signatur angegebenen Kopfzeilen. Meldet ein empfangender Server dkim=pass, hat er die betreffende Signatur erfolgreich geprüft. Das sagt etwas über die Signaturdomain und die Integrität der signierten Teile, aber nichts über die Absicht des Absenders oder die Vertrauenswürdigkeit des Inhalts. Auch ein Angreifer kann seine eigene Domain korrekt signieren. Eine bloße DKIM-Signature-Zeile zeigt lediglich, dass eine Signatur vorhanden ist – nicht, dass ihre Prüfung erfolgreich war. Grundlage ist RFC 6376.

DMARC verbindet erfolgreiche Authentifizierung mit der sichtbaren Absenderdomain

DMARC verlangt, dass mindestens eine erfolgreiche SPF- oder DKIM-Prüfung zur Domain im sichtbaren From ausgerichtet ist. Dieses sogenannte Identifier Alignment kann streng oder gelockert geprüft werden: Bei strengem Alignment müssen die betreffenden Domains übereinstimmen; beim üblichen gelockerten Alignment genügt grundsätzlich dieselbe organisatorische Domain. dmarc=pass ist deshalb für die sichtbare Absenderdomain aussagekräftiger als ein isoliertes SPF- oder DKIM-„pass“. Es bestätigt jedoch weder den Inhalt noch die Seriosität einer Organisation. Eine täuschend ähnliche, vom Angreifer kontrollierte Domain kann ihre eigenen Nachrichten vollständig korrekt mit SPF, DKIM und DMARC authentifizieren. Der aktuelle DMARC-Standard RFC 9989 beschreibt dieses Domain-Alignment.

ARC hilft bei Weiterleitungen – eine sichtbare ARC-Kette allein beweist jedoch nichts

ARC kann frühere Authentifizierungsergebnisse über Zwischenstationen hinweg dokumentieren, etwa bei Weiterleitungen oder Mailinglisten. Ein sichtbares ARC-Siegel reicht dafür nicht aus: Die Kette muss technisch validiert und anschließend im Kontext des jeweiligen Vermittlers bewertet werden. Das Widget zeigt vorhandene ARC-Angaben, führt aber keine kryptografische ARC-Prüfung aus. RFC 8617 beschreibt ARC.

SPF-, DKIM-, DMARC- und ARC-Ergebnisse stehen häufig in Authentication-Results. Lesen Sie „pass gemeldet“ deshalb wörtlich: Das Widget übernimmt eine Aussage aus dem vorliegenden Header und berechnet diese Prüfungen nicht erneut. Entscheidend ist, welches System die betreffende Zeile erzeugt hat. Ein Authentication-Results-Feld aus der vertrauenswürdigen Infrastruktur Ihres Mailanbieters hat eine andere Aussagekraft als eine gleich aussehende Zeile, die bereits mit der Nachricht angeliefert wurde. RFC 8601 beschreibt dafür unter anderem die Kennzeichnung des prüfenden Dienstes über die authserv-id und warnt davor, beliebige vorhandene Prüfergebnisse ungeprüft zu übernehmen.

Verwechselbare Domains und abweichende Antwortadressen

Vergleichen Sie die vollständige Domain mit einer Adresse, die Sie bereits unabhängig kennen. Achten Sie auf zusätzliche Wörter vor der eigentlichen Domain, vertauschte Buchstaben und ähnlich aussehende Zeichen aus anderen Schriftsystemen. In fіrma.example sieht das zweite Zeichen wie ein lateinisches „i“ aus, ist aber das kyrillische Zeichen U+0456. Solche Unicode-Verwechslungszeichen sind von normalen internationalisierten Domainnamen zu unterscheiden: Umlaute oder andere nichtlateinische Zeichen sind nicht automatisch verdächtig. Das Widget stellt bei internationalen Domains die lesbare Unicode- und die technische ASCII-Schreibweise gegenüber und sucht nach Unicode-Verwechslungszeichen nach UTS #39.

Ein Beispiel aus dem Alltag: Eine Mail nennt im From die erwartete Firma, verlangt aber eine Antwort an eine fremde Domain und drängt auf sofortige Zahlung. Die abweichende Antwortadresse allein kann einen legitimen Dienstleister erklären. Zusammen mit einer unerwarteten Kontoverbindung, ungewöhnlichem Zeitdruck oder einer unplausiblen Forderung steigt der Klärungsbedarf jedoch deutlich. Antworten Sie dann nicht auf diese Mail, sondern nutzen Sie eine Telefonnummer, App oder Website, die Sie unabhängig von der Nachricht kennen.

Linktext, tatsächliches Linkziel und Anhangname

Ein Link kann im sichtbaren Text die bekannte Domain zeigen und technisch zu einer anderen führen. Bei https://bank.example@anmeldung.example.net/ steht die bekannte Zeichenfolge vor dem @ im Userinfo-Bereich; der tatsächliche Host lautet anmeldung.example.net. Das Widget zeigt solche Ziele als Text und macht Mail-Links im Bericht nicht anklickbar. Sicherheitsdienste und Unternehmens-Gateways schreiben Links mitunter ebenfalls um. Prüfen Sie deshalb die Erklärung für eine Abweichung, statt jeden Unterschied automatisch als Betrug zu bewerten. Die Regeln für Aufbau und Interpretation von Webadressen stehen im URL-Standard.

Ein Anhang namens Rechnung.pdf.exe endet technisch auf .exe, auch wenn der vordere Teil wie ein PDF wirkt. Das Widget erkennt solche Namensmuster und auffällige Dateiendungen. Es öffnet die Datei nicht und untersucht ihren Inhalt nicht. Bei einer Mail mit QR-Code, Bildtext, eingebetteter Schadsoftware oder einem geschickt formulierten Zahlungsauftrag kann die Headeranalyse daher keine Entwarnung geben.

Ein „fail“ braucht Kontext – ein „pass“ ebenfalls

Stellen Sie sich eine weitergeleitete Einladung vor: SPF scheitert am letzten Weiterleitungsserver, während eine passende DKIM-Signatur erhalten bleibt und DMARC deshalb möglicherweise weiterhin erfolgreich ist. Ein pauschales Betrugsurteil wäre hier falsch. Umgekehrt kann ein Angreifer eine fast gleich geschriebene Domain registrieren und für sie gültige SPF-, DKIM- und DMARC-Ergebnisse erzielen. Die Prüfungen beantworten technische Fragen zur Autorisierung und Integrität des Versands. Ob Sie der Mail folgen sollten, entscheiden Sie anhand der gesamten Nachricht und eines unabhängigen Kontaktwegs.

Apple Mail auf dem Mac

Öffnen Sie die Nachricht und wählen Sie Darstellung → E-Mail → Alle Header. Kopieren Sie die Kopfzeilen anschließend in das Textfeld des Widgets. In den Darstellungseinstellungen von Mail können Sie außerdem festlegen, welche Headerfelder das Programm standardmäßig anzeigt. Wenn Sie stattdessen eine vollständige Nachrichtendatei besitzen, kann das Widget zusätzlich vorhandene Links und Anhangnamen betrachten.

Outlook

Im neuen Outlook und in Outlook im Web öffnen Sie die Nachrichtendetails über Weitere Aktionen → Anzeigen → Nachrichtendetails anzeigen. Im klassischen Outlook für Windows öffnen Sie die Mail in einem eigenen Fenster und wählen Datei → Eigenschaften; dort finden Sie das Feld Internetkopfzeilen. Microsoft beschreibt beide Wege. Eine .msg-Datei kann die Internetkopfzeilen enthalten, muss sie aber nicht vollständig enthalten. Das Widget weist auf fehlende Transportdaten hin.

Thunderbird und andere Programme

In Thunderbird öffnen Sie den Nachrichten-Quelltext über Ansicht → Nachrichten-Quelltext oder mit Strg+U; auf dem Mac entspricht die Tastenkombination Befehl+U. Kopieren Sie daraus die Kopfzeilen oder den vollständigen Rohtext. Die Thunderbird-Hilfe nennt die entsprechenden Tastenkombinationen. Falls das direkte Ziehen aus einem Mailprogramm keine Datei oder keinen verwertbaren Text an den Browser übergibt, speichern Sie die Nachricht zuerst und wählen die gespeicherte Datei anschließend im Widget aus.