Exchange IMAP Import: Why Email Dates Go Wrong

Exchange's Transport Pipeline and Your Email Dates

Exchange Online has a transport pipeline. Every message that enters a mailbox, whether it arrives from the internet, gets moved between folders, or gets imported via IMAP, passes through this pipeline. And the pipeline does what pipelines do: it stamps the message with metadata. Including a fresh Received: header with today's date.

This is the root cause of date corruption during Exchange IMAP imports. Not a bug. Not a misconfiguration. A deliberate architectural decision by Microsoft that treats every message entering a mailbox as a "new delivery," even when that message is actually 7 years old.

The result? You import 4,000 emails from an old IMAP server into Exchange Online, and every single one shows the import date. Emails from 2018, 2020, 2023, all stamped with today's date. Your users open Outlook on Monday morning and see a wall of identically-dated messages.

How the Exchange Admin Center Migration Wizard Works

The Exchange Admin Center (EAC) includes a built-in migration wizard for IMAP imports. It's the graphical interface that most Exchange admins reach for first: you go to Recipients, then Migration, create a new batch, select "Migrate to Exchange Online," pick IMAP as the source, upload a CSV with mailbox mappings, and start the batch.

Behind the scenes, the EAC migration wizard creates a New-MigrationBatch with the endpoint type set to IMAP. Exchange connects to your source IMAP server, reads each message, and writes it into the target Exchange Online mailbox. Simple enough on paper.

But here's what happens at the transport level. When Exchange Online receives the message from the IMAP source, it processes it through the same transport pipeline that handles regular email delivery. The pipeline adds a Received: header with the current timestamp. It sets the message's internal delivery date to now. And Outlook, OWA, and every other client connected to that mailbox uses this delivery date for display and sorting.

The original Date: header from 2019? Still there, buried in the message headers. But Exchange doesn't use it for the sort order in your inbox.

Received: from source-imap.oldserver.com (10.0.0.5) by
    AM6PR04MB5127.eurprd04.prod.outlook.com (2603:10a6:20b:f3::12)
    with Microsoft SMTP Server; Thu, 2 Apr 2026 08:44:19 +0000
Date: Fri, 22 Nov 2019 16:08:33 +0100

PowerShell: New-MailboxImportRequest and the Same Problem

Admins who prefer the command line often turn to New-MailboxImportRequest for importing PST files, or New-MigrationBatch with IMAP endpoints for server-to-server migrations. The expectation is that PowerShell gives more control. And it does, for some things. Not for dates.

New-MailboxImportRequest imports PST files into Exchange Online mailboxes. The PST file contains the original timestamps for every message. But when Exchange Online processes the import, the transport pipeline still stamps each message with a new delivery date. The PowerShell cmdlet doesn't have a parameter to override this behavior. There's no -PreserveDates flag (and believe me, admins have searched for one).

New-MigrationBatch -SourceEndpoint with an IMAP endpoint works similarly to the EAC wizard, just without the graphical interface. Same IMAP connection, same transport pipeline processing, same date overwriting. The cmdlet offers parameters for filtering by date range (-StartAfter, -CompleteAfter) and excluding folders, but nothing that controls how Exchange handles the incoming message's timestamp.

To be precise, this mainly affects the display date and sort order. The message content, including the original Date header, arrives intact. Exchange just wraps it in its own transport metadata and uses that for everything visible to the user.

Direct IMAP Import vs. Third-Party Tools

Does it matter whether you use Exchange's native IMAP import or a third-party tool like BitTitan MigrationWiz or CloudM? The short answer: the date problem happens either way, but for slightly different reasons.

With Exchange's native IMAP import (EAC wizard or PowerShell), Exchange itself connects to the source IMAP server and pulls messages. The transport pipeline processes each message on arrival. One pipeline, one set of headers added.

With third-party tools, the migration tool acts as an intermediary. It reads from the source, potentially transforms the message, and writes to Exchange Online. Exchange's transport pipeline still processes the incoming message, but the third-party tool may have also added its own Received: header during the relay. So you can end up with two layers of incorrect date metadata: one from the tool's processing and one from Exchange's transport pipeline.

The practical difference? When fixing dates after a native Exchange IMAP import, there's typically one migration Received: header to deal with. After a third-party tool migration into Exchange, there might be two or three. The underlying problem is identical, but the header chain is messier.

Why Exchange Online's Transport Rules Make It Worse

Here's something that catches even experienced Exchange admins off guard. Exchange Online has transport rules (now called "mail flow rules" in the admin center) that can fire on imported messages. If your organization has rules that stamp headers, add disclaimers, or modify messages based on conditions, those rules may process imported emails too.

This means an email from 2020 might not only get a new Received header with today's date, it might also get a disclaimer footer appended, or an X-header stamped by a compliance rule that didn't exist when the original email was sent. The date corruption is the most visible symptom, but transport rules can create additional unexpected modifications.

Can you disable transport rules during import? Yes, temporarily. But most admins don't think to do it because they don't expect the transport pipeline to process migrated messages in the first place. By the time they realize what happened, the import batch is complete and the damage is done.

What Wrong Dates Mean for Exchange Environments

Exchange environments tend to be business environments. Law firms, financial institutions, healthcare organizations, government agencies. These aren't personal Gmail accounts where a wrong date is mildly annoying. These are mailboxes where email timestamps have legal and regulatory significance.

A litigation hold in Exchange preserves emails based on date ranges. If every imported email shows the import date instead of the original date, the hold captures the wrong set of messages. An eDiscovery search for "all communications between January and March 2022" returns nothing because those emails now show April 2026.

Retention policies hit the same problem. An organization with a 3-year retention policy might accidentally delete emails that appear to be from 2026 (and are therefore "new") when they're actually from 2019 and should be preserved. Or the opposite: emails that should have been purged under the retention policy stick around because their apparent date is recent.

One scenario from late 2025: an MSP migrated around 200 mailboxes from a hosted Exchange provider to Microsoft 365 using the EAC migration wizard. Three weeks later, the client's compliance officer flagged that quarterly email archival reports showed every archived message with the same date. The entire email archive, going back 5 years, appeared to have arrived on a single Tuesday in November.

Fixing Exchange IMAP Import Dates

The original Date: header survives the Exchange transport pipeline intact. Microsoft's pipeline adds metadata around the message but doesn't modify the original RFC 2822 headers inside it. That original date is the anchor point for correction.

Redate.io connects to the Exchange Online mailbox (via Microsoft 365 admin-consented access), scans for messages with date anomalies caused by the IMAP import, and applies a proprietary correction engine that performs RFC compliance validation, message structure preservation, and targeted metadata reconstruction. The engine recognizes Exchange-specific transport pipeline signatures in the Received header chain and distinguishes import artifacts from legitimate delivery headers.

Every corrected message is verified individually: content integrity, attachment checksums, folder placement, and conversation threading. Originals are preserved in a visible backup folder for 30 days. If anything looks wrong, rollback is one click away.

Why not fix it with a PowerShell script? Because understanding the Received header problem is the easy part. Correcting 8,000 emails across 50 mailboxes without corrupting S/MIME signed messages, breaking nested MIME structures, mangling non-ASCII RFC 2047 headers, or losing folder assignments is the hard part. How do you verify that every single corrected message in a production environment is intact, that no attachment was lost, that no conversation thread was broken? A script that works on a test mailbox with 30 messages will choke on real-world edge cases. That contract with a 42 MB attachment and three inline images embedded in a multipart/mixed structure inside a multipart/alternative wrapper? Good luck.

Platform-Specific Guides

The date fix applies at the Exchange Online mailbox level, but users access their email through different clients. Each one displays dates differently:

• Fix Exchange IMAP import dates in Outlook
• Fix Exchange IMAP import dates in OWA (Outlook on the Web)

Looking for broader context on Microsoft 365 date issues across different migration tools? See the complete guide to fixing email dates after Microsoft 365 migration.

Exchange IMAP import left your mailboxes with wrong dates? Start with a free scan to see how many emails are affected and what the correction costs, no credit card required.