Sort by Sent Date Is Not a Fix

The most common advice on every forum

Search "emails showing wrong date after migration" on any IT forum, and the first response is almost always the same: "Sort by sent date instead of received date." You'll find this advice on Microsoft forums, Google Workspace help threads, Reddit, Spiceworks. It's become the default answer to what is actually a server-level data problem.

The advice is well-intentioned. In Outlook, switching the sort column from "Received" to "Sent" does visibly reorder messages. Emails that all appeared to share the same migration date suddenly fall back into their original chronological sequence. At first glance, the problem looks solved.

But it isn't.

Why it seems to work

The visual improvement

When a user switches the Outlook view to sort by "Sent Date", the inbox immediately looks right. Emails from 2020 appear before emails from 2023. For someone staring at 10,000 messages all stamped with the same migration date, that's a dramatic improvement.

It works in one view, on one device

The sort-by-sent-date workaround works in exactly one place: the specific folder view, on the specific device, where the user made the change. Switch to a different folder and the view may revert. Check email on another device and the setting doesn't follow.

All the ways it fails

Search results still show wrong dates

Email search in Outlook, Gmail, Apple Mail, and Thunderbird indexes messages using the received date (INTERNALDATE), not the sent date. When a user searches for "emails received in March 2022", the search engine checks INTERNALDATE, which still shows the migration date. The search returns zero results for March 2022 and surfaces everything for the migration date instead.

For users who regularly search by date range (accountants looking for invoices from a specific quarter, lawyers pulling correspondence from a case period), the mailbox is functionally unusable. Changing the sort column has no effect on what the search engine actually queries.

Compliance and eDiscovery are compromised

Tools like Microsoft Purview, Google Vault, and third-party compliance platforms query server-side metadata, including INTERNALDATE. Sorting by sent date in Outlook has absolutely no effect on what those tools retrieve. A legal hold request for "all emails received between January and March 2023" will return incorrect results.

For organizations in finance, healthcare, legal, and the public sector, inaccurate eDiscovery results can lead to sanctions, fines, or unfavorable legal rulings. The stakes here are real.

Must be set on every device and every folder

Outlook doesn't apply view settings globally. Changing the sort column in the Inbox doesn't change it in Sent Items, Drafts, Archive, or any custom folders. Each folder has to be adjusted individually. Settings are stored locally, which means the process repeats on every device. For an organization with 100 users, each with 4 devices and 10 folders, that's 4,000 individual view changes. Who's actually going to do that?

The INTERNALDATE is still wrong

The IMAP INTERNALDATE remains incorrect on the server. That affects backup tools, future migration tools (which propagate the wrong INTERNALDATE), API integrations, and email archiving systems. The INTERNALDATE problem persists indefinitely until it's corrected at the server level.

Email rules and filters use the received date

Outlook rules, Gmail filters, and date-based Exchange transport rules will malfunction. A rule that says "move emails received more than 90 days ago to Archive" may archive everything in the mailbox, or nothing at all. Power Automate flows and Google Apps Scripts that process emails based on received date produce incorrect results.

Some email clients don't even support it

Not every email client supports sorting by sent date. Apple Mail on iOS doesn't offer a "sort by sent date" option. Thunderbird handles date columns differently from Outlook. Webmail interfaces like Roundcube and Horde have limited column customization options.

Conversation threading breaks

Email clients that support conversation view group related messages based on headers and dates. When received dates are wrong, conversation threading can mis-order messages within a thread, or display the thread date as the migration date.

The actual fix: correct the server-side data

The reason "sort by sent date" fails is that it treats the symptom (wrong display order) without fixing the cause (wrong date metadata on the server). The real fix requires correcting the date metadata server-side for every affected email.

Once the server-side data is corrected, every email client displays the right date. Search results return accurate date ranges. Compliance tools query the correct timestamps. Rules and filters operate on the true received date. No per-device or per-folder configuration needed. The correction is permanent and universal.

How Redate.io performs the server-level fix

Redate.io's proprietary correction engine connects to the mailbox (Google Workspace, Microsoft 365, or any IMAP server) and scans each email to identify messages with migration "Received" headers. The scan is free.

For each affected email, a multi-stage analysis pipeline identifies migration signatures through pattern matching across hundreds of known migration tool signatures, applies targeted corrections while preserving message integrity (S/MIME signatures, multipart structures, inline attachments, non-ASCII headers, and dozens of other edge cases), and runs an integrity check on every corrected message. Originals are moved to a visible backup folder for 30 days. The full process is covered in can email dates be fixed after migration is complete.

After correction, there's nothing to configure in Outlook, no settings to change on every device, no workaround to remember. The dates are simply correct, everywhere, permanently.

Stop relying on a workaround that only half-works. Run a free scan to see how many emails have wrong dates, and fix 10 for free to verify the results.