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

The question everyone asks (and why it hides two very different situations)

Search "change received email date" in Google. You'll land on dozens of threads on Microsoft Q&A forums, Reddit threads, Quora questions. The request is clear, but the reasons behind it vary wildly depending on who's asking.

Some people want to falsify a date, retroactively, for reasons best left unexamined. And then there are IT admins who, after an IMAP migration, find all their emails showing the same date (the migration date), and simply want the real dates back. These two situations have nothing to do with each other, but they share the same search query.

This article addresses both. Spoiler: in the first case, undetectable modification isn't really possible. In the second, it's entirely legitimate, and it's exactly what Redate.io does.

First: what is an email's "date"?

An email doesn't contain a single date. It contains several, stored in different places, controlled by different parties.

The Date: header (RFC 2822)

This is the date the sender's email client writes into the message at the time of sending. It appears in the raw headers as:

Date: Mon, 14 Oct 2024 09:32:11 +0200

This header is part of the message body. It can technically be modified if you access the raw file. But "technically" is the key word here.

The Received: headers

Every mail server that handles an email adds its own Received: header with a timestamp. These headers form a chronological chain, from the sender's server all the way to your inbox. (If you've ever tried reading raw email headers, you know it's not exactly light reading. Dozens of lines of technical metadata, in an order that runs from newest to oldest.)

The IMAP INTERNALDATE

This is the most important piece of metadata for understanding why some modifications have no visible effect. INTERNALDATE is an attribute stored server-side on the IMAP server, independently of the message content. It's what most email clients use to sort emails in folders. Outlook uses it. Gmail does too. Apple Mail, in most cases, as well.

INTERNALDATE is not inside the message. It lives in the server's database. You can't modify it by editing a .eml file on your hard drive.

What actually happens when you edit locally

Editing a .eml file

A .eml file is a text file. You can open it in any editor, change the Date: line, save it. If you reimport that file into a local email client, the displayed date might change, depending on the client.

But here's what it doesn't change:

• The INTERNALDATE on the IMAP server (still untouched)
• The Received: headers added by intermediate servers
• Delivery logs at Google, Microsoft, or your provider
• The DKIM signature, if the message had one

Result: on your local machine, you might see a different date. In Outlook connected to Exchange Online, or Gmail in a browser, nothing has changed.

Changing the system clock

Some forums suggest changing your workstation's clock to "trick" the email client. This doesn't work. Outlook and Gmail don't read the system time to display received email dates. They read the INTERNALDATE from the server, or the message headers. The local clock plays no role anywhere in that process.

The Thunderbird approach

Thunderbird offers more flexibility than most clients. With extensions or by directly manipulating the profile (mbox files, .msf files), some people attempt to change how dates display. It can work within Thunderbird itself, for emails stored locally in POP3 mode. But as soon as Thunderbird is connected over IMAP, it resyncs with the server. The "fix" disappears at the next sync.

DKIM: the invisible barrier nobody mentions

Most emails sent since 2018 are signed with DKIM (DomainKeys Identified Mail). A DKIM signature looks like this in the headers:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=example.com; s=default;
  h=Date:From:To:Subject:Message-ID;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=ABC123...

The h= field lists the headers covered by the signature. In the example above, Date is signed. If you modify the message's Date: header, DKIM verification fails. Any mail server, any forensic analysis tool, can detect the modification by recalculating the signature.

This isn't a perfect protection (a malicious sender controls their own DKIM key and can sign whatever they want at send time). But for an email that's already been received and signed, modifying the Date: header leaves a detectable trace.

Server logs: the real source of truth

Even if you managed to modify all visible metadata in an email (headers, INTERNALDATE, everything), providers keep their own logs.

Google Workspace logs every message in the Admin Console audit logs. Microsoft 365 does the same in the Compliance Center (Purview). These logs include delivery timestamps, independently of what's displayed in clients. A lawyer, a legal team, or a security team can retrieve this data. The date visible in Outlook carries no weight in court or during a security audit.

To be precise: even an admin with domain delegation access to a mailbox cannot retroactively rewrite these logs. They're out of reach of any user, even privileged ones.

The legitimate case: post-migration correction

You just finished migrating 150 mailboxes from on-premises Exchange to Microsoft 365. Monday morning, the tickets start coming in: "all my old emails are dated last Friday." The migration date.

This is a well-documented problem, and it's completely different from what we've been describing. Here, nobody is trying to falsify anything. The real original dates still exist, intact, in the Date: header of every message. The issue lies elsewhere: the migration tool (BitTitan MigrationWiz, CloudM, imapsync, or another) inserted a Received: header with the migration date at the top of the chain. Outlook, which in certain contexts relies on the most recent Received: headers rather than INTERNALDATE, displays that date instead.

In this case, "correction" means restoring consistency between what the message says (the original Date: header, still there) and what the server thinks (the INTERNALDATE, set at migration time). This isn't falsification. It's restoration.

This is exactly the kind of problem an IMAP migration imposes on thousands of mailboxes. And it's what Redate.io solves.

Why doing it yourself fails at scale

Understanding the problem is one thing. Correcting it across 40,000 emails spread over 150 mailboxes without losing a single one is another.

Scripts you find on GitHub or Stack Overflow work fine on 20 test emails. They run into problems in production for reasons the script's author never anticipated:

• S/MIME signed or PGP encrypted emails have structures that can't be handled like ordinary messages
• Multipart messages with non-standard MIME boundaries cause parsing errors
• Headers encoded per RFC 2047 (non-ASCII characters in From: or Subject: fields) break naive parsers
• Google and Microsoft APIs enforce rate limits: at 3 AM during a 30,000-email batch, a 429 Too Many Requests error isn't handled, the script stops, and nobody knows where it left off
• No rollback mechanism: if a message gets corrupted during processing, there's nothing to fall back on

Redate.io keeps a copy of every original email in a visible backup folder for 30 days. Every correction is verified individually. The analysis pipeline handles hundreds of known migration tool signatures, along with all the edge cases a homemade script would miss.

For more detail on specific tools: BitTitan MigrationWiz and email dates, or CloudM Migrate: fixing wrong dates.

What changes, what never does

The distinction is clear. The first three rows describe superficial or detectable modifications. The last describes a legitimate metadata correction, aligned with the message's original content, after a migration introduced an inconsistency.

If you're in the situation described at the bottom of that table, after a migration using imapsync, BitTitan, CloudM, or another tool, Redate.io is built for exactly this.

Your emails are showing the migration date instead of the real dates? Scan your mailboxes for free with Redate.io and see exactly how many emails are affected before you decide anything.