Drop in the .eml or .emlx files a mail client exports and read them the way a mailbox would show them: the rendered body with its images, every header, the authentication verdicts the receiving server recorded, and the attachments, inline images included. Every file is parsed in your browser, with no signup and nothing uploaded.
Drop the .eml or .emlx files here
Read entirely in this browser and never uploaded. Up to 5 MB per file.
Create a free Unspam account to save your results and re-run these checks anytime, so you catch a broken setup before it costs you. No credit card.
An EML file is one email message saved as a file: the headers, the body and every attachment, in the plain-text format mail servers pass between themselves (RFC 5322, with the body structured as MIME). Nearly every client exports it. Gmail writes one when you choose Download message, Thunderbird when you save a message, Outlook on the web when you download a message, and Apple Mail stores the same thing inside a thin wrapper called .emlx, which this tool also reads. The catch is opening one: double-clicking hands it to whatever mail client the machine has, which is often none, and the file itself is unreadable by eye because the parts arrive base64 or quoted-printable encoded, in whatever character set the sender chose. A viewer's job is to decode all of that faithfully, and to say so when it cannot, because the person opening a saved message is often trying to find out what really arrived.
The rendered tab is the message as a mailbox would draw it: the HTML part, with inline images resolved from the file itself. The raw tab is the file exactly as saved, encodings and all. When something looks wrong, the raw source is the evidence, because it is the one view nothing has interpreted.
The SPF, DKIM and DMARC badges are read from the Authentication-Results header, which means they are the receiving server's verdicts at the moment of delivery, not this tool's opinion. A message saved from a sent folder never carries them, because no receiver has touched it yet.
Every server that handled the message stamped a Received header on top of the stack. Read here in order from origin to mailbox, with the delay each hop added, it shows where a slow message actually spent its time.
HTML mail loads images and styles from the sender's servers, and each of those loads tells the sender the message was opened, from which network, at what time. The rendered view loads them, the way a mailbox with images turned on does, and says so above the message, so reading a saved file is never silent about it. Nothing inside that frame can execute: no scripts, no forms, no further frames.
The operating system hands .eml files to whatever mail program claims the extension, which is often a client you never set up, a stub that demands an account, or nothing at all. Nothing about the file requires a mail client: drop it on this page and it is read where it lies.
Outlook's own save format is .msg, a binary container with a different structure entirely, and renaming one to .eml does not convert it. If a client offers a choice, export as .eml; it is the format everything else can read.
That file is TNEF, the packaging Outlook uses when it sends in its rich-text format, and the real attachments are sealed inside it. The fix is at the sender's end: sending as HTML or plain text instead of rich text makes the attachments arrive as attachments.
Accented characters turning into pairs of symbols means the message declares one character set and carries another. This viewer decodes what the message declares, and when the declaration itself is unreadable it says so above the message rather than guessing silently.
Images embedded in the file are decoded from the file itself, and images hosted on a remote server are fetched as the message is drawn. One that still does not appear is usually no longer on the sender's server, which is ordinary for campaign mail more than a few months old, or is referenced as an embedded part the message never actually carried, which is the sender's bug and not the file's.
Start with the authentication badges above the message. A fail there is the strongest signal a receiver acts on, and the delivery path shows which server handed the message over. The headers tab links straight into the header analyzer for the full verdict-by-verdict readout.
