Exchange IMAP-Import: Warum E-Mail-Daten verloren gehen

Exchanges Transport-Pipeline und Ihre E-Mail-Daten

Exchange Online hat eine Transport-Pipeline. Jede Nachricht, die in ein Postfach gelangt, ob sie aus dem Internet kommt, zwischen Ordnern verschoben oder ueber IMAP importiert wird, durchlaeuft diese Pipeline. Und die Pipeline tut, was Pipelines eben tun: Sie versieht die Nachricht mit Metadaten. Einschliesslich eines neuen Received:-Headers mit dem heutigen Datum.

Das ist die eigentliche Ursache der Datumsverfaelschung bei Exchange-IMAP-Imports. Kein Bug. Keine Fehlkonfiguration. Eine bewusste Architekturentscheidung von Microsoft, die jede in ein Postfach eingehende Nachricht als "neue Zustellung" behandelt, selbst wenn diese Nachricht tatsaechlich 7 Jahre alt ist.

Das Ergebnis? Sie importieren 4.000 E-Mails von einem alten IMAP-Server in Exchange Online, und jede einzelne zeigt das Importdatum. E-Mails von 2018, 2020, 2023, alle mit dem heutigen Datum gestempelt. Ihre Benutzer oeffnen Outlook am Montagmorgen und sehen eine Wand identisch datierter Nachrichten.

Wie der EAC-Migrations-Assistent funktioniert

Das Exchange Admin Center (EAC) enthaelt einen integrierten Migrations-Assistenten fuer IMAP-Imports. Es ist die grafische Oberflaeche, nach der die meisten Exchange-Administratoren zuerst greifen: Man geht zu Empfaenger, dann Migration, erstellt einen neuen Batch, waehlt "Zu Exchange Online migrieren", waehlt IMAP als Quelle, laedt eine CSV mit Postfachzuordnungen hoch und startet den Batch.

Hinter den Kulissen erstellt der EAC-Migrations-Assistent ein New-MigrationBatch mit dem Endpunkttyp IMAP. Exchange verbindet sich mit Ihrem Quell-IMAP-Server, liest jede Nachricht und schreibt sie in das Ziel-Exchange-Online-Postfach. Einfach auf dem Papier.

Aber hier ist, was auf Transportebene passiert. Wenn Exchange Online die Nachricht von der IMAP-Quelle empfaengt, verarbeitet es sie durch dieselbe Transport-Pipeline, die auch die normale E-Mail-Zustellung abwickelt. Die Pipeline fuegt einen Received:-Header mit dem aktuellen Zeitstempel hinzu. Sie setzt das interne Zustellungsdatum der Nachricht auf jetzt. Und Outlook, OWA und jeder andere Client, der mit diesem Postfach verbunden ist, verwendet dieses Zustellungsdatum fuer Anzeige und Sortierung.

Der originale Date:-Header von 2019? Immer noch da, vergraben in den Nachrichten-Headern. Aber Exchange verwendet ihn nicht fuer die Sortierreihenfolge in Ihrem Posteingang.

Received: from source-imap.oldserver.com (10.0.0.5) by
    AM6PR04MB5127.eurprd04.prod.outlook.com (2603:10a6:20b:f3::12)
    with Microsoft SMTP Server; Thu, 2 Apr 2026 08:44:19 +0000
Date: Fri, 22 Nov 2019 16:08:33 +0100

PowerShell: New-MailboxImportRequest und dasselbe Problem

Administratoren, die die Kommandozeile bevorzugen, greifen oft zu New-MailboxImportRequest fuer den Import von PST-Dateien oder New-MigrationBatch mit IMAP-Endpunkten fuer Server-zu-Server-Migrationen. Die Erwartung ist, dass PowerShell mehr Kontrolle bietet. Und das tut es, fuer manche Dinge. Nicht fuer Daten.

New-MailboxImportRequest importiert PST-Dateien in Exchange-Online-Postfaecher. Die PST-Datei enthaelt die originalen Zeitstempel fuer jede Nachricht. Aber wenn Exchange Online den Import verarbeitet, stempelt die Transport-Pipeline trotzdem jede Nachricht mit einem neuen Zustellungsdatum. Das PowerShell-Cmdlet hat keinen Parameter, um dieses Verhalten zu ueberschreiben. Es gibt kein -PreserveDates-Flag (und glauben Sie mir, Administratoren haben danach gesucht).

New-MigrationBatch -SourceEndpoint mit einem IMAP-Endpunkt funktioniert aehnlich wie der EAC-Assistent, nur ohne die grafische Oberflaeche. Dieselbe IMAP-Verbindung, dieselbe Transport-Pipeline-Verarbeitung, dieselbe Datumsueberschreibung. Das Cmdlet bietet Parameter zum Filtern nach Datumsbereich (-StartAfter, -CompleteAfter) und zum Ausschliessen von Ordnern, aber nichts, das kontrolliert, wie Exchange den Zeitstempel der eingehenden Nachricht behandelt.

Um genau zu sein, betrifft dies hauptsaechlich das Anzeigedatum und die Sortierreihenfolge. Der Nachrichteninhalt, einschliesslich des originalen Date-Headers, kommt intakt an. Exchange verpackt ihn einfach in seine eigenen Transport-Metadaten und verwendet diese fuer alles, was dem Benutzer sichtbar ist.

Direkter IMAP-Import vs. Drittanbieter-Tools

Macht es einen Unterschied, ob man Exchanges nativen IMAP-Import oder ein Drittanbieter-Tool wie BitTitan MigrationWiz oder CloudM verwendet? Die kurze Antwort: Das Datumsproblem tritt in beiden Faellen auf, aber aus leicht unterschiedlichen Gruenden.

Beim nativen IMAP-Import von Exchange (EAC-Assistent oder PowerShell) verbindet sich Exchange selbst mit dem Quell-IMAP-Server und zieht die Nachrichten. Die Transport-Pipeline verarbeitet jede Nachricht bei der Ankunft. Eine Pipeline, ein Satz hinzugefuegter Header.

Bei Drittanbieter-Tools agiert das Migrationstool als Vermittler. Es liest von der Quelle, transformiert moeglicherweise die Nachricht und schreibt in Exchange Online. Exchanges Transport-Pipeline verarbeitet die eingehende Nachricht immer noch, aber das Drittanbieter-Tool hat moeglicherweise auch seinen eigenen Received:-Header waehrend der Weiterleitung hinzugefuegt. Man kann also mit zwei Schichten falscher Datums-Metadaten enden: eine von der Tool-Verarbeitung und eine von Exchanges Transport-Pipeline.

Der praktische Unterschied? Bei der Korrektur von Daten nach einem nativen Exchange-IMAP-Import gibt es typischerweise einen Migrations-Received:-Header zu behandeln. Nach einer Drittanbieter-Tool-Migration in Exchange koennen es zwei oder drei sein. Das zugrundeliegende Problem ist identisch, aber die Header-Kette ist unuebersichtlicher.

Warum Exchange Onlines Transportregeln es verschlimmern

Hier ist etwas, das selbst erfahrene Exchange-Administratoren ueberrascht. Exchange Online hat Transportregeln (jetzt "Nachrichtenflussregeln" im Admin Center), die bei importierten Nachrichten ausgeloest werden koennen. Wenn Ihre Organisation Regeln hat, die Header hinzufuegen, Haftungsausschluesse anfuegen oder Nachrichten basierend auf Bedingungen aendern, koennen diese Regeln auch importierte E-Mails verarbeiten.

Das bedeutet, eine E-Mail von 2020 koennte nicht nur einen neuen Received-Header mit dem heutigen Datum bekommen, sondern auch einen Haftungsausschluss angehaengt bekommen oder einen X-Header, der von einer Compliance-Regel gestempelt wurde, die es zum Zeitpunkt des Versands der Original-E-Mail noch gar nicht gab. Die Datumsverfaelschung ist das sichtbarste Symptom, aber Transportregeln koennen zusaetzliche unerwartete Aenderungen verursachen.

Kann man Transportregeln waehrend des Imports deaktivieren? Ja, voruebergehend. Aber die meisten Administratoren denken nicht daran, weil sie nicht erwarten, dass die Transport-Pipeline migrierte Nachrichten verarbeitet. Bis sie erkennen, was passiert ist, ist der Import-Batch abgeschlossen und der Schaden angerichtet.

Was falsche Daten in Exchange-Umgebungen bedeuten

Exchange-Umgebungen sind tendenziell Geschaeftsumgebungen. Anwaltskanzleien, Finanzinstitute, Gesundheitsorganisationen, Behoerden. Das sind keine persoenlichen Gmail-Konten, bei denen ein falsches Datum leicht aergerlich ist. Das sind Postfaecher, in denen E-Mail-Zeitstempel rechtliche und regulatorische Bedeutung haben.

Ein Litigation Hold in Exchange bewahrt E-Mails basierend auf Datumsbereichen auf. Wenn jede importierte E-Mail das Importdatum statt des Originaldatums zeigt, erfasst der Hold den falschen Satz von Nachrichten. Eine eDiscovery-Suche nach "alle Kommunikation zwischen Januar und Maerz 2022" liefert nichts, weil diese E-Mails jetzt April 2026 zeigen.

Aufbewahrungsrichtlinien haben dasselbe Problem. Eine Organisation mit einer 3-Jahres-Aufbewahrungsrichtlinie koennte versehentlich E-Mails loeschen, die scheinbar von 2026 stammen (und daher "neu" sind), obwohl sie tatsaechlich von 2019 sind und aufbewahrt werden sollten. Oder umgekehrt: E-Mails, die gemaess der Aufbewahrungsrichtlinie haetten geloescht werden sollen, bleiben erhalten, weil ihr scheinbares Datum aktuell ist.

Ein Szenario von Ende 2025: Ein MSP migrierte etwa 200 Postfaecher von einem gehosteten Exchange-Anbieter zu Microsoft 365 mit dem EAC-Migrations-Assistenten. Drei Wochen spaeter meldete der Compliance-Beauftragte des Kunden, dass die quartalsmaessigen E-Mail-Archivierungsberichte jede archivierte Nachricht mit demselben Datum zeigten. Das gesamte E-Mail-Archiv, das 5 Jahre umfasste, schien an einem einzigen Dienstag im November eingetroffen zu sein.

Exchange-IMAP-Importdaten korrigieren

Der originale Date:-Header ueberlebt die Exchange-Transport-Pipeline unbeschaedigt. Microsofts Pipeline fuegt Metadaten um die Nachricht herum hinzu, modifiziert aber nicht die originalen RFC-2822-Header darin. Dieses Originaldatum ist der Ankerpunkt fuer die Korrektur.

Redate.io verbindet sich mit dem Exchange-Online-Postfach (ueber vom Microsoft-365-Administrator genehmigte Zugaenge), scannt nach Nachrichten mit Datumsanomalien, die durch den IMAP-Import verursacht wurden, und wendet einen proprietaeren Korrekturmotor an, der RFC-Konformitaetspruefung, Nachrichtenstrukturerhaltung und gezielte Metadatenrekonstruktion durchfuehrt. Der Motor erkennt Exchange-spezifische Transport-Pipeline-Signaturen in der Received-Header-Kette und unterscheidet Import-Artefakte von legitimen Zustellungs-Headern.

Jede korrigierte Nachricht wird einzeln verifiziert: Inhaltintegritaet, Anhangs-Pruefsummen, Ordnerplatzierung und Konversations-Threading. Originale werden 30 Tage lang in einem sichtbaren Sicherungsordner aufbewahrt. Falls etwas nicht stimmt, ist der Rollback einen Klick entfernt.

Warum nicht mit einem PowerShell-Skript beheben? Weil das Verstehen des Received-Header-Problems der einfache Teil ist. 8.000 E-Mails in 50 Postfaechern zu korrigieren, ohne S/MIME-signierte Nachrichten zu beschaedigen, verschachtelte MIME-Strukturen zu zerstoeren, Nicht-ASCII-RFC-2047-Header zu verstumeln oder Ordnerzuweisungen zu verlieren, tatsaechlich, das ist der schwierige Teil. Wie verifizieren Sie, dass jede einzelne korrigierte Nachricht in einer Produktionsumgebung intakt ist? Ein Skript, das bei einem Testpostfach mit 30 Nachrichten funktioniert, versagt bei realen Grenzfaellen. Der Vertrag mit dem 42-MB-Anhang und drei Inline-Bildern in einer multipart/mixed-Struktur innerhalb eines multipart/alternative-Wrappers? Viel Glueck.

Plattformspezifische Anleitungen

Die Datumskorrektur erfolgt auf der Exchange-Online-Postfachebene, aber Benutzer greifen ueber verschiedene Clients auf ihre E-Mails zu. Jeder zeigt Daten anders an:

• Exchange-IMAP-Importdaten in Outlook korrigieren
• Exchange-IMAP-Importdaten in OWA korrigieren (Outlook im Web)

Sie suchen breiteren Kontext zu Microsoft-365-Datumsproblemen mit verschiedenen Migrationstools? Sehen Sie sich den vollstaendigen Leitfaden zur Korrektur von E-Mail-Daten nach Microsoft 365-Migration an.

Exchange-IMAP-Import hat Ihre Postfaecher mit falschen Daten hinterlassen? Starten Sie mit einem kostenlosen Scan, um zu sehen, wie viele E-Mails betroffen sind und was die Korrektur kostet, ohne Kreditkarte.