PST Import in Outlook: Why All Your Dates Break

The symptom: every email shows today's date

You just finished a PST import into Outlook. The progress bar hit 100%, everything looked fine. Then you open the inbox... and every imported email shows today's date. A message from 2019, another from 2021, a five-year-old archive: all of them carry the same date. The day of the import.

This isn't a display glitch. It's not a timezone issue. It's a well-documented behavior, fully consistent with how IMAP handles date metadata. But it's still a disaster for anyone who needs to find old emails by date.

Local PST and IMAP: two very different worlds

Before explaining why dates break, you need to understand what a PST file actually is from a date-management perspective.

A PST file (Personal Storage Table) is a proprietary Microsoft format. It stores emails with their complete metadata: sent date, received date, attachments, categories, read flags. That metadata is managed directly by Outlook, outside any mail protocol. When you browse a PST in Outlook without a server connection, the dates you see come straight from the internal fields of the PST file. So far, no problem.

The problem appears when you try to move that content into a mailbox hosted on an IMAP server, whether that's Microsoft 365, Google Workspace, or any standard mail host. At that point you're leaving the PST world and entering the IMAP world, and the rules change completely.

IMAP APPEND and INTERNALDATE: the core of the problem

In IMAP, every message stored on the server has two types of date data:

• The Date: header (RFC 2822), which is part of the message content itself. This is the date the sender stamped on the message.
• The INTERNALDATE, a metadata value managed by the IMAP server. It represents when the message was deposited on the server. This is the value Outlook uses to sort messages in the "Received" date view.

(If you've ever tried reading raw email headers, you know it's not exactly beach reading. But that's where everything actually happens.)

When an email arrives normally on your server, the mail server automatically sets INTERNALDATE to the exact moment of reception. The date Outlook shows matches when you actually received the message.

When Outlook imports a PST file into an IMAP mailbox, it uses the IMAP APPEND command to push each message to the server. The IMAP standard allows passing an explicit INTERNALDATE during an APPEND. But Outlook doesn't do that. It sends the messages without specifying an INTERNALDATE. The IMAP server, with no instruction to the contrary, falls back to its default rule: INTERNALDATE gets set to the current time, meaning the moment of the import.

Result: 8,000 emails imported, 8,000 emails with today's date.

Why Outlook behaves this way

This isn't an oversight by Microsoft. It's an implementation choice that probably seemed reasonable at the time: in the original PST import use case, a user archives messages locally and "imports" them into their current mailbox. The relevant sort date would be the original received date... but Microsoft chose not to propagate INTERNALDATE during the import operation.

To be precise, this behavior applies to PST import via Outlook's native wizard (File > Open & Export > Import/Export). Other import methods, such as certain third-party tools or migrations through the Exchange Admin Center, may behave differently depending on how they implement IMAP APPEND.

This behavior has been documented on Microsoft forums for years. It didn't change with Outlook 2016, or Outlook 2019, or current Microsoft 365 versions. Someone importing a PST today will hit exactly the same problem as in 2015.

How this differs from a standard IMAP migration

Here's where it gets interesting, because a PST import produces a result similar to a classic IMAP migration with broken dates, but through a different mechanism.

In a typical IMAP migration, for example with BitTitan MigrationWiz or imapsync, emails move from a source IMAP server to a destination IMAP server. The migration tool fetches messages and reinserts them via IMAP APPEND. Some tools preserve INTERNALDATE correctly, others don't. But in all cases, the messages also pick up a new Received: header stamped with the migration date, which can affect how Outlook displays them independently of INTERNALDATE.

With a PST import, the mechanism is simpler: there's no migration Received: header added (PST files don't travel through an intermediate mail server), but INTERNALDATE simply never gets set to the correct value. The visible result is identical; the underlying cause is slightly different.

This distinction has a direct consequence for the fix: the approach isn't quite the same depending on whether you're dealing with an IMAP migration or a PST import. See also why INTERNALDATE causes broken dates for a detailed breakdown of both cases.

Why Outlook view settings don't fix anything

The typical reaction when you discover the problem is to dig through Outlook's settings. And there is one option that looks promising: sorting emails by "Date" rather than "Received Date".

Sorting by sent date is not a fix. It's a bandage.

Here's why: even if you switch the sort column to "Date" (which maps to the message's Date: header, i.e., the original date), several problems remain:

• Outlook's search index runs on INTERNALDATE. A search for "emails from January 2020" won't return your imported January 2020 emails, because their INTERNALDATE says they arrived on the day of the import.
• The "Today", "This Week", "This Month" groupings in Outlook's interface are based on INTERNALDATE, not the Date: header.
• In web interfaces (Outlook Web App, Gmail) and on mobile clients, the displayed date and sort behavior almost always depend on the server's INTERNALDATE.
• Automatic rules and filters that act on received date won't work correctly.

Changing the view fixes the display for one specific user, on one specific client, in one specific configuration. It doesn't correct the problem at the source.

Re-syncing the OST file won't help either

Another classic attempt: clear the OST cache and force a full resync from the server. The idea being that maybe the problem is in Outlook's local cache, not on the server.

Wrong direction. The OST file is a local cache that mirrors the IMAP server's state. If INTERNALDATE is wrong on the server, it will be wrong in the OST after resync. Deleting the OST changes nothing in the data stored on Exchange Online or Google Workspace. The server is the authority.

The only way to fix the dates is to correct the metadata directly on the server side, message by message. And that's precisely where things get complicated to do manually.

The scale problem: 1 email is trivial. 15,000 is something else

Technically, if you understand the problem, you might imagine writing a script that walks through the mailbox, reads each message's Date: header, and corrects INTERNALDATE accordingly. Understanding the problem is one thing. Correcting 15,000 emails without losing a single one is another.

A few realities from the field:

• Microsoft Graph and Gmail APIs enforce rate limits. A naive script will trigger 429 Too Many Requests errors, stop mid-correction, and leave you with a partially fixed mailbox, with no way to know which emails were processed and which weren't.
• Some emails inside a PST can have malformed or missing Date: headers. A script without proper edge-case handling will either corrupt those messages or skip them silently.
• Signed emails (S/MIME) and encrypted messages (PGP) have additional integrity constraints. Modifying their metadata carelessly can invalidate the cryptographic signature.
• Multipart/alternative structures with complex MIME boundaries sometimes behave unpredictably under modification operations.
• No rollback mechanism. If something goes wrong halfway through, how do you get back to the original state?

A script that works on 10 test emails won't work on a production mailbox of 50,000 messages. Last year, a client with a 40 GB PST archive tried to fix this with a Python script pulled from Stack Overflow. The result: 3,000 duplicate emails, 200 messages with inaccessible attachments, and two weeks of manual cleanup.

What Redate.io does in this specific case

Redate.io analyzes the metadata of every message in the target mailbox, identifies emails with incorrect dates (including those from a PST import), and applies a correction via its proprietary correction engine. The multi-stage analysis pipeline examines each message's header chain, extracts the original date with RFC compliance validation, and performs targeted metadata correction without altering message content.

Every corrected email is verified individually. Originals are kept in a visible backup folder for 30 days before any permanent change is made. The correction works across the three main platforms: Microsoft 365 (via Azure AD), Google Workspace (via domain delegation), and direct IMAP for standard mail hosts.

The initial scan is free. It shows exactly how many emails are affected and how the incorrect dates are distributed, before you decide anything.

See also:

• Fix Email Dates After Microsoft 365 Migration
• Outlook: IMAP Received Date vs Sent Date After Migration
• Can Email Dates Be Fixed After Migration Is Complete?

Your PST import wiped out all your email dates? Scan your mailbox for free on Redate.io to measure the scope of the problem before taking action.