May 2, 2026

How EML files are structured

An EML file is just a saved email message. If you open one in a text editor, it can look noisy at first, but the structure is fairly predictable once you know what to look for.

Most EML files follow the same basic shape:

Header-Name: header value
Another-Header: another value

Message body starts here

The blank line matters. Everything before it is metadata about the message. Everything after it is the message content. When the email includes HTML, plain text, images, or attachments, that content is usually split into MIME parts.

The top-level headers

Headers describe the message. These are the fields email clients, servers, spam filters, and testing tools use to understand where the message came from and what it contains.

Common headers include:

  • From: the sender shown to the recipient.
  • To, Cc, Bcc: recipients.
  • Subject: the email subject.
  • Date: when the sender says the message was created.
  • Message-ID: a unique identifier for the message.
  • Reply-To: where replies should go.
  • Content-Type: the format of the body.
  • MIME-Version: usually 1.0 for MIME messages.

For example:

From: Example App <noreply@example.com>
To: Jane <jane@example.com>
Subject: Reset your password
Date: Sat, 02 May 2026 10:30:00 +0000
Message-ID: <reset-123@example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8

Click the link below to reset your password.

This is a simple plain text email. There are no attachments, no HTML version, and no multipart structure.

Header folding

Long header values can be folded across multiple lines. A folded line starts with a space or tab, and it is still part of the previous header.

Subject: This is a very long subject line that continues
 onto the next line

Email parsers unfold that into one value:

Subject: This is a very long subject line that continues onto the next line

This is one reason EML files can look strange when viewed as raw text. Line breaks inside headers are not always new fields.

The body

After the blank line, the body begins.

If the email is plain text, the body is straightforward:

Content-Type: text/plain; charset=utf-8

Hello Jane,

Your verification code is 123456.

If the email is HTML, the body contains HTML markup:

Content-Type: text/html; charset=utf-8

<html>
  <body>
    <p>Your verification code is <strong>123456</strong>.</p>
  </body>
</html>

Most production emails include both text and HTML so clients can choose the best version to display.

MIME parts

MIME is what lets an email contain more than one kind of content. A typical modern email may include:

  • A plain text version.
  • An HTML version.
  • Inline images.
  • Attachments.
  • Nested messages.

When an email has multiple parts, the Content-Type header usually starts with multipart/ and includes a boundary.

Content-Type: multipart/alternative; boundary="abc123"

The boundary separates each part:

--abc123
Content-Type: text/plain; charset=utf-8

Your verification code is 123456.

--abc123
Content-Type: text/html; charset=utf-8

<p>Your verification code is <strong>123456</strong>.</p>

--abc123--

The final boundary has -- at the end, which marks the end of the multipart section.

Common multipart types

There are a few multipart types you will see often:

  • multipart/alternative: multiple versions of the same message, usually text and HTML.
  • multipart/mixed: a message with attachments.
  • multipart/related: HTML content with related inline resources, such as embedded images.

These can be nested. For example, an email with text, HTML, inline images, and a PDF attachment may have a multipart/mixed wrapper, with a multipart/alternative section inside it, and a multipart/related section inside that.

That nesting is normal. It is also why raw EML files can become difficult to read by hand.

Attachments

Attachments are also MIME parts. They usually include a filename, content type, transfer encoding, and encoded content.

--boundary123
Content-Type: application/pdf; name="invoice.pdf"
Content-Disposition: attachment; filename="invoice.pdf"
Content-Transfer-Encoding: base64

JVBERi0xLjQKJcfs...

The file content is often base64-encoded so it can safely travel through email systems that expect text. A parser decodes that content back into the original file.

For testing, the most useful attachment fields are usually:

  • Filename.
  • Content type.
  • Size.
  • Content ID for inline attachments.
  • Decoded file content if you need to compare it.

Encoded words and charsets

Headers and bodies can use different character encodings. You might see a subject line like this:

Subject: =?UTF-8?B?UmVzZXQgeW91ciBwYXNzd29yZA==?=

That is an encoded header value. Email clients decode it before showing the subject.

Bodies also define a charset:

Content-Type: text/plain; charset=utf-8

If the charset is missing or wrong, special characters can render incorrectly. This is one of the common reasons an email looks fine in one client and broken in another.

Why EML structure matters

Understanding EML structure helps when you need to debug:

  • Missing or incorrect recipients.
  • Broken HTML rendering.
  • Plain text fallbacks that do not match the HTML version.
  • Attachments that arrive with the wrong filename or content type.
  • Email clients showing the wrong part of a multipart message.
  • Tests that fail because they read the wrong body or miss a delayed attachment.

If you are testing email flows, it is often not enough to check that an email arrived. You usually want to inspect the subject, recipients, body, headers, and attachments in a repeatable way.

How to save an email as EML

Most email clients can save the original message source. The wording differs, but you are usually looking for an option like Save As, Download message, Show original, or Raw Message Source.

For example, in Apple Mail you can open an email and use File > Save As..., then choose Raw Message Source as the format. That saves the message as an EML-style raw email file, including the headers, MIME boundaries, body parts, and attachment data.

Other clients use similar flows:

  • Gmail: open the message menu and choose Download message.
  • Outlook: use Save As when available, or download/export the message from the desktop client.
  • Thunderbird: use Save As > File.

If the saved file opens in a text editor and starts with headers like From, To, Subject, Date, or Message-ID, you are looking at the raw message format described above.

Inspecting an EML file

You can open an EML file in a text editor, but it gets tedious as soon as MIME boundaries and attachments are involved.

If you just want to inspect a message, use the Mailisk EML viewer. It parses the EML file in your browser, shows the headers, text body, sanitized HTML preview, attachments, and MIME parts, and does not upload the file to a server.

Wrap-up

An EML file is not a special binary format. It is a raw email message saved to disk: headers first, a blank line, then the body. MIME adds the structure needed for HTML, plain text, inline assets, and attachments.

Once you understand those pieces, raw emails become much easier to debug, especially when you are building or testing email workflows.

Ready to start testing emails?
Create a free account.

Get started