iCloud to Office 365 Migration: Wrong Email Dates

A migration scenario that reliably breaks dates

You just finished moving your iCloud mailbox to Office 365. The emails are there, the folders look right, everything seems fine. Monday morning, the first complaint arrives: "All my old emails are showing today's date." Then a second. Then ten.

This isn't an isolated bug. Migrating from iCloud Mail to Office 365 is one of the most consistently documented sources of email date corruption, for very specific technical reasons tied to Apple Mail's behavior, the IMAP protocol, and how Microsoft 365 handles incoming messages.

Why iCloud to Office 365 breaks dates

To understand the problem, you need to separate three things that a lot of people (including experienced IT admins) mix up: the Date: header, IMAP INTERNALDATE, and file creation date.

The Date: header (RFC 2822)

Every email contains a Date: header that records when the message was sent. This header is embedded in the raw message body and, in theory, never changes. It's the "original" date in the strictest sense.

IMAP INTERNALDATE

The IMAP protocol (defined in RFC 3501) attaches a separate metadata value to each message called INTERNALDATE. This is what most email clients actually use to sort and display messages in the inbox, not the Date: header. Outlook in particular relies heavily on INTERNALDATE for both display and sorting.

The problem? When a migration tool copies an email from one IMAP server to another, it should ideally preserve that INTERNALDATE. In practice, that doesn't always happen.

Apple Mail's particular behavior

When Apple Mail syncs messages from iCloud, it sometimes uses the server-side file creation date as the reference for INTERNALDATE. This isn't strictly a bug, it's an interpretation of the IMAP spec that diverges from what other clients do. (If you've ever tried debugging an INTERNALDATE issue by reading the raw IMAP RFCs, you know the spec leaves a fair amount of room for interpretation here.)

The result: when you export or migrate from iCloud via Apple Mail, the INTERNALDATE values on messages may already be wrong before they ever reach Office 365.

The three iCloud migration methods and their pitfalls

Direct IMAP migration

The most common approach is to configure iCloud as the IMAP source and Office 365 as the destination, then run a migration tool (imapsync, MigrationWiz, or something custom-built). The tool connects to both servers and copies the messages across.

There are two problems here. First, Apple's IMAP servers have rate limits that force tools to pause, creating windows where connections close and reopen, which can generate spurious INTERNALDATE values. Second, every message copied into Exchange Online receives, by default, a deposit date matching the moment of migration, unless the tool explicitly passes the original INTERNALDATE in the insert command.

Some tools handle this correctly. Others don't, at least not consistently. And on a mailbox with 40,000 messages, even a 2% error rate means 800 emails showing the wrong date.

For migrations done via imapsync, see also: fix imapsync migration dates in Microsoft 365.

.mbox or .eml export then import

Some users export their iCloud emails through Apple Mail in .mbox format, then try to import them into Outlook. This is a manual approach that produces inconsistent results.

The .mbox format encodes emails as a sequence of text messages. Dates are present in the individual Date: headers, but the separator line between messages ("From ") includes a date that some importers interpret as the creation date. When Outlook imports a .mbox file converted to .pst, it sometimes uses that separator date rather than the message's own Date: header.

Drag and drop via Outlook

This is the method that causes the most damage. A user configures both accounts in Outlook (iCloud and Office 365), then drags and drops messages from one folder to another. It seems simple. It's a disaster for dates.

When Outlook moves a message by drag-and-drop between two IMAP accounts, it actually generates a new .EML file, inserts it into the destination account, and deletes the original. That new file inherits the Windows file creation date, meaning the exact moment of the drag-and-drop. The original Date: header is still present in the message body, but the INTERNALDATE recorded on the Exchange Online server corresponds to the time of the operation. Outlook then displays that migration date for every moved message.

To be precise, this behavior varies by Outlook version. Since the fall 2023 Outlook update, things have improved slightly in some scenarios, but drag-and-drop between accounts remains a documented source of date corruption.

What Office 365 and Outlook actually show

Exchange Online stores emails with their INTERNALDATE. Outlook Desktop reads that INTERNALDATE to populate the "Received" column and sort the inbox. If the INTERNALDATE was overwritten during migration, Outlook shows the migration date. Full stop.

Outlook Web App (OWA) does the same. There's no "alternate view" that would show the original Date: header. What you see in the date column is the INTERNALDATE.

The original Date: header is still there, intact, readable if you pull up the raw message headers. But nothing in the normal interface shows it. That's the core frustration: the correct information exists, it's just inaccessible without a technical fix.

What Microsoft support won't solve

If you open a ticket with Microsoft Support for this problem, here's roughly what you'll get: a confirmation that the displayed dates match the stored INTERNALDATEs, a suggestion to check sort settings in Outlook, and possibly a referral back to the migration tool you used.

That's not bad faith. Microsoft simply doesn't have a native tool to retroactively correct the INTERNALDATEs on thousands of messages already ingested into Exchange Online. Fixing it requires accessing messages individually, analyzing their headers, and reconstructing date metadata, which is outside the scope of standard support.

Apple support, for its part, considers the messages were exported correctly and that the problem is on the destination side. Both teams point at each other, and the user is left with 12,000 emails dated the day of the migration.

The scale problem

Understanding why dates are broken is one thing. Fixing them manually across a production mailbox is another.

Some IT admins try to script the correction. The basic idea isn't hard to conceptualize, but running it against real volumes surfaces problems that homemade scripts don't handle well:

• S/MIME-signed or PGP-encrypted emails can't be modified without invalidating the cryptographic signature
• Messages with complex multipart/alternative structures (HTML + plain text + nested attachments) are fragile to manipulate
• Non-ASCII encoded headers (RFC 2047, common with Japanese, Arabic, or Cyrillic characters) can be corrupted by tools that don't handle these encodings properly
• Microsoft Graph API quotas and Exchange Online rate limits (429 Too Many Requests) stop scripts not built for exponential backoff handling
• A script that runs fine on 500 test emails dies at 3 AM on the 8,000th message of a real mailbox, with no resume mechanism

And the question that really matters: how do you verify that every corrected email is intact after the fix? That the attachment is still there? That the thread isn't broken? A homemade script generally doesn't do that verification.

How Redate.io handles iCloud to Office 365 migrations

Redate.io connects directly to Office 365 via Microsoft 365 permissions (Azure AD), without requiring any access to iCloud servers. The emails are already in Exchange Online by the time Redate gets involved.

Redate's correction engine analyzes the header chain of each message to identify the original date, separating Received: headers added during migration from legitimate date metadata. This analysis includes pattern matching against signatures of known migration tools, which makes it possible to identify problematic headers even when they aren't immediately obvious.

Every corrected email is verified individually after processing. Originals are kept in a visible backup folder for 30 days, something no homemade script does by default. The initial scan is free and gives an exact count of affected emails before you decide whether to correct anything.

Redate also handles migrations from Google Workspace to Office 365 and post-migration corrections for other scenarios. See: fix email dates after Microsoft 365 migration or wrong email dates after Exchange Online migration.

Scan first, fix later

The recommended starting point for any iCloud to Office 365 migration that produced wrong dates: run Redate.io's free scan on the affected mailboxes. The scan identifies exactly how many emails have a suspicious INTERNALDATE and which folders they're in.

It takes between 12 and 45 minutes depending on volume, and gives a clear picture of the problem's scope before any changes are made. For MSPs managing multiple mailboxes after a migration, batch scanning avoids correcting mailboxes that don't need it.

If your email dates are wrong after migrating from iCloud, start with the free scan on Redate.io to measure the extent of the problem across your Office 365 mailboxes.