The Problem - Every Email Shows the Same Date
After an IMAP migration, users open their mailbox and discover something alarming: every single email displays the same date. Instead of showing the original sent or received date, each message shows the date the migration was performed. A mailbox with years of correspondence suddenly looks like everything arrived on a single day.
This is frustrating. IT administrators get flooded with complaints from users who can no longer find emails by date. Sorting by date becomes useless, and the chronological history of the mailbox is effectively destroyed.
What It Looks Like in Outlook
In Microsoft Outlook, the "Received" column shows the migration date for every email. Whether the original message was sent in 2018 or 2023, Outlook displays the same date - typically the day the migration tool processed that mailbox. The inbox, sent items, and every folder are affected. Users who rely on date-based sorting or search find their workflow completely broken.
What It Looks Like in Apple Mail
Apple Mail on macOS and iOS behaves similarly. The date displayed next to each message reflects the migration timestamp rather than the original date. Since Apple Mail uses the IMAP server's metadata to determine display dates, the same underlying problem produces the same visible result. Users scrolling through their inbox see a wall of identical dates.
What It Looks Like in Gmail Web
In the Gmail web interface, the impact is slightly different. Gmail's web client typically uses the "Date" header from the email itself, so messages may appear correctly when viewed in Gmail. However, the IMAP INTERNALDATE is still wrong, which means any IMAP client connecting to that Gmail account (Outlook, Thunderbird, Apple Mail) will show the migration date. This creates confusion when the same mailbox looks correct in one client but wrong in another.
Why This Happens - The Technical Cause
The root cause lies in how IMAP migration tools handle email headers and how email clients determine which date to display. Understanding this requires a brief look at the IMAP protocol and email header structure.
How IMAP Migration Tools Handle Email Headers
When an email is migrated from one server to another, the migration tool downloads the raw message from the source server and uploads it to the destination server using the IMAP APPEND command. During this process, the IMAP protocol requires the destination server to add a "Received" header to the message. This header contains the timestamp of when the message was inserted into the new server - the migration date.
The "Received" Header That Breaks Everything
Email messages typically contain multiple "Received" headers, each added by a mail server that handled the message during its original delivery. Email clients like Outlook determine the "received date" by looking at the most recent "Received" header - the one at the top of the header chain. When a migration tool adds a new "Received" header with the migration timestamp, it becomes the most recent header, and email clients display that date instead of the original.
This isn't a bug in the migration tool or the email client. Both are following the IMAP and email standards correctly. The problem is that the standards were never designed with bulk migration in mind, and the interaction between IMAP APPEND and email client date display logic produces this unintended result.
INTERNALDATE vs Date Header
IMAP servers store two different date values for each message. The "Date" header is part of the email message itself - it records when the message was originally composed and sent. The INTERNALDATE is metadata stored by the IMAP server, representing when the message was delivered to or inserted into that particular server.
Some migration tools attempt to preserve the original INTERNALDATE by setting it during the APPEND command. However, even when the INTERNALDATE is correctly set, the added "Received" header still causes problems in clients that prioritize the "Received" date over the INTERNALDATE. The result is that emails show the wrong date after migration regardless of whether the INTERNALDATE was preserved.
Which Migration Tools Cause This?
Nearly every IMAP migration tool can cause this problem. The issue is inherent to the IMAP protocol, not specific to any one tool. However, some tools are more commonly associated with the problem due to their widespread use.
BitTitan MigrationWiz
BitTitan MigrationWiz is one of the most popular commercial migration tools used by MSPs and IT consultants. MigrationWiz adds a "Received" header containing "mx.migrationwiz.com" during the migration process. This header becomes the most recent in the chain, causing all migrated emails to show the migration date in Outlook and other IMAP clients. See detailed guides for fixing BitTitan dates in Outlook, Microsoft 365, Google Workspace, and Exchange Online.
CloudM Migrate
CloudM Migrate (formerly Cloud Migrator) is widely used for Google Workspace migrations. Like other tools, CloudM adds its own "Received" header during the IMAP insertion process. Emails migrated with CloudM show the migration date in clients that rely on the "Received" header for date display. See detailed guides for fixing CloudM dates in Gmail, Outlook, Google Workspace, and Microsoft 365.
imapsync
imapsync is an open-source tool popular with Linux administrators and hosting providers. While imapsync attempts to preserve the INTERNALDATE, the destination server still adds a "Received" header during the APPEND operation. The imapsync FAQ acknowledges this limitation but does not offer a built-in solution for removing the added header after migration. See detailed guides for fixing imapsync dates in Outlook, Gmail, Microsoft 365, and Google Workspace.
GSMMO (Google Workspace Migration)
Google Workspace Migration for Microsoft Outlook (GSMMO) is Google's own tool for migrating from Exchange or Outlook PST files to Google Workspace. GSMMO can produce the same date issue, particularly when the migration involves an intermediate IMAP step or when the tool's header handling does not preserve the original date hierarchy. See detailed guides for fixing GSMMO dates in Outlook, Gmail, and Apple Mail.
Exchange Admin Center (Native IMAP Import)
Microsoft's own Exchange Admin Center includes a native IMAP import feature for migrating to Exchange Online (Microsoft 365). This built-in migration tool adds "Received" headers during the import process, causing the same date display issue in Outlook and other clients connecting to the migrated mailbox. See detailed guides for fixing Exchange IMAP migration dates in Outlook and OWA.
Manual IMAP Copy
Even manually copying emails between IMAP servers using a desktop client like Thunderbird can produce the wrong date issue. When an email client copies a message via IMAP, the destination server processes it as a new insertion and adds its own "Received" header with the current timestamp. See detailed guides for fixing manual IMAP copy dates in Outlook, Gmail, Thunderbird, and Apple Mail.
Why Common Workarounds Don't Work
When users and administrators encounter this problem, they typically try several workarounds before realizing that none of them actually solve the issue.
"Just Sort by Sent Date" - Why It's Not Enough
The most common suggestion is to switch from sorting by "Received" date to "Sent" date in the email client. While this can help with display order, it does not fix the underlying data. Search results still show the wrong date. Calendar integrations, compliance tools, and automated workflows that rely on the received date continue to malfunction. And users must remember to change this setting on every device and in every folder.
Re-migration - Expensive and Risky
Some administrators consider running the migration again, hoping to avoid the date issue on a second attempt. This approach is expensive (500 to 5,000 EUR depending on the number of mailboxes), time-consuming, and risky. A second migration introduces the same "Received" header problem, doubles the risk of data loss, and requires significant downtime. Re-migration does not fix the date issue unless the migration tool is fundamentally changed.
Manual Header Editing - Requires Server Access
Technically, the fix involves removing the migration "Received" header from each email. But doing this manually requires direct server access, knowledge of email header structure, and custom scripting. For a mailbox with 10,000 emails, manual header editing is impractical and dangerously error-prone. S/MIME signed emails, PGP encrypted messages, multipart structures with nested MIME boundaries, Content-Transfer-Encoding edge cases, non-ASCII headers (RFC 2047), oversized attachments: any of these can cause a naive script to corrupt data irreversibly. How do you confirm that 10,000 corrected emails are all intact? You don't, unless you have a verification system built from the ground up for exactly this purpose.
The Actual Fix - Restore Original Dates
The correct solution is to identify the migration artifacts in each email's header chain and apply targeted corrections that restore the original chronological order in every email client. This is not a simple header edit. The process involves RFC compliance validation, message structure preservation, and cross-referencing against a database of known migration tool patterns.
How Redate.io Fixes This
Redate.io connects to the mailbox (Google Workspace, Microsoft 365, or any IMAP server) and scans every email to identify messages affected by migration headers. The scan is free and shows exactly how many emails are affected before any payment is required.
For each affected email, Redate.io's proprietary correction engine runs the message through a multi-stage analysis pipeline. The engine applies pattern matching across hundreds of known migration tool signatures built from processing large volumes of real-world email data, handles encoding issues, multi-part message structures, inline attachments, and dozens of edge cases that would cause a DIY script to corrupt data (not the kind of thing you want to discover on a Monday morning). Every corrected email goes through integrity verification before being finalized. The original message is moved to a visible "Redate.io - Originals" folder (not deleted) and kept for 30 days.
The result? Emails display their correct original dates in every client. Sorting works again. The mailbox's chronological history is restored.
Frequently Asked Questions
Can dates be fixed months after migration?
Yes. The original "Date" header is preserved inside the email message regardless of when the migration occurred. Redate.io can fix email dates weeks, months, or even years after the migration was completed. The fix works as long as the original email headers are intact.
Will fixing dates delete my emails?
No. Redate.io never deletes emails. Original messages are moved to a visible folder called "Redate.io - Originals" in the mailbox, where they remain accessible for 30 days. Every fixed email is verified against the original before the process completes. If verification fails for any message, the original remains untouched.
Does this work with shared mailboxes?
Yes. Redate.io works with shared mailboxes in both Google Workspace and Microsoft 365. For shared mailboxes, admin-level access is required to authorize the connection. The fix process is identical to individual mailboxes - scan, fix, verify.
Ready to fix your email dates? Try Redate.io free scan and see how many emails need correction in your mailbox.