Neues Outlook: falsche Daten nach Migration - Ursachen

Zwei Outlook-Versionen, zwei Verhaltensweisen bei denselben E-Mails

Sie haben kürzlich Postfächer zu Microsoft 365 migriert, und einige Nutzerinnen und Nutzer beschweren sich, dass alle ihre alten E-Mails dasselbe Datum anzeigen (das der Migration). Dabei haben Sie vielleicht etwas Merkwürdiges bemerkt: Nutzer mit dem klassischen Outlook sehen im Lesebereich manchmal das richtige Datum, während diejenigen mit dem neuen Outlook für Windows konsequent das Migrationsdatum angezeigt bekommen. Dasselbe Postfach. Dieselben E-Mails. Unterschiedliche Ergebnisse.

Das ist kein Bug im eigentlichen Sinne. Es ist eine Architekturentscheidung, die direkte Auswirkungen darauf hat, wie Datumsangaben nach einer IMAP-Migration angezeigt werden. Um zu verstehen, was hier passiert, muss man sich die Details der E-Mail-Header und des IMAP-Protokolls ansehen (kein leichter Lesestoff, aber notwendig), denn keine Maßnahme auf Client-Seite reicht aus, um das Problem wirklich zu beheben.

Das IMAP-INTERNALDATE: der eigentliche Übeltäter

Wenn eine E-Mail auf einem IMAP-Server gespeichert wird, existieren zwei Datumstypen nebeneinander, die nicht dasselbe sind.

Der erste ist der Date:-Header, definiert durch RFC 2822. Das ist das Datum, das in der Nachricht selbst steht, also das, was der Absender beim Versand eingetragen hat. Es ist Teil des Nachrichtentexts und ändert sich nie, egal welchen Weg die E-Mail danach nimmt.

Das zweite ist das INTERNALDATE: eine vom IMAP-Server verwaltete Metadaten-Information außerhalb der eigentlichen Nachricht. Es gibt an, wann der Server die Nachricht gespeichert hat. Bei einer ordentlich konfigurierten Migration bewahren seriöse Werkzeuge das ursprüngliche INTERNALDATE. Bei einer schlecht konfigurierten Migration, oder mit Tools, die diese Metadaten nicht korrekt verwalten, wird das INTERNALDATE auf das aktuelle Datum der Migration zurückgesetzt. Das Ergebnis: Alle migrierten E-Mails tragen aus Sicht des Servers dasselbe Eingangsdatum.

(Wer schon mal die Logs von imapsync oder MigrationWiz durchforstet hat, weiß, dass es spezifische Optionen gibt, um das INTERNALDATE zu erhalten. Diese Optionen funktionieren nicht immer, und manche Zielserver ignorieren sie schlicht.)

Klassisches Outlook: Wie es Datumsangaben liest

Das klassische Outlook, also die lokal installierten COM-Versionen (Outlook 2016, 2019, 2021 sowie der Microsoft 365 Apps Desktop-Client), verwendet einen etwas komplexeren Mechanismus, um zu entscheiden, welches Datum in der Nachrichtenliste angezeigt wird.

Für E-Mails im Gesendet-Ordner verlässt es sich auf den Date:-Header. Für empfangene E-Mails nutzt es vorrangig das INTERNALDATE des Servers, aber in bestimmten Situationen (insbesondere wenn der OST-Cache beteiligt ist oder beim ersten Anzeigen im Lesebereich) kann es auch die Received:-Header-Kette auslesen, um ein ungefähres Ursprungsdatum zu rekonstruieren.

Genau deshalb beobachtet man dieses inkonsistente Verhalten: Das klassische Outlook kann im Lesebereich manchmal das richtige Datum zeigen, weil es für die Detailvorschau den originalen Date:-Header der Nachricht liest, auch wenn die E-Mail-Liste selbst das beschädigte INTERNALDATE verwendet. Das ist aber nicht zuverlässig und behebt nichts. Die Sortierung bleibt kaputt, Datumssuchen bleiben fehlerhaft.

Das neue Outlook: eine grundlegend andere Architektur

Das neue Outlook für Windows, das seit Ende 2023 schrittweise ausgerollt wird, ist keine COM-Anwendung mehr. Es ist im Wesentlichen eine Progressive Web App (PWA), die auf derselben Codebasis wie Outlook im Web (OWA) aufbaut. Dieser Umbau hat weitreichende Konsequenzen.

Das neue Outlook delegiert die Datumsanzeige vollständig an die Microsoft 365 API. Es liest keine Received:-Header, sucht nicht in der Header-Kette nach einem Ursprungsdatum und unternimmt keinerlei Rekonstruktionsversuch auf Client-Seite. Es zeigt schlicht das an, was der Server zurückliefert: das INTERNALDATE.

Ist das INTERNALDATE durch die Migration beschädigt, zögert das neue Outlook keinen Moment. Es zeigt für jede betroffene E-Mail das Migrationsdatum an, ausnahmslos und ohne Differenzierung. Das Verhalten ist konsistenter und vorhersehbarer als beim klassischen Outlook, macht das Migrationsproblem aber sofort sichtbar und unmöglich zu ignorieren.

Ein Admin, der freitagabend 300 Postfächer migriert, stellt montagmorgens fest, dass alle Nutzerinnen und Nutzer mit dem neuen Outlook ihre gesamten Archive mit dem Datum des vergangenen Wochenendes sehen. Die Tickets kommen schnell.

Warum Client-seitige Workarounds nicht funktionieren

Viele Admins probieren Client-seitige Lösungen aus, bevor sie verstehen, dass das Problem in den Serverdaten liegt. Hier die klassischen Versuche und warum sie scheitern.

Sortierung nach "Sendedatum" statt nach "Empfangsdatum"

Die Sortierung nach Sendedatum in Outlook stützt sich auf den Date:-Header der Nachricht, der intakt ist. Sie kann also funktionieren. Aber das ist ein Pflaster, keine Lösung. Datumssuchen bleiben kaputt. Datumsbasierte Regeln bleiben unbrauchbar. Und vor allem: Der Nutzer muss jeden Ordner, jedes Postfach manuell umkonfigurieren. Bei 300 Postfächern ist das unrealistisch. Die Sortierung nach Sendedatum ist keine Lösung, und Endnutzer verstehen nicht, warum sie ihre Gewohnheiten ändern sollen.

Outlook-Cache leeren oder Profil neu erstellen

Das berührt das serverseitige INTERNALDATE nicht. Nach der Profilneuerstellung synchronisiert Outlook die E-Mails erneut vom Server und erhält exakt dieselben beschädigten Metadaten zurück. Der Cache ist nicht das Problem.

OWA stattdessen verwenden

OWA und das neue Outlook teilen dieselbe Datenbasis. Ist das INTERNALDATE auf dem Exchange Online-Server beschädigt, zeigt OWA exakt dasselbe falsche Datum. Den Client zu wechseln ändert die Daten nicht.

Das Problem sitzt auf dem Server, in den Metadaten jeder einzelnen Nachricht. Keine Client-seitige Aktion kann Daten korrigieren, die serverseitig gespeichert sind.

Die Received-Header-Falle: Warum sie alles komplizierter macht

Wenn ein Migrationstool eine E-Mail via IMAP von einem Server auf einen anderen kopiert, fügt der Zielserver automatisch einen Received:-Header oben in die Kette ein, mit Datum und Uhrzeit des Einfügens. Das ist das normale Verhalten RFC-konformer SMTP- und IMAP-Server.

Diese Header häufen sich in umgekehrter Reihenfolge des E-Mail-Weges an. Der neueste steht oben. Manche E-Mail-Clients lesen den ersten Received:-Header, um das Empfangsdatum zu schätzen, was dann das Migrationsdatum statt des Originaldatums ergibt.

Zur Klarstellung: Dieses Verhalten ist nicht auf ein einzelnes Tool beschränkt. BitTitan MigrationWiz, CloudM, imapsync, GSMMO und selbst eine manuelle IMAP-Kopie zwischen zwei Thunderbird-Clients führen alle zu diesem Ergebnis. Der originale Date:-Header bleibt in der Nachricht erhalten. Genau das macht eine technische Korrektur möglich. Das INTERNALDATE hingegen ist eine separate, serverseitig verwaltete Metadaten-Information und lässt sich nicht durch bloßes Manipulieren der Nachrichten-Header auf Client-Seite korrigieren.

Mehr zu diesem Mechanismus bietet der Artikel über IMAP INTERNALDATE und warum Datumsangaben kaputtgehen.

Welche Migrationstools dieses Problem bei Microsoft 365 verursachen

Die Frage taucht häufig auf: Verursachen alle Migrationstools dieses Problem?

Die kurze Antwort lautet: Es hängt von der Konfiguration und der Zielplattform ab. Auf Exchange Online / Microsoft 365 ist der Server beim Umgang mit dem INTERNALDATE besonders streng. Selbst Tools, die es zu erhalten versuchen, scheitern manchmal, weil die Graph API und EWS (Exchange Web Services) je nach verwendetem Einfügepfad unterschiedlich reagieren.

BitTitan MigrationWiz gehört zu den am weitesten verbreiteten Tools für Migrationen zu Microsoft 365, und seine Datumsporbleme sind auch am besten dokumentiert. Die Seite BitTitan-Migrationsdaten in Microsoft 365 korrigieren behandelt die spezifischen Konfigurationen, auf die man achten sollte. CloudM und imapsync haben ihre eigenen Besonderheiten, dokumentiert auf CloudM-Migrationsdaten in Microsoft 365 korrigieren und imapsync-Migrationsdaten in Microsoft 365 korrigieren.

Was alle diese Tools gemeinsam haben: Der originale Date:-Header überlebt die Migration. Das ist die Grundlage, auf der eine Korrektur möglich ist.

Warum ein selbst gebautes Skript hier keine gute Idee ist

Das Problem zu verstehen erzeugt manchmal die Illusion, die Lösung sei einfach. In einer Produktionsumgebung ist sie das nicht.

Die Metadaten von auf Exchange Online gespeicherten E-Mails zu ändern ist alles andere als trivial. Die Graph API von Microsoft erzwingt strenge Rate Limits (der 429 Too Many Requests-Fehler mitten in einem Nacht-Batch kommt schneller als erwartet). S/MIME-signierte oder PGP-verschlüsselte E-Mails erfordern besondere Sorgfalt, um Signaturen nicht zu invalidieren. Mehrteilige Strukturen mit großen Anhängen erzeugen Netzwerk-Timeout-Probleme. Und vor allem: Wie überprüft man, E-Mail für E-Mail, dass die Korrektur wirklich funktioniert hat, ohne Inhalt oder Anhänge zu beschädigen?

Ein Skript, das auf 50 Test-E-Mails sauber läuft, verhält sich auf einem Postfach mit 40.000 Nachrichten und 8 Jahren Historie ganz anders. Die Wahrscheinlichkeit, dass ein Grenzfall etwas kaputt macht, steigt mit jedem weiteren Tausend Nachrichten. Und ohne Rollback-Mechanismus hinterlässt ein Fehler auf halbem Weg ein Postfach in einem inkonsistenten Zustand.

Weitere Informationen bietet der Artikel E-Mail-Datum nach Microsoft-365-Migration korrigieren mit einem umfassenden Überblick der verfügbaren Möglichkeiten.

Was Redate.io konkret tut

Jede Person meldet sich mit ihrem eigenen Microsoft-Konto an, und Redate.io öffnet genau dieses Postfach mit den Rechten, die diese Anmeldung gewährt (kein Portal, keine gespeicherten Passwörter). Redate.io scannt E-Mails mit falschen Datumsangaben kostenlos und wendet anschließend ein proprietäres Korrekturmodul auf die identifizierten Nachrichten an. Die mehrstufige Analyse-Pipeline führt einen Abgleich mit Hunderten bekannter Migrationstool-Signaturen durch, validiert die RFC-Konformität und rekonstruiert die korrekten Datums-Metadaten durch Header-Kettenanalyse.

Jede korrigierte E-Mail wird einzeln überprüft. Die Originalnachrichten bleiben in einem sichtbaren Sicherungsordner Ihres eigenen Postfachs, bis Sie sie selbst löschen. Das Preismodell ist eine einmalige Zahlung pro Postfach, ohne Abonnement.

Das neue Outlook zeigt danach die richtigen Daten an, weil die Serverdaten korrigiert wurden, nicht überdeckt.

Haben Sie betroffene Postfächer im neuen Outlook? Starten Sie einen kostenlosen Scan auf Redate.io, um genau zu sehen, wie viele E-Mails betroffen sind, bevor Sie über das weitere Vorgehen entscheiden.