Wrong Email Dates After Zoho to Microsoft 365 Migration

What happened to your mailbox

You just finished migrating your domain from Zoho Mail to Microsoft 365. Exchange Online is set up, mailboxes are provisioned, MX records are updated. Then Monday morning, a user opens Outlook and notices every email from 2021 is showing today's date. Another user sees messages from last year sitting at the top of the inbox, as if they just arrived. The tickets start rolling in.

This isn't an Outlook bug. It's not a Zoho-specific issue either. It's the expected, but poorly documented, behavior of any IMAP migration into Exchange Online. Understanding exactly why it happens is the first step to fixing it properly.

The technical root cause: INTERNALDATE and Received headers

An email stored on an IMAP server is made up of two distinct things: the raw message content (RFC 2822 headers, body, attachments) and the storage metadata managed by the IMAP server, which includes the INTERNALDATE. That metadata is what email clients actually use to display and sort messages.

The Date: header embedded in the raw message (RFC 2822) represents when the message was composed or sent by the sender. INTERNALDATE is when the IMAP server received or stored the message. On a healthy server, these two values are close. After a migration, that's a different story entirely.

How IMAP migration corrupts dates

When a migration tool (the Zoho Migration Wizard, imapsync, BitTitan, or anything else) transfers a message from Zoho Mail to Exchange Online, it does so over the IMAP protocol. The tool connects to Zoho, fetches the message, then inserts it into Exchange Online. And that's where things go wrong.

Exchange Online, upon receiving each message, generates a new Received: header and prepends it to the message. That header carries the exact date and time of insertion, meaning the migration date. Some migration tools try to preserve the original INTERNALDATE by passing it as a parameter. Others don't, or do it incorrectly, in which case Exchange Online automatically assigns the receipt timestamp as the INTERNALDATE.

The result: whether an email was sent in 2019 or 2022, its INTERNALDATE now points to migration week. Outlook reads that value first. Sorting collapses.

How the Zoho Migration Wizard behaves specifically

Zoho offers its own migration tool for leaving the platform: the Zoho Migration Wizard. It's convenient for simple migrations, but it has a documented behavior on admin forums: it doesn't always transmit the original INTERNALDATE correctly when inserting into the destination server.

To be precise, the problem mainly affects migrations to servers that systematically add a Received: header to every incoming message, which is exactly what Exchange Online does. Even if the Zoho Migration Wizard passes the original date via the APPEND parameter, the Received: header generated by Exchange Online ends up first in the header chain, and Outlook uses it to determine "when the email arrived".

Admins using generic IMAP tools like imapsync to leave Zoho hit the exact same problem, sometimes worse, because imapsync's default configuration isn't tuned for Exchange Online. (If you've ever scrolled through an imapsync log at 2 AM hunting down a sync error, you know it's a powerful tool that isn't particularly forgiving around edge cases.)

Why Outlook shows the wrong date

Outlook doesn't rely solely on the Date: header to display an email's date. In most views, it's the INTERNALDATE provided by the IMAP/Exchange server that drives sorting in the inbox. The original Date: header is still present in the message, intact, but it gets ignored in favor of INTERNALDATE.

That's why switching to "Sort by sent date" in Outlook doesn't actually solve anything. It shows a different value, sure, but sort behavior remains unstable depending on the Outlook version and view mode (grouped conversations or not). Sorting by sent date is not a fix. It's a bandage that falls off after the next client update.

The real scope of the problem

On a medium-sized Zoho to Microsoft 365 migration, you're easily looking at 50,000 to 500,000 affected messages, depending on how old the mailboxes are and the size of the organization. Every email transferred during the migration window carries the same corrupted date, which makes the problem immediately visible to users the moment they open Outlook.

Sent folders are often the worst. A sales rep searching for a quote sent in March 2022 has to dig through hundreds of emails all showing the migration date. The operational impact is real, not just cosmetic.

And contrary to what you might hope, the problem doesn't fade over time. INTERNALDATE is fixed at the moment of insertion. It doesn't correct itself. Without active intervention, those emails keep their corrupted date indefinitely.

Why fixing this yourself is riskier than it looks

The temptation makes sense: since the original Date: header is still in the message, you just need to... fix the metadata. Logically, that tracks. In practice, on a production mailbox with 80,000 emails, this is an operation that can go catastrophically wrong.

Here are some edge cases a homemade script probably won't handle well:

• S/MIME signed emails, where the signature covers the entire header structure. Modifying anything in the message invalidates the cryptographic signature.
• PGP encrypted messages, where the content is opaque and any manipulation of MIME envelopes can corrupt the message.
• Non-ASCII headers encoded per RFC 2047 (sender names with special characters), which break if the script doesn't handle encoding correctly.
• Base64-encoded attachments with malformed line endings, non-standard MIME boundaries, or nested multipart structures.
• Emails with no valid Date: header (these exist, especially in older Zoho exports), where the script has to decide what to do.

A script that works on 50 test emails won't work on a production Zoho mailbox with years of history. And how do you verify, message by message, that every corrected email is intact and no attachments were truncated? Verification is at least as complex as the correction itself.

There's also the quota problem. The Exchange Online API, via Microsoft Graph, enforces strict rate limits (the classic 429 Too Many Requests error). An unthrottled batch over 100,000 messages can trigger temporary blocks or silent errors that are nearly impossible to diagnose after the fact. Without a proper retry mechanism, you're starting over from scratch.

How Redate.io fixes dates after a Zoho migration

Redate.io connects to your Microsoft 365 tenant using standard Azure AD permissions, without requiring global admin access. The initial scan is free: Redate.io identifies affected mailboxes and estimates the volume of emails with incorrect dates, comparing INTERNALDATE against the values carried in the message's header chain.

The correction uses a proprietary engine that analyzes the full header chain of each message, identifies the specific signatures of Zoho migration tools (whether the Zoho Migration Wizard or imapsync configured for a Zoho departure), and reconstructs date metadata via a multi-stage validation pipeline. Each corrected email is verified individually: content integrity, attachment preservation, RFC compliance. Originals are kept in an accessible backup folder for 30 days.

No re-migration. No downtime. Users keep working in Outlook while the correction runs in the background.

Pricing is a one-time payment based on volume, no subscription. Details are available directly on the site.

Related scenarios worth knowing

If you're managing multiple migrations at once, or you're an MSP handling clients leaving Zoho, note that the same problem occurs when migrating from other platforms into Exchange Online. The mechanics are identical: the Received: header generated by Exchange overwrites INTERNALDATE regardless of the source.

For migrations from Google Workspace, on-premises Exchange, or via tools like BitTitan MigrationWiz or CloudM, dedicated articles on the Redate.io blog cover the specific behavior of each tool. The Wrong Email Dates After Exchange Online Migration article gives a full overview of every scenario that ends up on that tenant.

If your migration includes shared mailboxes or Exchange resources (rooms, equipment), the problem is the same, and the same correction tools apply. The Exchange IMAP migration date fix guides on the Redate.io site walk through the tenant connection steps.

For teams using imapsync specifically to leave Zoho, the imapsync: dates not preserved guide documents the imapsync configuration options and why they're not enough to avoid the problem on Exchange Online.

Still seeing your Zoho migration dates in Outlook? Scan your mailboxes for free on Redate.io to measure the exact scope of the problem before deciding how to act.