Veeam/Datto: Emails Show Restore Date, Not Send Date

The morning after the restore, the tickets start rolling in

You just finished restoring mailboxes via Veeam Backup for Microsoft 365. The operation went smoothly, the data is there, the folders are intact. Then Monday morning, a user writes in: "All my emails have today's date. I can't find anything."

The emails haven't disappeared. They're all there. But the displayed date corresponds to the exact time of the restore, not when they were originally sent or received. An email from January 2021 shows up as received last night at 11:47 PM. The conversation thread is scrambled. The chronology is unreadable.

This affects Veeam Backup for Microsoft 365, Datto SaaS Protection, Synology Active Backup for Microsoft 365, and AvePoint Cloud Backup, among others. Each in its own way, but the result is the same.

What's actually happening technically

To understand where the wrong date comes from, you have to look at how these tools reinsert emails into an Exchange Online or Google Workspace mailbox.

When a backup tool restores a message, it can't simply "put the email back" the way you'd move a file on a local disk. It writes a new copy of the message into the mailbox, through IMAP or through the provider's API (EWS or Microsoft Graph on the Microsoft side, the Gmail API on the Google side). And along with that copy, it has to tell the mailbox which date the message carries.

And that's where the problem starts. (If you've ever looked at the raw headers of a restored email, you've probably scrolled through twenty Received: lines before finding anything useful.)

IMAP APPEND and the Received: header

The IMAP protocol has a command called APPEND. It's used to insert a message into a mailbox. That's exactly what a restore tool does: it takes the backed-up message and injects it into the target mailbox via IMAP APPEND.

This command lets the tool pass a date along with the message. If the tool passes the message's original date, the mailbox keeps it: Microsoft 365, Outlook.com and Gmail all do. If it passes nothing, or the date of the restore, the mailbox files the email under the day of the restore. And some ways of writing a message back add one more line at the top: a Received: header dated the day of the copy. Gmail's own import API does exactly that.

That extra line looks something like this:

Received: by gmailapi.google.com
  with HTTPREST; Mon, 14 Apr 2025 23:47:12 +0000

The result: the original email is intact inside, with its original Date: header (say, "3 Jan 2021 09:15:00"). But a new Received: header has been stamped at the top, dated to the moment of the restore.

How Outlook and Gmail read the date

Email clients like Outlook or Gmail's web interface don't always read the Date: header to decide what date to show in the message list. Many use the INTERNALDATE from the IMAP protocol, meaning the date the message was added to the mailbox, or the most recent Received: header.

Outlook for Windows, especially since its late 2023 update, is particularly sensitive to this. When it sees a recent Received: header at the top of the chain, it uses that as the display date. The original Date: header gets buried in the message details, only visible if you open the email properties.

The end user sees a message list where everything is dated to the night of the restore. Three years of email history, flattened into a single night.

This is different from a migration problem

It's worth distinguishing this from the classic wrong-date problem after IMAP migration. In a migration, the tool moves emails from server A to server B, and whether each email keeps its date depends on what the tool tells server B as it writes it. Same mechanics, different context.

Here, we're talking about a restore from backup. The emails never left the organization, they were just stored somewhere safe (Azure Blob Storage, AWS S3, a Datto appliance...) and then reinjected. Users expect it even less: for them, these are "their" emails coming back, not imported emails from somewhere else.

But technically, the mechanism is identical. A reinjection that doesn't carry the original date produces the same artifacts. And the fix follows the same logic.

How each tool handles (or doesn't handle) INTERNALDATE

Not all tools behave exactly the same way, and this is where things get interesting.

Veeam Backup for Microsoft 365

Veeam uses the EWS (Exchange Web Services) API to restore to Exchange Online. EWS allows specifying the message date via the DateTimeReceived field, but this value isn't always reflected in the IMAP-level INTERNALDATE. The result: the sort date in Outlook may not match the original date, especially when restoring to a different mailbox than the original (granular restore to an alternate mailbox, for example).

Datto SaaS Protection

Datto restores via Microsoft Graph API or IMAP depending on the configuration. In both cases, the date the mailbox shows depends on whether the restore passes each message's original date. MSPs using Datto for their clients run into this fairly regularly, particularly after ransomware incidents where you're urgently restoring several hundred mailboxes at once. That's not the moment to discover all the dates are wrong.

AvePoint and Synology Active Backup

AvePoint Cloud Backup and Synology Active Backup for Microsoft 365 follow similar mechanisms. AvePoint has documented this behavior in its knowledge base (the message is restored with the restore date as the visible received date), without offering a native fix. Synology Active Backup has the same problem, amplified by the fact that the restore interface doesn't clearly distinguish "message date" from "restore date".

Good news: the original date is still there

What makes the situation recoverable is that the original Date: header hasn't been modified. It's still present, intact, inside every restored email. The restore changed the date the mailbox recorded, and sometimes added a Received: line on top, but it didn't touch the message content itself.

This is a property of the MIME format (RFC 2822): a message is immutable in its internal structure. Received: headers accumulate at the top like layers, but the original information stays underneath.

So no, you haven't lost the data. It's just hidden behind a reinjection artifact.

Why re-running the restore isn't the answer

The first instinct: delete the restored emails and re-run the restore, hoping the dates will be correct this time. This is a bad idea, for several reasons.

The restore tools won't behave any differently on a second pass. Same tool, same settings: the emails get written back the same way, without their original date. You'll get exactly the same result.

On top of that, re-running a restore on production mailboxes means time, bandwidth, and risk. Across 50 mailboxes with 20,000 messages each, you're looking at an operation lasting several hours that hammers the APIs and can trigger rate limits on the Microsoft or Google side (the dreaded 429 Too Many Requests at 2 AM during the batch).

The restore worked. The data is there. What needs fixing is the date artifact, not the restore itself.

Fixing it yourself: the real risks

Understanding the problem is one thing. Correcting it across 80,000 emails without losing a single one is another.

A Python script that loops through IMAP messages and corrects dates might look feasible. On 50 test emails, it'll work fine. In production, it's a different story. Edge cases pile up: S/MIME signed emails (modifying the header invalidates the cryptographic signature), PGP encrypted messages, multipart structures with non-standard MIME boundaries, RFC 2047-encoded headers (non-ASCII), 40 MB attachments that blow out the script's memory. And emails with multiple Received: headers added on top (if the restore was partially re-run, which happens), requiring more sophisticated detection logic.

Actually, the real risk isn't the script that crashes: it's the script that runs without any apparent error but produces corrupted messages. Damaged threads. Duplicates. Detached attachments. Things you might not catch until weeks later, when a user tries to find an important email.

And how do you verify that every corrected email is actually intact after the modification? A homemade script generally doesn't.

What Redate.io does differently

Redate.io analyzes the header chain of each email to identify reinjection artifacts, whether they come from a Veeam restore, a BitTitan migration, or a manual import. The proprietary correction engine doesn't need to know which tool did the damage: it looks for emails whose displayed date doesn't match their original date, so even a tool nobody has heard of gets caught.

Before correcting anything, Redate.io scans the entire mailbox and presents a report: how many emails are affected, what the incorrect date is, what original date was detected. That scan is free. You see the full scope of the problem before deciding whether to act.

Every email is verified individually after correction. Originals are kept in a visible backup folder until you delete them, providing a complete safety net if you ever need it.

Each person signs in with their own Microsoft or Google account, and Redate.io opens that one mailbox with the access that sign-in grants, with no email passing through intermediate servers. Correction happens in place, inside the mailbox, without any export or reimport.

For MSPs managing multiple affected clients at the same time, see the page dedicated to MSPs: Redate.io can process multiple mailboxes in parallel from a single interface.

Other scenarios that produce the same artifact

Restoring from a backup tool isn't the only case. The same date artifact appears in other situations:

• IMAP import from Exchange (archived mailboxes reinjected into Exchange Online)
• Migration to Exchange Online with tools that use IMAP on the destination side
• Granular restore from a PST that was exported and then reimported (see the article on PST import)
• Shared mailboxes reconstructed after an incident (see the fix for shared mailboxes)

In all these cases, the underlying mechanism is the same: a reinjection that doesn't carry the original date (sometimes with a new Received: header on top), and an email client that shows that new date as the reference.

The emails are there, and the original date is preserved inside every message. Run a free scan on Redate.io to see exactly how many emails are affected in your mailbox, then decide whether you want to go ahead with the correction.