SMTPUTF8 / Internationalized Email (RFC 6530/6531/6532)

If your subscribers or customers use email addresses written in their own scripts, such as 用户@例え.jp, you have to decide whether your platform accepts those addresses and whether it can deliver to them.

The Email Address Internationalization (EAI) suite lets email addresses and headers carry raw UTF-8, so that an address like that is a working mailbox. RFC 6530 is the framework, RFC 6531 is the SMTP extension (SMTPUTF8), and RFC 6532 covers the changes to the message format. RFC 6533 covers internationalized delivery status notifications (DSNs). The suite obsoletes the experimental RFCs 4952, 5336 and 5504.

For an email service provider (ESP), the core question EAI raises is operational: do you accept internationalized recipient addresses, and can you deliver to them from end to end?

Terminology (RFC 6530)

• All-ASCII address versus non-ASCII (i18n) address: the second kind has at least one non-ASCII character in the local part, in the domain, or in both.
• Conventional message: a message that strictly conforms to RFC 5322. Internationalized message: a message that uses the EAI extensions and therefore no longer conforms to RFC 5322. It exists only inside a channel where SMTPUTF8 has been negotiated.
• Domains could already be internationalized through the A-labels (xn--… Punycode) of Internationalized Domain Names in Applications (IDNA, RFC 5890–5894), and that works without EAI. What EAI adds is UTF-8 in the local part, which has no ASCII-compatible encoding at all, plus native U-labels and UTF-8 header values on the wire.

The pivotal design decision: no in-transit downgrade

The experimental protocol paired each non-ASCII address with an ASCII alternative, and let relays downgrade the message along the way. The working group abandoned this approach because of interoperability failures, security concerns about unauthenticated pairing of addresses, and complexity. The rule in RFC 5321 that "the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part" makes any rewriting of local parts in transit unsafe.

The consequence (RFC 6530 §8): a relay holding a message that requires SMTPUTF8 MUST either negotiate the extension with the next hop or reject or bounce the message, so that the sender can make another plan. There is no partial delivery and no automatic fallback to ASCII. Downgrading, where it happens at all, happens only at the endpoints (at submission or at final delivery).

The SMTP extension (RFC 6531)

• EHLO keyword: SMTPUTF8, with no parameters.
• Request: if the envelope or the message needs the capability, the client MUST add the SMTPUTF8 parameter, which takes no value, to MAIL FROM. Example: MAIL FROM:<用户@example.com> SMTPUTF8 BODY=8BITMIME.
• What it unlocks: UTF-8 in the local parts of MAIL and RCPT, U-label domains in the envelope and in trace fields, and the internationalized headers of RFC 6532 in the content.
• 8BITMIME is mandatory: servers that offer SMTPUTF8 MUST also support and announce 8BITMIME (RFC 6152). SMTPUTF8 is used with BODY=8BITMIME (or BODY=BINARYMIME where it is advertised), because UTF-8 headers are 8-bit data.
• Syntax: atext, quoted-string text, esmtp-values and sub-domains are extended with UTF8-non-ascii. The structure of delimiters in addresses is unchanged.
• Trace fields: a server that supports SMTPUTF8 and adds Received: to an SMTPUTF8 message SHOULD use the U-label form. The new WITH protocol values UTF8SMTP(A/S/SA) and UTF8LMTP(A/S/SA) record the negotiation.
• DSN: a server that advertises both DSN and SMTPUTF8 MUST implement RFC 6533 (delivery status notifications that can carry UTF-8).
• VRFY and EXPN gain an optional SMTPUTF8 parameter, so that the server knows UTF-8 replies are safe.

Relay and fallback rules, and error codes

A client that supports SMTPUTF8 but cannot negotiate it with the next hop MUST NOT transmit an internationalized address, or a message with internationalized headers at any MIME level. A mail submission agent (MSA) may transform the message at submission. A relay SHOULD reject the message or generate a non-delivery notification (as described in RFC 3464 and RFC 6533).

Rejection points: 553 at RCPT or 550 at MAIL where only ASCII is accepted, and 554 after DATA when recipients cannot accept internationalized headers.

Message format changes (RFC 6532)

• The format adds UTF8-non-ascii to VCHAR, ctext, atext, qtext, text and dtext. Raw UTF-8 therefore becomes legal in unstructured fields (Subject), address local parts, domains, comments and quoted strings. Header field names remain ASCII-only.
• The line length limit of 998 becomes 998 octets (a multi-byte character counts once for each of its octets). The recommended limit of 78 stays in characters, because it is about display width.
• Normalization: NFC SHOULD be used; NFKC SHOULD NOT, because it can merge distinctions needed to spell names. RFC 6530 adds: support at least NFC on the receiving side, and never depend on senders to normalize. C0 control characters are prohibited, and U+0008 (backspace) is explicitly forbidden in mailbox names.
• Encoded words (RFC 2047) SHOULD NOT be generated in an internationalized message. Write the UTF-8 directly. (Agents MAY convert encoded words to UTF-8 when quoting older material.)
• Message-ID: UTF-8 is permitted, but keeping it ASCII is advised, for threading through In-Reply-To: and References: with parties that do not support EAI.
• The message/global media type: an encapsulated message with UTF-8 header values, the EAI counterpart of message/rfc822. Unlike other message/* types, any content transfer encoding is permitted (relaxing RFC 2045 §6.4). 8bit or binary is recommended where allowed, and the message MUST get a 7-bit-safe encoding if it is handed to a 7-bit system. It is used in RFC 6533 DSNs to return internationalized originals.

Deliverability and operational implications for an ESP

1. The delivery path is all or nothing. You can deliver to user@例え.jp (an A-label domain with an ASCII local part) with an ordinary stack. You can deliver to 用户@anything only if every hop to the recipient's MX negotiates SMTPUTF8. If the MX does not offer it, the only compliant outcomes are rejection at submission or a bounce.
2. Provider support is uneven. Gmail and Outlook.com accept SMTPUTF8 for inbound mail, and Gmail advertises it for outbound mail. Many corporate gateways, smaller MTAs and downstream tools do not. An ESP that accepts EAI recipients needs to handle capability for each destination, and needs a clear bounce classification (X.6.7 or X.6.9) when no path exists.
3. Audit the whole stack, not only the MTA. The security section of RFC 6531 is explicit: systems for logging, trouble tickets, suppression and tracking must store full UTF-8 addresses (or a defined mapping to ASCII), or data is silently lost. Add to that list the validation regexes of signup forms, deduplication (normalize with NFC before comparing), Variable Envelope Return Path (VERP) encoding, bounce parsers (expect the RFC 6533 utf-8 address types) and the URL encoding of one-click unsubscribe links.
4. In principle, authentication is unaffected. SPF, DKIM and DMARC operate on domains, which have A-label forms. But apply the DKIM signature after any downgrade or transformation at an endpoint. Signed or encrypted content can never be upgraded or downgraded without breaking signatures (RFC 6530 names S/MIME and PGP explicitly).
5. Risk from homographs and confusable characters: internationalized From domains and local parts widen the room for phishing lookalikes (see brand protection). Receivers apply extra scrutiny to addresses that mix scripts.
6. A defensible minimum position for an ESP without full EAI support: accept internationalized domain names (IDNs) in A-label or U-label form (converting them to A-labels for SMTP), reject non-ASCII local parts at list import and in the API with a clear error, and document this. Accepting EAI addresses you cannot deliver to only manufactures bounces.

Related articles

• RFC 5321 (SMTP)
• RFC 5322 (Message Format), the ASCII baseline that EAI extends
• MIME and Encoding, including 8BITMIME and the encoding rules for message/*
• ESMTP Extensions, the negotiation mechanism SMTPUTF8 relies on
• Delivery Status Notifications, a format that RFC 6533 extends for EAI