New Outlook: Wrong Dates After Migration, Real Causes

Two Outlooks, two behaviors with the same emails

If you've recently migrated mailboxes to Microsoft 365 and some users are complaining that all their old emails show the same date (the migration date), you may have noticed something odd: users on classic Outlook sometimes see the correct date in the reading pane, while those on the new Outlook for Windows consistently see the migration date. Same mailbox. Same emails. Different results.

This isn't a bug in the strict sense. It's an architectural decision with direct consequences for how dates display after an IMAP migration. Understanding what's happening requires getting into the details of email headers and the IMAP protocol, which isn't exactly light reading, but it does explain why no client-side workaround is enough to fix the problem.

IMAP INTERNALDATE: the real culprit

When an email is stored on an IMAP server, it has two types of dates that coexist and don't overlap.

The first is the Date: header, defined by RFC 2822. This is the date written into the message itself, the one the sender set when they sent the email. It's part of the message body and never changes, regardless of what path the email takes afterward.

The second is the INTERNALDATE, a piece of metadata managed by the IMAP server, external to the message itself. It's the date the server recorded the message. During a normal migration, serious tools preserve the original INTERNALDATE. But during a poorly configured migration, or with certain tools that don't handle this metadata correctly, INTERNALDATE gets reset to the day of the migration. The result: every migrated email carries the same received date as far as the server is concerned.

(By the way, if you've ever read imapsync or MigrationWiz logs, you know there are specific options for attempting to preserve INTERNALDATE. These options don't always work, and some destination servers simply refuse to honor them.)

Classic Outlook: how it reads dates

Classic Outlook, meaning the COM-based versions installed locally (Outlook 2016, 2019, 2021, and the Microsoft 365 Apps desktop client), uses a slightly more complex mechanism to determine which date to display in the message list.

For emails in the Sent folder, it relies on the Date: header. For received emails, it prioritizes INTERNALDATE from the server, but in certain contexts (particularly when the OST cache is involved, or during the first display in the reading pane), it can also read the Received: header chain to reconstruct an approximate original date.

This is why you see that inconsistent behavior: classic Outlook can sometimes display the correct date in the reading pane, because it reads the original Date: header for the detailed preview, even if the message list itself uses the corrupted INTERNALDATE. But that's not reliable, and it fixes nothing. Sorting is still wrong. Date-based searches are still wrong.

The new Outlook: a radically different architecture

The new Outlook for Windows, rolling out progressively since late 2023, is no longer a COM application. It's essentially a Progressive Web App (PWA) built on the same codebase as Outlook on the web (OWA). This redesign has deep implications.

The new Outlook delegates date display entirely to the Microsoft 365 API. It doesn't read Received: headers, doesn't dig through the header chain to find an original date, and makes no attempt at client-side reconstruction. It simply displays what the server returns: INTERNALDATE.

The result: if INTERNALDATE was corrupted during migration, the new Outlook has no hesitation. It displays the migration date for every affected email, no exceptions, no nuance. This is more consistent and predictable behavior than classic Outlook, but it makes the migration problem immediately visible and impossible to ignore.

You migrate 300 mailboxes on a Friday night. Monday morning, every user on the new Outlook sees their entire archive dated last weekend. The tickets come in fast.

Why no client-side workaround works

Many admins try client-side fixes before realizing the problem lives in the server data. Here are the classic attempts, and why they fail.

Sorting by "Sent Date" instead of "Received Date"

Sorting by sent date in Outlook relies on the Date: header, which is intact. So yes, this sort can work. But it's a bandage, not a fix. Date-based searches remain wrong. Date-based rules remain useless. And the user has to manually reconfigure every folder, every mailbox. Across 300 mailboxes, that's not realistic. Sorting by sent date isn't a real solution, and end users don't understand why you're asking them to change how they work.

Clearing the Outlook cache or recreating the profile

This doesn't touch INTERNALDATE on the server. After recreating the profile, Outlook re-syncs the emails from the server and pulls down the exact same corrupted metadata. The cache isn't the problem.

Switching to OWA instead

OWA and the new Outlook share the same database. If INTERNALDATE is corrupted on the Exchange Online server, OWA shows exactly the same wrong date. Changing the client doesn't change the data.

The problem is on the server, in the metadata of each message. No client-side action can fix data stored server-side.

The Received header trap: why it complicates everything

When a migration tool copies an email from one server to another over IMAP, the destination server automatically adds a Received: header at the top of the chain, stamped with the date and time of the insertion. This is normal behavior for RFC-compliant SMTP and IMAP servers.

These headers accumulate in reverse order of the email's path. The most recent is at the top. Some email clients read the first Received: header to estimate the received date, which gives them the migration date instead of the original.

To be precise: this behavior isn't specific to any one tool. BitTitan MigrationWiz, CloudM, imapsync, GSMMO, and even a manual IMAP copy between two Thunderbird clients all produce this result. The original Date: header survives intact inside the message. That's precisely what makes a correction technically possible. But INTERNALDATE is a separate piece of metadata managed by the server, and it can't be fixed by simply manipulating the message headers on the client side.

For a deeper look at this mechanism, the article on IMAP INTERNALDATE and why dates break covers how this metadata is handled across different servers.

Which migration tools cause this problem on Microsoft 365

The question comes up often: do all migration tools cause this problem?

The short answer is that it depends on the configuration and the destination platform. On Exchange Online / Microsoft 365, the server is particularly strict about INTERNALDATE handling. Even tools that attempt to preserve it sometimes fail, because the Graph API and EWS (Exchange Web Services) behave differently depending on which insertion path is used.

BitTitan MigrationWiz is one of the most widely used tools for migrations to Microsoft 365, and it's also one of the best-documented sources of date problems. The dedicated page on fixing BitTitan migration dates in Microsoft 365 covers the specific configurations to watch for. CloudM and imapsync have their own quirks, documented respectively on fixing CloudM migration dates in Microsoft 365 and fixing imapsync migration dates in Microsoft 365.

What's common across all these tools: the original Date: header survives the migration. That's the foundation on which a correction is possible.

Why a homemade script is a bad idea here

Understanding the problem can create the illusion that the solution is simple. It isn't, not at production scale.

Modifying the metadata of emails stored on Exchange Online is not trivial. Microsoft's Graph API enforces strict rate limits (the 429 Too Many Requests error during a nightly batch happens faster than you'd expect). Handling S/MIME signed or PGP encrypted emails requires careful attention to avoid invalidating signatures. Multipart structures with large attachments add constraints around network timeouts. And the core question: how do you verify, email by email, that the correction worked without altering content or attachments?

A script that runs cleanly on 50 test emails won't behave the same way on a mailbox with 40,000 messages and 8 years of history. The probability that an edge case breaks something grows with every additional thousand messages. And without a rollback mechanism, an error halfway through leaves the mailbox in an inconsistent state.

See also: fixing email dates after a Microsoft 365 migration for a full overview of the available options.

What Redate.io actually does

Each person signs in with their own Microsoft account, and Redate.io opens that one mailbox with the access that sign-in grants, no portal, no application to register. It scans for emails with incorrect dates for free, then applies a proprietary correction engine to the identified messages. The multi-stage analysis pipeline performs pattern matching across hundreds of known migration tool signatures, RFC compliance validation, and header chain analysis to reconstruct the correct date metadata.

Every corrected email is verified individually. Original messages are kept in a visible backup folder, and Redate never deletes them: they stay there until you delete them yourself. The pricing model is a one-time payment per mailbox, no subscription.

The new Outlook then displays the correct dates, because the server data is fixed, not masked.

Got affected mailboxes on the new Outlook? Run a free scan on Redate.io to find out exactly how many emails are affected before deciding on next steps.