What this RFC defines
RFC 2046 defines the MIME media type system: the classification of content into types (text, image, audio, video, application, multipart, message) and subtypes. It introduces the multipart type, which allows a single email message to contain multiple separate content parts, each with its own headers.
Where you see it in practice
The multipart/alternative structure that lets email clients choose between your HTML and plain text versions is defined here. The multipart/mixed type used when you send an email with attachments comes from RFC 2046 section 5.1. When an email client displays an inline image embedded in an HTML email, it is navigating a multipart/related structure as defined in this RFC.
How it connects to other RFCs
RFC 2046 is part of the MIME suite alongside RFC 2045 (framework), RFC 2047 (header encoding), and RFC 2049 (conformance). RFC 2183 extends MIME with the Content-Disposition header for controlling inline versus attachment display. New media subtypes are registered with IANA following the procedures originally in RFC 2048.
Current status
RFC 2046 is a current standard, published November 1996. The media type registry it established continues to grow via IANA registration, but the core multipart structure defined here has not changed.
Multipart structure
RFC 2046 defined the multipart content type, which is what allows an email to contain both a text version and an HTML version, or an HTML body plus attachments, or a mixed set of inline images and text. Each multipart message has a boundary string declared in the Content-Type header (Content-Type: multipart/mixed; boundary=”…”), and the body is split into parts separated by that boundary. Each part has its own headers (Content-Type, Content-Transfer-Encoding) and its own body. This recursive structure lets MIME represent arbitrarily complex documents.
The five multipart subtypes
RFC 2046 defined five multipart subtypes. multipart/mixed is the general case for independent parts (typical for text + attachments). multipart/alternative provides multiple representations of the same content (typical for text + HTML), and the client should render only the last part it can display. multipart/parallel is meant for content that should be rendered simultaneously (rare in email). multipart/digest is a bundle of messages (used for mailing list digests). multipart/related was added later in RFC 2387 for HTML with inline images referenced by cid: URLs.
Boundary handling pitfalls
The boundary string must not appear anywhere in the message body, or parsing fails. RFC 2046 recommends boundaries include random characters to make collision effectively impossible. Poorly-implemented libraries sometimes generate weak boundaries like —=- that legitimately appear in scientific papers or code samples, causing parts to be split incorrectly. Robust implementations generate high-entropy boundaries (typically 20+ random characters). If you see MIME parsing failures on specific messages, boundary collision or malformed boundary syntax is a leading suspect.
RFC 2046 (November 1996) defines the MIME media types: the five top-level types (text, image, audio, video, application) plus the two composite types (multipart, message). Companion to RFC 2045 (which defines the MIME headers) and RFC 2048 (registration procedures). Introduces the multipart structure used by every attachment-carrying email, every HTML+text alternative, every DSN, MDN, and ARF report. Central concept: boundary delimiters separate parts within a multipart body.
RFC 2046 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Define MIME media types and multipart structure |
| Five discrete types | text, image, audio, video, application |
| Two composite types | multipart, message |
| Multipart mechanism | Boundary parameter delimits parts within body |
| Common multipart subtypes | mixed, alternative, related, digest, parallel, report |
| Companion RFCs | RFC 2045 headers, RFC 2047 encoded-word, RFC 2048 registration |
| Published | November 1996 |
The seven top-level MIME types
| Type | Purpose | Common subtypes |
|---|---|---|
text | Human-readable text | plain, html, css, csv, xml |
image | Still images | jpeg, png, gif, webp, svg+xml |
audio | Sound | mpeg, mp4, ogg, wav |
video | Moving images | mp4, webm, ogg, quicktime |
application | Non-textual data (fallback for anything not in the above four) | pdf, octet-stream, json, zip, msword |
multipart | Composite: multiple parts in one body | mixed, alternative, related, report, digest, parallel |
message | Encapsulated message or message-like data | rfc822, delivery-status, disposition-notification, feedback-report |
The multipart subtypes and their semantics
| Subtype | Meaning | Common use |
|---|---|---|
multipart/mixed | Parts are independent, shown in order | Message + attachments |
multipart/alternative | Parts are different representations of same content; recipient picks best-supported | Plain text + HTML pairing |
multipart/related | Parts collectively make one document (HTML + inline images) | HTML email with embedded images referenced by Content-ID |
multipart/digest | Each part is a message; default type is message/rfc822 | Mailing list digests |
multipart/parallel | Parts should be displayed simultaneously (rarely implemented) | Multimedia presentations (obsolete in practice) |
multipart/report | Structured report (DSN, MDN, ARF) per RFC 6522 | Bounce messages, read receipts, complaints |
Multipart body structure
Common multipart mistakes
--boundary-- (note the trailing double-dash). Omitting this makes parsers uncertain where the body ends; strict parsers reject, lenient parsers extend to end of message. Always emit the terminator.multipart/mixed[multipart/alternative[text/plain, text/html], attachment].Related standards and further reading
- RFC 2045: MIME base headers (Content-Type, Content-Transfer-Encoding, MIME-Version)
- RFC 2047: Encoded-word syntax for non-ASCII in headers
- RFC 2048: Media type registration procedures
- RFC 2049: MIME conformance criteria
- RFC 6522: multipart/report (used by DSN, MDN, ARF)
- RFC 2183: Content-Disposition header (attachment metadata)
- Content-Type and MIME Structure: practical multipart parsing
- RFC 5322 Guide: message format that MIME extends
Frequently asked questions
What is the difference between multipart/related and multipart/mixed?
multipart/related declares that the parts together form one document; typically an HTML part references inline images by Content-ID (cid:), and the images are additional parts. Mail clients render the HTML and resolve cid: references to their sibling image parts. multipart/mixed treats parts as independent; attachments are shown separately from the message body. Use multipart/related for HTML with truly inline images (logos in email templates), multipart/mixed for HTML + downloadable attachments.
Should HTML emails always include a plain text alternative?
Yes, per longstanding best practice. Wrap them in multipart/alternative: text/plain part first, text/html part second (recipient shows the last supported part, which is typically HTML). Reasons: mail clients that block HTML rendering (privacy-focused clients, accessibility tools, some corporate policies) fall back to plain text; spam filters prefer messages that offer plain text; some deliverability signals depend on the presence of both parts.
What is the preamble in a multipart body?
Text between the Content-Type header’s empty line and the first boundary. Ignored by MIME-aware parsers. Historically included messages like “This is a MIME-formatted message. If you see this text, your mail reader does not support MIME.” for pre-1996 clients. In 2026 no such clients exist, but the preamble is still legal (and sometimes used for debugging or attribution markers).
Can multipart parts contain nested multiparts?
Yes, arbitrarily deep in theory. A part can have Content-Type: multipart/anything with its own boundary and its own parts, which can themselves be multipart. Common pattern: multipart/mixed outer wrapper containing a multipart/alternative body pair and separate attachment parts. Enforce a reasonable depth limit (typically 10 or fewer) in parsers to prevent zip-bomb style attacks with deeply nested structures.
How long should a MIME boundary be?
Long enough that accidental collision with body content is statistically impossible: 20 or more random characters is standard. Real-world generators typically use 40+ characters with a prefix identifying the generator (e.g., ----=_NextPart_000_1234_A1B2C3D4.E5F6G7H8 for Outlook, ------------random for Thunderbird). RFC 2046 permits 1 to 70 characters but shorter boundaries risk collision; use the maximum reasonable length.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
