E-Mail-Datum fälschen: möglich, aber immer nachweisbar

E-Mail-Datum ändern: Worum geht es genau?

Die Frage taucht regelmäßig in Systemadministrations-Foren und MSP-Slack-Gruppen auf: Lässt sich das Datum einer E-Mail nach dem Versand ändern? Die kurze Antwort lautet ja, technisch gesehen. Aber die vollständige Antwort ist für jeden, der das zu zweifelhaften Zwecken tun möchte, weit weniger beruhigend.

Eine E-Mail ist keine monolithische Datei. Sie besteht aus einer Sammlung von Textheadern, gefolgt von einem Nachrichtentext. Unter diesen Headern tragen mehrere Datumsinformationen. Und einige lassen sich leichter ändern als andere.

In jeder E-Mail existieren drei Datierungsebenen gleichzeitig:

• Der Date:-Header (RFC 2822), den der Mail-Client beim Versand schreibt
• Die Received:-Header, die von jedem Relay-Server hinzugefügt werden
• Das IMAP-INTERNALDATE, ein serverseitig gespeichertes Metadatum, unabhängig vom Nachrichteninhalt

Jede dieser Ebenen lässt sich ändern. Keine davon, ohne Spuren zu hinterlassen.

Den Date:-Header ändern: die offensichtlichste Manipulation

Der Date:-Header ist reiner Text in der .eml-Datei. Technisch gesehen kann ihn jeder Hex-Editor oder ein Python-Skript in Sekunden überschreiben. Wer schon einmal die Roh-Header einer E-Mail in Gmail geöffnet hat (das kleine Menü "Original anzeigen"), weiß, dass das für jeden lesbar ist.

Das Problem? Seit 2004 signieren die große Mehrheit der Mailserver ausgehende E-Mails mit DKIM (DomainKeys Identified Mail). Diese kryptografische Signatur deckt explizit mehrere Header ab, darunter Date:, From:, Subject: und den Nachrichtentext. Die Signatur wird im Header DKIM-Signature: gespeichert.

Eine Änderung des Date:-Headers nach der Signierung macht die DKIM-Prüfung automatisch ungültig. Jeder empfangende Server kann die Signatur verifizieren, indem er den öffentlichen Schlüssel aus dem DNS der Absender-Domain abruft. Stimmt die Signatur nicht mehr, wird die Nachricht als manipuliert markiert. Gmail, Outlook.com und alle großen Anbieter führen diese Prüfung automatisch durch.

(Wer eine DKIM-Signatur einmal konkret sehen möchte: einfach die Roh-Header einer E-Mail von Gmail oder Office 365 öffnen. Dort findet sich eine Zeile DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=..., die wie Rauschen aussieht, aber tatsächlich ein kryptografischer Hash der gesamten Nachricht ist.)

Ergebnis: den Date:-Header einer DKIM-signierten E-Mail zu ändern bedeutet, das Siegel zu brechen. Die Manipulation ist für jeden Administrator sichtbar, der weiß, wo er suchen muss.

Received:-Header umschreiben: eine schwer zu fälschende Kette

Die Received:-Header zeichnen den Weg nach, den eine E-Mail vom Absender zum Empfänger zurückgelegt hat. Jeder SMTP-Server, der die Nachricht berührt, fügt einen hinzu, mit seinem Namen, seiner IP-Adresse und einem Zeitstempel. Eine E-Mail, die zwei oder drei Relays durchläuft, enthält entsprechend zwei oder drei gestapelte Received:-Header.

Lassen sie sich ändern? Technisch ja, an der eigenen Kopie der Nachricht. Aber hier liegt die Falle: Der Empfänger hat ebenfalls eine Kopie. Und sein Server hat zuletzt seinen eigenen Received:-Header hinzugefügt. Dieser Header liegt unter der Kontrolle des Empfängers, nicht des Absenders. Er ist von außen nicht fälschbar.

Die Konsistenz der Kette ist überprüfbar. Wenn die Zeitstempel aufeinanderfolgender Received:-Header inkohärent sind (ein Zwischen-Relay hätte die Nachricht empfangen, bevor der Absender sie geschickt hat), ist das sofort verdächtig. Forensische E-Mail-Analyse-Tools wie MXToolbox oder die internen Tools von Sicherheitsteams prüfen genau das.

Tatsächlich ist es nicht ganz korrekt zu sagen, dass Received:-Header vollständig unfälschbar sind: Ein Angreifer, der seine eigene Mail-Infrastruktur kontrolliert, kann glaubwürdige Header für die Relays fabrizieren, die er beherrscht. Aber das letzte Glied, den Server des Empfängers, kontrolliert er nie.

Das IMAP-INTERNALDATE: der technischste Fall

Das INTERNALDATE ist ein serverseitig gespeichertes IMAP-Metadatum. Es ist kein Header in der Nachricht selbst, sondern ein Wert, den der Server der Nachricht in seiner internen Datenbank zuordnet. Diesen Wert verwenden die meisten Mail-Clients, um Nachrichten im Posteingang zu sortieren.

Der IMAP-Befehl APPEND ermöglicht es, eine Nachricht auf einem Server abzulegen und dabei explizit ein INTERNALDATE anzugeben. Das ist eine legitime Protokollfunktion, dokumentiert in RFC 3501. Migrations-Tools nutzen das ständig: imapsync, BitTitan MigrationWiz, CloudM, GSMMO... alle legen E-Mails auf dem Zielserver mit einem angegebenen INTERNALDATE ab.

Theoretisch könnte jemand mit IMAP-Zugriff auf sein eigenes Postfach eine E-Mail mit einem beliebigen INTERNALDATE ablegen. Aber diese Manipulation ändert nicht die Header der Nachricht. Der ursprüngliche Date:-Header bleibt intakt, die Received:-Header bleiben intakt, die DKIM-Signatur bleibt intakt. Nur das serverseitige Sortier-Metadatum ändert sich.

Für einen Experten, der die Roh-Nachricht untersucht, ist die Diskrepanz zwischen INTERNALDATE und Date: sofort erkennbar. Und wenn die Nachricht DKIM-signiert ist, ist das ursprüngliche Datum kryptografisch belegt.

Die Message-ID: ein kaum fälschbarer Fingerabdruck

Jede E-Mail erhält eine eindeutige Kennung, den Header Message-ID:. Diese Kennung wird vom SMTP-Server des Absenders zum Versandzeitpunkt erstellt, in der Regel durch Kombination eines Zeitstempels, einer zufälligen Kennung und des Domainnamens des Servers.

Eine typische Message-ID sieht so aus: <CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>. Der Zeitstempel ist oft direkt in der Kennung kodiert. Das Datum der Nachricht zu ändern und dabei eine Message-ID mit einem inkompatiblen Zeitstempel zu behalten, erzeugt eine sofort auffällige Inkonsistenz.

Außerdem werden Message-IDs von großen Messaging-Systemen indexiert. Google, Microsoft und andere Akteure pflegen Logs, mit denen sich nachvollziehen lässt, wann eine Nachricht tatsächlich über ihre Infrastruktur gelaufen ist. In einem rechtlichen oder forensischen Kontext sind diese Logs über gerichtliche Verfahren zugänglich.

In der Praxis: Wer kann einen Manipulationsversuch erkennen?

Die Frage konkret gestellt: Sie erhalten eine E-Mail, bei der Sie vermuten, dass das Datum geändert wurde. Was kann ein IT-Administrator oder ein Anwalt mit etwas technischem Hintergrundwissen tun?

• DKIM-Prüfung: In Gmail zeigt das Menü "Original anzeigen" direkt oben das Ergebnis der DKIM-Prüfung an. Ein "PASS" bestätigt die Integrität der Nachricht seit dem Versand. Ein "FAIL" oder "SOFTFAIL" signalisiert eine Veränderung.
• Header-Analyse: Tools wie MXToolbox Header Analyzer oder die Google Admin Toolbox parsen automatisch die Received:-Kette und melden zeitliche Inkonsistenzen.
• Kohärenz von Message-ID und Date: Ein Analyst kann den in der Message-ID kodierten Zeitstempel mit dem deklarierten Date:-Wert vergleichen.
• Server-Logs: Hat die E-Mail einen Server durchlaufen, für den Sie Administrator sind, enthalten die SMTP-Logs den tatsächlichen Zeitpunkt der Nachrichtenannahme, unabhängig von allen Headern.

Kurz gesagt: Die Erkennungs-Tools sind zugänglich, kostenlos und erfordern keine fortgeschrittene Forensik-Expertise. Ein etwas neugieriger IT-Admin kann die Integrität einer E-Mail in unter zwei Minuten prüfen.

Der einzige legitime Fall für massenhafte Datumsänderungen: die IMAP-Migration

Es gibt ein Szenario, in dem Hunderttausende von E-Mails ganz ohne böse Absicht falsche Daten tragen: die IMAP-Migration.

Sie haben gerade eine Migration von 150 Exchange-Postfächern zu Google Workspace abgeschlossen. Montagmorgen rollen die Tickets ein. Nutzerinnen und Nutzer berichten, dass alle ihre alten E-Mails das gleiche Datum anzeigen, nämlich das Datum des Migrationswochenendes. Ihre Posteingänge sind unlesbar.

Was passiert ist, lässt sich dokumentieren und war vorhersehbar: Das Migrations-Tool (BitTitan, CloudM, imapsync oder ein anderes) hat die E-Mails via IMAP APPEND auf Google Workspace abgelegt. Es hat ein INTERNALDATE gesetzt, das dem Migrationsdatum entspricht, nicht dem ursprünglichen Versanddatum. Ergebnis: Outlook, das standardmäßig nach INTERNALDATE sortiert, zeigt für alle Nachrichten das Migrationsdatum an. Warum E-Mails nach der Migration das falsche Datum zeigen erklärt diesen Mechanismus im Detail.

Der ursprüngliche Date:-Header ist in jeder Nachricht intakt. Die DKIM-Signaturen sind intakt. Der Inhalt wurde nicht angetastet. Nur das serverseitige INTERNALDATE ist falsch.

Dieses Problem betrifft BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO und alle Tools, die IMAP APPEND verwenden, ohne das INTERNALDATE korrekt zu erhalten. Der Artikel zu BitTitan MigrationWiz behandelt die Besonderheiten dieses Tools. Die E-Mail-Migrations-Checkliste listet die Punkte auf, die vor und nach einer Migration zu prüfen sind, um solche Probleme zu vermeiden.

Der Unterschied zwischen Korrektur und Fälschung

Die Korrektur, die Redate.io vornimmt, ist das Gegenteil eines Fälschungsversuchs. Die proprietäre Korrektur-Engine analysiert die Header-Kette jeder Nachricht, identifiziert das ursprüngliche Datum, das im Date:-Header (RFC 2822) kodiert ist und sich nie verändert hat, und korrigiert die Datums-Metadaten, um sie mit dieser bereits in der Nachricht vorhandenen authentischen Information in Einklang zu bringen.

Der Date:-Header ist die Quelle der Wahrheit. Er wurde vom Mail-Client des Absenders zum Versandzeitpunkt geschrieben. Er ist durch die DKIM-Signatur abgedeckt. Redate.io verändert ihn nicht. Was korrigiert wird, ist die durch das Migrations-Tool eingeführte Diskrepanz, nicht das ursprüngliche Datum.

47.000 E-Mails nach einer missglückten Migration zu korrigieren, ohne eine einzige zu verlieren, ohne Konversations-Threads zu zerstören, ohne Anhänge zu beschädigen, ohne um 3 Uhr morgens einen 429-Fehler auf der Google-API auszulösen: Das ist eine mehrstufige Analyse-Pipeline mit Behandlung von Grenzfällen (S/MIME, PGP, Nicht-ASCII-Encodierungen nach RFC 2047, komplexe Multipart-Strukturen). Ein Python-Skript mit fünf Zeilen würde das erste Produktiv-Postfach nicht überleben. Können E-Mail-Daten nach der Migration korrigiert werden? zeigt im Detail, warum der DIY-Ansatz bei realen Volumina riskant ist.

Redate.io scannt Postfächer kostenlos, identifiziert E-Mails mit falschen Daten und korrigiert sie über eine Validierungs-Pipeline, die jede Nachricht einzeln prüft. Die Originale werden 30 Tage lang in einem sichtbaren Sicherungsordner aufbewahrt. Falls etwas schiefgeht, ist ein Rollback möglich.

Hat Ihre Migration die Daten Ihrer E-Mails verschoben? Starten Sie einen kostenlosen Scan auf Redate.io, um das Ausmaß des Problems zu messen, bevor Sie entscheiden, wie Sie vorgehen.