Takeout mbox Import: All Emails Dated Today

You opened your Google Takeout archive, imported the mbox file into Thunderbird with ImportExportTools NG (or into Apple Mail), then dragged the folders to your new IMAP account. In the client, the emails were neatly sorted year by year. On the destination account, they're all dated today. This article explains what happens with an imported Takeout mbox, why the displayed date is the date of the copy, how to confirm it in a few minutes, and how to fix it on the server side.

First thing to know: your emails aren't damaged. The original date is still inside the message. It's just no longer the one the destination account puts forward.

The Typical Imported Takeout mbox Scenario

You just closed a personal Gmail account you opened fifteen years ago. You requested the export on takeout.google.com, waited for Google's message (two days for a big mailbox), and downloaded four zip archives. Inside each one, a .mbox file per label. You import them into Thunderbird: the local folder fills up, sorting by date is flawless, 2009 at the bottom, yesterday at the top.

Then you do what anyone would do. You select the folders and drag them to the destination IMAP account, whether that's Microsoft 365, a hosting provider or Google Workspace. The transfer runs all evening. Monday morning, you open the webmail.

The problem? All 18,400 emails are dated to the weekend, within a window of a few hours. A 2014 contract sits next to last week's newsletter, and nobody can find anything in chronological order anymore.

The case is very close to old emails that all have the same date, with one big difference: no migration tool is involved here. Drag and drop is enough.

Three Dates in a Single Email

To understand this, you have to stop talking about "the date" of an email. A message imported from an mbox file carries at least three, and they don't serve the same purpose.

The Date Header: The Sender's Date

This is the Date: header defined by RFC 2822 (carried over into RFC 5322). The sender's client writes it at the moment of sending, for example Date: Tue, 14 Mar 2017 09:12:45 +0100. It's part of the message, it travels with it, and Takeout keeps it as is. It's what makes the fix possible, since it stays intact.

The mbox From Line: A Façade Date

In an mbox file, each message is preceded by a line starting with From (with a space, no colon). It isn't a header: it's a separator specific to the file format, and it isn't part of the message. No serious tool should rely on it to date an email.

INTERNALDATE: The Date the Server Received It

Third date, and the most discreet one: INTERNALDATE, defined by RFC 3501. It's an attribute the IMAP server stores next to the message (not inside it), and it corresponds to the date the message was dropped into the mailbox. Outlook, webmails and phones use it to display and sort the received date. For the details of the mechanism, the article on INTERNALDATE and why IMAP dates go wrong goes further.

A word about Received: headers, often blamed wrongly here. The Received lines of an exported Gmail email tell the real route of the message in 2017: they carry old, legitimate dates. In this specific case, the wrong date doesn't live in the message at all, but in the metadata the server assigns to the copy.

Why the Destination Account Shows the Copy Date

When a client drops a message onto an IMAP server, it uses the APPEND command. That command optionally accepts a date to give the message. If the client supplies it, the server keeps it as the INTERNALDATE. If not, the server applies the rule set by RFC 3501: the current date and time. In other words, the displayed date depends on how the tool wrote the email. A tool that doesn't pass the original date gets the date of the copy.

The consequence: while you drag your folders across, each message takes the date of its own drop. A folder of 3,000 emails copied in 40 minutes lands inside a 40-minute window.

So why did Thunderbird's local folder look perfect? Because Thunderbird sorts there on the Date header, not on a server date, since a local folder has no server. Apple Mail behaves in a similar way with imported mailboxes: everything looks fine as long as the messages stay on the Mac. The truth shows up the moment other software, Outlook for instance, reads the IMAP mailbox.

Actually, it's not quite accurate to say every client gets it wrong every time. Some versions pass the date, others don't, and the behavior has changed across updates. So two colleagues following the same method can end up with different results, which makes the diagnosis more confusing than it should be.

Drag and drop isn't a migration. It's a copy, and a copy carries the date it was made.

How to Recognize This Case in Five Minutes

Before looking for a solution, confirm you're really in this scenario and not another one. Four checks are enough.

• Compare the two places. Thunderbird's local folder (or Apple Mail's imported mailbox) shows the right dates, while the IMAP account shows recent dates for the same messages.
• Look at the range. In a folder of the IMAP account, the received dates fit within a few hours, or even a few minutes, around the moment you moved the folders.
• Open a message's source. In Thunderbird, View then Message Source; in Outlook, the message properties show the headers. You should find an old Date: line while the display shows a recent date.
• Check the order. Messages appear in the order the client copied them, not in chronological order.

Here's what the comparison looks like on a real message:

Date: Tue, 14 Mar 2017 09:12:45 +0100          (in the message, intact)
Date displayed by the IMAP account: day of the copy   (server metadata)

If those two lines don't tell the same story, you're in the right place. And if the displayed dates are wrong but Date: is wrong too, that's a different, rarer problem, outside the scope of this article.

(By the way, if you've never read raw email headers, bring a coffee: it's hardly beach reading.)

Sorting by Sent Date: A Band-Aid

The reflex is to switch the sort to the sent date. In Outlook, it works more or less, provided you redo it on every folder and every device. But search, notifications, age-based rules and mobile views keep using the received date. A user looking for "the email from last September" on their phone won't see anything logical.

Another tempting idea: redo the copy. On an account already in use, that mostly produces duplicates next to the messages already there, with the same wrong dates or different ones. A good hundred folders later, you no longer have a single clean mailbox.

The Server-Side Fix

The good news is that the original date is still there. The fix is about making the destination account display it, without touching the content of your messages.

That's what Redate does. The service connects to the mailbox (Google Workspace through domain-wide delegation, Microsoft 365, Outlook.com and Hotmail with each person's Microsoft account, or direct IMAP with the address and password). Redate doesn't need to know which tool did the damage: it finds the emails whose displayed date doesn't match their original date, whether the cause was a drag and drop from a Takeout mbox or something else. Scanning your mailbox is free and shows you the extent of the problem before you decide anything.

For the correction itself, Redate relies on a proprietary correction engine, a multi-stage analysis pipeline that examines the header chain of each message and gives every email its original date back. Each corrected email is then verified individually, with RFC compliance validation and message structure preservation. Originals are never deleted: they stay in a visible folder of your mailbox until you delete them yourself.

Why DIY Is Risky

Understanding the problem is one thing. Fixing 15,000 emails without losing a single one is another.

A script that works on ten test messages won't survive a production mailbox of 30,000. It runs into signed S/MIME emails, where the slightest change breaks the signature. Encrypted PGP messages. Nested multipart/alternative structures, inconsistent MIME boundaries, unexpected Content-Transfer-Encoding values, non-ASCII headers encoded per RFC 2047, 40 MB attachments. Then come the API quotas, the 429 Too Many Requests error at 3 AM in the middle of a batch, the network timeouts that cut the operation off at message 11,874.

And then what? How do you know each message is intact? With no rollback mechanism, one mistake leaves duplicate messages, lost attachments, broken threads and vanished labels. Redate checks every email automatically and keeps the original within reach, precisely so you never have to gamble on it.

One last tip, free of charge: keep your original Takeout archives until the mailbox is validated. The mbox file remains the reference copy, even when the destination account looks correct.

Guides Related to Your Client

Depending on the client you used for the copy, these detailed guides cover the exact case: fix the dates of an IMAP copy made in Thunderbird and the same case in Apple Mail.

Your Takeout is already copied to the IMAP account and the dates are wrong? Start Redate's free scan to see how many emails are affected, then fix them with a one-time payment, with no mailbox size limit.