← RFC Reference

RFC 6522: Multipart/Report Media Type (Updated)

Why This Exists

Email generates many types of automated reports: bounce notifications (RFC 3464), spam complaints (RFC 5965), authentication failure reports (RFC 6591), and TLS failure reports (RFC 8460). All of these need a common container format that can carry both a human-readable summary and a machine-parseable report.

multipart/report is that container. It was originally defined in RFC 3462, which itself updated RFC 1892. RFC 6522 is the current version, bringing the specification in line with modern MIME registration procedures and clarifying ambiguities from the earlier drafts.

The key changes from RFC 3462 to 6522:

• Updated MIME type registration to follow the current IANA template format
• Clarified that the report-type parameter is required, not optional
• Tightened the specification language to remove ambiguities about part ordering
• Aligned with the updated MIME framework in RFC 6838

How It Works

A multipart/report message is a MIME multipart message with a required report-type parameter that identifies the kind of report inside. It contains two or three MIME parts in a specific order:

1. Human-readable part (text/plain or text/html) — a summary for humans who open the message in a mail client.
2. Machine-readable report — the structured data. The content type depends on the report-type:
   • delivery-status → message/delivery-status (RFC 3464)
   • feedback-report → message/feedback-report (RFC 5965)
   • tlsrpt → application/tlsrpt+json (RFC 8460)
3. Original message (optional) — message/rfc822 (full message) or text/rfc822-headers (headers only) of the message that triggered the report.

Structure Example: DSN Bounce

From: mailer-daemon@mail.example.org
To: sender@example.com
Subject: Delivery Status Notification (Failure)
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
    boundary="REPORT-BOUNDARY-001"

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

Your message to user@example.org could not be delivered.
The mailbox does not exist.

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

Reporting-MTA: dns; mail.example.org
Arrival-Date: Tue, 10 Mar 2026 14:22:00 -0500

Final-Recipient: rfc822;user@example.org
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp; 550 5.1.1 Mailbox not found

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

From: sender@example.com
To: user@example.org
Subject: Invoice #1234
Message-ID: <inv-1234@example.com>

--REPORT-BOUNDARY-001--

Structure Example: ARF Complaint

Content-Type: multipart/report; report-type=feedback-report;
    boundary="ARF-BOUNDARY-001"

--ARF-BOUNDARY-001
Content-Type: text/plain

This is a spam complaint for a message from 203.0.113.10.

--ARF-BOUNDARY-001
Content-Type: message/feedback-report

Feedback-Type: abuse
User-Agent: FBL/1.0
Version: 1
Source-IP: 203.0.113.10

--ARF-BOUNDARY-001
Content-Type: message/rfc822

[original message]

--ARF-BOUNDARY-001--

Key Technical Details

The report-type Parameter

The report-type parameter on the Content-Type header is required and tells parsers what kind of machine-readable data to expect in the second MIME part:

Part Ordering Rules

• The first part must always be human-readable (text/plain or similar).
• The second part must be the machine-readable report with the content type matching the report-type.
• The optional third part contains the original message or its headers. It must use message/rfc822, text/rfc822-headers, or message/global (for internationalized messages).

Internationalization

RFC 6522 adds support for message/global and message/global-headers as alternatives for the third part, accommodating internationalized email addresses and headers per RFC 6531/6532.

Common Mistakes

• Omitting the report-type parameter. Without report-type, parsers cannot determine what the second MIME part contains. RFC 6522 makes this parameter mandatory; always include it.
• Wrong part order. Some implementations put the machine-readable part first. The human-readable part must come first so that mail clients that do not understand the report type still display something useful.
• Parsing only by Content-Type. Do not try to detect report type by scanning the second part's Content-Type. Use the report-type parameter on the outer multipart/report Content-Type — that is what it is for.
• Treating multipart/report as multipart/mixed. While structurally similar, multipart/report has strict part ordering and semantics. A generic MIME parser may display it, but a report processor must respect the defined structure.
• Confusing RFC 3462 and RFC 6522. They define the same content type. RFC 6522 obsoletes 3462. If you see references to RFC 3462 in existing code, the behavior is equivalent — but cite 6522 in new implementations.

Deliverability Impact

• Foundation of all email reporting. Every DSN, ARF complaint, DMARC aggregate report, and TLS failure report uses multipart/report. If your parser cannot handle this container, you cannot process any automated email feedback.
• Bounce processing depends on correct parsing. Your bounce processor must first recognize multipart/report, then check report-type=delivery-status, then extract the message/delivery-status part. Getting any step wrong means missed bounces and degraded list hygiene.
• Complaint loop processing. Feedback loop reports from mailbox providers use report-type=feedback-report. Parsing the container correctly is the first step to extracting complaint data and suppressing recipients.
• TLS reporting. SMTP TLS Reporting delivers JSON payloads inside multipart/report with report-type=tlsrpt. These reports reveal TLS negotiation failures that silently prevent your mail from being delivered securely.

Related RFCs