Sample EML and MSG email files — free download
Email fixtures for importers, parsers, archivers and migration tooling: RFC 5322 .eml as Gmail, Thunderbird and Outlook export it, a real Outlook .msg written as an OLE2 compound file with MAPI properties, an Apple Mail .emlx, a Unix mbox and an MHTML web archive. Every address uses the reserved example.test domain and every person in them is invented.
19 ready-made email test files
| File | Size | What it catches | |
|---|---|---|---|
| missing-required-headers.eml | 103 bytes | Parsers that assume Date and Message-ID always exist, and ones that only split the header block on CRLFCRLF. Both are extremely common assumptions. | download |
| empty-body.eml | 273 bytes | Readers that assume every message has content. A subject-only message is legitimate and common for calendar and notification mail. | download |
| plain-text.eml | 337 bytes | Baseline for any .eml parser. Confirms header parsing, CRLF handling and that the body is separated by exactly one blank line. | download |
| spoofed-display-name.eml | 410 bytes | Phishing display. Any client that shows only the display name presents this as coming from [email protected], when the actual address is [email protected]. The single most common real-world phishing pattern. | download |
| unicode-headers.eml | 427 bytes | Header decoding. A client that prints the raw =?UTF-8?B?...?= instead of the decoded text, or mangles the display name in a reply. | download |
| quoted-printable.eml | 535 bytes | Quoted-printable decoding. Catches decoders that mishandle soft line breaks (a trailing =) or fail to unescape =XX sequences. | download |
| threaded-reply.eml | 551 bytes | Conversation threading. Clients that thread on subject alone will group this wrongly; ones that ignore References will orphan it. | download |
| html-multipart.eml | 593 bytes | Clients that pick the wrong alternative, or render the HTML part as literal text. Also catches parsers that stop at the first part. | download |
| attachment-tricky-filename.eml | 643 bytes | Filename sanitising on save. The name decodes to a double-extension file, which is exactly the pattern used to disguise executables. Also catches parsers that only understand the simple filename="..." form. | download |
| web-archive.mht | 689 bytes | MHTML handling. Same MIME container as email, which is why mail parsers often accept it and why it is a recurring vector for smuggling HTML past filters that only inspect the outer content type. | download |
| with-attachment.eml | 693 bytes | Attachment extraction: base64 decoding, filename parsing, and handlers that assume every part is text. | download |
| winmail-tnef.eml | 695 bytes | The classic "why did I receive winmail.dat" bug. Catches clients that surface the TNEF blob as an unreadable attachment instead of decoding the attachments inside it. | download |
| apple-mail.emlx | 742 bytes | Apple Mail import and migration. The leading byte count and trailing plist break every tool that assumes a .emlx is just an .eml, which is the usual reason Mail exports fail to import elsewhere. | download |
| inline-image-cid.eml | 774 bytes | Inline-image rendering. Catches clients that show the image as a separate attachment instead of inline, and HTML sanitisers that strip cid: references. | download |
| forwarded-nested.eml | 864 bytes | Recursive parsing. Catches extractors that treat the nested message as opaque text, and anything that does not recurse into message/rfc822 when scanning attachments. | download |
| dkim-spf-headers.eml | 1007 bytes | Header-chain parsing and authentication display. Useful for testing code that surfaces SPF/DKIM/DMARC results, and for checking that a long Received chain is folded and read correctly. | download |
| long-folded-headers.eml | 1.0 KB | Header unfolding. Catches parsers that read one physical line per header, truncate at 78 characters, or lose recipients after the first fold. | download |
| mailbox.mbox | 1.1 KB | mbox splitting. A parser that splits on every line starting with "From " will corrupt the third message; one that never unescapes ">From " will silently alter the body text. | download |
| outlook-message.msg | 6.5 KB | Outlook-specific handling. A .msg is a property bag, not a mail format, so no RFC 5322 parser can read it. Opens in Outlook and parses in extract_msg. Also a second OLE2 fixture, sharing its container with legacy .doc and .xls. | download |
Every file is generated from source — no third-party copyright — and each has its own page with a published SHA-256 you can verify after download.
Questions
Where can I download a sample .eml file?
Pick any .eml in the table below. The plain-text one is the smallest starting point; the multipart, inline-image and attachment files exercise progressively more of a MIME parser. All of them use CRLF line endings and a fixed date, so the bytes never change between downloads.
Where can I download a sample Outlook .msg file?
The .msg below is a genuine MAPI message in an OLE2 compound file, not an .eml with the extension changed. It opens in Outlook and parses with extract_msg, and the property streams carry the sender, recipients, subject and body as Outlook itself writes them.
What is the difference between .eml and .msg?
.eml is the raw RFC 5322 message: plain text headers followed by a MIME body, and almost every mail client can read it. .msg is Microsoft-specific and structurally unrelated, a compound binary document holding MAPI properties in named streams. Code that handles one will not handle the other.
Do you have an email with an attachment for testing?
Yes, several. One carries a straightforward attachment, one uses an inline image referenced by Content-ID, and one has a filename built to break naive extraction: RFC 2047 encoding, a path separator and a double extension.
How do I test email header parsing?
The set below covers headers folded across many lines, RFC 2047 encoded-word subjects in non-Latin scripts, quoted-printable bodies, a threaded reply with In-Reply-To and References, a forwarded message nested as message/rfc822, DKIM and SPF headers, a message missing headers the RFC requires, and a spoofed display name whose visible sender does not match the real address.
Is the personal data in these emails real?
No. Every name, address and phone number is invented, the domains are all under example.test, which IANA reserves for exactly this purpose, and no message can be delivered anywhere.