What Are Internationalized Email Addresses (EAI)?

The short answer
Internationalized email addresses (EAI) let both sides of an address use non-ASCII Unicode characters — like josé@correo.es or 用户@例子.公司. Defined by the RFC 6530 family and carried by the SMTPUTF8 extension, they only work when every mail server on the path and the recipient's client all support them. Many still don't.
What are internationalized email addresses (EAI)? The RFC 6530 family for non-ASCII local parts and domains — and why they still get rejected.
On this page
Most email addresses are written in plain English letters, but yours does not have to be. Internationalized email addresses — usually shortened to EAI — let people use their own name, in their own script, on both sides of the @ sign. An address like josé@correo.es or 用户@例子.公司 is a valid email address under a set of internet standards published in 2012.
The catch is support. An internationalized address only reaches you if every mail server it passes through, plus the app the recipient reads it in, all understand the standard. This guide covers what EAI is, the RFCs behind it, how it differs from an internationalized domain, and why a signup form still tells you the address is invalid.
What is an internationalized email address?#
An internationalized email address is an address that contains characters outside the old 7-bit US-ASCII set — accented Latin letters, or Cyrillic, Greek, Arabic, Hebrew, and CJK characters — in the local part (left of the @), the domain (right of the @), or both.
The framework that defines this is RFC 6530, 'Overview and Framework for Internationalized Email,' published in February 2012. It replaced an earlier, experimental set of specifications and laid out how non-ASCII text should be carried through the mail system from one end to the other.
How do internationalized email addresses work?#
EAI is not one change but three, each in its own standard. Together they let raw UTF-8 travel from the sender's keyboard to the recipient's screen without being flattened into ASCII along the way.
| Standard | Year | What it does |
|---|---|---|
| RFC 6530 | 2012 | The overview and framework for internationalized email; it obsoletes the earlier experimental specifications (RFCs 4952, 5504 and 5825) |
| RFC 6531 | 2012 | Defines SMTPUTF8 — the EHLO keyword a server advertises to signal it accepts messages with UTF-8 addresses and headers |
| RFC 6532 | 2012 | Extends the RFC 5322 header format so fields like From, To and Subject can carry UTF-8 directly, and defines the message/global media type |
SMTPUTF8 is a per-hop handshake
Why is my Unicode email address rejected?#
Because delivery is end to end, a perfectly valid EAI address can still fail. The address is rarely the problem; some server or program between the sender and the mailbox does not speak the standard, and the weakest link in the chain decides whether a Unicode address survives the trip.
When a server that lacks SMTPUTF8 is handed a UTF-8 address, RFC 6531 tells it to refuse the message rather than guess. On the RCPT command you get reply code 553, and on MAIL you get 550, both with the enhanced status code 5.6.7 — 'Non-ASCII addresses not permitted for that sender/recipient.'
- A signup or checkout form validates the address with an old pattern that only allows ASCII characters
- A legacy relay or spam gateway in the delivery path does not advertise SMTPUTF8
- The recipient's mail app accepts the message but shows the address as mojibake — garbled symbols — or blank

The bounce code to look for
Punycode domain vs Unicode local part#
The two halves of an address are internationalized by different mechanisms, and confusing them is the most common EAI mistake. A non-ASCII domain has been possible for far longer than a non-ASCII mailbox name, because the domain has an escape hatch the local part does not.
That escape hatch is Punycode. An internationalized domain name (IDN) is converted to a plain-ASCII form that begins with the xn-- prefix, so legacy SMTP never sees the Unicode at all. The local part has no such ASCII encoding — it can only travel as raw UTF-8, which is exactly why it needs SMTPUTF8.
| Internationalized domain (IDN) | Unicode local part (EAI) | |
|---|---|---|
| Which side of the @ | The domain, right of the @ | The mailbox name, left of the @ |
| How it travels | Encoded to an ASCII form beginning xn-- (Punycode) | Sent as raw UTF-8; there is no ASCII equivalent |
| Standard | IDNA and Punycode (RFC 5890, RFC 3492) | SMTPUTF8 (RFC 6531) |
| Works on legacy SMTP? | Yes — the wire form is plain ASCII | No — the server must advertise SMTPUTF8 |
| Introduced | Punycode 2003; IDNA2008 in 2010 | The RFC 6530 family in 2012 |
Common misconceptions about EAI#
Because internationalized addresses look ordinary and mostly work, a few wrong assumptions are easy to pick up. These are the ones that lead to broken forms and undelivered mail.
| Common belief | What's actually true |
|---|---|
| Gmail fully supports Unicode email addresses | Gmail can send to and receive from EAI addresses (announced August 2014), but you cannot create a @gmail.com address with non-Latin characters — Google accounts stay ASCII |
| An accented or emoji domain is the same thing as EAI | That is an internationalized domain (IDN), handled by Punycode on the wire. The Unicode local part is the piece that genuinely needs SMTPUTF8 |
| If an address is standards-valid, it works everywhere | It only works if every server on the path and the recipient's client support SMTPUTF8; one legacy hop rejects it with a 5.6.7 error |
| EAI is rare, so it can be safely ignored | Registries in many scripts issue internationalized domains, and forms that reject them lock out real users — verify support rather than assuming absence |
Where AI Emaily fits#
AI Emaily is an AI email client that connects to your existing mailbox — Gmail, Outlook, iCloud, Fastmail, Proton or any IMAP account — rather than running its own mail server. So its reach for internationalized addresses is whatever your provider already offers: if the connected account's outbound path advertises SMTPUTF8, a message to an EAI correspondent goes out; if it does not, no client can add support the transport itself lacks.
What the app does regardless of the script an address is written in is the useful part — it triages the message on arrival, drafts a reply in your voice, and lets you search across every connected account. Its own interface is localized into many languages, which is a separate matter from what a mail server can put on the wire. We build AI Emaily; you can see the current plans and start a 7-day free trial from the pricing page.
Frequently asked
See it in AI Emaily
Keep reading
Sources
- RFC 6530 — Overview and Framework for Internationalized Email
- RFC 6531 — SMTP Extension for Internationalized Email
- RFC 6532 — Internationalized Email Headers
- RFC 3492 — Punycode: A Bootstring encoding of Unicode for IDNA
- Google Workspace Updates — Internationalized email address support in Gmail (2014)

Written by
Nafiul HasanNafiul Hasan is an entrepreneur and AI automation system builder with 10+ years of experience turning messy, manual workflows into reliable automated systems. He designs and ships AI enterprise solutions end-to-end — the agent logic, the data plumbing, and the product people actually use — and founded AI Emaily to give busy professionals their attention back. He writes here from the builder's seat: what works, what breaks, and how to put AI to work without giving up control.