What this RFC defines
RFC 6531 defines the SMTPUTF8 SMTP extension, which allows UTF-8 to be used in MAIL FROM and RCPT TO envelope addresses, enabling internationalized email addresses containing non-ASCII characters to be transmitted via SMTP. Servers that support it advertise 250-SMTPUTF8 in their EHLO response.
Where you see it in practice
When your mail server sends an email to an internationalized address, it needs to use the SMTPUTF8 extension to include the UTF-8 address in the MAIL FROM and RCPT TO commands. Without SMTPUTF8, SMTP cannot carry non-ASCII envelope addresses and the message cannot be delivered. MTAs that do not support SMTPUTF8 cannot deliver to internationalized addresses and must downgrade the message.
How it connects to other RFCs
RFC 6531 extends RFC 5321 (SMTP) and is part of the EAI suite alongside RFC 6530 (framework overview) and RFC 6532 (UTF-8 message headers). It builds on RFC 1869 (ESMTP extension framework) for the EHLO advertisement mechanism. RFC 6532 extends message headers to match; RFC 6531 handles the envelope.
Current status
RFC 6531 is a current standard, published February 2012. SMTPUTF8 is supported by Postfix, Exim, and major cloud mail providers. Full EAI deployment requires SMTPUTF8 support across the entire delivery path, which is still in progress globally.
The SMTPUTF8 extension
RFC 6531 defined the SMTPUTF8 extension in February 2012, allowing SMTP envelope addresses to contain non-ASCII characters. A server advertises SMTPUTF8 in its EHLO response; a client that sees this can send MAIL FROM and RCPT TO commands with UTF-8-encoded addresses. Without SMTPUTF8, envelope addresses must be pure ASCII, which means addresses with non-ASCII characters can only be sent to servers that speak SMTPUTF8 all the way through the delivery chain.
Related extensions required together
SMTPUTF8 alone is not enough for full internationalization. Sending a message to alice@例え.jp requires SMTPUTF8 (envelope), 8BITMIME (message body), and RFC 6532 header support at every hop. Without 8BITMIME, the body must be encoded to 7-bit, which is inefficient. Without RFC 6532, the From and To headers cannot carry the UTF-8 address either. Most modern MTAs (Postfix 2.11+, Exim 4.86+, Microsoft Exchange 2016+, Sendmail 8.16+) implement all three together.
Support status in 2026
Major mailbox providers support SMTPUTF8 on inbound: Gmail (since 2014), Outlook.com (partial), iCloud (since 2015), and Yandex have full support. Support on outbound and among smaller providers is more variable. If you send bulk email to addresses with non-ASCII characters, expect some percentage of legitimate addresses to fail delivery due to SMTPUTF8 gaps somewhere in the path. Tracking these failures separately from other bounce categories helps identify the pattern.
RFC 6531 (February 2012) defines SMTPUTF8: an RFC 5321 extension that lets SMTP transport internationalized email addresses containing UTF-8 characters (like 用户@例え.jp or usuário@correo.es). Advertised as SMTPUTF8 in EHLO. Pairs with RFC 6532 (UTF-8 in message headers), RFC 6533 (internationalized delivery status), and RFC 5890 (IDNA 2008 for domains). Deployment is uneven in 2026: mainstream providers support it, but many legacy MTAs and enterprise gateways do not.
RFC 6531 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Transport email addresses with non-ASCII local-parts and domains |
| Advertised as | SMTPUTF8 in EHLO response |
| Requested by | SMTPUTF8 parameter on MAIL FROM |
| Depends on | SMTP session must have advertised SMTPUTF8; message contains UTF-8 headers |
| Companion RFCs | RFC 6532 headers, RFC 6533 DSN, RFC 5890 IDNA |
| Published | February 2012 |
| Deployment 2026 | Gmail, Microsoft 365, Yahoo, iCloud, ProtonMail support; many legacy and enterprise gateways do not |
What SMTPUTF8 allows and requires
| Element | Without SMTPUTF8 | With SMTPUTF8 |
|---|---|---|
| Local-part of address | ASCII only (RFC 5322 addr-spec) | UTF-8 permitted (e.g., 用户) |
| Domain part of address | ASCII (Punycode/A-label for IDN) | UTF-8 directly (U-label for IDN, e.g., 例え.jp) |
| Message headers | ASCII with RFC 2047 encoded-word for non-ASCII | UTF-8 directly per RFC 6532 |
| Message body | Any (MIME-declared) | Any (MIME-declared, unchanged) |
| DSN and MDN reports | ASCII in structured fields | UTF-8 per RFC 6533 |
SMTPUTF8 dialogue example
SMTPUTF8 vs IDNA (Punycode)
xn--. So 例え.jp becomes xn--r8jz45g.jp. SMTPUTF8 allows the U-label (UTF-8) form directly on the wire. Both are valid; the choice depends on whether SMTPUTF8 is negotiated. Sender-side code should be prepared to emit either form.Downgrade paths when SMTPUTF8 unavailable
| Element | Downgrade approach |
|---|---|
| ASCII address | Transmit as-is; no downgrade needed |
| ASCII local-part + IDN domain | Encode domain as Punycode; safe fallback |
| UTF-8 local-part | No standard fallback; delivery fails (permanent 5xx) |
| UTF-8 header (Subject, display name) | Encode with RFC 2047 encoded-word (=?UTF-8?B?…?=) |
| UTF-8 body content | No downgrade needed; MIME handles body encoding |
Common SMTPUTF8 handling mistakes
MAIL FROM:<alice@sender.com> SMTPUTF8 activates it for the transaction. Sending UTF-8 addresses in RCPT TO without the parameter is a protocol error even when both sides support SMTPUTF8.Related standards and further reading
- RFC 6532: Internationalized email headers (UTF-8 in headers)
- RFC 6533: Internationalized DSN and MDN status codes
- RFC 5337: Internationalized DSN and Disposition Notifications
- RFC 5890: IDNA 2008 (internationalized domain names)
- RFC 5891: IDNA 2008 protocol
- RFC 6530: Overview of internationalized email
- RFC 5321: SMTP (base protocol SMTPUTF8 extends)
- RFC 6152: 8BITMIME (prerequisite for SMTPUTF8)
- RFC 5322 Guide: message format that headers extend
- RFC 2047 Guide: legacy encoded-word for non-ASCII headers
- Hard Bounce vs Soft Bounce: for handling SMTPUTF8 downgrade failures
Frequently asked questions
What is the difference between SMTPUTF8 and Punycode?
Punycode (per IDNA 2008) encodes UTF-8 domain names into ASCII with an xn-- prefix, allowing ASCII-only infrastructure to handle international domains. SMTPUTF8 lets SMTP transport UTF-8 directly, without conversion. For domains, both mechanisms coexist: SMTPUTF8 uses UTF-8 U-labels on the wire, IDNA uses ASCII A-labels. For local-parts (before the @), SMTPUTF8 is the only mechanism: local-parts do not have a Punycode equivalent.
Why does SMTPUTF8 require 8BITMIME?
SMTPUTF8 headers contain non-ASCII bytes; some legacy 7-bit-clean transports would corrupt them. RFC 6152 (8BITMIME) ensures the SMTP path preserves all 256 byte values. RFC 6531 explicitly requires 8BITMIME advertisement as a prerequisite for SMTPUTF8; a server advertising SMTPUTF8 without 8BITMIME is non-conformant.
Which mail providers support SMTPUTF8?
Gmail, Microsoft 365, Outlook.com, Yahoo Mail, iCloud, ProtonMail, Fastmail all support SMTPUTF8 in receiving. Sending support varies: most support ASCII local-parts with IDN domains (Punycode); native UTF-8 local-parts have more variable support. Legacy enterprise gateways (older Cisco IronPort, Barracuda, some Symantec appliances) may not support SMTPUTF8 and will bounce UTF-8 local-parts. Test each provider’s actual behavior; advertisement in EHLO does not always match reality.
What happens if I send to a UTF-8 address through a non-SMTPUTF8 MTA?
The sending MTA advertises SMTPUTF8 in EHLO; the next hop does not respond compatibly. Standard behavior: the sending MTA generates a permanent 5xx bounce indicating the address cannot be represented in the downstream path. There is no automatic downgrade for UTF-8 local-parts (no Punycode equivalent exists). This is why deployments in East Asia and other regions with heavy UTF-8 address usage cluster around SMTPUTF8-capable providers.
Should my application support UTF-8 email addresses in signup forms?
Yes for internationalization, but with awareness. Accept UTF-8 addresses per RFC 6531 syntax. Validate with a library that supports internationalized addresses (Python email.utils, JavaScript email-addresses). Preserve the user’s input exactly; do minimal normalization. When sending, verify the delivery path supports SMTPUTF8 (via ESP capability or test send). Provide feedback to the user if their address cannot be reached from your infrastructure.
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.
