All My Old Emails Have the Same Date: What's Going On?

The symptom: all your old emails grouped under the same date

You open Outlook, Gmail, or Apple Mail one morning. Something's off. Hundreds, sometimes thousands of old emails are all showing the same date: a few days ago, or a few weeks back. Messages from 2021, 2019, 2016 are appearing as if they arrived yesterday. Sorting by date is now meaningless. You're looking for an important email from last year, and it's buried in a block of thousands of messages that all seem to come from the same day.

New emails still show the correct dates. It's only the older messages that are affected.

So what on earth happened?

The first instinct: blame the software

Naturally, you think it's a bug. Outlook crashed. An update went sideways. A corrupted file. And that's usually where the rabbit hole begins: you search "Outlook date bug", land on forums talking about OST files, SCANPST.exe, rebuilding your Outlook profile from scratch...

Two hours later, the problem's still there.

For the record, SCANPST is a repair tool for local Outlook data files. It can fix certain file corruptions, but it doesn't touch anything stored on the mail server. Even if you repair your OST file perfectly, the dates will still be wrong, because the problem isn't on your machine.

The problem is inside the emails themselves, on the server.

What actually happened: a migration

In almost every case, this symptom shows up after an email migration. Your company moved from an old system to Google Workspace, Microsoft 365, or a new server. Someone, somewhere, ran a tool to transfer all your emails from one place to another.

You might not have been told about it. Or you knew, but didn't connect it to the date problem. That's completely understandable.

Migration tools do a lot of heavy lifting: they copy thousands of messages, entire folder structures, attachments. But they have a sneaky side effect. When an email is transferred from one server to another, the tool adds a small technical line to the email called a "Received:" header, which records when the message arrived on the new server. In other words: the migration date.

That's the root of the problem.

How your email client decides which date to show

An email actually contains several different dates, hidden in its technical data. There's the original sent date (the one you normally see), but also "Received:" headers that log each hop the message made across the internet.

(If you've ever clicked "Show source" or "View full headers" on an email, you've probably seen those cryptic lines that look like an incomprehensible wall of text. That's exactly what they are.)

Under normal circumstances, your email client looks at the most recent "Received:" header to figure out when to display the email. This logic works perfectly: the last "Received:" always corresponds to the message arriving in your inbox, a few seconds after it was sent.

But after a migration, that logic backfires. The migration tool added a new "Received:" header at the very top, stamped with the transfer date. Your email client reads that header first, sees the migration date, and displays it. The original sent date is still there, intact, buried further down in the email's data. Your client just never gets to it, because it stops at the first header.

Result: 8,000 emails that all seem to have arrived on the same Tuesday in November.

Which tools cause this?

The most common migration tools all behave this way. BitTitan MigrationWiz, CloudM, imapsync, GSMMO (Google's free tool for migrating from Outlook), and plenty of others. It's not really a flaw on their part: it's a consequence of how the email protocol works technically. These tools add that header because that's what the protocol calls for when a message is relayed from one server to another.

The problem is that nobody warns users it's going to happen.

If your company recently switched email providers, or your IT department ran a "cloud migration", that's almost certainly what's going on here. You can verify by looking at the affected dates: do they all cluster around roughly the same period? If so, that period is the migration window.

False leads to avoid

A few solutions that come up constantly in forums, and don't work:

Repairing the data file with SCANPST

As mentioned above: SCANPST repairs local Outlook files (the .pst or .ost files sitting on your computer). It doesn't modify emails on the server. After the repair, your emails will still have the same wrong dates, because those dates live inside the emails themselves, not in the local file.

Recreating the Outlook profile

Same logic. Recreating an Outlook profile means starting fresh locally, then re-downloading all your emails from the server. Those re-downloaded emails will have exactly the same wrong dates as before. You've just wasted time reconfiguring everything.

Sorting by "sent date" instead of "received date"

Some forums suggest changing the sort option in Outlook, switching from received date to sent date. It can help in some cases... but not always. And it doesn't fix anything for other apps, other devices, or other people accessing your mailbox. The underlying cause is still there. Sorting by sent date isn't a solution, it's a bandage.

Reinstalling the email client

No. The emails are on the server, not in the software. Reinstalling Outlook, Gmail, Apple Mail, or Thunderbird changes nothing about the data stored online.

The good news: the real dates are still there

Here's something important to understand, and what makes correction possible: the original sent date of each email hasn't been erased. It's still in the email, in a header called "Date:" that corresponds to the send date chosen by the sender. This is an email standard (defined by a technical specification called RFC 2822) that all migration tools respect, because modifying it would be a serious protocol violation.

In other words, if you received an email on March 14, 2022, that email still contains that date somewhere in its data. It's just no longer the one your client shows first.

That's precisely what makes correction possible. This isn't data loss. It's a metadata reading issue: your email client is reading the wrong date, while the correct date is still present. You can read more about the underlying mechanics in this detailed explanation of why emails show wrong dates after migration.

Why DIY correction is risky

You might be wondering whether an IT person could just write a script to fix this. Understanding what's happening is one thing. Correcting it cleanly across thousands of emails without losing a single one is another matter entirely.

An email isn't a simple text file. It can contain attachments, digital signatures, content encoded in complex formats. Modifying the metadata of such a message without breaking its structure means handling dozens of edge cases: S/MIME signed messages, PGP encrypted emails, non-standard encodings, multipart structures... A homemade script that works on 20 test emails will very likely fail on a production mailbox of 15,000 messages. And if something goes wrong, how do you verify that no email was damaged or lost? With a DIY script: you can't.

Without a backup mechanism and per-message verification for every single email, the risk of collateral damage is real.

What Redate.io does

Redate.io is a service built specifically for this problem. It connects to your mailbox (Google Workspace, Microsoft 365, or an IMAP server), identifies emails whose dates were altered by a migration, and corrects them via a proprietary engine that performs header chain analysis and date metadata reconstruction for each message individually.

Every corrected email is verified individually. Originals are kept in a visible backup folder for 30 days. If anything looks wrong, you can roll back.

The initial scan is free: Redate.io analyzes your mailbox and shows you exactly how many emails are affected before you decide anything. No surprises.

Pricing is a one-time payment based on the volume of emails to correct. No subscription. You pay once, the problem is fixed.

Want to see the full extent of the damage before committing? Run a free scan of your mailbox on Redate.io and find out in minutes how many emails are affected.