Exchange IMAP Import: Why Email Dates Go Wrong

Exchange IMAP Imports and Your Email Dates

Exchange Online gives every message in a mailbox a date, and that's the date Outlook shows and sorts by. For an email that arrives from the internet, it's the moment of delivery. For an email copied in by a migration, it's whatever date the migration gave the copy: the original one when the migration passes it along, the day of the import when it doesn't.

That's where date corruption during Exchange IMAP imports comes from. Exchange Online doesn't overwrite a date it's given. But when an import doesn't carry each email's original date, the copy of a 7-year-old message gets the date of the import, as if it had just been delivered.

The result? You import 4,000 emails from an old IMAP server into Exchange Online, and emails show the import date instead of their own. Emails from 2018, 2020, 2023, dated today. 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 admins run into. Microsoft doesn't document how the migration sets the date of each copied message, and admins report emails that come out with the date of the sync instead of the date they were received. Outlook, OWA, and every other client connected to that mailbox then use that 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.

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 the PowerShell cmdlet doesn't have a parameter that controls which date each imported message gets. 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 result for dates. 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. Only the date the copy was given is wrong, and that's the one behind 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. How it sets the date of each copy is up to Microsoft, and not documented.

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. When the tool writes over IMAP, Exchange Online keeps the date the tool passes: if the tool sends each email's original date, the copy keeps it; if it doesn't, the copy gets the date of the migration. Some tools also add their own Received: header during the relay.

The practical difference? The headers left behind aren't the same from one tool to another, so a fix can't rely on one fixed pattern. The underlying problem is identical: the date shown isn't the email's original date.

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 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 import intact. The import doesn't modify the original RFC 2822 headers inside the message. That original date is the anchor point for correction.

Redate.io connects to the Exchange Online mailbox (each person signs in with their own Microsoft account), 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. Redate doesn't need to know which tool did the import: it finds the emails whose displayed date doesn't match their original date.

Every corrected message is verified individually: content integrity, attachment checksums, folder placement, and conversation threading. Originals stay in a visible backup folder of your own mailbox until you delete them yourself. 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.