The Microsoft 365 Migration Date Problem
After migrating to Microsoft 365 (Exchange Online), organizations frequently discover something that should have been in the migration project's risk assessment but wasn't: every email in every mailbox displays the migration date instead of the original received date. Users open Outlook and see thousands of emails all stamped with the same date. Sorting by date is useless. Search results return misleading timestamps. The entire chronological history of the mailbox appears destroyed.
This problem affects migrations from every source platform: on-premises Exchange, Gmail, Google Workspace, Zimbra, Lotus Notes, and any other IMAP server. It hits migrations using every popular tool, including BitTitan MigrationWiz, the native Exchange Admin Center IMAP import, and third-party tools like CloudM and imapsync. The root cause is the same in every case: a "Received" header added during the migration process overrides the original date display in Outlook.
Common Migration Paths to Microsoft 365
From Gmail / Google Workspace
Organizations switching from Google Workspace to Microsoft 365 typically use BitTitan MigrationWiz, CloudM, or the Exchange Admin Center's IMAP import feature. Each of these tools extracts emails from Gmail and inserts them into Exchange Online. During insertion, Exchange Online adds a "Received" header with the migration timestamp. This header becomes the most recent "Received" header in the email, causing Outlook to display the migration date as the received date.
From On-Premises Exchange
Migrations from on-premises Exchange (2010, 2013, 2016, 2019) to Exchange Online use Microsoft's native migration tools (cutover migration, staged migration, hybrid migration) or third-party tools like BitTitan. Hybrid migrations that use the Exchange migration endpoint sometimes preserve dates correctly, but IMAP-based migrations and third-party tool migrations frequently produce the date issue. The outcome depends on exactly how the migration tool inserts messages into Exchange Online.
From Other IMAP Servers
Migrations from Zimbra, Zoho, cPanel-hosted email, Dovecot, and other IMAP servers to Microsoft 365 are typically performed using the Exchange Admin Center's native IMAP import or imapsync. Both methods result in Exchange Online adding "Received" headers during the import process. Every migrated email shows the migration date in Outlook.
How Exchange Online Handles Migrated Emails
Exchange Online and "Received" Headers
When a message is inserted into an Exchange Online mailbox (whether via IMAP, EWS, or the Microsoft Graph API), Exchange Online processes it as a new message delivery and adds transport-related headers. These headers include a "Received" entry with the current timestamp. For migrated emails, this timestamp is the migration date rather than the original delivery date.
How Outlook Reads the Date
Outlook (Desktop, Web, and Mobile) determines the "Received" date by reading the email's metadata and headers. The "Received" column - which is the default view in Outlook - shows the date from the topmost "Received" header or the delivery timestamp stored in Exchange. After migration, this value reflects when the migration tool delivered the message to Exchange Online, not when the message was originally sent or received. For a full technical explanation, see fix Outlook wrong date after migration.
Outlook on the Web (OWA)
Outlook on the web (OWA) shows the same wrong date as Outlook Desktop. Unlike the Gmail web interface (which sometimes shows the correct date from the "Date" header), OWA consistently displays the Exchange delivery timestamp. There's no client-side workaround. The fix must happen at the server level.
Microsoft's Built-In Tools Can't Fix This
Exchange Admin Center
The Exchange Admin Center provides extensive mailbox management features, but it doesn't include a tool for correcting email dates after migration. No bulk header editing capability. No date correction wizard. No PowerShell cmdlet that modifies the "Received" headers of existing messages.
Compliance Tools (eDiscovery, Retention)
Microsoft 365 compliance tools like eDiscovery and retention policies use the email's stored timestamps. After migration, these tools reflect the migration date, which can cause real problems with legal holds, regulatory compliance, and audit trails. This isn't just a user convenience issue, it can have legal and regulatory implications for organizations subject to email retention requirements.
PowerShell
Exchange Online PowerShell provides powerful mailbox management capabilities, but it can't modify the raw content of email messages. The Set-MailboxMessageConfiguration cmdlet and related commands control mailbox settings, not individual message headers. There's no supported PowerShell approach for removing "Received" headers from existing messages in Exchange Online. So what are administrators supposed to do?
Fixing Microsoft 365 Dates with Redate.io
How Redate.io Connects to Microsoft 365
Redate.io connects to Exchange Online via an Azure AD (Entra ID) application registration. The administrator creates an app registration in the Azure portal, grants the necessary mail permissions (Mail.ReadWrite), and provides admin consent for the tenant. This allows Redate.io to access all mailboxes in the organization through the Microsoft Graph API or IMAP with OAuth2 authentication.
The app registration process takes about 15 minutes and follows Microsoft's standard OAuth2 patterns. No user passwords are shared, authentication is handled entirely through Azure AD tokens.
Getting Started
Register an Azure AD Application. In the Azure portal, navigate to Azure Active Directory (Entra ID), then App registrations, and create a new application. Configure it as a multi-tenant or single-tenant app depending on the organization's requirements.
Grant Mail Permissions. Add the Microsoft Graph permission "Mail.ReadWrite" (application permission) to the app registration. Grant admin consent so the application can access mailboxes without individual user authorization.
Create Client Secret or Certificate. Generate a client secret or upload a certificate for authentication. Note the Application ID and Tenant ID.
Connect in Redate.io. Log in to Redate.io, select "Microsoft 365" as the platform, and enter the Application ID, Tenant ID, and client secret. Redate.io validates the connection and lists available mailboxes.
Scan and Fix. Select mailboxes to scan. The free scan identifies affected emails in each mailbox. After reviewing the results, select a plan and start the fix. Redate.io's proprietary correction engine processes each email through a multi-stage analysis pipeline, handling S/MIME signatures, multipart MIME structures, encoding edge cases, and dozens of other variations that would cause a naive script to corrupt data.
What Redate.io Delivers
For each affected email, Redate.io's correction engine analyzes the complete header chain, applies targeted corrections based on pattern matching across hundreds of known migration signatures, and confirms each result through integrity verification before finalizing. Original messages are moved to a "Redate.io - Originals" folder within the mailbox and retained for 30 days. This is far more complex than a find-and-replace on header text.
After the Fix
Once Redate.io completes the fix, Outlook (Desktop, Web, and Mobile) displays the correct original dates. Sorting by "Received" date works as expected. Search results return accurate timestamps. Compliance tools reflect the correct dates for legal and regulatory purposes. The fix is permanent, no ongoing maintenance required.
Tool-Specific Guides for Microsoft 365
Migrated to Microsoft 365 and email dates are wrong? Start a free scan with Redate.io to identify affected emails across all mailboxes and restore correct dates in Outlook, OWA, and every connected client.