Dates d'emails fausses après migration Zoho vers Microsoft 365

Ce qui s'est passé sur votre boîte mail

Vous venez de finaliser la migration de votre domaine depuis Zoho Mail vers Microsoft 365. L'infrastructure Exchange Online est en place, les boîtes sont provisionnées, les enregistrements MX sont mis à jour. Et puis, lundi matin, un utilisateur ouvre Outlook et remarque que tous ses emails de 2021 affichent la date d'aujourd'hui. Un autre constate que ses messages de l'année dernière sont triés en haut de sa boîte de réception, comme s'ils venaient d'arriver. Les tickets commencent à tomber.

Ce n'est pas un bug Outlook. Ce n'est pas non plus un problème spécifique à Zoho. C'est le comportement attendu, mais mal documenté, de n'importe quelle migration IMAP vers Exchange Online, et comprendre exactement pourquoi ça arrive est la première étape pour le corriger proprement.

La cause technique : INTERNALDATE et en-têtes Received

Un email stocké sur un serveur IMAP est composé de deux choses distinctes : le contenu brut du message (les en-têtes RFC 2822, le corps, les pièces jointes) et les métadonnées de stockage gérées par le serveur IMAP, dont l'INTERNALDATE. C'est cette métadonnée qui intéresse les clients mail pour afficher et trier les messages.

L'en-tête Date: défini dans le message brut (RFC 2822) représente la date à laquelle le message a été composé ou envoyé par l'expéditeur. L'INTERNALDATE, lui, est la date à laquelle le serveur IMAP a reçu ou stocké le message. Normalement, sur un serveur sain, ces deux valeurs sont proches. Après une migration, c'est une autre histoire.

Comment la migration IMAP corrompt les dates

Quand un outil de migration (le Zoho Migration Wizard, imapsync, BitTitan, ou n'importe quel autre) transfère un message de Zoho Mail vers Exchange Online, il le fait via le protocole IMAP. L'outil se connecte à Zoho, récupère le message, puis l'insère dans Exchange Online via une commande IMAP APPEND. Et c'est là que ça se gâte.

Exchange Online, à réception de chaque message, génère un nouvel en-tête Received: qu'il ajoute en tête du message. Cet en-tête porte la date et l'heure exactes de l'insertion, c'est-à-dire la date de la migration. Certains outils de migration tentent de préserver l'INTERNALDATE original en le passant comme paramètre à la commande APPEND. D'autres ne le font pas, ou le font incorrectement, auquel cas Exchange Online attribue automatiquement la date de réception comme INTERNALDATE.

Résultat : qu'il s'agisse d'un email envoyé en 2019 ou en 2022, son INTERNALDATE pointe désormais vers la semaine de migration. Outlook lit cette valeur en priorité. Le tri s'effondre.

Le comportement spécifique du Zoho Migration Wizard

Zoho propose son propre outil de migration pour quitter sa plateforme : le Zoho Migration Wizard. Cet outil est pratique pour les migrations simples, mais il a un comportement documenté sur les forums d'administrateurs : il ne transmet pas toujours correctement l'INTERNALDATE original lors de l'insertion dans le serveur de destination.

Pour être précis, le problème touche principalement les migrations vers des serveurs qui ajoutent systématiquement un en-tête Received: à chaque message entrant, ce qui est exactement le comportement d'Exchange Online. Même si le Zoho Migration Wizard passe la date originale via le paramètre APPEND, l'en-tête Received: généré par Exchange Online se retrouve en première position dans la chaîne d'en-têtes, et Outlook s'en sert pour déterminer "quand l'email est arrivé".

Les admins qui utilisent des outils IMAP génériques comme imapsync pour quitter Zoho rencontrent exactement le même problème, parfois en pire, parce que la configuration par défaut d'imapsync n'est pas optimisée pour Exchange Online. (D'ailleurs, si vous avez déjà parcouru un log imapsync ligne par ligne à la recherche d'une erreur de synchronisation à 2h du matin, vous savez que c'est un outil puissant mais pas particulièrement indulgent pour les cas limites.)

Pourquoi Outlook affiche la mauvaise date

Outlook n'utilise pas uniquement l'en-tête Date: pour afficher la date d'un email. Dans la majorité des affichages, c'est l'INTERNALDATE fourni par le serveur IMAP/Exchange qui est utilisé, notamment pour le tri de la boîte de réception. L'en-tête Date: original est bien présent dans le message, intact, mais il est ignoré au profit de l'INTERNALDATE.

C'est pourquoi l'option "Trier par date d'envoi" dans Outlook ne résout pas vraiment le problème. Elle affiche une date différente, certes, mais le comportement de tri reste instable selon les versions d'Outlook et les modes de vue (conversations regroupées ou non). Le tri par date d'envoi n'est pas une solution. C'est un pansement qui tombe à la première mise à jour de client.

L'étendue réelle du problème

Sur une migration Zoho vers Microsoft 365 de taille moyenne, on parle facilement de 50 000 à 500 000 messages affectés, selon l'ancienneté des boîtes et la taille de l'organisation. Chaque email transféré pendant la fenêtre de migration porte la même date corrompue, ce qui rend le problème immédiatement visible pour les utilisateurs dès la première ouverture d'Outlook.

Les dossiers Envoyés sont souvent les plus problématiques. Un commercial qui cherche un devis envoyé en mars 2022 se retrouve à fouiller dans des centaines d'emails qui affichent tous la date de migration. L'impact opérationnel est réel, pas juste cosmétique.

Et contrairement à ce qu'on pourrait croire, le problème ne disparaît pas avec le temps. L'INTERNALDATE est fixé au moment de l'insertion. Il ne se corrige pas tout seul. Sans intervention active, les emails garderont leur date corrompue indéfiniment.

Pourquoi corriger ça soi-même est plus risqué qu'il n'y paraît

La tentation est compréhensible : puisque l'en-tête Date: original est toujours dans le message, il suffit de... corriger les métadonnées. Sur le papier, c'est logique. En pratique, sur une boîte de production de 80 000 emails, c'est une opération qui peut tourner catastrophiquement mal.

Voici quelques cas limites qu'un script maison ne gérera probablement pas bien :

• Les emails S/MIME signés, dont la signature couvre l'intégralité des en-têtes. Modifier quoi que ce soit dans la structure du message invalide la signature cryptographique.
• Les messages PGP chiffrés, où le contenu est opaque et toute manipulation des enveloppes MIME peut corrompre le message.
• Les en-têtes non-ASCII encodés en RFC 2047 (noms d'expéditeurs avec caractères spéciaux), qui cassent si le script ne gère pas l'encodage correctement.
• Les pièces jointes encodées en base64 avec des lignes mal terminées, des frontières MIME non standard, ou des structures multipart imbriquées.
• Les emails sans en-tête Date: valide (ça existe, notamment dans les vieux exports Zoho), où le script doit décider quoi faire.

Un script qui fonctionne sur 50 emails de test ne fonctionnera pas sur une boîte de production Zoho exportée avec des années d'historique. Et comment vérifier, message par message, que chaque correction est intacte et que les pièces jointes n'ont pas été tronquées ? La vérification est au moins aussi complexe que la correction elle-même.

Il y a aussi la question des quotas. L'API Exchange Online, via Microsoft Graph, impose des limites de taux strictes (les fameuses erreurs 429 Too Many Requests). Un batch non throttlé sur 100 000 messages peut déclencher des blocages temporaires ou des erreurs silencieuses difficiles à diagnostiquer après coup. Sans mécanisme de reprise sur incident, vous recommencez depuis le début.

Comment Redate.io corrige les dates après migration Zoho

Redate.io se connecte à votre tenant Microsoft 365 via les permissions Azure AD standard, sans accès admin global. Le scan initial est gratuit : Redate.io identifie les boîtes affectées et estime le volume d'emails avec des dates incorrectes, en comparant l'INTERNALDATE aux valeurs portées par la chaîne d'en-têtes du message.

La correction utilise un moteur propriétaire qui analyse la chaîne complète d'en-têtes de chaque message, identifie les signatures spécifiques des outils de migration Zoho (qu'il s'agisse du Zoho Migration Wizard ou d'imapsync configuré pour un départ de Zoho), et reconstruit les métadonnées de date via un pipeline de validation multi-étapes. Chaque email corrigé est vérifié individuellement : intégrité du contenu, préservation des pièces jointes, conformité RFC. Les originaux sont conservés dans un dossier de sauvegarde accessible pendant 30 jours.

Pas de re-migration. Pas de downtime. Les utilisateurs continuent à utiliser Outlook pendant que la correction s'exécute en arrière-plan.

La tarification est un paiement unique basé sur le volume, sans abonnement. Les détails sont disponibles directement sur le site.

Cas voisins à connaître

Si vous gérez plusieurs migrations en parallèle, ou si vous êtes MSP et que vous administrez des clients qui quittent Zoho, notez que le même problème se produit lors de migrations depuis d'autres plateformes vers Exchange Online. La mécanique est identique : l'en-tête Received: généré par Exchange écrase l'INTERNALDATE quelle que soit la source.

Pour les migrations depuis Google Workspace, depuis Exchange on-premises, ou via des outils comme BitTitan MigrationWiz ou CloudM, les articles dédiés sur le blog de Redate.io détaillent les comportements spécifiques à chaque outil. La page Mauvaises dates email après migration vers Exchange Online donne une vue d'ensemble de tous les scénarios qui aboutissent sur ce tenant.

Si votre migration implique des boîtes partagées ou des ressources Exchange (salles, équipements), le problème est le même, et les mêmes outils de correction s'appliquent. Les guides de correction IMAP vers Exchange sur le site Redate.io détaillent les étapes de connexion à votre tenant.

Pour les équipes qui utilisent imapsync spécifiquement pour quitter Zoho, la page imapsync : dates non préservées documente les options de configuration imapsync et pourquoi elles ne suffisent pas à éviter le problème sur Exchange Online.

Vos dates de migration Zoho sont toujours affichées dans Outlook ? Scannez vos boîtes gratuitement sur Redate.io pour mesurer l'étendue exacte du problème avant de décider comment agir.