MSG to EML

A .msg is not a mail message. It is a container — the same little filesystem-in-a-file that a pre-2007 Word document is — holding one stream per property: the subject in one, the sender’s name in another, the body in a third, each attachment in a storage of its own. Nothing outside Outlook opens it, which is why a message forwarded by a colleague can be unreadable on a Mac, on a phone, and to everything else in this section.

So this is a rebuild, not a rename. The container is opened, the properties are read out, and a fresh message is written around them in the format the rest of the world uses. Saying that plainly matters, because the difference shows up later: a rebuilt message is not byte-for-byte what the sender transmitted, and it cannot be.

The headers the message arrived with are kept where Outlook stored them. Outlook keeps the original header block in a property of its own, so the Received chain, the Return-Path and the authentication results survive the conversion intact — which is the part that matters when the question is where a message really came from. What is dropped is the lines describing the body: those referred to the message as it was transmitted, and the body below them has just been written out again.

A DKIM signature will no longer verify. It is kept, because it is evidence that one was there and what it claimed. But the signature covers the body as transmitted, and the body has been rebuilt from properties Outlook decoded years ago. A .msg converter that quietly dropped the header would be hiding this; one that kept it without saying so would be implying a check that will fail.

What comes across: sender, recipients split into To and Cc, the date, the subject, the plain body and the HTML body, and the attachments — base64 encoded, with an image the message refers to by name kept beside the HTML so it still appears in place rather than arriving as a stray file.

What does not, and is named rather than guessed at. A message whose body exists only in Outlook’s compressed rich-text format is not read: that format is a compression scheme of its own wrapped around a word-processor format, and this tool says so instead of handing you an empty message. Nor is an attachment that is itself a whole message rather than a file. And where the sender is recorded as an internal directory name — the /O=EXCHANGE… string an office sees for its own colleagues — there is no address to write, so the From line carries the display name alone rather than an address somebody invented.

Once it is an .eml, the rest of this section will read it: the words on their own, or the message as a document.

A colleague forwards quarterly-report.msg, 74 KB, and it will not open on anything you own. Choose it and press Convert the message.

You get quarterly-report.eml, and a result panel reading Recipients 1, Attachments 1. Opened in a text editor, the top of the file now reads From: Dana Okonkwo <dana@example.org>, To: Accounts <accounts@example.com>, Date: Tue, 4 Mar 2025 09:12:44 +0000, a subject written as an encoded word because it has an em dash in it, then the Received line the message actually arrived with. Below that, a plain part in quoted-printable and the attachment in base64.

The date is written in UTC rather than in your own time zone. Outlook stored it in UTC, so converting it would have put the location of whoever ran the conversion into a file about somebody else’s correspondence.

Now a harder one. internal-thread.msg came from an office mailbox, and after converting it the panel lists one thing under what could not be carried over: the sender is stored as an internal directory name rather than an address. The From line reads Dana Okonkwo with no angle brackets. That is the truth about the file — Exchange never wrote an address into it — and the alternative would have been to make one up.

If the message came from a Gmail export instead, it is already .eml and needs none of this. The four extensions and which is which are set out in the piece on why not to upload one.