Recreating an Outlook Profile: Why Dates Change

The troubleshooting move that breaks your dates

A user complains that Outlook won't sync. Emails aren't coming in, the Sent folder isn't updating, the spinner just keeps spinning. The technician diagnoses a corrupted profile, deletes the OST file, rebuilds the Outlook profile from scratch. Result: Outlook reconnects, emails reappear, everything looks fine.

Until the next morning, when the user opens their inbox and realizes that 8 years of correspondence now shows the same date: today.

It's the exact same symptom as a failed IMAP migration. And for the same reasons.

What actually happens technically

To understand why rebuilding a profile produces this result, you need to revisit a distinction most technicians don't know well: the difference between an email's Date: header and its IMAP INTERNALDATE.

Every email contains an RFC 2822 Date: field in its headers indicating when the message was sent. This field is written by the sender's email client at the moment of sending, then carried intact through every server along the way to your inbox. It never changes. An email sent on March 14, 2019 at 9:32 AM will always have that Date: field intact, regardless of what happens afterward.

IMAP INTERNALDATE is something else entirely. It's a metadata value managed by the mail server, independent of the message content. It records when the message was "deposited" in the mailbox. Under normal conditions, when an email arrives via SMTP, the server records the time of receipt as INTERNALDATE. So an email received on March 14, 2019 will have an INTERNALDATE consistent with its send date.

Outlook, by default, sorts and displays emails using the INTERNALDATE provided by the IMAP server, not the message's own Date: header. (If you've ever opened the full properties of an email in Outlook to read its raw headers, you know that's not exactly casual reading.)

What deleting the OST file actually triggers

When Outlook uses an IMAP account, it maintains a local database: the OST file (Offline Storage Table). This file is a local mirror of the emails stored on the server, including their metadata, read states, categories, and so on.

Deleting the OST file wipes that local mirror. Outlook then has to re-download everything from the IMAP server.

The problem? When Outlook re-downloads a message via IMAP, it uses the FETCH command to retrieve the content. But it doesn't consistently use FETCH INTERNALDATE to retrieve and preserve the original IMAP date. In certain configurations and versions of Outlook, the client rebuilds its local index using the date it re-downloaded the message rather than the INTERNALDATE stored on the server.

And just like that, every email in the mailbox ends up dated to the day of the reload.

Not all Outlook versions behave the same way

Actually, this behavior doesn't affect every version of Outlook identically, and that's where things get complicated to diagnose.

Outlook 2016 and 2019 in IMAP mode have documented behavior around incorrect index reconstruction after cache deletion. The new Outlook (web-based, rolling out gradually since late 2023) handles caching differently and can produce variable results. Outlook via Exchange or Microsoft 365 with an account configured in Exchange mode is less exposed to this specific issue, because the MAPI/Exchange protocol handles synchronization differently from IMAP.

But if your user is on an IMAP account configured in classic Outlook, and a technician deleted the OST file or rebuilt the profile: the risk is real.

How to tell this apart from an actual migration

An IT admin receiving "my dates are wrong" tickets after a profile rebuild might mistakenly assume it's a migration problem. Here's how to tell the two cases apart.

The IMAP migration case

During an IMAP migration (BitTitan, CloudM, imapsync, etc.), the migration tool copies emails from one server to another. For each copied message, it creates a new entry on the destination server via the IMAP APPEND command. If the tool doesn't explicitly specify the original INTERNALDATE in that command, the destination server records the current time as INTERNALDATE. On top of that, some tools also add a Received: header with the migration date, which makes things worse in certain clients. You can read the full breakdown in the article on IMAP INTERNALDATE and why dates break.

The profile rebuild case

Here, the emails are still on the same server, with the same original INTERNALDATE values. Nothing moved on the server side. It's purely Outlook's local cache that was rebuilt with incorrect dates. The visible symptom is identical (all emails show the same recent date), but the root cause is different.

To confirm: log into the mailbox via webmail (Gmail, Outlook.com, or your hosting provider's webmail interface). If the dates shown in webmail are correct, the problem is purely local to Outlook. If the dates are also wrong in webmail, the issue is server-side (a migration or direct modification of INTERNALDATE values on the server itself).

Why the original dates are still recoverable

Good news: in both cases (migration or profile rebuild), the original dates aren't lost.

The RFC 2822 Date: header is an integral part of the message. It's as immutable as the message body or its attachments. An email sent in 2017 contains something like this in its raw text:

Date: Mon, 12 Jun 2017 14:23:41 +0200

That line is present in the message stored on the server. It hasn't been modified. What Outlook displays (incorrectly) is metadata external to the message content.

That's what makes correction possible. Redate.io's engine analyzes the header chain of each message to extract the real original date, then performs targeted metadata correction without altering message content. The INTERNALDATE visible to Outlook is reconstructed from that authentic information, which is always present in the message itself.

The "clean rebuild" trap

You just fixed a sync problem for a user. Their Outlook is working again, new emails are coming in. You close the ticket.

Three days later, the user calls back: they're looking for an email from a supplier from last year, but in Outlook all their 2023 emails appear as received "yesterday". They can't find anything. Auto-archiving may have filed recent emails as old ones. And their manager is asking for an email thread from September 2022 for a dispute.

This scenario comes up regularly. Not because the technician did anything wrong, but because this Outlook behavior isn't documented in any visible way in standard troubleshooting guides.

Workarounds that don't actually fix anything

Sorting emails by "Sent Date" instead of "Received Date" in Outlook is the first thing users try. And it seems to work... until they realize that sorting by sent date is only available for certain folders, that it disappears when you switch views, and that other apps (mobile, webmail, automatic sorting rules) keep using the incorrect INTERNALDATE.

Sorting by sent date is not a fix. It's a bandage that hides the symptom without touching the real problem. Redate.io explains this in detail in the article Sort by Sent Date Is Not a Fix.

Rebuild the profile a second time? That changes nothing if Outlook's behavior is to reconstruct its cache using the current date.

Export to PST and reimport? Be careful. A PST export from an Outlook with corrupted dates exports the corrupted metadata. The PST file will contain the wrong dates. Reimporting it fixes nothing, and can actually make things worse by creating duplicates with inconsistent dates. This is covered separately in the article on PST import and dates resetting to today.

What Redate.io does in this specific case

Whether the problem comes from an IMAP migration or an Outlook profile rebuild, the server-side result is similar: emails whose date metadata is inconsistent with their actual content.

Redate.io connects directly to the mailbox (Google Workspace, Microsoft 365, or direct IMAP), scans all messages to identify those with incorrect metadata, then applies its multi-stage analysis pipeline to correct each email individually. Every correction is verified. Redate.io never deletes the originals. They stay in a visible backup folder in your own mailbox until you delete them yourself.

The process handles the edge cases that homemade scripts miss every time: S/MIME signed messages, emails with non-ASCII encodings in headers (RFC 2047), complex multipart structures, Date: headers with non-standard or malformed timezones. A script that runs cleanly on 50 test emails in a development mailbox can irreversibly corrupt 2000 messages in production. There's no native rollback in IMAP once a message has been replaced without a prior backup.

For Outlook-specific cases, the fix page fix manual IMAP copy dates in Outlook walks through the steps to connect your mailbox and run the analysis.

Preventing the problem on future interventions

If you're a technician or IT admin who regularly works on Outlook profiles, a few habits can prevent this situation entirely.

Before deleting an OST file or rebuilding a profile, check the dates displayed in webmail. If they're correct, note it in your ticket. After the rebuild, log into webmail again and compare the dates shown there with what Outlook displays. If there's a discrepancy, you've caught the problem immediately, before the user complains three days later.

For planned migrations, the email migration checklist lists the checks to run before and after to catch this type of problem as soon as the operation wraps up.

You rebuilt an Outlook profile and now every date in your mailbox is wrong? Run a free scan on Redate.io to identify affected emails and correct the metadata without touching your message content.