Internationalized Email Addresses (EAI): Should Your Form Accept Them?

Internationalized email addresses are valid. RFC 6531 lets both the local part and the domain contain UTF-8, so 用户@例子.广告 is a real address format. Whether to accept one depends on your stack. A non-ASCII domain alone (user@münchen.de) converts to ASCII and works anywhere. A non-ASCII local part needs SMTPUTF8 support at every hop, and many systems still don't have it.

This post covers what the RFCs say, how common validators treated these addresses in our tests, and which large providers' mail servers advertised SMTPUTF8 when we connected to them on 6 October 2026.

Two different things called "international email"

An IDN domain has an ASCII equivalent. A non-ASCII local part does not, and that is where the compatibility problems are.

Example	What is non-ASCII	ASCII form exists?	Needs SMTPUTF8?
user@münchen.de	Domain only	Yes: user@xn--mnchen-3ya.de	No, once converted
josé@example.com	Local part	No	Yes
用户@例子.广告	Both	Domain only (xn--fsqu00a.xn--4rr70v)	Yes

The ASCII form of a domain label is called an A-label (the xn-- punycode form). The Unicode form is a U-label. Converting between them is defined by IDNA (RFC 5890), and every mainstream language has a function for it. In Node it's domainToASCII from node:url, and in Java it's java.net.IDN.toASCII.

Local parts have no such mapping. josé is just josé, and only the receiving server can say what it means.

What the RFCs actually changed

RFC 6531 adds UTF-8 to a few grammar rules and requires that the receiving server announce support. The parsing rules and the size limits stay the same.

The framework is RFC 6530. The SMTP part is RFC 6531, which extends the RFC 5321 grammar in section 3.3:

sub-domain   =/  U-label
atext        =/  UTF8-non-ascii
qtextSMTP    =/  UTF8-non-ascii

RFC 6532 makes the same change to atext in message headers. Three more points from the text matter for developers:

• Parsing is unchanged. RFC 6531 section 3.2: "the actual parsing of the <local-part> and the delimiters used are unchanged from the base email specification". The @ and the dots still mean what they always meant.
• DNS still uses ASCII. Domains "MUST conform to and be processed as specified for" IDNA, and lookups use either a Unicode-aware DNS library or the A-label form.
• No SMTPUTF8, no delivery. If the next server doesn't announce the extension, the client "MUST NOT transmit an internationalized email address". Instead it should reject the message or bounce it.

The older experimental versions (RFC 5335 to 5337) let messages be downgraded in transit, with an ASCII alternative attached to each address. RFC 6530 section 6 explains that this was dropped, partly over security concerns. There is no automatic fallback. If one hop lacks support, the mail doesn't arrive.

Length limits don't change either. RFC 5321's limits (64 octets for the local part, 256 for the whole path including angle brackets) are counted in octets. The only length change RFC 6531 makes is 10 extra characters on the MAIL command line. 用户 is two characters but six octets, so check Buffer.byteLength or len(s.encode()), not .length.

Which mail servers advertise SMTPUTF8

When we connected on 6 October 2026, the inbound servers for Gmail, Outlook.com, QQ and Mail.ru advertised SMTPUTF8. Seven other large providers did not.

We connected to the lowest-preference MX host for each domain on port 25, sent EHLO, and checked the reply before and after STARTTLS. The result was the same both times:

Domain	MX host checked	SMTPUTF8 advertised
gmail.com	gmail-smtp-in.l.google.com	Yes
outlook.com	outlook-com.olc.protection.outlook.com	Yes
qq.com	mx3.qq.com	Yes
mail.ru	mxs.mail.ru	Yes
yahoo.com	mta7.am0.yahoodns.net	No
aol.com	mx-aol.mail.gm0.yahoodns.net	No
icloud.com	mx02.mail.icloud.com	No
zoho.com	smtpin.zoho.com	No
yandex.ru	mx.yandex.ru	No
protonmail.com	mail.protonmail.ch	No
fastmail.com	in1-smtp.messagingengine.com	No

Two caveats. This tells you whether a server will accept mail involving such addresses, not whether the provider lets users sign up with one. Google's username rules allow only "letters (a-z), numbers (0-9), and periods (.)". And it is one snapshot from one network. Providers change their configuration.

The practical meaning: a user at a provider without SMTPUTF8 can't receive mail from an EAI address, and a domain without it can't host one. Your outbound provider matters too, because it is the first hop. Ask your ESP whether it supports SMTPUTF8 before you accept non-ASCII local parts.

How common validators treat these addresses

Most libraries accept IDN domains. Fewer accept non-ASCII local parts, and some reject both.

Run on 6 October 2026 with the versions shown:

Validator	user@münchen.de	用户@例子.广告
Chrome 155 <input type="email">	Accepted, value converted to user@xn--mnchen-3ya.de	Rejected
validator.js 13.15.35 isEmail (defaults)	Accepted	Accepted
validator.js with allow_utf8_local_part: false	Accepted	Rejected
Python email-validator 2.3.0 (defaults)	Accepted	Accepted
Python email-validator, allow_smtputf8=False	Accepted	Rejected
Apache Commons Validator 1.11.0	Accepted	Rejected
Jakarta Mail 2.1.5 InternetAddress.validate()	Accepted	Accepted
PHP 8.5 filter_var(FILTER_VALIDATE_EMAIL)	Rejected	Rejected
WordPress is_email()	Rejected	Rejected

PHP's FILTER_FLAG_EMAIL_UNICODE accepted josé@example.com but still rejected both of the addresses above, because the flag covers the local part, not the domain. WordPress documents is_email as not handling "i18n domains". Its sanitize_email is worse: it turned user@münchen.de into user@mnchen.de, a different domain. That one is covered in verifying email on WordPress forms.

The browser result surprises people in both directions. Chrome accepted the IDN domain, but it rewrote the field's value to the punycode form, so your server receives user@xn--mnchen-3ya.de and the user may see it too. It rejected any non-ASCII local part (josé@example.com failed as well). We only tested Chrome, and other browsers may behave differently. If you need to accept non-ASCII local parts, use type="text" with inputmode="email" and validate on the server.

A sensible policy

Accept IDN domains everywhere. Accept non-ASCII local parts only if your whole sending path supports SMTPUTF8, and say clearly when you don't.

1. Convert the domain to an A-label before MX lookups and duplicate checks. münchen.de and xn--mnchen-3ya.de are the same domain and should be one account.
2. Normalize to NFC. é can be one code point (U+00E9) or two (e plus U+0301). They look identical, but they're different strings, and in our test === returned false until we called .normalize("NFC"). RFC 6530 section 10.1 advises supporting addresses "in Normalized form, using at least Normalization Form NFC". Python's email-validator does this for you.
3. Don't lower-case the local part. Case rules for non-ASCII letters vary by language, and RFC 5321 already leaves local-part case up to the receiving server.
4. Check lengths in bytes.
5. Decide on local parts deliberately. If your ESP, CRM or database can't handle them, reject them with a specific message ("We can't send to addresses with accented or non-Latin characters before the @ yet") rather than a generic "invalid email". The person's address is valid, and the limitation is yours.

The main risk of accepting Unicode is look-alike characters: a Cyrillic а is a different character from a Latin a. That matters more for display and anti-phishing than for signup, but it's one more reason to compare A-label domains and NFC strings rather than raw input.

Checking SMTPUTF8 yourself

One EHLO tells you whether a server advertises the extension.

import smtplib

def advertises_smtputf8(mx_host: str) -> bool:
    with smtplib.SMTP(mx_host, 25, timeout=10) as smtp:
        code, reply = smtp.ehlo("your-hostname.example")
        return code == 250 and "SMTPUTF8" in reply.decode().upper()

This needs outbound port 25, which most cloud providers block. Look up the MX host first with the MX lookup tool.

The takeaway

• user@münchen.de is an ordinary address in disguise. Convert the domain and accept it.
• josé@… and 用户@… are valid, but they only work where every hop supports SMTPUTF8. On 6 October 2026, 4 of the 11 large providers we checked advertised it.
• Chrome's <input type="email"> rejects non-ASCII local parts and silently converts IDN domains to punycode. PHP's filter_var and WordPress's is_email reject IDN domains outright. Validate on the server if you need either.
• Normalize to NFC, compare A-label domains, and count octets.
• For the full list of characters the standards allow in ASCII addresses, see valid email address characters.