POP to IMAP: Why Your Old Emails Show Today's Date

The classic Monday morning scenario

You just switched your email account from POP3 to IMAP. The setup was simple, your hosting provider walked you through it, everything went smoothly. Then you reopened your inbox. Emails from 2019, 2021, your archives from last year... all showing the same date: today. Sometimes the exact same time, down to a few seconds.

This isn't a bug in your email client. It's not a timezone issue. It's the expected behavior of the IMAP protocol, and it hits anyone who uploads locally stored emails to a server this way.

POP3 vs IMAP: a fundamental storage difference

To understand why this happens, you first need to understand how POP3 works, and how it's radically different from IMAP.

With POP3, the server is just a temporary mailbox. Your client (Outlook, Thunderbird, Apple Mail) connects, downloads the messages, then deletes them from the server (or keeps them, depending on your settings). The emails then live exclusively on your local machine: in a .pst file for Outlook, in Thunderbird's local profile, in a database on your hard drive.

With IMAP, it's the opposite: emails live on the server. Your client just displays what's stored remotely. Hence the seamless sync across all your devices.

The problem happens in the transition between the two. Specifically, when you upload your old local POP emails to the IMAP server.

IMAP APPEND: the command that changes everything

When your email client uploads a local message to an IMAP server, it uses the IMAP APPEND command. This tells the server: "store this message in this folder."

The server receives the message, saves it, and assigns it a timestamp. That timestamp is the INTERNALDATE. It's IMAP's central metadata field: it records when the message was deposited on the server. And by default, if the client doesn't explicitly pass a date in the APPEND command, the server uses... the current moment.

In other words: it doesn't matter if the message contains a 2018 date in its headers. If nobody tells the server "this email is from 2018", the server assumes it was just deposited now and assigns today's INTERNALDATE.

(If you've ever looked at raw email headers, you've seen the Date: line buried among a dozen Received: lines. That Date: field, defined by RFC 2822, holds the real send date. But the IMAP INTERNALDATE is a separate server-side metadata field, completely independent of the message content itself.)

Why this differs from a server-to-server IMAP migration

In a standard IMAP-to-IMAP migration (with BitTitan, CloudM, imapsync, etc.), the problem is slightly different. The migration tool copies messages from one server to another, and in that case, it can (in theory) pass the original INTERNALDATE to the destination server via the APPEND command. The issue there is that some tools add a Received: header stamped with the migration date, which throws off the display in clients like Outlook.

In your situation, you're starting from purely local data. There's no source INTERNALDATE to copy. The .pst file or Thunderbird profile stores messages in its own proprietary format, with its own internal metadata. When the email client reads those messages to upload them to the IMAP server, it reconstructs the APPEND command from the message content. Most of the time, it doesn't pass an explicit date.

Result: the IMAP server receives hundreds or thousands of messages within a few minutes, and stamps them all with the same narrow time window: right now.

That's precisely why the problem propagates instantly to all your devices. Your phone, your tablet, your second computer: they all connect to the same IMAP server and see exactly the same thing. No fix is possible from the client side.

What each client displays, and why

Not all email clients behave the same way. This is something many IT admins discover after the fact.

Outlook (in recent versions, especially since the 2023-2024 updates) uses the server's INTERNALDATE for the "Received" column. So it shows the upload date, not the original send date. For more on this specific Outlook behavior, this article on Outlook IMAP received date vs sent date covers it in detail.

Gmail / Google Workspace and Thunderbird are a bit more nuanced. Gmail, for example, can sometimes use the Date: header field for display, which makes everything look fine... until you try to sort by date and realize the order is completely scrambled.

Apple Mail generally displays the date extracted from the Date: header, but sorting and search rely on the INTERNALDATE in the background. So your emails might appear correctly dated visually, but the sort function stops working properly. For Apple Mail's specific behavior, see Apple Mail shows wrong dates after migration.

The good news: the original date is still there

The Date: header of every email, the one holding the real send date, hasn't been touched. It's still right there, inside the message. It's what you see when you open an email and look at the details.

What the IMAP server "broke" is only the INTERNALDATE, the external metadata field. The message itself is intact.

That's what makes correction possible. It also explains why the problem can go unnoticed for a while: emails look correct when you open them one by one. It's only when you look at your inbox list, sorted by date, that the problem becomes obvious. Emails from 2019 appear at the top as if they just arrived. All with the same date.

The scale problem: 3,000 emails is not the same as 3

You might be thinking: "I'll just delete and reimport, properly this time." On 5 or 10 test emails, sure, that works. On a mailbox with 8,000 messages, nested folders, large attachments, S/MIME signed emails, and conversation threads going back to 2015... that's a different story entirely.

A homemade script that works on a test batch of 50 emails can easily produce duplicates, lose attachments, or break conversation threads on a production mailbox. API quota management, network timeouts, messages with non-standard MIME structures... these are edge cases a non-specialized tool simply doesn't handle.

And if something goes wrong halfway through? Without a backup and rollback mechanism, you lose data with no way to recover it.

This is a well-known problem for admins managing volume migrations. Understanding why dates are broken is one thing. Cleanly correcting 15,000 emails while preserving every message structure is another. For a deeper look at this, this article on fixing email dates after migration walks through the different approaches and their limits.

How Redate.io handles this specific case

Redate.io was built precisely for this type of situation. Its analysis engine identifies emails where the INTERNALDATE doesn't match the date contained in the message headers, whether from a POP-to-IMAP migration, a server-to-server IMAP migration, or a manual upload of local archives.

The multi-stage analysis pipeline inspects the header chain of each message, validates RFC compliance, and reconstructs date metadata without altering message content: not the text, not the attachments, not the MIME structure, not any digital signatures. Every corrected email is individually verified before being committed.

Originals are kept in a visible backup folder for 30 days. If anything doesn't look right, you can restore.

The initial scan is free: Redate analyzes your mailbox, identifies affected emails, and shows you the exact count before you decide anything. No blind commitment.

Redate.io connects directly to your mailboxes via Google Workspace (domain delegation), Microsoft 365 (Azure AD), or direct IMAP. No local installation. No .pst files to export and wrestle with manually.

For admins managing multiple mailboxes who want a practical perspective on this kind of case, the article on how MSPs fix client email date issues is a good companion read. And for the specifics of date correction in Thunderbird, which has its own behavior during POP/IMAP transitions, see Thunderbird shows wrong date after migration.

If you haven't done it yet: get ahead of the problem

If you haven't uploaded your local archives to the IMAP server yet, or if you're planning more POP account migrations in your organization, here's what to keep in mind.

• Check whether your email client supports passing an explicit date in the APPEND command. Thunderbird, for example, has had inconsistent behavior on this across versions.
• Run a test first on a validation account with 50-100 representative messages: old emails, attachments, signed emails. Check the displayed dates across different clients.
• Plan the correction before end users start working on the migrated mailbox. Fixing dates on an active mailbox is more complex than on a clean post-migration one.
• Document the email count before and after migration. It's the only way to detect silent data loss.

For a complete checklist of what to verify before and after a migration, the email migration checklist article covers all the cases.

Your old emails are showing today's date after switching from POP to IMAP? Run a free scan on Redate.io to measure the extent of the problem and correct the date metadata without touching your message content.