Backdating an Email: What's Possible and What's Detectable

Backdating an email: what are we actually talking about?

The question comes up regularly in sysadmin forums and MSP Slack groups: is it possible to change an email's date after it's been sent? The short answer is yes, technically. But the full answer is far less reassuring for anyone hoping to do it for questionable purposes.

An email isn't a monolithic file. It's a collection of text headers followed by a message body. Several of those headers carry date information. And some are easier to modify than others.

Three layers of dating coexist in every email:

• The Date: header (RFC 2822), written by the mail client at the moment of sending
• The Received: headers, added by each server that relays the message
• The IMAP INTERNALDATE, a metadata value stored server-side, independent of the message content itself

Each of these layers can be modified. None of them can be modified without leaving traces.

Modifying the Date: header: the most obvious manipulation

The Date: header is plain text inside the .eml file. Technically, any hex editor or Python script can rewrite it in seconds. If you've ever opened the raw headers of an email in Gmail (the little "Show original" menu), you know it's readable by anyone.

The problem? Since 2004, the vast majority of mail servers sign outgoing emails with DKIM (DomainKeys Identified Mail). This cryptographic signature explicitly covers several headers, including Date:, From:, Subject:, and the message body. The signature is stored in the DKIM-Signature: header.

Modifying the Date: after signing mechanically invalidates DKIM verification. Any receiving server can check the signature by fetching the public key from the sending domain's DNS. If the signature no longer matches, the message is flagged as tampered. Gmail, Outlook.com, and all major providers perform this check automatically.

(By the way, if you want to see a DKIM signature in the flesh, open the raw headers of any email received from Gmail or Office 365: you'll find a line like DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=... that looks like noise but is actually a cryptographic hash of the entire message.)

So: modifying the Date: on a DKIM-signed email breaks the seal. The change is visible to any administrator who knows where to look.

Rewriting Received: headers: a chain that's hard to fake

The Received: headers trace the path an email takes between sender and recipient. Every SMTP server that touches the message adds one, with its name, IP address, and a timestamp. An email that passes through two or three relays contains two or three stacked Received: headers.

Can they be modified? Technically, yes, on your own copy of the message. But here's the catch: the recipient also has a copy. And their server added its own Received: header last. That header is under the recipient's control, not the sender's. It can't be forged from the outside.

The coherence of the chain is verifiable. If the timestamps on successive Received: headers don't add up (an intermediate relay received the message before the sender sent it, for example), that's immediately suspicious. Email forensic tools like MXToolbox or security team tooling check exactly this.

Actually, it's not entirely accurate to say Received: headers are impossible to fake in full: an attacker who controls their own mail infrastructure can fabricate convincing headers for the relays they own. But they never control the final link: the recipient's server.

IMAP INTERNALDATE: the most technical case

INTERNALDATE is an IMAP metadata value stored server-side. It's not a header inside the message itself: it's a value the server associates with the message in its internal database. This is the value most mail clients use to sort messages in the inbox.

The IMAP APPEND command lets you deposit a message onto a server while explicitly specifying an INTERNALDATE. This is a legitimate protocol feature, documented in RFC 3501. Migration tools use it constantly: imapsync, BitTitan MigrationWiz, CloudM, GSMMO... all of them deposit emails on the destination server with a specified INTERNALDATE.

Theoretically, someone with IMAP access to their own mailbox could deposit an email with any INTERNALDATE they choose. But this manipulation doesn't touch the message headers. The original Date: stays intact, the Received: headers stay intact, the DKIM signature stays intact. Only the server-side sort metadata changes.

For an expert examining the raw message, the discrepancy between INTERNALDATE and the declared Date: is immediately visible. And if the message is DKIM-signed, the original date is cryptographically attested.

Message-ID: a fingerprint that's hard to fake

Every email generates a unique identifier: the Message-ID: header. This identifier is built by the sending SMTP server at the moment of sending, typically combining a timestamp, a random identifier, and the server's domain name.

A typical Message-ID looks something like this: <CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>. The timestamp is often encoded directly in the identifier. Changing the message's date while leaving a Message-ID with an incompatible timestamp creates an inconsistency that's immediately noticeable.

On top of that, Message-IDs are indexed by major messaging systems. Google, Microsoft, and others maintain logs that make it possible to trace when a message actually traveled across their infrastructure. In a legal or forensic context, those logs are accessible through judicial procedures.

In practice: who can detect a manipulation attempt?

Let's make this concrete. You receive an email and you suspect its date has been changed. What can an IT administrator or a lawyer with basic technical knowledge actually do?

• DKIM verification: in Gmail, the "Show original" menu displays the DKIM verification result directly at the top of the page. A "PASS" confirms the message's integrity since it was sent. A "FAIL" or "SOFTFAIL" signals tampering.
• Header analysis: tools like MXToolbox Header Analyzer or the Google Admin Toolbox automatically parse the Received: chain and flag temporal inconsistencies.
• Message-ID / Date consistency: an analyst can compare the timestamp encoded in the Message-ID with the declared Date: value.
• Server logs: if the email passed through a server you administer, the SMTP logs contain the actual date and time the message was accepted, independent of any header.

The detection tools are accessible, free, and don't require advanced forensic expertise. A mildly curious IT admin can verify an email's integrity in under two minutes.

The one legitimate case for mass date correction: IMAP migration

There's one scenario where hundreds of thousands of emails end up with wrong dates through no malicious intent: IMAP migration.

You just finished migrating 150 Exchange mailboxes to Google Workspace. Monday morning, the tickets start rolling in. Users report that all their old emails are showing the same date, the date of the migration weekend. Their inboxes are unreadable.

What happened is documented and predictable: the migration tool (BitTitan, CloudM, imapsync, whatever) deposited the emails onto Google Workspace via IMAP APPEND. It specified an INTERNALDATE matching the migration date, not the original email date. Result: Outlook, which sorts by INTERNALDATE by default, displays the migration date on every message. Why emails show wrong dates after migration explains this mechanism in detail.

The original Date: header is intact in every message. The DKIM signatures are intact. The content hasn't moved. It's only the server-side INTERNALDATE that's wrong.

This problem affects BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO, and every tool that uses IMAP APPEND without correctly preserving INTERNALDATE. The BitTitan MigrationWiz article covers that tool's specific quirks. The email migration checklist lists the points to verify before and after a migration to avoid this kind of problem.

The difference between correcting and falsifying

The correction Redate.io performs is the opposite of a falsification attempt. The proprietary correction engine analyzes the header chain of each message, identifies the original date encoded in the Date: header (RFC 2822) that was never touched, and corrects the date metadata to align with that authentic information already present in the message.

The Date: header is the source of truth. It was written by the sender's mail client at the moment of sending. It's covered by the DKIM signature. Redate.io does not modify it. What gets corrected is the discrepancy introduced by the migration tool, not the original date.

Correcting 47,000 emails after a botched migration without losing a single one, without breaking threads, without corrupting attachments, without triggering 429 errors at 3 AM on the Google API: that's a multi-stage analysis pipeline with edge-case handling (S/MIME, PGP, non-ASCII encodings per RFC 2047, complex multipart structures). A five-line Python script wouldn't survive the first production mailbox. Can email dates be fixed after migration details why DIY is risky at real volumes.

Redate.io scans mailboxes for free, identifies emails with incorrect dates, and corrects them through a validation pipeline that verifies each message individually. Originals are kept in a visible backup folder for 30 days. If something goes wrong, rollback is possible.

Did your migration shift all your email dates? Run a free scan on Redate.io to measure the extent of the problem before deciding what to do.