What this RFC defines
RFC 6522 defines the multipart/report MIME content type, a structured format for email messages that carry both human-readable and machine-readable administrative information. It is the container format used for delivery status notifications (bounces) and abuse reports.
Where you see it in practice
When your ESP shows you a bounce message with a structured breakdown of the delivery failure, the outer message structure is a multipart/report as defined by RFC 6522. It contains at least two parts: a text/plain human-readable explanation and a message/delivery-status machine-readable block. Email processing systems use the machine-readable part to automatically classify bounces by status code without parsing free-form text.
How it connects to other RFCs
RFC 6522 obsoletes RFC 3462. It is used by RFC 3464 (DSN format, which fills the machine-readable part) and RFC 5965 (ARF format, which uses multipart/report for spam complaints). It relies on RFC 2046 (MIME media types) for its multipart container structure.
Current status
RFC 6522 is a current standard, published January 2012. The multipart/report format it defines is universally generated by MTAs for bounce messages and by mailbox providers for FBL complaint reports and has not been superseded.
The multipart/report media type
RFC 6522 defined the multipart/report media type, which is the container used by DSN (RFC 3464), MDN (RFC 8098), and ARF feedback reports (RFC 5965). A multipart/report has a required “report-type” parameter identifying which kind of report it carries: delivery-status, disposition-notification, feedback-report, or others. The body has two or three parts: a human-readable explanation, the machine-readable report content, and optionally the original message or headers.
Why a dedicated media type
Before multipart/report, delivery status information was carried in ad-hoc formats that varied by MTA. Some sent plain text explanations; some sent proprietary XML; some embedded the original message inline. RFC 3462 (later obsoleted by RFC 6522) standardized a single format that all conformant MTAs could produce and parse. This standardization is what makes automated bounce processing possible: any mailing list manager or ESP can parse any DSN from any MTA using the same code.
Parsing considerations
Multipart/report parsing must handle two edge cases carefully. First, the required report-type parameter is sometimes missing or misspelled by older MTAs; robust parsers should attempt to identify the report type from the content-type of the second part. Second, the “original message” part may be truncated, missing, or contain non-standard content; parsers should extract what they can and continue rather than failing on the whole report. These leniency rules are why RFC 6522 explicitly allows partial reports.
RFC 6522 (January 2012) defines the multipart/report MIME type: the container format used by DSN (RFC 3464), MDN (RFC 3798 / RFC 8098), and ARF (RFC 5965). A multipart/report message has a specific three-part structure and carries a mandatory report-type parameter that distinguishes the report family. Obsoletes RFC 3462. This is the wrapper you parse before extracting the actual bounce, read receipt, or complaint payload.
RFC 6522 at a glance
| Aspect | Detail |
|---|---|
| Purpose | MIME container for machine-readable email reports |
| MIME type | multipart/report |
| Required parameter | report-type (identifies the report family) |
| Structure | Three parts: human-readable, machine-readable, original message (or headers) |
| Used by | DSN, MDN, ARF, and future report families |
| Published | January 2012 (obsoletes RFC 3462) |
| Extensibility | New report types register their own report-type value with IANA |
The three-part multipart/report structure
| Part | Content-Type | Purpose | Required? |
|---|---|---|---|
| 1 (human) | text/plain (typical) | Free-form explanation for the recipient of the report | Required |
| 2 (machine) | Depends on report-type | Structured data specific to the report family | Required |
| 3 (original) | message/rfc822 or text/rfc822-headers | Original message or its headers for correlation | Recommended |
The report-type parameter
| Value | Report family | Part 2 Content-Type | Defined in |
|---|---|---|---|
delivery-status | DSN (delivery outcomes, bounces) | message/delivery-status | RFC 3464 |
disposition-notification | MDN (read receipts) | message/disposition-notification | RFC 3798, RFC 8098 |
feedback-report | ARF (abuse complaints) | message/feedback-report | RFC 5965 |
tlsrpt | TLS Reporting | application/tlsrpt+gzip or application/tlsrpt+json | RFC 8460 |
A complete multipart/report envelope
Common multipart/report handling mistakes
Related standards and further reading
- DSN Parsing Guide: practical multipart/report parsing patterns
- Feedback Loops and ARF Guide: complaint report handling
- Content-Type and MIME Structure: parsing multipart bodies
- Hard Bounce vs Soft Bounce: acting on DSN reports
Frequently asked questions
How do I distinguish a DSN from an MDN in my inbox pipeline?
Read the Content-Type of the outer multipart/report envelope. The report-type parameter tells you the family: delivery-status is DSN, disposition-notification is MDN, feedback-report is ARF. Do not rely on Subject line patterns or Return-Path conventions; they vary. The MIME structure is the authoritative signal.
Why does the multipart/report format have three parts instead of just structured data?
Backward compatibility with older mail clients. Part 1 (human-readable) lets a person who receives the report in any mail client understand what happened. Part 2 (machine-readable) is for automated processing. Part 3 (original) allows correlation with the sent message. A pure structured format would be smaller but would break for humans without specialized tooling.
What if a report has more than three parts?
RFC 6522 allows additional parts after the standard three, though this is uncommon. Robust parsers should read parts 1, 2, and 3 by their expected Content-Types and ignore additional parts unless a specific extension defines them. Real-world reports occasionally include extra parts for auxiliary data (signed attestations, extended metadata); these are safe to ignore for basic parsing.
Can multipart/report be signed with DKIM or S/MIME?
Yes. The outer message that carries multipart/report is a normal RFC 5322 email; it can be DKIM-signed like any other message. Report generators sending across trust boundaries (particularly ARF feedback reports and TLS reports) commonly DKIM-sign to allow the recipient to verify authenticity. When present, verify DKIM before acting on the report contents.
What is the difference between message/delivery-status and multipart/report?
message/delivery-status is the Content-Type of the second part inside a DSN’s multipart/report envelope. It carries the structured Action, Status, Diagnostic-Code, and per-recipient fields defined by RFC 3464. multipart/report is the outer container that wraps this structured part together with human-readable text and the original message. You need both to fully parse a DSN.
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.
