The email category gives message parsers, importers, and forensic tools real, documented fixtures. The EML set is standards-compliant RFC 822/MIME: a plain-text message, a multipart/alternative message carrying both a text and an HTML body, and a multipart/mixed message with a base64-encoded file attachment — each with full headers (From, To, Subject, Date, Message-ID, MIME boundaries). An MBOX mailbox concatenates a short three-message thread with the classic 'From ' separator lines, so you can test mailbox splitting and thread reconstruction. Every message uses fixed dates, message IDs, and boundaries for reproducibility, and every address and name is fictional. Use them to test header parsing, MIME decoding, attachment extraction, HTML-part sanitising, and EML-to-other-format conversion.
Filter email on Browse · 110 files · 11 subcategories
An email annotated with DKIM-Signature, Received-SPF, and Authentication-Results headers (all reporting pass) — for testing email-authentication header parsing. The DKIM signature value is a sample placeholder, not real cryptography.
The failing twin of the all-pass fixture, headers otherwise identical: SPF fail, DKIM fail with a quoted reason property, DMARC fail under p=REJECT. The quoted reason string contains a semicolon-free phrase specifically to test method-splitting.
The fully authenticated baseline: SPF pass, DKIM pass, DMARC pass with aligned domains, under a p=REJECT policy. The DKIM signature is a visible SAMPLE placeholder, so the header parses and reports pass but will never verify cryptographically.
SPF passes and DKIM passes, yet DMARC fails — because the signing domain is the relay's, not the From domain's, and the policy demands strict alignment. Any dashboard that reports authentication by reading dkim= alone shows this message as trustworthy.
A mailing-list post carrying three Authentication-Results headers stamped by three different hosts, where DKIM passed upstream and failed at the final hop after the list rewrote the message. Only the topmost header, from the receiving host, may be trusted.
Two DKIM-Signature headers for the same message — the RSA/Ed25519 double-signing used during algorithm migrations — with an l= body-length tag on the first. l= means only the first 120 octets are covered, so anything appended afterwards still verifies; both values are SAMPLE placeholders.
A forwarded message carrying a two-instance ARC chain — Seal, Message-Signature and Authentication-Results at i=1 and i=2 — where DKIM broke in transit but ARC records that it passed upstream. Every seal is a visible SAMPLE placeholder, not real cryptography.
RFC 822 message with a text/calendar REQUEST attachment — for calendar invite importers.
Cancel twin for the SAMPLE calendar invite — same UID, SEQUENCE bumped, METHOD=CANCEL.
Standalone SAMPLE iCalendar CANCEL for calendar parsers without MIME wrapping.
Standalone SAMPLE iCalendar REQUEST for calendar parsers without MIME wrapping.
A meeting-invitation email carrying an iCalendar (.ics) VEVENT with METHOD=REQUEST — for testing calendar-invite detection, ICS extraction, and RSVP handling.
A bounce / non-delivery report (NDR) — a multipart/report message with a human-readable notice, a message/delivery-status part, and the original headers — for testing bounce parsing and delivery-status extraction.
SAMPLE delivery/DSN-related .eml (calendar-invite-note) for mailbox parsers.
SAMPLE delivery/DSN-related .eml (out-of-office) for mailbox parsers.
SAMPLE delivery/DSN-related .eml (receipt-mdn) for mailbox parsers.
multipart/report delivery-status SAMPLE with action=delayed for DSN parsers.
multipart/report delivery-status SAMPLE with action=delivered for DSN parsers.
multipart/report delivery-status SAMPLE with action=failed for DSN parsers.
A multipart/report that advertises report-type=delivery-status but is deliberately incomplete: the required message/delivery-status part is missing, leaving only human prose and the returned headers. Real MTAs emit this, and a parser must not assume the part exists.
multipart/report delivery-status SAMPLE with action=relayed for DSN parsers.
One multipart/report carrying two per-recipient blocks: a permanent 5.1.1 failure and a temporary 4.4.7 delay for the same original message. Bounce processors that read only the first block suppress a good address, or keep retrying a dead one.
The same bounce as its twin, except the returned content is text/rfc822-headers — the privacy-preserving form most large providers send. A processor keyed on message/rfc822 finds nothing here and reports an un-attributable bounce.
A bounce whose third part is the complete original message — headers and body — as message/rfc822. Paired with the headers-only twin beside it, it shows whether a bounce processor can recover the original Message-ID from either shape.
A permanent bounce whose extended status is 5.7.1 — rejected by policy — with Remote-MTA, Original-Recipient and Last-Attempt-Date all present. Suppression lists that key on the 5.x class alone blacklist a perfectly valid address over a sender-side problem.
SAMPLE delivery/DSN-related .eml (bounce-mailbox-full) for mailbox parsers.
SAMPLE delivery/DSN-related .eml (dsn-delayed-plain) for mailbox parsers.
SAMPLE delivery/DSN-related .eml (dsn-failed-plain) for mailbox parsers.
A single header whose value is one 1,001-character token with no whitespace, making the line 1,024 octets — past the 998-octet limit RFC 5322 sets and impossible to fold. Fixed-size line buffers truncate here, and the truncation is silent.
A Subject split mid-word across two adjacent encoded-words. RFC 2047 requires the linear whitespace between them to be discarded, so the correct result is one word; a decoder that keeps the space renders a split that reads as a typo.
One unbroken encoded-word of 148 characters, well past the 75-character ceiling RFC 2047 sets. Real senders emit these, and a decoder should still recover the whole word rather than truncating it at 75 or rejecting the header.
A Subject folded across four physical lines, one encoded-word per line, which is the shape RFC 2047 prescribes for long international headers. Because the fold whitespace is discarded on decode, each continuation word carries its own leading space inside the encoded-word — omit that and the subject decodes run-together.
An encoded-word naming a charset no registry knows. The payload happens to be UTF-8, so a decoder has a choice: fall back and show readable text, or leave the raw encoded-word visible. What it must not do is raise and drop the whole header.
Encoded-words used everywhere they turn up in practice: both display names, the Subject, and — against the spec but very common — inside the quoted filename parameter, where RFC 2231 is the conformant mechanism. A tolerant parser decodes all four.
A header line and a body line sitting exactly on the RFC 5322 maximum of 998 octets excluding CRLF. Both are legal, so anything that rejects, wraps, or truncates them is off by one against the spec — this is the reference case for that boundary.
Two headers folded with horizontal tabs instead of spaces, which RFC 5322 permits exactly as it permits spaces. Parsers that test only for a leading space treat the continuation as a brand-new header and lose the second half of the Subject.
An eight-deep References chain folded so each Message-ID sits on its own line. There is no comma between msg-ids in this header, so a parser that splits on the line break rather than unfolding first ends up with ids that carry a leading space.
A single Subject built from three encoded-words in three charsets and two encodings. RFC 2047 allows this, and it is what happens when a subject is quoted through several mail systems, so each word has to be decoded on its own terms.
The ISO-8859-1 Subject again, base64-encoded instead of Q-encoded. Base64 hides the charset entirely, so this is the fixture that catches a decoder guessing the charset from the octets instead of reading the encoded-word's charset token.
A German Subject encoded as ISO-8859-1 'Q', the shape most legacy mail actually uses. Each umlaut is one =XX escape, so a decoder that assumes UTF-8 produces mojibake rather than a clean error.
A Russian Subject as a KOI8-R base64 encoded-word. KOI8-R orders Cyrillic letters by Latin transliteration rather than alphabetically, so a decoder that substitutes any other Cyrillic codepage returns readable-looking but wrong text.
A Japanese Subject as a Shift_JIS base64 encoded-word. Shift_JIS second bytes overlap ASCII punctuation values, so a decoder that scans the decoded octets for delimiters before converting the charset splits the string in the wrong place.
A Subject header carrying accented Latin text and an emoji as a single UTF-8 base64 encoded-word. Its Q-encoded twin decodes to the identical string, so the two together isolate the encoding from the charset.
The same Subject as the UTF-8 'B' twin, written with 'Q' encoding instead: underscores stand for spaces and every non-token octet is an =XX escape. A decoder that forgets the underscore rule produces visibly different text from its twin.
A reply carrying In-Reply-To and References headers — for email thread reconstructors.
A To: header listing 24 addresses, folded after every comma. Address-list parsers that unfold and split in the wrong order produce addresses with a leading space or lose the display name of every recipient after the first.
An email whose Subject uses RFC 2047 UTF-8 encoded-words (café / crème) — for header decoding tests.
SAMPLE .eml focusing on auto submitted header behaviour.
SAMPLE .eml focusing on content language header behaviour.
SAMPLE .eml focusing on dkim signature shape header behaviour.
SAMPLE .eml focusing on list unsubscribe header behaviour.
SAMPLE .eml focusing on priority urgent header behaviour.
SAMPLE .eml focusing on reply to different header behaviour.
SAMPLE .eml focusing on return path header behaviour.
SAMPLE .eml focusing on thread topic header behaviour.
One mailbox whose four messages each use a different charset and alternate between quoted-printable and base64, with RFC 2047 subjects to match. The file itself is LF-stored while the encoded payloads decode to CRLF text — the split every importer has to handle.
Three messages in one mailbox: an original whose body contains both a bare "From " line and an already-escaped ">From " line, the reply that threads to it, and the multipart/report bounce that reply triggered. mboxrd escaping is what makes the round trip lossless.
A larger mbox mailbox with a six-message back-and-forth thread — for testing mailbox splitting, thread reconstruction, and pagination over more than a couple of messages.
A multipart/mixed email with a base64-encoded CSV file attachment — for testing attachment detection, decoding, and extraction from an EML message.
An mbox mailbox concatenating a short three-message email thread with the classic 'From ' separator lines and >From body escaping — for testing mailbox splitting and thread reconstruction.
A multipart/alternative email carrying both a plain-text and an HTML body — for testing MIME part selection, HTML-part handling and sanitising, and multipart parsing.
A standards-compliant plain-text email message (.eml) with full headers — the simplest valid RFC 822 message for testing email header parsing and EML import.
An attachment with a bare Content-Disposition: attachment and no name in either header. A client has to invent a filename, and the extension it invents decides whether the saved file opens as a spreadsheet or as unknown binary.
A base64 text/plain message in utf-8 carrying the identical body to the quoted-printable twin beside it. Base64 is opaque to whitespace and line-start characters, so it is the reference side of the pair when a QP decoder is suspect.
A base64 text/plain message in utf-8 carrying the identical body to the quoted-printable twin beside it. Base64 is opaque to whitespace and line-start characters, so it is the reference side of the pair when a QP decoder is suspect.
A base64 text/plain message in iso-8859-1 carrying the identical body to the quoted-printable twin beside it. Base64 is opaque to whitespace and line-start characters, so it is the reference side of the pair when a QP decoder is suspect.
A base64 text/plain message in utf-8 carrying the identical body to the quoted-printable twin beside it. Base64 is opaque to whitespace and line-start characters, so it is the reference side of the pair when a QP decoder is suspect.
A base64 text/plain message in utf-8 carrying the identical body to the quoted-printable twin beside it. Base64 is opaque to whitespace and line-start characters, so it is the reference side of the pair when a QP decoder is suspect.
A multipart/related message with an HTML body referencing a CID-inline PNG — for email client and MIME parser tests.
A single-part text/html email with no text/plain alternative — edge case for clients that require multipart/alternative.
The same 16x16 PNG appears twice with the same filename: once inline with a Content-ID, once as a plain attachment. Deduplicating by filename or by content hash collapses the pair and loses one of them, which is how an attachment silently disappears.
A forward that embeds the whole original message, headers and all, as a message/rfc822 part — and that original is itself a multipart with its own attachment and threading headers. Extractors routinely stop at the message/rfc822 boundary and miss the nested file.
The alternative parts are ordered richest-first, the opposite of what RFC 2046 requires. A client that blindly takes the last part shows plain text here and HTML everywhere else, which is exactly the intermittent-looking bug this fixture pins down.
Text and HTML alternatives that state different totals and different delivery dates. The spec says the parts must be alternative renderings of the same content, so this fixture shows what a tool extracts when they are not — the answer depends entirely on which part it picks.
A zero-length text/plain alternative next to a real HTML part — the shape produced by senders that add a plain part only to satisfy spam filters. Anything preferring plain text renders a blank message unless it falls back when the chosen part is empty.
The same release notes as plain text, Markdown (RFC 7763) and HTML, ordered least-faithful first. Most selectors only know the plain/HTML pair, so this is the fixture that shows whether an unfamiliar middle part is skipped or mistaken for the body.
Two complete messages carried in a multipart/digest, neither part declaring a Content-Type. RFC 2046 makes the default message/rfc822 inside a digest instead of the usual text/plain, so a parser that hardcodes the text default renders raw headers as body text.
The related container's root is the second part, named by the start= parameter, with an image sitting first. A reader that assumes the first part is always the root displays a PNG as the message body.
The HTML body references a Content-ID that no part in the message provides — the everyday result of a forward that dropped an attachment. A renderer should show the alt text and carry on, not emit a broken external request or fail the whole message.
Two inline image parts, only one of them referenced by the HTML. Attachment counters disagree loudly on this shape: some report one attachment, some two, some none, and the answer changes what a user sees in the message list.
An HTML body referencing two base64 PNG parts by Content-ID, both resolved. This is the baseline for the three related/cid fixtures beside it: everything a cid resolver needs is present and correctly spelled.
Nested MIME (mixed wrapping alternative plus a text attachment) — for deep MIME tree walkers.
A quoted-printable text/plain message in utf-8 whose body carries accented French text, guillemets, an em dash and a euro sign. It is the exact twin of the base64 message beside it: both decode to the same 247 octets, so a decoder can be diffed against a known-equal pair.
A quoted-printable text/plain message in utf-8 whose body starts a line with "From " and holds a lone "." line, which quoted-printable escapes as =46rom and =2E. It is the exact twin of the base64 message beside it: both decode to the same 219 octets, so a decoder can be diffed against a known-equal pair.
A quoted-printable text/plain message in iso-8859-1 whose body is single-byte ISO-8859-1 rather than UTF-8, so each umlaut is one octet. It is the exact twin of the base64 message beside it: both decode to the same 176 octets, so a decoder can be diffed against a known-equal pair.
A quoted-printable text/plain message in utf-8 whose body holds a single line far past 76 columns, forcing quoted-printable soft breaks. It is the exact twin of the base64 message beside it: both decode to the same 451 octets, so a decoder can be diffed against a known-equal pair.
A quoted-printable text/plain message in utf-8 whose body ends lines with spaces and tabs that quoted-printable must encode as =20 and =09. It is the exact twin of the base64 message beside it: both decode to the same 193 octets, so a decoder can be diffed against a known-equal pair.
The conformant answer to non-ASCII filenames: a filename split into three numbered RFC 2231 segments with a charset and a language tag, plus size and creation-date parameters. Parsers commonly handle filename*= but not the numbered continuation form.
Two text/plain parts inside a mixed container, the second marked inline but carrying a filename. Clients split on this: some concatenate it into the body, some list it as an attachment because a filename is present, and the two behaviours look like different messages.
The canonical rich-mail shape written out in full: a mixed container holding a related container holding an alternative pair, plus a CSV attachment at the outer level. A tree walker has to reach depth three to find the HTML body and still report exactly one attachment.
An attachment whose filename uses RFC 2231 UTF-8 encoding (résumé) — for MIME filename decoders.
S/MIME-shaped SAMPLE with a placeholder PKCS7 part (not a real signature) for MIME structure tests.
A reply carrying the Exchange threading headers — Thread-Topic and a SAMPLE Thread-Index — next to the standard References chain, plus an X-MS header with an empty value. Empty header values are legal and are a common cause of parser exceptions.
Simple follow-up SAMPLE message #1 for mailbox threading pads.
Simple follow-up SAMPLE message #2 for mailbox threading pads.
Simple follow-up SAMPLE message #3 for mailbox threading pads.
A References header that lists the same two Message-IDs twice, in a repeating order — what a client produces when it appends without checking. A threader that treats the chain as a literal path builds a cycle or reports a depth of four for a two-deep thread.
The immediate parent named by In-Reply-To was never delivered, but its grandparent is in the References chain. A threader has to fall back up the chain instead of orphaning the message — the everyday case after a deleted or filtered message.
A reply that declares its parent only through In-Reply-To. Threading code that builds ancestry from References alone files this message as a new thread root, splitting a conversation in the message list.
The same reply expressed the other way round: a References chain with no In-Reply-To. Together with its twin it isolates which of the two headers a threading implementation actually reads, since either alone is sufficient under RFC 5322.
Threaded SAMPLE reply at depth 1 with a long References chain and bulky X-headers.
Threaded SAMPLE reply at depth 2 with a long References chain and bulky X-headers.
Threaded SAMPLE reply at depth 3 with a long References chain and bulky X-headers.
Threaded SAMPLE reply at depth 4 with a long References chain and bulky X-headers.
Threaded SAMPLE reply at depth 5 with a long References chain and bulky X-headers.
Threaded SAMPLE reply at depth 6 with a long References chain and bulky X-headers.
Threaded SAMPLE reply at depth 7 with a long References chain and bulky X-headers.
Threaded SAMPLE reply at depth 8 with a long References chain and bulky X-headers.
An HTML newsletter email (multipart/alternative) with a table-based responsive layout and a List-Unsubscribe header — for testing HTML-email rendering, sanitising, and marketing-email parsing.
An order-confirmation / receipt email (multipart/alternative) with an itemised order table in both text and HTML — a transactional-email fixture for testing parsing and data extraction.
No — every address, name, and message is fictional, with fixed dates, Message-IDs, and MIME boundaries for reproducibility.
A plain-text message, a multipart/alternative message carrying both text and HTML bodies, and a multipart/mixed message with a base64-encoded file attachment — each with full RFC 822 headers.
It concatenates a short three-message thread with the classic 'From ' separator lines, so you can test mailbox splitting and thread reconstruction.
Header parsing, MIME decoding, attachment extraction, HTML-part sanitising, and EML-to-other-format conversion.
We use Google Analytics and show ads via Adsterra. Non-essential cookies and ad scripts run only after you allow the matching categories. See our cookie policy.
