Changing a Received Email's Date: What's Real?

An email has three "dates". Not one.

When people talk about "changing a received email's date", most picture editing a field somewhere, the way you'd change a file's creation date in Windows. The reality is a bit more involved. An email actually carries three distinct dating layers, each with its own rules, its own gatekeepers, and its own consequences if you touch it.

Understanding those three layers is understanding why some corrections are technically sound, and others are either impossible or immediately detectable as forgeries.

Layer 1: the IMAP INTERNALDATE

The INTERNALDATE is a metadata value stored server-side, outside the message itself. It's not part of the email content. The IMAP server sets it, and it's what most email clients use to sort messages in your inbox list.

Outlook, for example, sorts messages by INTERNALDATE by default. Gmail does too, in certain views. So if your INTERNALDATE is wrong, all your emails appear to share the same date in the interface, regardless of what the internal message headers say.

The INTERNALDATE is set when the message is deposited on the server. Via the IMAP protocol, the only way to "modify" it is indirect: you have to use the APPEND command to deposit a new copy of the message with the desired date. There's no SETINTERNALDATE IMAP command. That detail matters, and we'll come back to it.

Layer 2: the Date: header (RFC 2822)

This is the Date: field in the raw message headers. It's set by the sending email client at send time, and it travels with the message from server to server. It's the send date as declared by the sender.

(If you've never looked at raw email headers, by the way, it's a surprisingly alien read. Every message drags around twenty-odd lines of technical metadata that 99% of people have never seen.)

Technically, nothing stops someone from sending an email with a backdated or future-dated Date: field. SMTP servers don't validate it. But receiving servers do record the actual arrival time in Received: headers, which immediately creates an inconsistency that any email client or analysis tool can spot.

Layer 3: the stacked Received: headers

Every time an SMTP server relays a message, it prepends a Received: header with a timestamp. An email that passed through three servers will have three Received: headers. They're read bottom to top: the oldest is at the bottom, the most recent at the top.

This is exactly where migration tools create the problem. When BitTitan MigrationWiz, CloudM, imapsync, or GSMMO migrate an email, they reinsert it on the new server via IMAP. That deposit generates a new Received: entry timestamped at the moment of migration. Result: your oldest email, something from 2019, ends up with a Received: dated November 2024. And since some email clients (Outlook chief among them) use the most recent Received: as the display date...

There's your problem. 15,000 emails all showing the same migration date.

Can you actually "modify" these dates?

Technically yes for the INTERNALDATE (with constraints). Technically possible but pointless for the Date: header. And for the Received: headers, it's worth looking at carefully.

Rewriting a Received: header is trivial. And immediately detectable.

A Received: header is just a line of text in the message. You can edit it like any text file. It's exactly as simple as it sounds.

But here's what happens next.

First problem: DKIM. The DKIM signature (DomainKeys Identified Mail) is computed over a set of message headers, sometimes including Received: headers. Modifying a signed header invalidates the signature. Any receiving server that checks DKIM will immediately see that the message was altered. That's not a subtle forgery, it's an alarm going off.

Second problem: internal message IDs. Modern mail servers (Google Workspace, Microsoft 365) assign each message a unique, incrementing internal identifier. These IDs are tied to the INTERNALDATE and reception order. Modifying a Received: header without matching those identifiers creates inconsistencies that audit tools catch without difficulty.

Third problem, more practical: even if you edit the Received: in the message content, you haven't touched the INTERNALDATE, which still reflects the IMAP deposit time. The email client keeps showing the wrong date for sorting. You modified the message for nothing.

So. Rewriting Received: headers to forge an email date for malicious purposes: trivial technically, detectable in seconds by any expert. Not a serious path.

The Date: header: changing the past on paper

Same logic applies to the Date: header. You can modify it in the message body. But the Received: headers authenticated by intermediate servers remain intact and tell a different story. The timeline is incoherent. Any analyst or court comparing those fields will see it immediately.

To be precise, this doesn't stop some email clients from displaying the modified Date: if you feed them the .eml file directly. But in the context of a live mail server, with authentication and logs, the modification is transparent.

IMAP migration: the only context where correcting dates is legitimate

There's one case, and only one, where modifying a received email's date is not just possible but technically justified: fixing the damage caused by a poorly handled IMAP migration.

Here's the concrete situation. You just migrated 80 Exchange mailboxes to Microsoft 365. The migration finished on a Friday night. Monday morning, the first tickets come in: "All my emails have the same date", "I can't find an email from last year", "My conversation history with this client is completely broken". You've got 80 blocked users and your manager waiting for an answer.

In this context, the problem is documented, identifiable, and its cause is clear: the migration tool added a Received: header dated the day of migration, and certain email clients use that new header as the display date. The original Date: header, on the other hand, is intact in every message. It was never modified. It still contains the correct original send date.

The correction isn't a forgery: it's a restoration. You're working from true data (the original Date: header) to rebuild consistent metadata. That's fundamentally different from trying to make a 2024 email look like it was sent in 2019.

For more detail on the specific mechanics of each tool, these guides cover the concrete cases: fixing BitTitan dates in Microsoft 365, fixing CloudM dates in Outlook, or fixing imapsync dates in Google Workspace.

Why writing your own script is risky

The basic logic is accessible. Any IT admin who's spent time on IMAP forums can piece together the general approach. That's not the issue.

The issue is the gap between a script that works on 50 test emails and a script that runs across 40,000 production messages without losing a single email, corrupting a single attachment, or breaking a single conversation thread.

A few concrete cases that homemade scripts typically don't handle:

• S/MIME signed emails: the signature covers content and headers. Any modification to the message structure invalidates the signature. A clumsily corrected signed email arrives with "invalid signature" at the recipient end.
• PGP encrypted messages: same family of problems, with potentially worse consequences depending on the implementation.
• Non-ASCII encodings in headers: RFC 2047 describes how special characters are encoded in headers. A script that manipulates headers without handling these cases will silently corrupt email subjects containing accented characters, Japanese text, or Arabic names.
• API rate limits: Google Workspace and Microsoft 365 implement aggressive throttling. At 3 AM, a batch of 10,000 emails hitting a 429 Too Many Requests error with no exponential backoff handling leaves half the mailboxes half-corrected.
• Corrupted MIME boundaries: multipart messages with attachments have precise MIME boundaries. Regenerating them incorrectly makes attachments unreadable.

And the question no homemade script answers: how do you verify that every corrected email is intact? A script that modifies 40,000 messages with no per-message verification is a gamble. A gamble on data your users often consider irreplaceable.

The article on options for fixing email dates after migration explores the different approaches, including their respective limits.

What Redate.io does in this context

Redate.io is built specifically for this case: correcting dates corrupted by an IMAP migration, at scale, without risk to message integrity.

The service connects directly to the affected mailboxes (Google Workspace via domain-wide delegation, Microsoft 365 via Azure AD, or direct IMAP), scans for messages with incorrect dates for free, then applies a proprietary correction pipeline that handles the edge cases documented above. Each email is verified individually after correction. Originals remain in a visible backup folder for 30 days.

Pattern matching covers hundreds of known migration tool signatures: BitTitan MigrationWiz, CloudM, imapsync, GSMMO, and their variants. Detection is precise: Redate.io doesn't touch emails whose dates are already correct.

The pricing model is simple: one-time payment per mailbox, no subscription. The diagnostic scan is free, so you can measure the extent of the damage before deciding anything.

If you're managing mailboxes affected by this problem, this article on wrong dates in Outlook after migration details the most common symptoms and how to distinguish them from other causes.

Ready to measure the extent of the problem across your mailboxes? Run a free scan on Redate.io and see exactly how many emails are affected before any correction is made.