Falsche E-Mail-Daten 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 ist das erwartete, aber schlecht dokumentierte Verhalten jeder IMAP-Migration zu Exchange Online. 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 die IMAP-Migration Daten beschädigt

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 erzeugt beim Empfang jeder Nachricht einen neuen Received:-Header, der an den Anfang der Nachricht gesetzt wird. Dieser Header trägt Datum und Uhrzeit der Einfügung, also das Migrationsdatum. Manche Migrationstools versuchen, das ursprüngliche INTERNALDATE zu erhalten, indem sie es als Parameter an den APPEND-Befehl übergeben. Andere tun das nicht, oder sie tun es fehlerhaft. In letzterem Fall weist Exchange Online automatisch das Empfangsdatum 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 betrifft das Problem vor allem Migrationen zu Servern, die systematisch einen Received:-Header zu jeder eingehenden Nachricht hinzufügen, was genau das Verhalten von Exchange Online ist. Selbst wenn der Zoho Migration Wizard das ursprüngliche Datum über den APPEND-Parameter übergibt, landet der von Exchange Online generierte Received:-Header an erster Stelle in der Header-Kette, und Outlook nutzt genau diesen, um zu bestimmen, "wann die E-Mail angekommen ist".

Admins, die generische IMAP-Tools wie imapsync für den Wechsel von Zoho verwenden, stoßen auf exakt dasselbe Problem, manchmal sogar in schlimmerer Form, weil die Standardkonfiguration von imapsync nicht für Exchange Online optimiert ist. (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, die spezifischen Signaturen der Zoho-Migrationstools erkennt (ob Zoho Migration Wizard oder imapsync, konfiguriert für einen Abgang von Zoho), 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 für 30 Tage in einem zugänglichen Sicherungsordner.

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: Der von Exchange generierte Received:-Header überschreibt das INTERNALDATE, 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 Falsche E-Mail-Daten 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 warum sie auf Exchange Online nicht ausreichen, um das Problem zu vermeiden.

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.