Every Email File Format Explained And Which One You Have

Two questions sort every email format there is. Does the file hold one message or a whole mailbox. Was its structure published or kept private. Answer those two and you know how portable your file is, what software will read it and what you stand to lose if you move it somewhere else.

People rarely go looking for an email format. One arrives attached to a job that has to be finished today. The only real question is what to do with it. Start by working out which of them you are holding, because every decision after that follows from the answer.

Formats are not protocols. IMAP, POP3 and Exchange describe how mail moves between machines. MBOX, PST and EML describe how it sits on a disk once it arrives. A mailbox can use any protocol and still be stored in any format, which is the single commonest confusion in this whole subject.

The Two Questions That Sort Every Mail Format

The formats look like a long unrelated list until you place them on two axes. Sorted that way, a format you have never seen still tells you what it will and will not do.

The top left corner is where mail goes when it needs to outlive the program that made it. The bottom right is where mail lives while a specific program is looking after it. Most migration work is a move from the second to the first and back again.

How to Tell Which Format You Have

The extension is a hint rather than an answer, because it is only a label the operating system reads. The bytes at the start of the file are the actual evidence.

If nothing on that list matches, the file is probably not mail at all. A ZIP that is not an OLM, a database from some other application or a renamed archive all turn up regularly in folders labelled backup.

Age is the other clue, useful when an archive arrives with no context at all. A format cannot predate the software that invented it, so the date on the folder rules some answers straight out.

Formats That Hold a Single Message

These four store one message each. They are the formats you want when mail has to be read by someone else, quoted in a document or kept for a long time, because none of them needs a particular program to make sense.

EML

An EML file is a message written to disk exactly as it arrived, header block first and body underneath, with nothing separating them but the empty line the standard requires. The structure is RFC 5322, the same specification the message obeyed while it was in transit. No container is placed around it and no field is removed.

Attachments ride along inside it, encoded as base64 so that binary files survive a channel built for text. That is why EML travels so well. Any mail client, any platform, any decade. The awkward part is never the file itself but the folder around it, which is where EML runs into trouble at volume. It is also why a large mailbox in EML form is unwieldy, since forty thousand messages means forty thousand files and a file system that has to think about all of them at once.

MSG

MSG is what Outlook produces when a message is dragged out of it. Underneath it is a compound file, a small structured container rather than text, which is why a plain editor renders it as mostly noise.

The reason the format exists is that Outlook stores properties an ordinary message has no field for. Categories, flags, follow up reminders, voting buttons and the internal address book entries behind a sender. MSG keeps those. Any other format drops them, which is what people mean when they say something was lost in conversion.

Those extra fields are MAPI properties, named for the Messaging Application Programming Interface that Outlook and Exchange are built on. Inside the file each one gets a stream named after its number, which is why so little software can read an MSG. It is the thread running through three formats on this page. MSG carries MAPI properties for one message. PST and OST are MAPI stores holding many. Anything outside that family has nowhere to put them.

EMLX

Apple Mail introduced EMLX with OS X 10.4 in 2005. The Library of Congress format registry describes it as three parts in one file.

MHT

MHT is a web archive rather than a mail format, though it turns up constantly in mail work. It bundles a page and everything the page needs, images and stylesheets included, into a single MIME document. Saving a message as MHT gives you something that opens in a browser and looks right without any attachments going missing.

TNEF, The winmail.dat Problem

TNEF is not a mail format so much as a wrapper Outlook sometimes puts around one. When Outlook sends a message in Rich Text Format to somebody whose client has never heard of TNEF, the formatting and every real attachment get packed into a single file called winmail.dat. That is what the recipient sees instead of the invoice or the photograph they were promised.

The fix belongs to the sender. Nothing the recipient does is a proper solution, because the attachments are intact inside the wrapper but the message was addressed in a format their software cannot unpack. Sending as HTML or plain text stops it happening at all. A winmail.dat already in your inbox can be opened. Tell the sender anyway, since otherwise the next one arrives exactly the same way.

Formats That Hold a Whole Mailbox

These six hold many messages in one file, usually with the folder structure as well. That convenience is exactly what ties them to the software that wrote them.

Mail/
  Inbox
  Sent
  Clients/
    Acme
    Globex

archive.pst
  └ Inbox
  └ Sent
  └ Clients
      └ Acme
      └ Globex

Inbox/
  new/
  cur/
  tmp/
Sent/
  new/
  cur/
  tmp/

MBOX

An MBOX is a plain text file holding many messages one after another, divided by a separator line rather than by any index. It is the oldest format on this page and the least structured, which is both why almost anything can read it and why it has so many quirks. It is also the one most people now hold without knowing, because a Gmail export through Google Takeout arrives as MBOX. There is a full explanation of MBOX and its four variants if you are holding one.

PST And OST

A PST is Outlook's own container on Windows, short for Personal Storage Table, holding mail alongside contacts, calendar, tasks and notes. It predates Outlook itself, having arrived with Microsoft Exchange Client and Windows Messaging. Despite being a Microsoft format it is not a closed one, since Microsoft publishes the structure and licenses it, which is why software other than Outlook can read a PST at all. There is a fuller account of what a PST actually stores if you are holding one.

Two kinds of PST exist. The older ANSI variant stops at two gigabytes and corrupts as it approaches that ceiling. The Unicode variant that replaced it runs far larger and handles non Latin characters properly. A PST from the early 2000s is likely the first kind, which matters before you try to add anything to it.

An OST is a local cache of a mailbox that lives on a server, built the same way as a PST but bound to the profile that created it. That binding is why copying one achieves nothing. Outlook writes one whenever Cached Exchange Mode is on, which today covers Microsoft 365 and Outlook.com accounts as well as on premises Exchange. Copy an OST to another machine and Outlook there will not touch it, because the profile it belongs to does not exist. That single design decision is behind most of the difficulty people have with OST files.

OLM

OLM is what Outlook for Mac writes when you export an archive. Underneath, per the Archive Team format wiki, it is a ZIP container holding XML and content folders. That makes it far more inspectable than its Windows counterpart.

OLM is an export format, not a storage format. Outlook for Mac keeps its working data in its own database and only produces an OLM when you ask it to. Two things follow. Outlook on Windows has never been able to import one. Microsoft has confirmed that the new Outlook for Mac does not import them either. An OLM in hand is an archive that needs converting before anything can use it.

EDB

An EDB is an Exchange mailbox database, a server side store built on the Extensible Storage Engine rather than a file belonging to any one person. Microsoft describes a mailbox database as the unit mailboxes are created and stored in. Each one of those databases is a single EDB file. A server runs several of them, so an EDB holds many mailboxes without holding all of them.

People meet one when a server is decommissioned and a database is the only surviving copy, which is a recovery job rather than a file you open. On Exchange 2003 and earlier the EDB was paired with an STM file holding native internet content. The two only make sense together. If you have inherited an EDB from that era without its STM, half the mail is missing before you start.

DBX

DBX belongs to Outlook Express, which shipped with Windows for years and has been gone for many more. Each mail folder was one DBX file. The structure was never published, so reading one today means a tool written specifically for it. These turn up in old backups and inherited machines more often than you would expect.

Where Maildir Fits

Maildir belongs on this page even though it is not a file. It is a directory of individual messages, one per file, with names that encode delivery state. It exists because MBOX has no answer for two programs writing at once. A directory of separate files does.

You will meet Maildir on mail servers and on Linux desktops rather than in a folder someone hands you. Mentally it belongs with EML, since both are one message per file. The difference is that Maildir adds a naming convention on top, so the folder itself carries information a container format would otherwise hold inside it.

The practical consequence is that a Maildir cannot be attached to an email or copied as a single item. Anyone handing you one usually hands you a ZIP of it instead, which is why a mail archive that unzips into thousands of numbered files is almost always a Maildir rather than something that has gone wrong.

Formats You Will Meet Less Often

Four more turn up regularly enough in inherited archives to be worth recognising, even though none of them is anybody's first guess.

MBX is the ambiguous one. Published descriptions of it disagree, because Eudora used it, Outlook Express version 4 used it and a UW IMAP variant used it, all for different structures. Anyone telling you an MBX is definitely one of those has skipped a step.

Eudora's version is worth a specific warning. Wikipedia's account of the mbox family records two habits that break naive conversion. Eudora replaces the sender's address in the separator line with the constant ???@???, so the From_ line carries no real address at all. It also pulls attachments out of the message and keeps them in a separate folder beside the mailbox. Convert the MBX on its own and you get mail with every attachment missing. Nothing in the file will tell you they ever existed.

Calendar and contact files are not mail formats. ICS and VCF travel alongside mail and often sit in the same export, but each describes an event or a person rather than a message. They read as attachments in a mail archive and as standalone files everywhere else, which is why a mailbox export can produce them without them belonging to any of the families above.

Which Formats Travel And Which Do Not

Portability is the property that decides how much work a migration will be. It comes down to whether anybody outside the original vendor could write a reader.

Notice that PST sits on the portable side. That surprises people, because Outlook guards it so closely in practice. The format being documented is what makes every third party PST reader possible, including the browser based ones.

What This Means When You Have to Move Mail

Every migration is the same shape. Something wrote your mail into a container. Something else now needs it in a different one. Three things decide how cleanly that goes.

1. What the destination will accept. This is a constraint rather than a preference. Outlook takes PST. Thunderbird and Apple Mail take MBOX. A review platform usually wants individual messages. Exporting to anything else just moves the problem along.
2. What the source format carries that the target does not. Moving from a rich container to a plain one always drops something. Find out what it drops before you start. Discover it afterwards and the original may already be gone.
3. Whether folder structure has to survive. Single message formats have no folders, so the structure has to live in directory names instead. If it matters, check it on the other side rather than assuming.

Once you know which format you are holding, the route is usually short. Our mail converters cover the direct paths between these formats. Every one of them runs in the browser tab, so the mailbox never leaves the machine it is already sitting on. Where the job is reading rather than moving, the viewers take the file as it stands and no conversion happens at all.