MIME structure of an email: multipart/alternative, the plain-text part and encodings

What it is

An email is a header block followed by a body; MIME lets the body be a tree of parts, each with its own Content-Type. A message with text and HTML versions uses multipart/alternative. RFC 2046 requires the parts to be placed in increasing order of preference, with the preferred format last, so text/plain comes first and text/html last; clients display the last part they can render. Inline images sit in a multipart/related wrapper around the HTML part; attachments go in an outer multipart/mixed. Bodies with non-ASCII bytes declare a Content-Transfer-Encoding: quoted-printable for mostly-ASCII text (encoded lines are limited to 76 characters with soft breaks) or base64 for binary. Header fields such as Subject and display names cannot carry raw UTF-8 in classic mail; RFC 2047 encoded-words (=?utf-8?q?...?=, at most 75 characters each) wrap them.

Why it matters

Mail without a text part, with a text part that says "view this in an HTML client", or with a subject whose umlauts arrive as question marks reads as spam to filters and to people. Most templating bugs live at this layer: escaping, encoding and line length, not the copy.

How to apply

• Generate the plain-text part from the same data as the HTML rather than by stripping tags: headings as lines, links as label: URL, tables as lists. Keep both templates in one place so a change to one is a change to both.
• Build messages with the platform's MIME library (for example Python's email package); never concatenate boundaries by hand.
• Escape every variable inserted into the HTML part with the same rules as for web pages, and keep the text part free of HTML entities.
• Let the library pick quoted-printable for text and base64 for attachments; keep source lines short, because the message format (RFC 5322) limits lines to 998 characters and recommends 78.
• Route non-ASCII subjects and display names through encoded-words; test with a name containing umlauts and an emoji.
• Use absolute HTTPS URLs and inline CSS; external stylesheets and scripts are ignored or blocked by mail clients.

Pitfalls

A text part written once and forgotten when the HTML changes. Alternative parts in the wrong order, so text-preferring clients show the wrong one. Charset declared as UTF-8 while the bytes are Latin-1. multipart/related images without Content-ID references, which arrive as attachments. Tracking redirectors in the text part, where the raw URL is what the reader sees.