eM Client: Wrong Dates After PST or Thunderbird Import

The symptom: all your emails show the same date

You just finished a PST import into eM Client, or migrated from Thunderbird to your new mailbox. The import completed without any obvious errors. But opening your inbox, something's off: hundreds, sometimes thousands of emails all show the same date, the day of the import. An email from 2019 looks like it arrived yesterday. A contract signed three years ago appears as if it just came in.

The natural first reaction is to blame eM Client. Wrong setting, wrong sort column, display bug... You dig through the preferences. You toggle between "Date received" and "Date sent". Nothing changes. Or rather, something changes, but it doesn't fix the underlying problem.

That's because the problem isn't in eM Client. It's in the server metadata.

The real cause: IMAP INTERNALDATE overwritten during import

To understand what's happening, you need to go one level deeper and look at how the IMAP protocol stores emails.

Every message on an IMAP server has two distinct types of dates:

• The Date: header (defined by RFC 2822): this is the date the sender wrote into the message at send time. It's encapsulated inside the message body, theoretically untouched.
• INTERNALDATE: a server-side metadata value, external to the message itself, representing when the message was deposited into the mailbox. This is the value email clients use first when sorting and displaying emails.

During a PST import or a migration from Thunderbird, the import tool (whether it's eM Client's built-in module, a third-party tool, or a manual IMAP copy) deposits messages onto the destination IMAP server. And if the tool doesn't explicitly preserve the original INTERNALDATE at deposit time, the server automatically assigns the current INTERNALDATE, meaning the date and time of the import.

Result: 8,000 archived emails going back to 2017, all stamped as "received" on the day of your migration.

(If you've ever tried reading raw email headers using "View source" in eM Client, by the way, you've probably noticed the original Date: header is still there, intact. That's the clue that the problem is with the server INTERNALDATE, not the message itself.)

Why changing the sort column doesn't help

The confusion comes from a distinction most people don't know about. In eM Client, as in Outlook or Thunderbird, there are generally two date columns:

• "Date received" (or "Arrival date"): based on the server INTERNALDATE.
• "Date" or "Sent date": based on the message's Date: header.

A lot of admins discover this and think they've found the fix: switch to "Sent date", and the problem disappears visually in eM Client. But that's not quite right.

Actually, even if you sort by sent date in eM Client, the problem persists for every other client and every other interface accessing the same mailbox. If your users check email from OWA, from Outlook on a desktop, from the Gmail app on mobile, or from any IMAP-configured client, they'll see the import dates. The sort setting in eM Client only applies to eM Client, and it does nothing to the metadata stored on the server.

On top of that, Microsoft 365 and Google Workspace native web views sort by INTERNALDATE. You can't change that behavior from the client side.

Sorting by sent date isn't a solution. It's a bandage over a real problem.

The specific case of PST imports

PST file imports deserve their own section. A PST (Personal Storage Table) file is a proprietary Microsoft format that stores emails, contacts, and calendars locally. When you import a PST into eM Client, two scenarios are possible:

• Local import to an IMAP account: eM Client reads the PST and pushes messages to the destination IMAP server. If the deposit date isn't preserved, INTERNALDATE gets overwritten. This is the most common scenario, and where dates end up corrupted.
• Import to a local folder: messages stay on the machine, off-server. INTERNALDATE doesn't exist in that context, and eM Client can display the message's Date: header. Fewer date problems here, but also less practical usefulness.

For Thunderbird, the situation is similar. Whether you use eM Client's built-in import function (which reads Thunderbird profiles) or copied mbox folders over IMAP, messages get re-deposited onto the server with no guarantee of INTERNALDATE preservation. And a server receiving a message without an explicit date instruction on INTERNALDATE will always timestamp at the moment of receipt.

Which platforms are affected?

The problem is identical regardless of the destination platform, because this is standard IMAP protocol behavior:

• Microsoft 365 / Exchange Online: INTERNALDATE is overwritten during any import that doesn't use IMAP APPEND with an explicit date parameter. Same applies to migrations from Exchange on-premise.
• Google Workspace: same behavior. Emails imported via eM Client or third-party tools show the import date in Gmail and in the admin interface.
• Classic IMAP hosts (OVH, Infomaniak, Ionos, etc.): no special date handling when receiving a message via APPEND. INTERNALDATE will be the deposit date.

A client reached out after migrating around a hundred mailboxes from Exchange 2013 to Microsoft 365, using eM Client as a transition tool for certain VIP accounts. The mailboxes migrated cleanly via MigrationWiz were fine, but the ones that went through eM Client all had import dates. The affected users were not pleased, to put it mildly.

Why a homemade script won't solve this easily

Technically, someone who understands the IMAP protocol might think about writing a script to fix the INTERNALDATEs. The original Date: header is right there, intact in every message. Just read it and reconstruct the server metadata accordingly, right?

In theory, yes. In practice, it's a minefield.

Edge cases pile up fast on a production mailbox. S/MIME digitally signed messages are particularly sensitive to any structural manipulation. PGP encrypted messages too. Emails with large attachments, non-standard MIME boundaries, or unusual Content-Transfer-Encoding values can corrupt silently if processing isn't rigorous. A script that works on 50 test emails won't hold up reliably against a 20,000-message mailbox with six years of history.

Then there's API quota management. On Microsoft 365, hitting rate limits on the Graph API or EWS at 3 AM during a correction batch of 8,000 messages is manageable. But it doesn't manage itself. An unsupervised script that hits a 429 Too Many Requests error on message number 3,741 might continue, might not. And you won't necessarily know which messages were actually processed.

And most importantly: how do you verify that every corrected email is intact after processing? A homemade script generally has no individual verification mechanism. Redate.io does this automatically, for every single message.

Fixing dates at the source with Redate.io

Redate.io addresses the problem where it actually lives: at the server metadata level, not at the email client level.

The process starts with a free scan. Redate.io connects to the affected mailbox (Microsoft 365 via Azure AD, Google Workspace via domain delegation, or direct IMAP for classic hosts) and identifies emails whose date metadata is inconsistent with the message content. You see the results before paying anything.

The correction uses a proprietary engine that performs full header chain analysis on each message, applies pattern matching across hundreds of known import tool signatures (including the specific behaviors of eM Client, Thunderbird, and PST imports), and performs targeted metadata reconstruction without altering message content, attachments, or MIME structure.

Each corrected email is verified individually. Originals are kept in a visible backup folder for 30 days, something a homemade script won't do by default.

Pricing is simple: one-time payment per mailbox, based on the volume of emails to correct. No subscription, no recurring fees. See the getting started page for details.

For your next migration: what to check

If you're planning a migration and want to avoid this problem from the start, the key question is simple: does the tool you're using explicitly preserve INTERNALDATE when depositing messages on the destination server?

For PST imports to Microsoft 365, Microsoft-certified tools (like MigrationWiz in its native modes, or the Exchange Online migration tool) generally handle that preservation. For manual imports via eM Client or Thunderbird, it's rarely the case. Check your tool's documentation before running an import on production mailboxes.

A solid email migration checklist always includes a post-migration date check on a sample of mailboxes. If you want to go deeper, the email migration checklist covers this in detail.

For admins who regularly handle migrations for clients, the article on fixing email dates as an MSP and the one on how IMAP INTERNALDATE works give a more complete picture of the problem.

Email dates corrupted after an eM Client import? Run a free scan on Redate.io to measure the scope of the problem before deciding what to do.