Fix imapsync Email Date Issues

The --syncinternaldates Promise (and Where It Stops)

You ran the imapsync command. You included --syncinternaldates because you read the docs and you're careful like that. The migration finishes, the log says everything transferred, zero errors. Then you open the mailbox in Outlook and every email shows yesterday's date.

This is one of the most common frustrations with imapsync, and it's been confusing sysadmins since at least 2017. The --syncinternaldates flag is supposed to preserve the IMAP INTERNALDATE during migration. And it does: it gives each copy the internal date the source server holds. That's exactly where the trap is.

imapsync is an open-source Perl tool written by Gilles Lamiral, and it's genuinely good at what it does. It handles IMAP-to-IMAP mailbox transfers with a level of reliability that most commercial tools envy. But imapsync can only copy the dates it finds, and that's where things get complicated.

How IMAP Dates Actually Work

There are three different "dates" involved in every email, and most people (including some IT admins) conflate them:

The Date: header (RFC 2822) - the date the sender's email client stamped on the message when it was composed. This lives inside the message body and is never modified by mail servers.
Received: headers - each mail server that handles the message adds one with its own timestamp. They form a chain from sender to recipient. The topmost (most recent) Received header is what some email clients use for display.
INTERNALDATE - an IMAP server-side timestamp that controls how messages are sorted in the mailbox. This is set when the message is first stored via IMAP APPEND.

When imapsync migrates a message, it reads the message from the source server (including its INTERNALDATE) and writes it to the destination server using IMAP APPEND. The --syncinternaldates flag tells imapsync to pass the source INTERNALDATE to the destination server during APPEND.

Here's the good news: Microsoft 365, Outlook.com and Gmail keep the date they're given. So when dates come out wrong, the problem is elsewhere.

Why the Dates Can Still Be Wrong

The IMAP specification (RFC 3501) says that if a date-time is provided with the APPEND command, the server SHOULD use it. "SHOULD" in RFC language means "do this unless you have a good reason not to." Microsoft 365, Outlook.com and Gmail do: a copy that carries its original date keeps it.

What imapsync passes, though, is the date the SOURCE server holds for each message, not the date the email was sent. On a healthy mailbox the two match. On a mailbox that was already migrated once or restored from a backup, the source may hold the date of that earlier operation, and imapsync copies it as is.

Gmail is a case apart only when the copy goes through Gmail's own import API instead of IMAP: that API adds a Received: line dated the day of the copy, and Outlook can show that date. imapsync speaks IMAP, so it isn't affected.

Dovecot and Cyrus, the two most common open-source IMAP servers, keep the date from APPEND as well. So whatever the destination, the question is the same: what date did the source hold?

Common imapsync Command-Line Mistakes That Break Dates

Beyond the source dates, admins often trip over imapsync's command-line options, or blame the wrong ones. Here are the mistakes I see most often:

Copying from a source whose dates were already wrong

--syncinternaldates is on by default: imapsync gives each copy the internal date the source server holds (its documentation: "Sets the internal dates on host2 as the same as host1"). If the source mailbox is itself the result of an earlier migration or a restore, its internal dates may already be those of that operation, and imapsync faithfully copies the wrong date. This is the most common cause, and the easiest to miss, because the log shows two identical dates.

Using --syncinternaldates with --addheader

Some guides recommend using --addheader to inject a custom header during migration. Adding a header modifies the message (one more line at the top) but not the date imapsync passes, so it won't explain wrong dates. The copy is simply no longer identical to the original, which matters if you compare the two.

Confusing --minage and --maxage with date preservation

The --minage and --maxage flags filter which messages to migrate based on their age. They don't affect how dates are handled at the destination. I've seen admins spend hours tweaking these flags thinking they'd fix the date issue. They won't.

Blaming TLS for shifted dates

Over TLS (--ssl1, --ssl2), setting up connections adds latency, and on a large migration (50,000+ messages) it adds up to hours. It doesn't touch the dates: each copy carries the date imapsync passes, whatever time it actually lands.

Reading imapsync Logs: What the Output Actually Tells You

imapsync produces detailed logs, which is great. But the log output can be misleading when it comes to dates.

A typical successful transfer line looks like this:

msg source stratemind/42 {5765} D:2019-01-15 13:22:07 -> dest stratemind/42 {5765} D:2019-01-15 13:22:07

Both dates match. That means imapsync sent the correct INTERNALDATE to the destination. And Microsoft 365, Outlook.com and Gmail all keep the date they're given. But two identical dates only prove the copy is faithful to the SOURCE: if the source date was already wrong, both columns show the same wrong date.

Want to verify what actually happened? After migration, connect to the destination with an IMAP client and check the INTERNALDATE directly:

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

If the returned date isn't the date the email was sent, look at the same message on the source: you'll find the same wrong date there. The log didn't lie, it copied what it was given.

This is one of the most frustrating aspects of debugging date issues: a clean log file, two identical dates, and still the wrong date in Outlook, because the error was there before imapsync ran.

Large-Scale imapsync Migrations: Where Date Issues Multiply

A single mailbox migration with imapsync is annoying when dates break. But MSPs and IT departments running imapsync across hundreds of mailboxes face a different scale of problem entirely.

Consider a typical enterprise migration scenario. You're moving 200 mailboxes from a Zimbra server to Microsoft 365. You write a wrapper script that loops through a CSV of users, calling imapsync for each one. The migration runs over a weekend. Monday morning, you have 200 mailboxes with wrong dates, and around 1.2 million emails total showing the migration timestamp.

Can you re-run imapsync to fix it? Technically yes, but imapsync will skip messages that already exist at the destination (it's designed to be idempotent). You'd need --delete2 to remove destination messages and re-transfer them, which is risky on a production mailbox. And if the source dates were the problem, a second run copies the same wrong dates again.

Some admins try a hybrid approach: run imapsync with --dry first to test, then the real migration. But --dry only simulates the transfer: it shows the dates imapsync would pass, not whether they're the dates the emails were sent. Nothing warns you that the source dates are already wrong.

DIY Fixes and Their Limits

If you search forums and mailing lists (the imapsync-devel list on SourceForge is still active as of early 2026), you'll find suggestions ranging from creative to dangerous.

Some people suggest using a Perl one-liner to modify the INTERNALDATE on the destination server directly. Others recommend exporting all messages to mbox format, manipulating the dates, and re-importing. A few have written Python scripts that use imaplib to fetch, modify, and re-insert messages.

All of these approaches share the same fundamental problems. How do you handle S/MIME signed messages without breaking the signature? What about multipart MIME structures with nested boundaries? Non-ASCII headers encoded with RFC 2047? PGP-encrypted messages where you can't even inspect the content? A script that handles 50 test messages in a dev environment will choke on the edge cases in a production mailbox of 30,000 messages.

And the biggest question nobody asks until it's too late: how do you verify that every single modified message is still intact? That attachments didn't get corrupted, that threading still works, that the 85 MB spreadsheet someone emailed in 2020 survived the manipulation?

(If you've ever tried parsing raw email headers in Perl, you know it's not exactly a relaxing afternoon activity.)

How Redate.io Fixes imapsync Date Issues

The original Date: header is always intact after an imapsync migration. imapsync transfers the raw message faithfully; the wrong date sits in the metadata the copy received, not in the message. That original header is what makes correction possible.

Redate.io connects directly to the mailbox (Google Workspace, Microsoft 365, or any IMAP server), scans for emails with date anomalies, and applies targeted metadata correction through a proprietary header chain analysis and date reconstruction pipeline. It doesn't need to know which tool did the migration: it finds the emails whose displayed date doesn't match their original date.

Every corrected email is verified individually: message integrity, attachment preservation, folder placement, threading, labels. Originals are kept in a visible Redate.io - Originals backup folder, and stay there until you delete them yourself. If anything looks wrong, rolling back is one click away.

The free scan connects to the mailbox, identifies every email with a date anomaly, and reports the exact count and cost. No credit card required, no software to install. For the specifics of your platform:

Redate.io also works on migrations that happened months or years ago. The Date: header doesn't expire, and neither does the ability to correct what went wrong.

Migrated with imapsync and stuck with wrong dates? Run a free scan to see exactly how many emails are affected.

imapsync Dates Not Preserved? How to Fix Them