There is a line in every HTML newsletter you have ever received that you have never read. It looks like this:
--=_Part_84721_1938475620.1698765432100It appears again between the parts, and once more at the end with two trailing hyphens. Your mail client strips it out before rendering. Most senders never look at it. And yet that line — the MIME boundary — is the seam at which the plain-text-or-HTML decision actually gets made. Everything upstream of it is a template setting. Everything downstream is a rendering outcome. The boundary is where the writer’s intention is either declared or defaulted.
RFC 2046, published in November 1996, is the document that gave us this structure. It is not a style guide, and it was not written for people who compose newsletters. But read as a writer’s document, it says something useful and slightly uncomfortable: the container disciplines the content. If you want to make deliberate format choices rather than inherit them, it helps to know what the container is actually doing.
What RFC 2046 actually specifies
The specification defines multipart as “data consisting of multiple entities of independent data types,” and among its initial subtypes it names alternative “for representing the same data in multiple formats” (RFC 2046, §3). That is the whole of the mechanism in one sentence. A message can carry more than one rendition of the same content, and the container declares which renditions exist.
Two other definitions in the same document matter for anyone who writes. First, text/plain is described as “plain text containing no formatting commands or directives of any sort,” intended to be displayed “as-is,” requiring “no special software … aside from support for the indicated character set” (§4.1). Second, the default character set, assumed when no charset parameter is given, is US-ASCII (§4.1.2).
Those two facts together explain a great deal of what goes wrong in the inbox. A plain-text part is not a degraded version of the HTML part; the spec treats it as a complete, self-sufficient rendition. And a message that does not declare its character set is, by the letter of the standard, claiming to be US-ASCII — a claim that most contemporary newsletters cannot honestly make.
The container is recursive, and that is the point
RFC 2045, the companion document published the same month, notes that the definitions of message, entity, body part, and body are “clearly circular,” and that this is “unavoidable, since the overall structure of a MIME message is indeed recursive” (§2.6). A part can contain parts. A newsletter with a plain-text body, an HTML body, and an inline logo is not one thing with attachments; it is a tree of containers, each with its own declared type.
This is where platform defaults become visible. When a sending tool decides on your behalf that your message is multipart/alternative nested inside multipart/related nested inside multipart/mixed, it has made three editorial decisions for you: that the text and HTML versions are alternatives to each other, that the images belong to the HTML document rather than standing alone, and that anything else is an independent attachment. Those are reasonable defaults. They are still decisions, and you can read them in the headers.
The practical audit is simple. Open the raw source of a message you have sent — most clients offer a “show original” or “view source” command — and read the Content-Type lines from the top down. Each one names a container and its boundary. The nesting you see is the structure your tool chose. Whether it matches the structure you intended is a separate question, and one only you can answer.
Why the boundary disciplines the content
Here is the constraint that makes the boundary an editorial device rather than a technical formality. The boundary string must not appear inside any of the encapsulated parts. If it does, a parser will split the message at the wrong place, and the reader will see fragments of markup or truncated prose.
This is a structural argument, not a quoted rule from the passages above, but it follows directly from how delimiters work: a delimiter that can occur in the data cannot reliably delimit the data. The consequence for a writer is that you cannot compose the parts in isolation and hope they fit. You have to know the whole message before you write any part of it. The container asks you to hold the entire piece in view — what it says, what it shows, what it carries — and then to divide it deliberately.
That is the opposite of how most newsletter tools work. They invite you to write in a visual editor, then generate a plain-text version by stripping tags. The plain part becomes a residue of the HTML part. The spec permits this. The craft does not recommend it.
Writing the pair, not the fallback
If the plain-text part is written first and written completely, the HTML part becomes an enhancement of an already-finished piece. If the HTML part is written first and the plain part generated from it, the plain part is whatever survived the stripping. Both are legal MIME. Only one of them treats the reader who sees plain text as a reader rather than a failure mode.
A workable sequence, offered as recommendation rather than as anything the RFCs prescribe:
- Draft the plain part as the argument. Write it as you would write a letter. Complete sentences, real paragraphs, links written out in full where they carry meaning. If the piece does not work here, it does not work.
- Treat the HTML part as a second setting of the same text. Headings, emphasis, and layout should clarify the argument, not replace it. If a sentence only makes sense next to an image, the sentence needs rewriting.
- Declare the character set explicitly. RFC 2046 makes US-ASCII the default in the absence of a
charsetparameter (§4.1.2). If your text contains anything outside that range — an em dash, a curly quote, a name with an accent — the default is a false statement about your content. RFC 2049 requires conformant agents to be able to send at leasttext/plainmessages “with the character set specified with the charset parameter if it is not US-ASCII” (§2). Declaring it is a small act of editorial responsibility: it tells the reader’s software what you intended instead of asking it to guess. - Keep the tree as shallow as the message needs. RFC 2045 records that the working group favored “compatibility … over elegance” (§1). That is a useful disposition for a writer, too. A two-part alternative is often enough. Nesting earns its place only when the message genuinely has independent parts — an attachment that stands alone, an image that belongs to the HTML document.
What the history suggests about restraint
MIME was not invented in 1996. RFC 1521, published in September 1993, redefined message bodies “to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information,” and its authors note that MIME “was first defined and published as RFCs 1341 and 1342,” with RFC 1521 a “relatively minor updating” intended to supersede RFC 1341 (RFC 1521, §1). The 1996 documents are a revision of that work, not a fresh start.
What the revision added was not new ambition but clearer structure: the media type system, the conformance criteria in RFC 2049, the explicit statement that the mechanism was designed to be extensible and that the set of types and parameters would “grow significantly over time” (RFC 2046, §1). The designers expected the container to be stretched. They built it to stretch without breaking.
That expectation is worth holding onto. The multipart container is not a constraint to be worked around; it is a structure that anticipates variety. The question for a writer is not whether the format can hold what you want to say, but whether you have chosen the shape deliberately or accepted the one your tool supplied.
The seam is the decision
RFC 5322, the current Internet Message Format specification, is careful about its own scope: it “specifies a syntax only for text messages” and “makes no provision for the transmission of images, audio, or other sorts of structured data,” leaving the MIME series to describe those mechanisms (RFC 5322, §1.1). The header section and the body are separated by an empty line; everything above it describes the message, everything below it is the message. MIME lives in the headers, which means the format decisions are made before the first word of the body is read.
This is the quiet discipline of the container. The boundary line is invisible to readers, but it is the place where the writer’s choices about what the message is made of become fixed. A writer who can read a Content-Type header can see what a sending tool has decided on their behalf. That visibility is the precondition for making a deliberate choice instead of inheriting one.
The inbox is a site of editorial independence, but only for writers who know what their container is doing. The boundary is where that independence is either exercised or defaulted — one line, repeated between the parts, closing with two hyphens at the end.
Questions writers ask
Do I have to send both plain text and HTML?
No. RFC 2046 defines multipart/alternative as a way to represent the same data in multiple formats; it does not require that you use it. A plain-text-only message is a complete message. The choice is yours, and the spec does not rank the options.
What happens if my plain-text part is just a stripped version of the HTML?
Technically, nothing breaks. The message is still valid MIME. But the plain part will read as fragments — headings without context, links without destinations, sentences that referred to a layout that is no longer there. The reader who sees it is reading a residue, not a rendition.
Why does my character set matter if my client handles it automatically?
Because the default is US-ASCII (RFC 2046, §4.1.2), and a message that relies on the default while containing other characters is making a claim about itself that is not true. Declaring charset=utf-8 explicitly removes the ambiguity. RFC 2049 treats explicit charset declaration as part of conformance for non-US-ASCII text (§2).
How do I see what my sending tool actually produced?
Send yourself a test message and use your client’s “show original” or “view source” command. Read the Content-Type headers from the top. The nesting and the boundary strings you see are the structure your tool chose. Compare that to the structure you intended.
Is a deeper multipart tree better?
No. Depth should follow from the message’s actual parts, not from a template’s ambition. A shallow tree that matches the content is easier to read, easier to audit, and less likely to produce the kind of malformed nesting that confuses parsers.
