What Is Exchange Admin Center IMAP Import?
Microsoft provides a built-in IMAP migration feature in the Exchange Admin Center (EAC) that allows administrators to import emails from any IMAP server into Exchange Online (Microsoft 365). This native tool is designed for organizations migrating from non-Microsoft email platforms: Gmail, Zimbra, Dovecot, Courier, cPanel-hosted email, and any other server that supports IMAP.
The Exchange Admin Center IMAP import is often the first tool administrators try. No third-party software. No additional licensing costs. Directly integrated into the Microsoft 365 administration interface. It seems like the obvious choice.
But this native Microsoft tool produces the same date issue that affects third-party migration tools. After completing an IMAP import through the Exchange Admin Center, every migrated email displays the migration date instead of the original received date. Users open Outlook and find that years of email history appear to have arrived on a single day. It's Microsoft's own tool breaking dates in Microsoft's own email client.
How the Exchange IMAP Import Causes Date Problems
The Import Process
The Exchange Admin Center IMAP import works by connecting to the source IMAP server, downloading each email, and inserting it into the target Exchange Online mailbox. During this insertion process, Exchange Online treats each imported email as a new delivery and adds transport headers, including a "Received" header with the current timestamp - the import date.
The "Received" Header Added by Exchange Online
When Exchange Online receives a message (whether through normal delivery or IMAP import), it adds "Received" headers that document the message's path through Microsoft's mail transport infrastructure. These headers contain timestamps reflecting when Exchange Online processed the message. For imported emails, these timestamps match the date and time of the import operation, not the original delivery date.
A typical Exchange-added "Received" header during IMAP import looks like:
Received: from BN6PR01MB1234.prod.exchangelabs.com
by BN6PR01MB5678.prod.exchangelabs.com with HTTPS;
Mon, 15 Jan 2024 08:30:45 +0000This header is placed at the top of the header chain, making it the most recent "Received" header. Outlook reads this header to determine the received date and displays the import date for every migrated email.
Why Microsoft's Own Tool Has This Issue
It seems absurd that Microsoft's own migration tool causes a date display issue in Microsoft's own email client. But the explanation is actually logical: the IMAP import correctly records when it processed the message (a requirement of email transport standards), and Outlook correctly reads the most recent "Received" header to determine the received date (standard email client behavior). The combination of these two correct behaviors produces an incorrect result for migrated emails. Two right things making a wrong. For the full technical explanation, see why emails show wrong dates after IMAP migration.
Configuring the IMAP Import (Does Not Prevent the Issue)
Exchange Admin Center Settings
The Exchange Admin Center IMAP import offers configuration options for folder mapping, item filtering, and migration batch scheduling. But none of these options control how Exchange Online handles "Received" headers during import. There's no checkbox for "preserve original dates" and no setting that prevents Exchange from adding transport headers. The date issue is a consequence of the mail transport architecture, not a missing configuration option.
PowerShell Migration Cmdlets
Administrators who use PowerShell cmdlets (New-MigrationBatch, New-MoveRequest) for IMAP migration have access to additional parameters, but none of them prevent the "Received" header from being added. The Start-MigrationBatch cmdlet and related commands control the migration process, not the mail transport behavior of Exchange Online. Even with the most careful PowerShell configuration, imported emails will have the migration date as their recieved date in Outlook.
The Impact on Outlook and OWA
Outlook Desktop
Outlook Desktop is the most affected client. The default view sorts emails by "Received" date, which shows the import timestamp for every migrated message. Users who rely on date-based searching, sorting, and filtering find their workflow completely broken. An inbox spanning five years of correspondence appears as though everything arrived on the same day. How do you find that important email from 2021 when every message says it arrived in January 2024?
Outlook on the Web (OWA)
OWA displays the same wrong dates as Outlook Desktop. Unlike the Gmail web interface (which sometimes reads the "Date" header), OWA consistently uses the Exchange delivery timestamp. There is no OWA setting or view option that displays the original date instead of the import date.
Outlook Mobile
Outlook Mobile (iOS and Android) also displays the import date. The problem is consistent across all Outlook platforms because they all read the same date value from Exchange Online. For a complete guide on Outlook-specific date issues, see fix Outlook wrong date after migration.
Common Workarounds (and Why They Fail)
Sorting by "Sent" Date
The most frequently suggested workaround is changing the Outlook view to sort by "Sent" date instead of "Received" date. While this changes the display order, it doesn't fix the underlying data. The "Received" date remains wrong in search results, rules, compliance tools, and any other feature that references the received timestamp. And this workaround requires every user to change settings on every device.
Re-running the IMAP Import
Re-importing the emails doesn't fix the date issue. A second import adds another set of "Received" headers with a new timestamp, further complicating the header chain without correcting the displayed date. Re-importing may also create duplicate emails if the tool doesn't properly handle de-duplication.
Using a Different Migration Tool
Switching to a third-party migration tool (BitTitan MigrationWiz, CloudM, or imapsync) doesn't avoid the date issue. Every tool that inserts emails into Exchange Online triggers the same transport header behavior. The issue is in how Exchange Online processes incoming messages, not in the migration tool itself. For a comparison of all fix options, see can email dates be fixed after migration.
Fixing Exchange IMAP Import Dates with Redate.io
How Redate.io Identifies Exchange Import Headers
Redate.io connects to Exchange Online and runs each email through its proprietary multi-stage analysis pipeline. For Exchange IMAP imports, Redate.io applies pattern matching across hundreds of known migration signatures, including Exchange Online transport infrastructure patterns (such as "prod.exchangelabs.com"), to precisely identify which "Received" headers were added during import versus which ones are part of the original delivery chain.
What Redate.io Delivers
After processing, every corrected email displays its original received date in Outlook, OWA, and every connected client. Chronological order is restored. Every fix goes through integrity verification before it's finalized, and originals are preserved in a "Redate.io - Originals" folder for 30 days. The correction engine handles the edge cases that make DIY approaches dangerous: S/MIME signed messages, PGP-encrypted content, multipart MIME structures with nested boundaries, encoding variations, and corrupted MIME boundaries. This is far more complex than a find-and-replace on header text.
Connecting to Exchange Online
Redate.io connects to Exchange Online via Azure AD (Entra ID) app registration with OAuth2 authentication. The administrator creates an app registration, grants Mail.ReadWrite permissions, and provides admin consent. No user passwords are required. The setup process takes about 15 minutes and follows the same patterns used by other Microsoft-certified applications.
Platform-Specific Guides
Frequently Asked Questions
Is this a known issue with Microsoft?
Microsoft doesn't officially document this as a known issue with the Exchange Admin Center IMAP import. Support tickets about the date issue typically receive workaround suggestions (sort by Sent date) rather than a fix. The issue is a consequence of standard Exchange transport behavior, not a bug in the import feature.
Can PowerShell fix the dates after import?
No. Exchange Online PowerShell doesn't provide cmdlets for modifying the raw content of existing email messages. The Set-Mailbox and related cmdlets control mailbox configuration, not individual message headers. The fix requires working at a level that PowerShell simply doesn't expose for Exchange Online.
Does Redate.io work with hybrid Exchange environments?
Yes. Redate.io works with any mailbox hosted in Exchange Online, no matter whether the organization uses a hybrid Exchange configuration. The fix is applied to the Exchange Online mailbox and doesn't require access to on-premises Exchange servers.
Exchange IMAP import left every email with the wrong date? Start a free scan with Redate.io to identify affected emails in each mailbox and restore correct dates in Outlook, OWA, and every connected client.