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

EAI digest: the SMTPUTF8 SMTP extension, UTF-8 headers, the no-downgrade rule, error codes, and what an ESP must decide about accepting and delivering internationalized addresses.

Foundationalesp-operatorsender

The EAI (Email Address Internationalization) suite lets email addresses and headers carry raw UTF-8: 用户@例え.jp as a working mailbox. RFC 6530 is the framework, RFC 6531 the SMTP extension (SMTPUTF8), RFC 6532 the message-format changes; RFC 6533 covers internationalized DSNs. The suite obsoletes the experimental RFCs 4952/5336/5504. For an ESP the core question EAI forces is operational: do you accept internationalized recipient addresses, and can you deliver to them end-to-end?

Terminology (RFC 6530)

All-ASCII address vs. non-ASCII (i18n) address — the latter has at least one non-ASCII character in local part and/or domain.
Conventional message: strictly RFC 5322-conformant. Internationalized message: uses EAI extensions and is no longer RFC 5322-conformant — it exists only inside an SMTPUTF8-negotiated channel.
Domains were already internationalizable via IDNA (RFC 5890–5894) A-labels (xn--… Punycode) — that works without EAI. What EAI adds is UTF-8 in the local part (which has no ASCII-compatible encoding at all) and native U-labels plus 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 mid-path. The working group abandoned this: interoperability failures, unauthenticated address-pairing security concerns, and complexity. RFC 5321's rule that "the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part" makes any transit rewriting of local parts unsafe.

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

The SMTP extension (RFC 6531)

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

Relay/fallback rules and error codes

An SMTPUTF8-aware client that cannot negotiate SMTPUTF8 with the next hop MUST NOT transmit an internationalized address or a message with internationalized headers at any MIME level. An MSA may transform the message at submission; a relay SHOULD reject or generate a non-delivery notification (per RFC 3464/6533).

Enhanced code	Meaning	Typical basic codes
`X.6.7`	Non-ASCII addresses not permitted for that sender/recipient	550, 553
`X.6.8`	UTF-8 reply required but client did not declare SMTPUTF8 support	252, 550, 553
`X.6.9`	UTF-8 header message cannot be transferred to one or more recipients — message rejected	550
`X.6.10`	Deprecated (duplicate of X.6.8)	—

Rejection points: 553 at RCPT / 550 at MAIL where ASCII-only is required; 554 after DATA when recipients can't accept internationalized headers.

Message format changes (RFC 6532)

Adds UTF8-non-ascii to VCHAR, ctext, atext, qtext, text, dtext — i.e., raw UTF-8 becomes legal in unstructured fields (Subject), address local parts, domains, comments, and quoted strings. Header field names remain ASCII-only.
The 998 line-length limit becomes 998 octets (multi-byte characters count per octet); the 78 "should" limit stays in characters (it's about display width).
Normalization: NFC SHOULD be used; NFKC SHOULD NOT (it can merge distinctions needed to spell names). RFC 6530 adds: support normalized forms at least NFC on the receiving side, and never depend on senders to normalize; C0 controls prohibited, U+0008 (backspace) 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 permitted, but staying ASCII is advised for In-Reply-To:/References: threading with non-EAI parties.
message/global media type: an encapsulated message with UTF-8 header values (the EAI analog of message/rfc822). Unlike other message/* types, any content-transfer-encoding is permitted (relaxing RFC 2045 §6.4); 8bit/binary recommended where allowed, and it MUST get a 7-bit-safe encoding if handed to a 7-bit system. Used in RFC 6533 DSNs to return internationalized originals.

Deliverability and operational implications for an ESP

All-or-nothing delivery path. You can deliver to user@例え.jp (A-label domain, 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 doesn't offer it, the only compliant outcomes are reject-at-submission or bounce.
Provider support is uneven. Gmail and Outlook.com accept SMTPUTF8 inbound and Gmail advertises it outbound; many corporate gateways, smaller MTAs, and downstream tooling do not. An ESP accepting EAI recipients needs per-destination capability handling and a clear bounce classification (X.6.7/X.6.9) when the path doesn't exist.
Whole-stack audit, not just the MTA. RFC 6531's security section is explicit: logging, trouble-ticket, suppression, and tracking systems must store full UTF-8 addresses (or a defined ASCII mapping) or data is silently lost. Add to that list: signup-form validation regexes, deduplication (normalize with NFC before comparing), VERP encoding, bounce parsers (expect RFC 6533 utf-8 address types), and one-click unsubscribe URL encoding.
Authentication is unaffected in principle — SPF/DKIM/DMARC operate on domains, which have A-label forms — but DKIM-sign after any endpoint downgrade/transformation, and signed or encrypted content can never be up/downgraded without breaking signatures (RFC 6530 flags S/MIME/PGP explicitly).
Homograph/confusable risk: internationalized From-domains and local parts widen the phishing-lookalike surface (see brand protection); receivers apply extra scrutiny to mixed-script addresses.
A defensible minimal posture for an ESP without full EAI support: accept IDN domains in A-label or U-label form (convert to A-label for SMTP), reject non-ASCII local parts at list import/API with a clear error, and document it. Accepting EAI addresses you cannot deliver to just manufactures bounces.