Fix imapsync Email Date Issues

The --syncinternaldates Promise (and Why It Breaks)

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 technically, it does try. But "try" is doing a lot of heavy lifting in that sentence.

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 date preservation is not entirely in imapsync's hands, 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 problem: the destination server is not obligated to honor that date.

Why Destination Servers Ignore INTERNALDATE

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." Several major email platforms have decided they have a good reason.

Microsoft 365 is the biggest offender. When a message arrives via IMAP APPEND, the Exchange transport pipeline stamps it with a new Received header containing the current date, then sets the INTERNALDATE based on that delivery timestamp. It doesn't matter what date imapsync requested. The M365 server overrides it.

Google Workspace (Gmail) behaves differently but can still cause issues. Gmail's IMAP implementation does respect the INTERNALDATE from APPEND in most cases, but it adds its own Received header. If the email client reading the mailbox prioritizes Received headers over INTERNALDATE for display (and Outlook does exactly this), dates still appear wrong.

Dovecot and Cyrus, the two most common open-source IMAP servers, generally honor the INTERNALDATE from APPEND. So imapsync migrations between two Dovecot servers usually preserve dates correctly. The problems start when the destination is a hosted platform with its own transport processing.

Common imapsync Command-Line Mistakes That Break Dates

Even when the destination server would cooperate, admins often trip over imapsync's command-line options. Here are the mistakes I see most often:

Forgetting --syncinternaldates entirely

The flag is not enabled by default. If you run a basic imapsync --host1 source --host2 dest --user1 user --user2 user without it, imapsync doesn't attempt to preserve dates at all. The destination server uses the current timestamp for every message. This is the most common cause, and it's the easiest to miss because imapsync doesn't warn you about it.

Using --syncinternaldates with --addheader

Some guides recommend using --addheader to inject a custom header during migration. If you're adding headers, you're modifying the message, which can trigger the destination server to treat it as a "new" message and stamp it accordingly. The interaction between these two flags is poorly documented.

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.

SSL negotiation causing timestamp drift

When migrating over TLS with --ssl1 and --ssl2, the connection setup adds latency. In large migrations (50,000+ messages), this latency accumulates. While it doesn't change dates by days, it can cause messages sent minutes apart to arrive with identical timestamps at the destination, losing their relative ordering.

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. But it doesn't mean the destination server actually stored that date. imapsync reports what it requested, not what the server accepted.

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 is the migration date instead of 2019-01-15, the destination server ignored imapsync's request. The log lied to you (well, it told you what it asked for, not what it got).

This gap between what imapsync reports and what actually happens is one of the most frustrating aspects of debugging date issues. You can stare at a clean log file for hours and never realize the dates are wrong on the other end.

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 broken dates, and around 1.2 million emails total showing the migration timestamp.

Can you re-run imapsync with --syncinternaldates if you forgot it the first time? 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 even then, if the destination server ignores the INTERNALDATE, you're back to square one.

Some admins try a hybrid approach: run imapsync with --dry first to test, then the real migration. But --dry doesn't test what the destination server does with the INTERNALDATE. It only simulates the transfer. The date problem is invisible until messages are actually written to the destination.

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; it's the destination server's metadata handling that causes the display problem. 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. The correction handles the specific patterns that imapsync migrations leave behind, including the characteristic Received header signatures from destination servers that overrode the INTERNALDATE.

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 for 30 days. 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