Email Address Internationalization: SMTPUTF8 and EAI in Practice

Addresses like 佐藤@例え.jp are valid email. How EAI and SMTPUTF8 work, who supports them, and what sending systems break when a Unicode address shows up.

For most of email's history, an address had to be ASCII: no accents, no scripts beyond Latin, no exceptions. That constraint excluded the native writing systems of most of the world's population, and the fix has existed since 2012 as a set of RFCs collectively called Email Address Internationalization. A decade on, the mailbox providers largely support it, and the long tail of sending infrastructure largely does not. This article covers how EAI works and where your stack probably breaks.

Two problems, two mechanisms

Internationalized domains were solved first and separately. IDNA encodes Unicode domain labels into ASCII punycode (例え.jp becomes xn--r8jz45g.jp), so the DNS never had to change and any mail system can route to an internationalized domain by using the encoded form. If only the domain is non-ASCII, ordinary email works today with no special support.

The local part, everything left of the @, has no such encoding trick: 佐藤@example.jp cannot be punycoded, because the local part belongs to the receiving server, not to DNS. EAI (RFC 6530 and companions) solves it directly: messages may carry UTF-8 in envelope addresses and headers, and a sending server asks permission by checking whether the receiving server advertises the SMTPUTF8 extension. No advertisement, no transmission; the message cannot be silently downgraded to ASCII because no faithful downgrade exists.

1> EHLO sender.example.com
2< 250-mx.receiver.jp
3< 250-SIZE 52428800
4< 250-SMTPUTF8          <- receiver supports EAI
5< 250 STARTTLS
6> MAIL FROM:<info@example.com> SMTPUTF8
7> RCPT TO:<佐藤@例え.jp>
8> ...

The support landscape

Gmail has accepted and sent EAI mail since 2014, Outlook.com followed, and the major MTAs (Postfix, Exim, and the commercial gateways) all implement SMTPUTF8. India's government-driven adoption push made Hindi-script addresses a real user population, and registrars in China, Russia, and the Arabic-speaking world operate internationalized mailbox services. The receiving side of the internet is substantially ready.

The sending side is the patchwork. ESP support ranges from full to none, often undocumented until a support ticket forces the question. Web frameworks ship email validation regexes that hard-reject non-ASCII local parts. CRMs store addresses in columns with ASCII collations, form libraries strip what they cannot validate, and analytics pipelines choke on what the form let through. The practical consequence: a user with an internationalized address usually cannot even sign up, and when they can, some downstream system mangles the address into an undeliverable string.

Authentication and EAI

The authentication stack survives internationalization better than folklore suggests. SPF, DKIM, and DMARC all operate on domains, which resolve through punycode exactly as before; a DKIM d= tag uses the ASCII-encoded domain and validates normally. Headers in EAI messages may be raw UTF-8 rather than MIME encoded-words, which older parsing code mishandles, and DMARC aggregate report tooling occasionally stumbles on UTF-8 local parts in report data. Test your parsing path, but expect the protocol layer to hold.

What senders should actually do

The right investment depends entirely on your market. A German B2B SaaS will encounter internationalized local parts rarely; a consumer product in India, China, Thailand, or Russia will meet them as a real user segment. In both cases the floor is the same: do not corrupt what you receive. Storing addresses as UTF-8, validating with a library that understands EAI instead of a homegrown regex, and failing gracefully with an honest error beats silently truncating a user's identity.

EAI is what infrastructure transitions look like from the middle: the standards are done, the biggest players moved, and the remaining friction lives in ten thousand codebases that validate email with a regex from 2009. You do not have to lead this transition. You do have to stop your stack from being the hop that breaks it, because the users it excludes will never appear in your metrics as anything but absence.