SMTPUTF8: what RFC 6530-6533 and IDNA define

Register an address like 用户@例え.jp, or write a Subject: header in Cyrillic without extra encoding, and the original email standards have nothing to say. SMTP and the message-header format were fixed decades before Unicode was standard practice, and they assumed 7-bit ASCII everywhere it mattered.

ASCII-only by design

The original SMTP and message-format standards restrict mailbox names, domain names, and header values to 7-bit US-ASCII. That works for anyone whose name and address fit inside 128 characters of English text, and shuts out everyone else. A user in Tokyo, Moscow, or Riyadh whose name doesn't transliterate cleanly into ASCII has no standard way to use it as a mailbox name or see it rendered correctly in a header.

This isn't a display problem a mail client can paper over on its own. The limit sits inside the protocol: SMTP commands like MAIL FROM and RCPT TO were specified as ASCII strings, and RFC 5322 headers inherited the same constraint. Fixing it meant extending the transport protocol itself, not just the software rendering the message afterward.

What RFC 6530-6533 define

Four RFCs, published together in 2012, cover internationalized email as one set: the scope of the problem, the SMTP extension, the header change, and how a bounce reports a non-ASCII recipient.

RFC 6530 is the framework and overview document. It defines the scope of "internationalized email addresses" and introduces the term SMTPUTF8, the capability the other three RFCs build on.

"Full use of electronic mail throughout the world requires that (subject to other constraints) people be able to use close variations on their own names (written correctly in their own languages and scripts) as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses."

RFC 6531 defines the actual SMTP extension: how a client and server negotiate SMTPUTF8 support during the EHLO exchange, and how that negotiation lets UTF-8 appear directly in MAIL FROM and RCPT TO without any ASCII-safe encoding.

RFC 6532 extends MIME and message headers to permit UTF-8 directly. That reduces, without eliminating, the need for RFC 2047's older encoded-word syntax: a header can carry UTF-8 text as-is once both ends of the exchange support it.

RFC 6533 defines how a delivery status notification (DSN) carries a non-ASCII original recipient address, so a bounce for an internationalized address stays a valid, parseable DSN in its own right.

IDNA: encoding domain names separately

RFC 6530-6533 cover the mailbox side: the local part and the headers. The domain part is a separate concern with its own RFC family. RFC 5890 through RFC 5894, known as IDNA2008, define how a non-ASCII domain name gets encoded into the ASCII-compatible xn-- (Punycode) form DNS stores. DNS itself never adopted UTF-8 at the wire level, so a domain name has to become an ASCII string before a resolver can look it up. IDNA defines that encoding.

How it works

Negotiation happens once, at the start of the SMTP session. During EHLO, a server that supports internationalized mail advertises the SMTPUTF8 keyword in its response. A client that also supports it can then send MAIL FROM and RCPT TO with UTF-8 characters directly, tagged with the SMTPUTF8 parameter, and header values, per RFC 6532, may likewise carry UTF-8 without falling back to ASCII-safe encoding.

The domain part of an address is handled independently. If it's non-ASCII, it gets encoded to its xn-- Punycode form for DNS lookups, since DNS stays ASCII-only at the wire level regardless of whether SMTPUTF8 was negotiated on the SMTP side. Both encodings can be in play on the same address: a UTF-8 local part next to a domain whose actual DNS lookup runs on Punycode.

If a message to a non-ASCII recipient bounces, the resulting DSN uses RFC 6533's encoding to carry that original recipient address, so the bounce message stays a valid, parseable notification rather than breaking on the same ASCII assumption that caused the original problem.

Anatomy

SMTPUTF8 negotiation:

IDNA domain encoding:

RFC 6532 header change: a header value that would otherwise need RFC 2047 encoded-word syntax (=?UTF-8?B?<base64>?=) can instead carry UTF-8 text directly, once both sides of the exchange support it. RFC 2047 syntax still applies wherever that support isn't present.

Worked example

A client and server negotiate SMTPUTF8 and exchange a message with a non-ASCII recipient:

220 mx.example.jp ESMTP ready
EHLO mail.sender.example
250-mx.example.jp Hello mail.sender.example
250 SMTPUTF8
MAIL FROM:<sender@sender.example> SMTPUTF8
250 OK
RCPT TO:<用户@例え.jp>
250 OK

The 250 SMTPUTF8 line in the EHLO response confirms the server accepts the extension. MAIL FROM carries the SMTPUTF8 parameter, and RCPT TO uses the UTF-8 recipient directly, without needing any encoding on the mailbox side.

The domain's DNS lookup is a separate step, using the Punycode form, xn--fsqu00a.xn--zckzah, not the Unicode 例え.jp a person reads. A resolver looking up the MX record for this domain queries the xn-- form. SMTPUTF8 support on the sending and receiving servers has no bearing on that lookup.

Where support still breaks down

SMTPUTF8 only works end to end if every hop along a message's path supports it. One relay in the chain that doesn't understand the extension forces either a rejection or a fallback, and no standardized, universal downgrade path exists for that case. It's one of internationalized email's real deployment gaps, more than a decade after these RFCs were published.

Most major mailbox providers now accept non-ASCII local parts. Support outside a handful of large providers stays uneven. The standard covers a fully internationalized address end to end; not every intermediary along the route implements it.

Check it yourself

Look up the MX record for a domain with a non-ASCII name and see the Punycode form DNS returns:

dig +short MX 例え.jp

The result comes back as the domain's xn-- form, the domain-side IDNA encoding working independently of any mailbox-side SMTPUTF8 support. DNS never sees the Unicode label, only its ASCII-compatible encoding.

Where it fits

RFC 6531 extends the base transport protocol. See SMTP (RFC 5321) for the command sequence it builds on. RFC 6532 touches the same headers covered in message format (RFC 5322 and MIME). For the full standards landscape, see the reference hub.

FAQ

Do I need IDNA if I already support SMTPUTF8?

Yes. They cover different layers. SMTPUTF8 lets a mailbox's local part and headers use UTF-8 directly. IDNA is what makes a non-ASCII domain name resolvable in DNS at all, since DNS itself stays ASCII-only.

What happens if one server in the delivery path doesn't support SMTPUTF8?

The message either gets rejected at that hop or needs a fallback path, and no standardized universal downgrade exists. Full SMTPUTF8 support requires every hop along the route to support it.

Does SMTPUTF8 replace RFC 2047 encoded-words?

Not entirely. RFC 6532 allows UTF-8 directly in headers when both ends support it, which reduces the need for encoded-word syntax, but RFC 2047 still applies wherever SMTPUTF8 or RFC 6532 support isn't present.

Can I use a non-ASCII email address anywhere today?

Not reliably everywhere. Most large mailbox providers now accept non-ASCII local parts, but support is uneven, and a message can still hit a non-supporting relay somewhere along its path.

RFC reference

RFCs covered: RFC 6530, RFC 6531, RFC 6532, RFC 6533, RFC 5890-5894 (IDNA2008). Superseded / updated by: None for RFC 6530-6533. RFC 5890-5894 (IDNA2008) obsoletes the earlier IDNA2003 family, RFC 3490-3492.