← RFC Reference

RFC 3462: Multipart/Report Content Type

Why This Exists

When the DSN (Delivery Status Notification) framework was created in the mid-1990s, the authors needed a MIME container that could carry both human-readable and machine-readable content in the same message. Regular multipart/mixed would work structurally, but it provides no semantic signal that the message is an automated report with a specific internal format.

multipart/report solves this by:

• Signaling to mail clients that the message is an automated report, enabling special UI treatment (many clients display bounces differently from regular mail)
• Including a report-type parameter so parsers know what machine-readable format to expect inside
• Defining a strict part ordering: human-readable first, machine-readable second, original message third

RFC 3462 was the second revision of this spec (after RFC 1892). It was later obsoleted by RFC 6522, which tightened the language and updated the IANA registration. The actual wire format did not change — messages conforming to RFC 3462 also conform to RFC 6522.

How It Works

The multipart/report content type works like any MIME multipart, with added constraints:

Content-Type Declaration

Content-Type: multipart/report; report-type=delivery-status;
    boundary="REPORT-BOUNDARY"

The report-type parameter tells the recipient what kind of report this is. The boundary parameter separates the MIME parts, as with any multipart message.

Three-Part Structure

--REPORT-BOUNDARY
Content-Type: text/plain

; Part 1: Human-readable summary
Delivery to user@example.org failed permanently.
The recipient mailbox does not exist.

--REPORT-BOUNDARY
Content-Type: message/delivery-status

; Part 2: Machine-readable report
Reporting-MTA: dns; mx.example.com

Final-Recipient: rfc822;user@example.org
Action: failed
Status: 5.1.1

--REPORT-BOUNDARY
Content-Type: text/rfc822-headers

; Part 3: Original message headers (optional)
From: sender@example.com
To: user@example.org
Subject: Hello
Message-ID: <msg-001@example.com>

--REPORT-BOUNDARY--

Key Technical Details

Report Types Defined Over Time

When RFC 3462 was published, only delivery-status existed. Later RFCs added more report types that all use the same multipart/report container:

Minimum Parts Required

RFC 3462 requires at least two parts: the human-readable summary and the machine-readable report. The third part (original message) is optional but strongly recommended for DSNs, as it lets the sender identify which message bounced.

Relationship to RFC 6522

RFC 6522 obsoletes this document. The changes are editorial, not behavioral:

• The report-type parameter is explicitly marked as required (3462 was ambiguous)
• The IANA registration template was updated to current standards
• Support for internationalized message types (message/global) was added

If your code already handles RFC 3462 correctly, it handles RFC 6522 too. The wire format is unchanged.

Common Mistakes

• Treating the human-readable part as authoritative. The first part is for display only. Automated systems must parse the second (machine-readable) part. The human-readable text may not match the structured data.
• Assuming only three parts. While most reports have exactly three parts, the spec allows for two (no original message). Your parser should not fail when the third part is absent.
• Ignoring multipart/report entirely. Some bounce processors attempt to parse all bounce messages as free-form text. This works poorly. Always check for multipart/report first and use the structured data when available.
• Not checking the report-type. A multipart/report with report-type=feedback-report is a spam complaint, not a bounce. Treating it as a bounce (and removing the address from your list) is wrong — the address is valid, the recipient just does not want your mail.
• Generating reports without the third part. While technically valid, omitting the original message headers makes it much harder for the sender to identify which message triggered the report. Always include at least the headers.

Deliverability Impact

• All automated email feedback flows through this format. Whether it is a bounce, a spam complaint, a read receipt, or a TLS report, the outer container is multipart/report. Understanding this format is prerequisite to processing any of them.
• Correct bounce classification starts here. By checking report-type first, your system can route delivery-status messages to your bounce processor and feedback-report messages to your complaint handler — two fundamentally different workflows.
• Mail client display. Many mail clients recognize multipart/report and render it specially (e.g., showing a "delivery failed" banner). Generating well-formed reports improves the user experience when your server sends bounces.
• Message-ID correlation. The third part (original message or headers) is how you match a bounce back to the message that caused it. Without it, you are guessing based on recipient address alone, which is unreliable with forwarding and aliases.

Related RFCs