Falsches E-Mail-Datum nach Migration von Zoho zu Microsoft 365

Was in Ihrem Postfach passiert ist

Die Migration Ihrer Domain von Zoho Mail zu Microsoft 365 ist abgeschlossen. Die Exchange-Online-Infrastruktur steht, die Postfächer sind provisioniert, die MX-Einträge aktualisiert. Und dann, Montagmorgen, öffnet ein Benutzer Outlook und stellt fest, dass alle seine E-Mails aus 2021 das heutige Datum anzeigen. Ein anderer bemerkt, dass Nachrichten vom letzten Jahr ganz oben in seinem Posteingang auftauchen, als wären sie soeben angekommen. Die ersten Tickets trudeln ein.

Das ist kein Outlook-Bug. Es ist auch kein Zoho-spezifisches Problem. Es passiert, wenn das Migrationstool das Originaldatum jeder E-Mail nicht übergibt. Genau zu verstehen, warum es passiert, ist der erste Schritt, um es sauber zu beheben.

Die technische Ursache: INTERNALDATE und Received-Header

Eine auf einem IMAP-Server gespeicherte E-Mail besteht aus zwei verschiedenen Dingen: dem rohen Nachrichteninhalt (RFC-2822-Header, Textkörper, Anhänge) und den vom IMAP-Server verwalteten Speichermetadaten, darunter das INTERNALDATE. Genau diese Metadaten nutzen E-Mail-Clients, um Nachrichten anzuzeigen und zu sortieren.

Der im rohen Nachrichteninhalt definierte Header Date: (RFC 2822) gibt das Datum an, an dem die Nachricht vom Absender verfasst oder gesendet wurde. Das INTERNALDATE hingegen ist das Datum, an dem der IMAP-Server die Nachricht empfangen oder gespeichert hat. Auf einem gesunden Server liegen diese beiden Werte normalerweise nah beieinander. Nach einer Migration sieht das ganz anders aus.

Wie eine IMAP-Migration das Datum beschädigen kann

Wenn ein Migrationstool (der Zoho Migration Wizard, imapsync, BitTitan oder ein anderes) eine Nachricht von Zoho Mail zu Exchange Online überträgt, geschieht das über das IMAP-Protokoll. Das Tool verbindet sich mit Zoho, ruft die Nachricht ab und fügt sie über einen IMAP APPEND-Befehl in Exchange Online ein. Und genau hier liegt das Problem.

Exchange Online behält das Datum, das es erhält: Wenn das Tool das ursprüngliche INTERNALDATE jeder Nachricht mit dem APPEND-Befehl übergibt, behält die Kopie dieses Datum. Manche Migrationstools tun das. Andere tun das nicht, oder sie tun es fehlerhaft. In letzterem Fall weist Exchange Online den Moment der Einfügung, also das Migrationsdatum, als INTERNALDATE zu.

Das Ergebnis: Ob es sich um eine E-Mail aus dem Jahr 2019 oder 2022 handelt, ihr INTERNALDATE zeigt nun auf die Migrationswoche. Outlook liest diesen Wert vorrangig. Die Sortierung bricht zusammen.

Das spezifische Verhalten des Zoho Migration Wizard

Zoho bietet ein eigenes Migrationstool für den Wechsel zur Konkurrenz an: den Zoho Migration Wizard. Das Tool ist für einfache Migrationen praktisch, hat aber ein in Administrator-Foren dokumentiertes Verhalten: Es überträgt das ursprüngliche INTERNALDATE beim Einfügen in den Zielserver nicht immer korrekt.

Genauer gesagt: Wenn der Zoho Migration Wizard das ursprüngliche Datum tatsächlich übergibt, behält Exchange Online es bei, und Outlook zeigt das richtige Datum an. Die E-Mails, die das Migrationsdatum zeigen, sind jene, deren Datum nicht mit übergeben wurde.

Admins, die generische IMAP-Tools wie imapsync für den Wechsel von Zoho verwenden, können auf dasselbe Problem stoßen: imapsync kopiert das Datum, das der Quellserver für jede Nachricht vorhält, sodass ein falsches Datum an der Quelle zu einem falschen Datum am Ziel wird. (Wer schon einmal einen imapsync-Log Zeile für Zeile nach einem Synchronisierungsfehler um 2 Uhr nachts durchforstet hat, weiß: Das ist ein mächtiges Tool, aber keins, das Grenzfälle besonders nachsichtig behandelt.)

Warum Outlook das falsche Datum anzeigt

Outlook verwendet für die Datumsanzeige einer E-Mail nicht ausschließlich den Date:-Header. Bei der Mehrzahl der Ansichten, besonders bei der Sortierung des Posteingangs, wird das vom IMAP/Exchange-Server gelieferte INTERNALDATE verwendet. Der originale Date:-Header ist zwar intakt in der Nachricht vorhanden, wird aber zugunsten des INTERNALDATE ignoriert.

Deshalb löst die Option "Nach Sendedatum sortieren" in Outlook das Problem nicht wirklich. Sie zeigt zwar ein anderes Datum an, aber das Sortierverhalten bleibt je nach Outlook-Version und Ansichtsmodus (gruppierte Unterhaltungen oder nicht) instabil. Nach Sendedatum zu sortieren ist keine Lösung. Es ist ein Pflaster, das bei der nächsten Client-Aktualisierung abfällt.

Das tatsächliche Ausmaß des Problems

Bei einer mittelgroßen Migration von Zoho zu Microsoft 365 sind schnell 50.000 bis 500.000 betroffene Nachrichten erreicht, je nach Alter der Postfächer und Größe der Organisation. Jede während des Migrationsfensters übertragene E-Mail trägt dasselbe beschädigte Datum, was dazu führt, dass das Problem für Benutzer sofort beim ersten Öffnen von Outlook sichtbar wird.

Der Ordner "Gesendete Elemente" ist oft am stärksten betroffen. Ein Vertriebsmitarbeiter, der ein im März 2022 verschicktes Angebot sucht, muss sich durch Hunderte von E-Mails wühlen, die alle das Migrationsdatum anzeigen. Die operative Auswirkung ist real, nicht nur kosmetisch.

Und anders als man meinen könnte, verschwindet das Problem nicht mit der Zeit. Das INTERNALDATE wird zum Zeitpunkt der Einfügung festgesetzt. Es korrigiert sich nicht von selbst. Ohne aktiven Eingriff behalten die E-Mails ihr beschädigtes Datum auf unbestimmte Zeit.

Warum eine manuelle Korrektur riskanter ist, als sie aussieht

Die Versuchung ist verständlich: Da der ursprüngliche Date:-Header noch immer in der Nachricht vorhanden ist, müsste man doch einfach... die Metadaten korrigieren. Auf dem Papier klingt das logisch. In der Praxis ist es bei einem Produktionspostfach mit 80.000 E-Mails eine Operation, die katastrophal schiefgehen kann.

Hier einige Grenzfälle, die ein selbst geschriebenes Skript wahrscheinlich nicht korrekt behandeln wird:

• S/MIME-signierte E-Mails, deren Signatur die gesamten Header abdeckt. Jede Änderung an der Nachrichtenstruktur macht die kryptografische Signatur ungültig.
• PGP-verschlüsselte Nachrichten, bei denen der Inhalt undurchsichtig ist und jede Manipulation der MIME-Umschläge die Nachricht beschädigen kann.
• Nicht-ASCII-Header, die nach RFC 2047 kodiert sind (Absendernamen mit Sonderzeichen), die brechen, wenn das Skript die Kodierung nicht korrekt verarbeitet.
• Anhänge, die in Base64 mit schlecht abgeschlossenen Zeilen, nicht standardkonformen MIME-Grenzen oder verschachtelten Multipart-Strukturen kodiert sind.
• E-Mails ohne gültigen Date:-Header (das gibt es tatsächlich, besonders in alten Zoho-Exporten), bei denen das Skript entscheiden muss, was zu tun ist.

Ein Skript, das bei 50 Test-E-Mails funktioniert, wird bei einem Zoho-Produktionspostfach mit Jahren an Historie nicht funktionieren. Und wie prüft man Nachricht für Nachricht, dass jede Korrektur intakt ist und keine Anhänge abgeschnitten wurden? Die Überprüfung ist mindestens so komplex wie die Korrektur selbst.

Dazu kommt die Frage der API-Kontingente. Die Exchange-Online-API über Microsoft Graph unterliegt strengen Ratenbegrenzungen (die bekannten 429-Too-Many-Requests-Fehler). Ein unkontrollierter Batch über 100.000 Nachrichten kann temporäre Sperren oder stille Fehler auslösen, die im Nachhinein schwer zu diagnostizieren sind. Ohne Wiederherstellungsmechanismus bei Fehlern fängt man von vorne an.

Wie Redate.io Daten nach einer Zoho-Migration korrigiert

Redate.io verbindet sich über Standard-Azure-AD-Berechtigungen mit Ihrem Microsoft-365-Tenant, ohne globalen Admin-Zugriff. Der erste Scan ist kostenlos: Redate.io identifiziert die betroffenen Postfächer und schätzt das Volumen der E-Mails mit falschen Daten, indem es das INTERNALDATE mit den Werten der Header-Kette der Nachricht vergleicht.

Die Korrektur verwendet ein proprietäres Modul, das die vollständige Header-Kette jeder Nachricht analysiert, dabei nicht wissen muss, welches Tool die Migration durchgeführt hat (Zoho Migration Wizard, imapsync oder ein anderes), und die Datumsmetadaten über eine mehrstufige Validierungs-Pipeline rekonstruiert. Jede korrigierte E-Mail wird einzeln überprüft: Inhaltsintegrität, Anhänge erhalten, RFC-Konformität. Die Originale bleiben unverändert in einem sichtbaren Sicherungsordner Ihres eigenen Postfachs, bis Sie sie selbst löschen.

Keine Re-Migration. Kein Downtime. Benutzer arbeiten weiterhin in Outlook, während die Korrektur im Hintergrund läuft.

Die Preisgestaltung basiert auf einem einmaligen Zahlungsbetrag nach Volumen, ohne Abonnement. Details sind direkt auf der Website verfügbar.

Verwandte Szenarien, die Sie kennen sollten

Wenn Sie mehrere Migrationen parallel verwalten oder als MSP Kunden betreuen, die Zoho verlassen, gilt dasselbe Problem auch bei Migrationen von anderen Plattformen zu Exchange Online. Die Mechanik ist identisch: Die Kopie erhält das vom Tool übergebene Datum, unabhängig von der Quelle.

Bei Migrationen von Google Workspace, von Exchange on-premises oder über Tools wie BitTitan MigrationWiz oder CloudM beschreiben die entsprechenden Artikel im Redate.io-Blog das spezifische Verhalten jedes Tools. Der Artikel Falsches E-Mail-Datum nach Migration zu Exchange Online gibt einen Überblick über alle Szenarien, die auf diesem Tenant enden.

Wenn Ihre Migration gemeinsame Postfächer oder Exchange-Ressourcen (Räume, Ausstattung) umfasst, ist das Problem dasselbe, und dieselben Korrekturwerkzeuge gelten. Die Anleitungen zur IMAP-nach-Exchange-Korrektur auf der Redate.io-Website beschreiben die Schritte zur Verbindung mit Ihrem Tenant.

Für Teams, die imapsync speziell für den Wechsel von Zoho verwenden, dokumentiert der Artikel imapsync: Daten nicht erhalten? die imapsync-Konfigurationsoptionen und woher die falschen Datumsangaben wirklich kommen.

Zeigt Outlook Ihre Zoho-Migrationsdaten noch immer falsch an? Scannen Sie Ihre Postfächer kostenlos auf Redate.io, um das genaue Ausmaß des Problems zu messen, bevor Sie entscheiden, wie Sie vorgehen.