What Is an MBOX File? The Mailbox Format Behind Thunderbird, Apple Mail and Google Takeout
An MBOX file holds a whole mailbox in one plain text file. Jump to your question below, or read it through in order.
An MBOX file holds a whole mailbox in one plain text file. Jump to your question below, or read it through in order.
An MBOX file is a plain text file that holds a whole mailbox. Every message sits one after another in the same file. Each one starts with a line that begins with the word From and a space, and that line is how a program knows where the next message begins.
It is the format Thunderbird uses for your local folders, the format Apple Mail exports and the format Google Takeout hands you when you download your Gmail.
Think of a notebook rather than a filing cabinet. Every email is written into the same notebook one after the next. A line at the top of each page tells you a new email has started.
That is the whole idea. An MBOX file is text, so you can open one in Notepad and read the messages with your own eyes. There is no database, no index and nothing proprietary about it.
MBOX is short for mailbox. It goes back to Fifth Edition Unix in the 1970s, which makes it one of the oldest file formats still in daily use.
MBOX is not one format. It is a family of four closely related ones, and they disagree about a single detail. Section 3 explains which is which, and why that detail can damage a message.
| File | Holds | Stored as | Made by |
|---|---|---|---|
.mbox | A whole mailbox or folder | Plain text, readable | Thunderbird, Apple Mail, Gmail export |
.eml | One single message | Plain text, readable | Almost every email client |
.pst | Mail, calendar, contacts and tasks | Binary database | Microsoft Outlook |
.ost | A cached copy of one mailbox | Binary database | Microsoft Outlook |
Read down the third column and the split is clear. MBOX and EML are text you can read without any software at all. PST file format and OST (Offline Storage Table) file are binary databases that need Outlook.
That difference is why MBOX keeps being chosen for backups and archives. A format you can still read in thirty years without the original program is worth something.
This page explains the format. Have a specific error on screen instead? The MBOX file errors guides deal with those one by one, from a file that will not import to one that is too large to move.
Inside an MBOX file there is nothing but text. Headers, message body and attachments all sit in the same stream. A line starting From plus a space marks the start of each message.
Open one in a text editor and you will see the same four things repeating, over and over, for every message in the mailbox.
From: header you see in your inbox. This one has no colon and it sits above everything else.
RFC 4155 sets out exactly what that separator line contains. Four parts in this order and nothing else.
From, one space, the sender address in the RFC 2822 addr-spec form, one space, then the date and time in the old Unix ctime style with no timezone on the end.
Two details in that line catch people out. The first is that there is no colon after From, which is what separates it from the ordinary From: header two lines below it.
The second is that the address on the separator line is the envelope sender, the address the mail server actually delivered to. It is often not the address shown in your mail program.
The standard also requires that every message ends with a completely empty line. That blank line and the next From line together are the join between one message and the next.
Never open an MBOX file in a word processor to edit it. Reading it in Notepad is fine. Saving it from Word or TextEdit is not, because those programs rewrite the line endings and add formatting, and either one breaks every message boundary in the file.
If you need to change something, work on a copy and use a plain text editor that does not convert line endings.
There are four MBOX variants and they disagree about one thing: what to do when a line inside a message happens to start with the word From and a space. Get that wrong and the message is damaged.
Here is the problem the variants were invented to solve. A message boundary is a line starting From and a space. Now imagine somebody writes this in the middle of an email:
The fix everybody reached for was to put a greater-than sign in front of it on the way in, and take it off again on the way out. The four variants are four different opinions about how to do that.
| Variant | On the way in | Comes back out exactly? | Uses Content-Length |
|---|---|---|---|
| mboxo | Adds > in front | No. A line that already began >From is left alone, so the reader strips a > that was never added | No |
| mboxrd | Adds > in front, and adds another one to lines that already start >From | Yes. Always reversible | No |
| mboxcl | Same escaping as mboxrd | Yes | Yes |
| mboxcl2 | Nothing. Lines are left exactly as written | Yes, as long as the reader honours Content-Length | Yes, and it depends on it |
Quoting an earlier email puts a greater-than sign at the start of a line. That is how reply quoting has worked for decades. So a line reading >From the top is completely normal in a real message.
Mboxo leaves that line alone when it writes the file, because it only escapes lines starting with From. The reader then strips one greater-than sign from every line starting >From, including that one. The quote marker vanishes and the message is no longer what was sent.
Mboxrd closes the hole by escaping the already-escaped ones too, so >From becomes >>From. Strip one on the way out and you are back exactly where you started, every time. That is why the qmail mail server adopted it.
“This specification does not prescribe any escape syntax for message body lines that begin with the character sequence of ‘From’.”
That sentence is the reason this section has to exist. The one standard MBOX has does not settle the question, so every program answers it on its own.
Almost always mboxrd. It is what Thunderbird writes, what Google Takeout produces and what most modern tools expect, so if nobody has told you otherwise, assume mboxrd.
Two exceptions are worth knowing. Thunderbird uses an mboxrd variation with its own extra quoting rules rather than plain mboxrd.
Eudora is the other one. It used an mboxo variation that replaced the sender address on the separator line with the constant string ???@???. That is why an old Eudora mailbox can look like it has lost every sender.
Mixing variants is what actually corrupts mailboxes. The Library of Congress puts it plainly. Messages cannot be reliably read from mboxo or mboxrd mailboxes by mboxcl or mboxcl2 readers. Delivering into an mboxcl2 mailbox with mboxo or mboxrd tools will corrupt it.
In practice this means one thing. Pick one program to write to a given MBOX file and let it be the only one that does.
There is no single MBOX location. Thunderbird keeps its files inside your profile folder, Apple Mail writes .mbox packages wherever you export them and Google Takeout puts yours inside the archive you download.
Most pages answer this with one path and move on. That does not work, because the answer depends entirely on which program made the file.
Thunderbird stores mail inside its profile folder. These are the documented defaults, and the profile name in the middle is random, so expect a folder called something like xxxxxxxx.default-release.
AppData\Roaming, which is hidden, so browsing to it does not work.
Rather than hunting for it, let Thunderbird tell you. Open the menu, choose Help, then Troubleshooting Information and click the button next to Profile Folder. It opens the exact folder for the profile you are using.
Inside, your mail sits under Mail for local folders and ImapMail for accounts left on the server.
Apple Mail does not keep working MBOX files. It exports them. Choose Mailbox then Export Mailbox, and in Apple's own words, Mail exports the mailboxes as .mbox packages.
A package is a folder that macOS displays as though it were a single file. That one fact explains a complaint people have every day: they copy a .mbox to a Windows machine and find a folder instead of a file.
Nothing is wrong when that happens. Open the folder and the real MBOX data is inside, in a file named mbox with no extension at all. That file is what any other program needs, and the Info.plist beside it is only Apple's own bookkeeping.
Gmail keeps nothing on your computer. You get an MBOX file only when you ask Google Takeout for one. It arrives inside a ZIP or TGZ archive along with whatever else you exported.
Section 6 covers what is inside that download, because a Takeout MBOX file behaves differently from one Thunderbird wrote.
Thunderbird writes MBOX by default and gives the file no extension. Your inbox is a file called Inbox, and the Inbox.msf beside it is only an index.
Thunderbird's own documentation is clear that mbox is the default store for local mail. The alternative, maildir, has to be switched on per account and most people never touch it. Its sibling SeaMonkey stores mail the same way.
What surprises people is what that looks like on disk. Open the Mail folder in a Thunderbird profile and you find files named Inbox, Sent and Trash with nothing after the name.
| On disk | What it is | Safe to delete? |
|---|---|---|
Inbox | The MBOX file. Every message you have is in here | No. This is your mail |
Inbox.msf | The index, or Mail Summary File. Headers only, so the message list draws fast | Yes. Thunderbird rebuilds it from the MBOX file |
Inbox.sbd | A folder holding the subfolders of your inbox | No. The mail in those subfolders lives here |
The .msf file is a small database of header information for that folder. Deleting one is a standard fix when a folder shows the wrong messages or none at all. It costs you nothing, because Thunderbird reads the MBOX file again and writes a fresh index.
That is exactly the repair behind MBOX 0x80004005 NS_ERROR_FAILURE in Thunderbird, and it is worth trying before anything more drastic.
Adding .mbox to the filename changes nothing. Thunderbird finds its folders by name, so renaming Inbox to Inbox.mbox inside a live profile hides the folder from Thunderbird. Copy the file out first, then rename the copy if another program insists on the extension.
Deleting a message in Thunderbird marks it as gone. It does not remove the bytes. The message stays inside the MBOX file until the folder is compacted, which is why a folder you have emptied can still be enormous.
Right-click the folder and choose Compact. Thunderbird rewrites the file without the deleted messages, and the size finally drops.
Google Takeout exports Gmail as MBOX. Labels cannot be folders in MBOX, so Google writes each message's labels into an X-Gmail-Labels header instead.
Gmail is the reason most people meet an MBOX file at all. Ask Google for a copy of your mail and this is the format it arrives in.
Takeout/Mail/ as one or more .mbox files.This one worries people, so it is worth being precise. Gmail has no folders. It has labels, and one message can carry several of them at once.
MBOX has no way to record that. Google's answer is a header: every message in the export carries an X-Gmail-Labels line listing the labels it had. A message with three labels can therefore appear three times in the export.
They are not copies of different messages. Check the Message-ID header and you will find it is the same message each time. Any tool that deduplicates on message ID will collapse them back down.
Takeout splits big exports. You pick a maximum archive size when you request the export, and anything larger is broken into several files. Download every part. A single missing part means missing mail, not a damaged file.
The MBOX format sets no size limit at all. Every limit you hit comes from somewhere else: the drive it sits on, or the program reading it.
Search this question and you will be told 4 GB. That number is real, but it is not a rule of the format. Knowing where it comes from tells you whether a large MBOX file is actually a problem for you.
| Limit | Size | Applies when |
|---|---|---|
| The MBOX format | No file size limit | Never. The format is a text stream with no length field |
| A FAT32 drive | 4 GB per file | Most USB sticks and SD cards straight out of the packet |
| Thunderbird before version 12 | 4 GB per folder | Old profiles and old backups only |
| Your computer's memory | Varies | A tool that loads the whole file at once rather than streaming it |
Thunderbird used a 32-bit number to record where each message sat in the file. That ran out at 4 GB, so a folder simply stopped growing.
Mozilla widened it to 64 bits and shipped the change in Thunderbird 12. The bug is marked verified and fixed, so the hard cap is long gone.
The honest footnote came from Mozilla's own developers afterwards. Folders over 4 GB were only really supported on the newer message store, and the default mbox store still had rough edges. Treat 4 GB as the point where a Thunderbird folder becomes worth splitting, not as a wall.
Copying to a USB stick is where most people meet the 4 GB limit. The file is fine and the drive is fine. FAT32 simply cannot hold a single file that large, whatever the file contains.
Format the drive as exFAT or NTFS and the same copy works. We cover the exact symptoms in MBOX file too large over 4 GB to move or import.
The other size problem is memory rather than storage. Some programs read the whole MBOX file into memory before showing you anything, and on a large file that stalls or crashes. It is the failure described in MBOX MemoryError or hang on a large file.
One number does work in your favour. MBOX is text, so it compresses hard. Zipping an archive you are keeping rather than reading usually cuts it by well over half.
Windows has no built-in handler for MBOX, so double-clicking does nothing. Outlook cannot open one either, in any version. You need a program that understands the format.
Use this when you have been handed an MBOX file and want to know what to reach for before you download anything.
If Outlook is where the mail has to end up, reading is not the job. The file has to become a PST (Personal Storage Table) file first, because that is the only mail container Outlook imports.
One thing to rule out before blaming the file. When a program says it found nothing to import, the usual cause is that it was pointed at a folder rather than at the file itself. That is covered in no valid MBOX files found on import.
MBOX trades safety for simplicity. One file is easy to copy, easy to read and easy to compress. It is also one file that two programs can fight over.
Every mail storage format answers the same question: one file or many? MBOX says one. Everything good and bad about it follows from that single choice.
| MBOX | Maildir | EML | PST | |
|---|---|---|---|---|
| Messages per file | The whole folder | One | One | The whole mailbox |
| Readable as text | Yes | Yes | Yes | No |
| Needs file locking | Yes | No | No | Yes |
| Random access to one message | No, reading is sequential from the top | Yes | Yes | Yes, it is indexed |
| Damage spreads | Yes, past the damaged point | No, one message | No, one message | Yes |
| Also holds calendar and contacts | No | No | No | Yes |
Maildir gives every message its own file, inside three folders named tmp, new and cur. A message is written into tmp first and only then moved, so a reader never sees a half-written message.
The designer's stated goal was no locks. Two programs can read and deliver at the same time without either one waiting. The format also stays reliable over a network drive, which is exactly where MBOX gets into trouble.
The cost is thousands of tiny files. That is fine for a mail server and awkward for a person who wants to email one archive to somebody.
You are archiving and moving. One file per folder, readable in thirty years, compresses to a fraction of its size and is accepted by almost every mail program.
The mailbox is live and busy. Or it sits on a network drive. Or you need to pull out single messages often. Those are the cases MBOX handles worst.
MBOX files rarely rot on their own. They break when two programs write to one file at the same time, when a copy is cut short or when a text editor rewrites the line endings.
Knowing the cause matters, because three of these four are things you can simply stop doing.
Because the whole folder is one file, two programs touching it at once is a real risk rather than a theoretical one. Unix systems grew several locking mechanisms to prevent it, and they do not agree with each other.
There are fcntl locks, lockf locks and plain dot lock files. The dot lock files exist because the other two are unreliable over a network file system, or NFS. That is the single best argument for not keeping a live MBOX mailbox on a network drive.
Corruption does not have to mean the whole file. MBOX is read from the top, so a broken message stops everything after it. The messages before it are intact, which is why splitting a damaged file at the From lines recovers far more than people expect.
A specific message on screen is far more useful than a general worry. These are the ones that come up most often with MBOX files.
| What you see | What it usually means |
|---|---|
| No valid MBOX files were found | The importer was pointed at a folder, or at an Apple Mail package, instead of the file inside it. See the no valid MBOX files error |
| 0x80004005 NS_ERROR_FAILURE | A Thunderbird folder whose index no longer matches the MBOX file. See MBOX error 0x80004005 |
| Mac error -36 | A read or write that failed part way, often on an external or network drive. See Mac error -36 on an MBOX file |
| 0x80070057 invalid parameter | A folder path longer than Windows will accept, common after unzipping a deep export. See MBOX 0x80070057 invalid parameter |
| OVERQUOTA or maximum mailbox size | The server refused the upload, so the MBOX file itself is not the problem. See MBOX IMAP OVERQUOTA errors |
MBOX has one standard, RFC 4155. It registers the media type rather than the format, and everything else is thirty years of convention.
You do not need this section to open or fix anything. It is here because it explains why MBOX behaves the way it does.
.mbox, and often no extension at allapplication/mbox, registered by RFC 4155 in 2005From and a spaceMail transfer was standardized early and thoroughly. Mail storage never was. It was left to whoever wrote the program, and for twenty-five years every program made its own choices.
RFC 4155 arrived in 2005 and did something narrower than people assume. It registered application/mbox as a media type so mbox data could be labelled correctly when sent between systems. The Library of Congress states the position flatly: there is no authoritative specification aside from RFC 4155.
That is why the same file can be read perfectly by one program and mangled by another, with neither of them doing anything wrong.
The date on a From line is not the date format used anywhere else in email. It is the output of an old C function called ctime, minus the timezone.
It is always exactly the same length, which is how a parser can trust it. It also carries no timezone at all, so it tells you when the server received the message in UTC and nothing about where the sender was.
The proper Date: header inside the message is the one with the timezone. When the two disagree, that header is the one to believe.
Software patches. The git format-patch command writes its output as an mbox file, and git send-email sends it to a mailing list.
The reason is neat. A patch and an email are both headers followed by text. So a thread of review comments and the patch itself can travel in one file that any mail program can already read.
Two questions sort out most of what is left. Answer them in order.
Is it really one file? An Apple Mail export is a package that Windows shows as a folder. Point your program at the mbox file inside it, not at the folder.
Does it read MBOX at all? Outlook and the Windows Mail app never have. Section 8 lists what does, and reaching for the wrong program is the most common reason a good file looks broken.
Seeing a named error instead? The MBOX file error fixes cover each one on its own page, and the Mozilla Thunderbird errors guides deal with the program most people are using when they meet one.
Ready to migrate this mail somewhere else? The Outlook Data File (.pst) guide explains what Outlook needs, and OST file format covers the cached copy Outlook keeps beside it.
Found something here that does not match what you are seeing? Send us the exact wording on screen and we will check it against the standard.