What this RFC defined
RFC 5337 extended the Delivery Status Notification (DSN) and Message Disposition Notification (MDN) formats to support internationalized email addresses. Before RFC 5337, DSN messages could not correctly represent non-ASCII addresses in their structured fields, which was a gap as EAI deployment began in the late 2000s.
Where you would have seen it in practice
In early internationalized email deployments, if a message sent to a UTF-8 address failed to deliver, the bounce message generated by the receiving server needed to include the original internationalized address in the DSN. RFC 5337 defined how to do this for that transitional period before the complete EAI suite was finalised.
How it connects to other RFCs
RFC 5337 was part of the early EAI standardisation effort and extended RFC 3464 (DSN format). It was obsoleted by RFC 6533, which is the current standard for internationalized DSN and MDN. RFC 6533 superseded both RFC 5337 and the equivalent MDN extension in a single, consolidated update.
Current status
RFC 5337 was obsoleted by RFC 6533 in 2012. New implementations should reference RFC 6533 for internationalized delivery notifications. RFC 5337 is retained as a historical reference documenting the evolution of EAI standardisation during its early development phase.
Internationalized DSNs and MDNs
RFC 5337 defined how DSNs (delivery status notifications) and MDNs (message disposition notifications) work with the internationalized email extensions (RFC 6531 SMTPUTF8 and RFC 6532 headers). When an email address contains non-ASCII characters, the corresponding status reports need to carry those addresses correctly without ASCII-encoding them. RFC 5337 specified the encoding rules and extended the report format to accommodate international addresses.
Superseded by RFC 6533
RFC 5337 was updated and largely subsumed by RFC 6533 in February 2012, which is now the current standard for internationalized delivery reports. The concepts are the same; RFC 6533 integrated errata and clarifications. If your implementation references RFC 5337, it is not broken but new work should target RFC 6533. Both documents extend RFC 3464 (DSN) and RFC 8098 (MDN) with internationalization support.
Practical relevance
Internationalized email is still relatively niche in 2026: most email addresses use ASCII, and the SMTPUTF8 extension is not universally supported. However, when it is used (Japanese, Chinese, Cyrillic, or other non-Latin domains and mailboxes), correct DSN handling matters for bounce processing. If your MTA supports SMTPUTF8, it should also implement RFC 6533-style DSNs to avoid producing bounces that fail to identify the failed recipient correctly.
RFC 5337 (September 2008), updated by RFC 6533 (2012), defines Internationalization Extensions for DSN and MDN: how DSN (Delivery Status Notification) and MDN (Message Disposition Notification) handle internationalized email addresses per SMTPUTF8. Introduces new SMTP extension keyword UTF8SMTP (later renamed SMTPUTF8) and defines how DSN/MDN report failures for UTF-8 addresses. Companion to the SMTPUTF8 ecosystem; ensures international mail bounces produce actionable diagnostic reports.
RFC 5337 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Extend DSN and MDN for internationalized email addresses |
| Status | Historical (experimental); updated by RFC 6533 (2012) |
| Companion RFCs | RFC 6531 SMTPUTF8, RFC 6532 internationalized headers |
| Applies to | DSN (per RFC 3464) and MDN (per RFC 8098) |
| Key concept | UTF-8 addresses in Original-Recipient, Final-Recipient, and other DSN/MDN fields |
| Published | September 2008 |
| Superseded by | RFC 6533 (February 2012) |
Changes from RFC 5337 to RFC 6533
| Aspect | RFC 5337 (2008) | RFC 6533 (2012) |
|---|---|---|
| SMTP extension keyword | UTF8SMTP | SMTPUTF8 (renamed for consistency) |
| Status | Experimental | Standards track |
| ORCPT parameter | Introduced; UTF-8 form | Same, refined |
| DSN report format | UTF-8 in Original-Recipient, Final-Recipient | Same, with new address-type utf-8 |
| Downgrade path | Defined for legacy DSN receivers | Same |
The ORCPT parameter with UTF-8 addresses
Downgrade path for legacy DSN receivers
Common internationalized DSN mistakes
用户@example.com as recipient and delivery fails, the DSN should report Final-Recipient: utf-8;用户@example.com. ASCII-folding to something like Final-Recipient: rfc822;?@example.com loses information; the sender cannot identify which recipient failed.Related standards and further reading
- RFC 6531 SMTPUTF8 Guide: base SMTPUTF8
- RFC 3464 DSN Guide: bounce message standard
Frequently asked questions
Should I reference RFC 5337 or RFC 6533?
RFC 6533 for current work. It superseded RFC 5337 in 2012, renamed the SMTP extension keyword from UTF8SMTP to SMTPUTF8 for consistency, and moved from experimental to standards track. RFC 5337 remains valid for historical reference; the semantics carried through to RFC 6533 largely unchanged.
What happens to a bounce when the recipient has an international address?
Depends on peer support. If both sender and receiver support SMTPUTF8 and RFC 6533, the DSN preserves the UTF-8 address in Original-Recipient and Final-Recipient using address-type utf-8. If the DSN is generated by a legacy intermediate MTA, the address may be downgraded to A-label form (for the domain) or lost (for a non-ASCII local-part). Well-designed downgrade paths per RFC 6533 minimize information loss.
Does every MTA supporting SMTPUTF8 need to implement RFC 6533?
Strongly recommended. An MTA that advertises SMTPUTF8 but produces DSNs that mangle UTF-8 recipient addresses is providing a broken experience. RFC 6533 defines the correct DSN behavior for internationalized addresses. Modern MTAs (Postfix, Exim, Sendmail, Microsoft Exchange) implement SMTPUTF8 with proper DSN handling.
What is the difference between address-type rfc822 and utf-8 in DSN?
The address-type in Original-Recipient and Final-Recipient specifies how to interpret the address string. rfc822 means ASCII per RFC 5322 addr-spec. utf-8 (introduced by RFC 5337 and refined by RFC 6533) means UTF-8 per SMTPUTF8. Parsers must handle both; utf-8 addresses need Unicode-aware normalization for comparison.
Are internationalized DSNs common in 2026?
Growing but still niche. SMTPUTF8 adoption is uneven; mailboxes with non-ASCII local-parts remain rare outside East Asia, Cyrillic-speaking regions, and Arabic-speaking regions. Where adopted, RFC 6533-compliant DSN handling is essential for actionable bounce processing. Bounce-handling infrastructure at large senders should be tested with SMTPUTF8 samples to catch parser issues before they cause data loss.
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.
