Outlook: IMAP Received Date vs Sent Date After Migration

The symptom everyone recognizes

You just finished an IMAP migration to Microsoft 365 or Google Workspace. Monday morning, the tickets start rolling in: "All my emails have the same date", "My inbox history is broken", "I can't find anything anymore." You open Outlook and sure enough, thousands of emails are showing last weekend's date. Not the date they were sent. The date the migration ran.

This isn't an Outlook bug. It's a direct consequence of how the IMAP protocol and migration tools work. But to understand why, you need to open the hood.

Three dates inside a single email

An email is more complex than it looks. Headers, message body, attachments... and several distinct timestamps coexisting in the same file. (If you've ever tried reading raw email headers, you know it's not exactly beach reading.)

The Date: header (RFC 2822)

This is the date the sender stamped on the message at the moment of sending. Defined by RFC 2822, it looks like this:

Date: Tue, 14 Mar 2023 09:42:17 +0100

This header is baked into the message itself. It never changes, unless someone directly modifies the raw message content. It's the "sent date" in the strict sense.

The Received: header (added at each network hop)

Every server that handles an email in transit adds a Received: header to the top of the message, with its own timestamp. An email that passes through three servers accumulates three Received: headers. The most recent one always appears first. It looks something like this:

Received: from mail.example.com ([93.184.216.34])
        by mx.google.com with ESMTPS
        id x1234abcd.2024.06.15.08.31.02;
        Sat, 15 Jun 2024 08:31:02 +0000 (UTC)

So when a migration tool like BitTitan MigrationWiz, CloudM, imapsync, or GSMMO moves an email from a source server to a destination server, it behaves like another network hop. It injects a new Received: header at the very top of the stack, stamped with the migration date and time.

The IMAP INTERNALDATE

This is the third date, and the one that causes the problem. The INTERNALDATE is a metadata value stored server-side in IMAP, independent of the message content itself. It represents when the email was delivered (or inserted) into the mailbox. When a migration tool inserts an email, it chooses what value to assign to the INTERNALDATE. And in many cases, tools use the current migration timestamp. Not the original date.

That's where everything breaks down.

Why Outlook shows the migration date

Outlook uses INTERNALDATE to populate the "Received" column. This is its default behavior, and it's consistent with the IMAP spec: INTERNALDATE is supposed to represent when a message arrived in the mailbox. In a normal email flow (a real incoming message), INTERNALDATE is close to the value in the Date: header. They're coherent.

After a broken migration, the INTERNALDATE of every imported email points to the night of June 14-15, 2024 (or whatever migration date applies). Outlook reads this value, displays it in the "Received" column, and the result is catastrophic: 45,000 emails appear to have arrived on the same evening.

To be precise, the first Received: header (the most recent in the stack) also influences display in certain configurations. But INTERNALDATE remains the primary driver for the "Received" column in Outlook with IMAP sync.

The "Add the Sent column" workaround in Outlook

The first thing most IT admins do when they discover the problem is look for a client-side workaround. And there is one.

In Outlook, you can customize the column layout of a folder to replace (or supplement) the "Received" column with the "Date" or "Sent" column. The "Date" column reads directly from the message's Date: header, not from INTERNALDATE. Since the Date: header wasn't touched by the migration, the original dates reappear.

To do this in Outlook (desktop, Microsoft 365 version): right-click the column header in the message list, choose "View Settings", then modify the columns to remove "Received" and add "Date". This can be deployed via GPO for an organization-wide rollout.

On paper, this fixes the visual problem. In practice, it's a bandage on an artery.

The real limits of this workaround

Mobile and web clients

Outlook on iOS, Android, and Outlook Web App (OWA) don't offer the same customization options. The view change you deployed on Windows machines doesn't carry over. Users checking email on their phones keep seeing the migration date. In a mid-size organization, that's probably half your users.

Search

Outlook search relies on the Windows Search index (or the Exchange/Microsoft 365 server-side index). That index is built from INTERNALDATE, not the Date: header. If a user searches for "emails from January 2022", search returns messages where INTERNALDATE falls in January 2022. Not messages where the Date: header says January 2022. Old emails simply don't surface in date filters anymore. Changing the display column does absolutely nothing about this.

Email rules

Outlook rules ("if email was received before...", "if email was received after...") also use INTERNALDATE. Any rule based on date ranges for sorting or archiving will stop working correctly after migration if INTERNALDATE hasn't been corrected.

Compliance and eDiscovery

This is probably the most serious issue. Compliance tools, legal archiving systems, and eDiscovery platforms (Microsoft Purview, for example) use INTERNALDATE as the reference point for legal queries. If your organization has retention obligations or needs to respond to discovery requests, corrupted INTERNALDATEs can create genuine legal exposure. An audit requesting "all emails between date X and date Y" won't return the right results.

Third-party tools

CRMs, ticketing systems, email archivers... anything that connects to your mail server via IMAP or the Microsoft 365/Google Workspace APIs reads INTERNALDATE. Adjusting the Outlook view fixes nothing for these systems.

The only real fix: correct at the server level

Sorting by sent date in Outlook isn't a solution. It's a patch. The real fix has to happen at the server metadata level, not the client view.

Concretely, that means correcting the INTERNALDATE of each email so it matches the original value from the Date: header. The original Date: header is always present in the message (the migration didn't erase it), which is what makes correction possible. That's where the real date information lives.

On Google Workspace, the Gmail API exposes an internalDate parameter that lets you act directly on this metadata. On Microsoft 365, the mechanism differs but the expected result is the same. On a standard IMAP server, the spec allows the date to be specified when inserting a message.

Actually, doing this on tens of thousands of production emails without data loss, without duplicates, without breaking threads or labels, while handling edge cases (S/MIME signed messages, complex MIME structures, non-ASCII encodings per RFC 2047, oversized attachments, already-corrupted MIME boundaries after migration) is a different matter entirely. A script that works on 50 test emails won't hold up against a 40,000-message mailbox. Handling 429 errors (API quota exhausted), network timeouts at 2 AM, messages with MIME structures already partially corrupted by the migration... all of that requires serious engineering.

That's precisely what Redate.io does. The proprietary correction engine analyzes the header chain of each email, identifies the reliable original date, and applies targeted metadata correction without touching the message content. Every corrected email is verified individually. Originals are kept in a backup folder for 30 days, which means a rollback is possible at any point. That's something a homemade script never offers.

Identifying the migration tool responsible

The problem looks the same regardless of which tool caused it, but the details vary. BitTitan MigrationWiz, CloudM, imapsync, and GSMMO each leave their own signature in the Received: headers they inject. Redate.io's analysis pipeline maintains a pattern-matching database across hundreds of known migration tool signatures to distinguish migration headers from legitimate transit headers in the chain.

If you don't know which tool was used for your migration (it happens, especially when inheriting infrastructure from another MSP), Redate.io's free scan identifies affected mailboxes and gives you a volume estimate before any commitment.

For specific contexts, detailed guides are available: fix imapsync dates in Outlook, fix BitTitan dates in Outlook, and fix CloudM dates in Outlook.

What to do now

If you're reading this after a migration, the good news is that the original Date: header is intact in every single email. The real date information is there, present in each message. The problem is in the metadata, not the content. And metadata can be fixed.

You can also read IMAP INTERNALDATE explained: why dates break to go deeper on the mechanics of the problem, or the full guide on wrong Outlook dates after migration for an overview of the different scenarios.

Ready to fix the dates in your mailboxes? Run a free scan on Redate.io to identify affected emails and estimate the volume before any correction.