mbox vs Maildir: Mailbox Storage Formats Explained

mbox and Maildir are the two classic ways a mail server or archive keeps messages on disk. If you have downloaded Gmail through Google Takeout, restored a Thunderbird profile, migrated a Postfix or Dovecot server, or tried to open a backup file with an unfamiliar extension, you have touched one of them — usually without being told which. The difference decides how safely two things can write to the same folder at once, how expensive it is to delete a message, whether a backup can copy the mailbox while mail is arriving, and which desktop apps can actually open the file your export tool just handed you.

This guide sets the two formats side by side, explains how each one lays messages out on disk, and takes the export decision seriously: which format your tool gives you, and what you can realistically open it with. There is a comparison table, a section on where each format wins, a note on Google Takeout, and an honest third option for readers who do not want to manage a mailbox file at all.

The verdict, up front#

For a mail server that receives messages continuously and needs concurrent readers and writers, Maildir is the safer default and has been for over two decades. One-file-per-message means a new message can be delivered while a client is reading a different message in the same folder, without either process holding a lock. Backups can copy the directory while mail is arriving, and a corruption event affects one file, not the folder.

For an archive — a static export you want to move between apps, keep on disk, or attach to an email — mbox is still the format most tools produce and most clients import. One file per folder travels as a single object, compresses well, and is trivial to email or upload. Google Takeout exports Gmail in mbox for exactly that reason.

mbox and Maildir solve different problems. The right question is not 'which is better' but 'which one is on the other end of the pipe I am about to run.' Running the server, pick Maildir. Opening an export, expect mbox and choose an app that can read it.

At-a-glance comparison#

The first row — how each format lays a folder out on disk — causes every other difference in the table. Read it as the cause, and the rest as the effects.

How mbox stores a folder as one file#

An mbox file is a plain text file. Every message in the folder is stored one after another, and the boundary between messages is a line starting with 'From ' — the word From followed by a space, no colon. That single line, called the From_ line, is how any reader locates where one message ends and the next begins. After it come the message's headers, a blank line, and the body. Then another From_ line, and the next message.

The design is old and elegant, roughly as simple as a file format can be. It is why almost every tool that exports mail — Google Takeout, Thunderbird's ImportExportTools NG, most other clients — produces an mbox file. One file is easy to hand you.

Trouble starts as soon as more than one process wants to touch it. Delivering a new message means the mail transfer agent has to take a lock so a concurrent reader does not see a half-written message and run past its own end. Deleting a message in the middle is worse — the classic approach is to mark it deleted, then later compact the file by rewriting it end to end. If anything crashes mid-compact, the whole folder is in a bad state.

Several mbox variants exist — mboxo, mboxrd, mboxcl, mboxcl2 — differing mainly in how they escape body lines that happen to start with 'From '. The variants are a compatibility footnote today; mboxrd is what Google Takeout produces and what most modern tools read and write.

How Maildir stores each message as its own file#

Maildir was designed by Daniel J. Bernstein for qmail in the mid-1990s to fix mbox's locking and corruption problems. Instead of one file per folder, a Maildir is a directory with three subdirectories: tmp, new and cur. Every message is a single file, and its lifecycle is a trip through those three directories.

Delivery: the mail transfer agent picks a unique filename — timestamp, hostname and counter combined — and writes the message into tmp/. When the write completes, it renames the file into new/. On any POSIX filesystem, that rename is atomic: to every other process, the file appears in new/ either fully written or not at all. No half-message state, no lock.

When the mail client opens the folder, it moves the file from new/ into cur/, appending a suffix that encodes the message's flags — ':2,S' for seen, ':2,SR' for seen and replied. Flags live in the filename, so setting or clearing one is a rename — again atomic and lock-free. Deleting a message is deleting one file.

Two processes can deliver mail into the same folder simultaneously without coordinating, because filenames are unique and renames are independent. rsync can walk the directory while mail is arriving and every file it copies is a complete message. A corruption event affects one message, not the folder. Random access is essentially free — the filesystem is the index that mbox has to reconstruct by scanning.

Where mbox genuinely wins#

It would be tidy to say mbox is legacy and Maildir has replaced it. It has not, and pretending otherwise misses why exports keep landing in your inbox as .mbox files.

The first win is portability as a single object. One file is easier to email, upload, download, checksum and compress than a tree with tens of thousands of tiny files. A mailbox with 40,000 messages in Maildir is 40,000 filesystem entries; the same mailbox as an mbox is one. Copying it across a network is dramatically faster, and it survives cloud storage, email attachments, and compressed archives — anything that expects a file rather than a directory.

The second win is universal readability. Because mbox is plain text with a trivial delimiter, almost any language can parse it in a few lines — Python's mailbox module, Perl, Ruby, Go, JavaScript. The registered media type is application/mbox, defined in RFC 4155. Maildir has no registered media type — it is a directory layout, not a file.

The third win is the export decision Google made for you. Takeout produces mbox because a mailbox is a thing you download; downloading a single file is not awkward. Most desktop clients import mbox natively. Very few import Maildir without first converting it or standing up an IMAP server locally. For an archive a human will actually open on a laptop next year, mbox lands in the fewest dead ends.

Where Maildir genuinely wins#

Maildir is what to run on the server, and the reasons are not close. Atomic-rename delivery lets the MTA, the local delivery agent, and any number of IMAP or POP3 clients touch the same folder concurrently without any of them holding a lock. On a busy shared server, that is the difference between mail arriving smoothly and mail queueing behind a stuck writer.

Deletion is the second big win. In mbox, removing a message eventually forces a full rewrite to reclaim space; a large folder with heavy churn spends real I/O compacting itself. In Maildir, deletion is a single unlink() and the space returns immediately. Flags — read, replied, flagged, deleted — live in the filename, so setting one is a rename, not a content rewrite.

Backups behave dramatically better. Because every file in new/ and cur/ is a complete message that arrived via an atomic rename, rsync can walk the directory while mail is being delivered and never see a torn write. Restoring is per-message: a corrupt file loses one message. Snapshotting a live Maildir is safe by construction; snapshotting a live mbox mid-append is risky enough that most operators quiesce the server first.

Maildir scales sideways: nothing in the design cares whether a folder holds a hundred or a hundred thousand messages — the filesystem handles addressing. mbox scans slow down as folders grow because random access walks From_ lines from the front. Dovecot, the most-deployed IMAP server today, supports both and recommends Maildir for exactly these reasons — concurrency, per-message durability, cheap deletes.

The illustration below is the mental model to hang the rest of this on: mbox is one long file the reader has to scan, Maildir is a directory of small files the filesystem indexes for you.

What each format costs to open — and where to check#

Neither format has a licence or subscription: both are open, documented, unpatented. What varies is the cost of the tool you use to open the file or directory — the cost that surprises people who assumed 'it is a standard, so anything can read it.'

For mbox, the free options are excellent. Thunderbird with the ImportExportTools NG add-on imports an mbox file into a local folder. Apple Mail imports mbox natively via File > Import Mailboxes. MailStore Home is free for personal use and reads mbox. On the command line, mutt has spoken mbox since the 1990s. Outlook is the notable holdout — it does not read mbox natively, and the mbox-to-PST converters that fill the gap span a wide range of packaging (free tiers, per-seat licences, one-off usage-metered), so verify on the vendor's own page before committing.

For Maildir, mainstream desktop clients rarely read the directory layout directly. The usual path is to point a local IMAP server such as Dovecot at the Maildir and connect a normal mail client to that server. Command-line clients like mutt and neomutt read Maildir directly. To move mail out of a Maildir into a hand-off archive, doveadm (bundled with Dovecot) exports a Maildir folder to mbox — and that mbox is what you actually give the recipient.

The Google Takeout question#

One of the most common ways a normal person meets an mbox file is by exporting Gmail through Google Takeout. Takeout produces one .mbox file per account, containing every message in every label. Gmail's labels are preserved as an X-Gmail-Labels header inside each message rather than as folders — because mbox has no concept of labels. When you re-import into Thunderbird or Apple Mail, every message lands in a single flat 'All Mail' folder; the labels are still readable in the headers but not shown as folder membership.

That is the trade-off of mbox as an archive: it preserves messages perfectly but flattens the organisational structure your provider layered on top. If keeping label structure matters, some third-party tools parse the X-Gmail-Labels header on import and recreate labels as folders — but you have to reach for one deliberately.

If you expected Maildir out of Takeout because your server runs Maildir, that mismatch is normal. Takeout is an archive path, not a server-migration path.

Who each format is genuinely for#

Maildir is for you if you are running your own mail — Postfix or qmail as the MTA, Dovecot or Courier as the IMAP server — and want a store that survives concurrent access, cheap deletes, and rsync-friendly backups. It is what the operator's manual usually recommends and what most self-hosted mail on Linux runs today. Also for you if you are archiving a live mailbox from the same filesystem, since you can copy while it is still receiving.

mbox is for you if the mailbox is going to leave the machine as a single object — a Takeout download, a folder you are emailing to a colleague, a per-user archive on cheap object storage, a legal-hold export sitting in a compressed archive for seven years. Also for you if the reader on the other end is a normal desktop client with no server behind it, because it almost certainly imports mbox and almost certainly does not import Maildir.

And if you were just handed a .mbox file and do not care about any of this: install Thunderbird, add the ImportExportTools NG extension, and use its 'Import mbox file' option. Shortest path from a downloaded archive to a folder you can search and read.

A third option: not managing a mailbox file at all#

There is a reader for whom neither format is really the answer, because they do not want to be an operator or archivist — they want a modern mail client that syncs, searches and drafts, and they do not want to think about where the bytes sit. For that reader, the third option is not a format: it is a hosted mailbox reached over IMAP, JMAP, Gmail's API or Microsoft Graph, with the storage question delegated to the provider. Under the hood the provider may be running Maildir on Dovecot or a proprietary object store, but you do not see the file — you see the mailbox.

AI Emaily sits in that position. It connects to Gmail, Outlook, iCloud, Fastmail, Proton (via bridge), Zoho and any standard IMAP account through OAuth or app passwords, keeps your mail on the server the way IMAP is meant to, and adds an AI layer on top for triage and drafting. The honest reason to mention it here: if you inherited a folder full of mbox exports, we do not manage those for you — you still want Thunderbird or Apple Mail for the archive itself. But if 'mbox or Maildir' is the first symptom of a bigger question — 'how do I stop babysitting my mail on disk' — a hosted account plus a modern client keeps the storage question out of your week. Nothing sends without your approval in the default mode, and we do not train models on your mail. AI Emaily is a 7-day free trial on Pro (card required, $0 if you cancel before day seven), not a permanent free tier.

For the durable archive side — periodic exports you keep on disk regardless of provider — mbox is still the format we would tell you to save them in. IMAP for daily use, mbox exports for the archive; that pairing gives you sync and a portable long-term copy without the sharp edges of either alone.

The bottom line#

The mbox vs Maildir difference collapses to one question — is this a folder being written to right now, or a folder you are handing off? A live folder wants Maildir: one file per message and atomic renames make concurrency, backups and deletes cheap and safe. A hand-off wants mbox: one file per folder makes the archive a single portable object almost every desktop client can open. Neither is going away, and neither is 'better' outside a specific job.

Choosing for a server, choose Maildir. Opening an export, expect mbox and pick a client that reads it — Thunderbird with ImportExportTools NG is the reliable free path. If the deeper question is 'how do I stop managing mailbox files on a disk at all,' the answer is a hosted account and a modern client that keeps storage invisible.