The Three Dates Inside Every Email
Every email stored on an IMAP server carries at least three distinct date values. Understanding how these dates work, and how email clients choose which one to display, is the key to understanding why migration breaks dates. This article is a technical deep-dive into the IMAP date system, aimed at IT administrators and anyone who wants to understand the root cause of post-migration date issues.
1. The RFC 2822 "Date" Header
The "Date" header is defined in RFC 2822 (Internet Message Format). It's set by the sender's email client at the moment the message is composed and sent. This header is part of the email message body itself, it travels with the message and is never modified by mail servers along the delivery path. A typical Date header looks like this:
Date: Mon, 15 Jan 2024 09:32:17 +0100
The Date header represents the "sent date" of the message. It's the most reliable date because it's set once and never altered. However, it reflects the sender's clock, which may be misconfigured. In rare cases, the Date header may be missing entirely (particularly in automated system notifications or malformed messages).
2. The IMAP INTERNALDATE
INTERNALDATE is defined in RFC 3501 (IMAP4rev1 protocol). It's a server-side metadata value that represents the date and time when the message was delivered to the server. Unlike the Date header, INTERNALDATE isn't part of the email message itself. It's stored separately by the IMAP server as metadata.
When an email is delivered normally (not migrated), the IMAP server sets the INTERNALDATE to the current time at the moment of delivery. This closely matches the Date header, typically within seconds or minutes. Email clients often use INTERNALDATE as the "received date" because it reflects when the server actually received the message.
Here's where it gets interesting. When a message is inserted via the IMAP APPEND command (which is what migration tools use), the APPEND command allows the client to specify the INTERNALDATE explicitly. Well-designed migration tools use this feature to preserve the original INTERNALDATE from the source server. But even when INTERNALDATE is correctly set, the "Received" header problem (described below) can still override the displayed date in many email clients.
3. The "Received" Headers Chain
Every time an email passes through a mail server, that server prepends a "Received" header to the message. This creates a chain of Received headers that records the path the email took from sender to recipient. The most recent (topmost) Received header shows the last server that handled the message, and the oldest (bottommost) shows the first.
A normal email might have 3 to 6 Received headers, documenting the journey from the sender's outgoing server through any relay servers to the recipient's incoming server. Each Received header includes a timestamp. Here's a simplified example:
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Received: from smtp.sender.com; Mon, 15 Jan 2024 09:32:18 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
How Email Clients Choose Which Date to Display
Outlook (Desktop, Web, Mobile)
Microsoft Outlook uses a combination of INTERNALDATE and the topmost "Received" header to determine the "Received" date displayed in the inbox. In practice, Outlook tends to prioritize the timestamp from the most recent Received header for the "Received" column. The "Sent" column uses the Date header. Since Outlook defaults to sorting by the "Received" column, the Received header timestamp is what users see first.
Apple Mail
Apple Mail on macOS and iOS primarily uses the IMAP INTERNALDATE for its date display. If the INTERNALDATE was correctly preserved during migration, Apple Mail may display the right date, but only if the INTERNALDATE was explicitly set during the APPEND operation. If the migration tool didn't set INTERNALDATE, the server defaults to the insertion time (the migration date). For details on how this affects Apple Mail users, see Apple Mail wrong date after migration.
Thunderbird
Mozilla Thunderbird offers the most flexibility. It can display both "Date" (from the Date header) and "Received" (from the Received headers). By default, Thunderbird shows the Date header value, which means dates may appear correct in Thunderbird even when they're wrong in Outlook. The "Received" column in Thunderbird, however, still shows the migration date. See Thunderbird wrong date after migration for more details.
Gmail Web Interface
Gmail's web client uses the Date header for its primary date display. This means Gmail web often shows correct dates even after migration. But the IMAP INTERNALDATE on the Gmail server is still wrong, which affects every IMAP client that connects to that Gmail account. The discrepancy between Gmail web and Outlook or Apple Mail is a common source of confusion, and one that wastes a lot of admin troubleshooting time.
Why IMAP APPEND Breaks Dates
What Happens During Migration
When a migration tool moves an email from Server A to Server B, the tool connects to Server A via IMAP and downloads the raw message, then connects to Server B and uses the APPEND command to insert it. During that insertion, Server B processes the incoming message and adds a new Received header with the current timestamp, the migration date. This is standard IMAP behavior defined in the protocol. The server treats every APPEND as a new message delivery.
The Result: A Contaminated Header Chain
After migration, the email's Received headers look like this:
Received: from migration-tool; Fri, 11 Apr 2025 14:22:08 +0000
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
The migration tool's Received header is now the topmost entry. Any email client that uses the topmost Received header to determine the display date (Outlook, in particular) will show "April 11, 2025" instead of "January 15, 2024." The original Date header and the original Received headers are still intact underneath, but they're no longer in the position that email clients prioritize.
Even Good INTERNALDATE Handling Doesn't Prevent This
Some migration tools correctly set the INTERNALDATE during APPEND. For example, imapsync explicitly preserves the source server's INTERNALDATE. But the Received header is added by the destination server, not by the migration tool. The migration tool has no control over this behavior. Even with perfect INTERNALDATE preservation, the topmost Received header still contains the migration date, and clients like Outlook still display the wrong date.
So what can you actually do about it?
Which Migration Tools Add Received Headers
Every IMAP migration tool causes this problem because the Received header is added by the destination server, not by the migration tool itself. The content of the added header varies by tool and server, though.
BitTitan MigrationWiz adds a Received header containing "mx.migrationwiz.com." CloudM Migrate adds headers referencing "cloudm.io." imapsync triggers a generic Received header from the destination server. GSMMO adds headers with "gmailapi.google.com" references.
The Fix: Restoring Correct Dates
The good news is that the correct date information still exists inside every email. The original Date header is intact. The original Received headers are intact. The problem is that a contaminating header sits on top of them.
Redate.io's proprietary correction engine analyzes the complete header chain of each affected email, applying pattern matching across hundreds of known migration tool signatures to identify exactly which headers need correction. The multi-stage analysis pipeline handles edge cases that trip up simpler approaches: S/MIME signed messages, PGP-encrypted content, multipart/alternative structures, Content-Transfer-Encoding issues, non-ASCII headers (RFC 2047), oversized attachments, and corrupted MIME boundaries.
After correction, every email goes through an integrity verification process to confirm the message structure, content, and attachments are preserved exactly. Originals are kept in a visible backup folder for 30 days.
Could you write a script to attempt this yourself? Technically, yes. But the difference between "it works on 95% of emails" and "it works on 100% of emails without corrupting a single one" is where months of engineering go. And when you're talking about someone's entire mailbox, that 5% failure rate means hundreads of silently damaged messages with no way to verify what went wrong.
Want to see how many emails in your mailbox have broken dates? Run a free scan with Redate.io to get an instant count of affected emails, with no payment required.