Internationalized email addresses explained

An internationalized email address contains characters outside ASCII: in the domain (info@bücher.example), in the local part before the @ (zoë@example.com), or in both. The two halves work very differently. An internationalized domain has an ASCII form, its A-label (xn--bcher-kva.example), so any mail server can deliver to it. A non-ASCII local part has no ASCII form: every server that handles the message must support the SMTPUTF8 extension, and when one does not, the message bounces rather than being converted. Forms should accept both kinds, store them as UTF-8 and normalize them to NFC.

The standards

Internationalized email is often called EAI, for Email Address Internationalization. It rests on two sets of standards: IDNA2008 for domain names and four RFCs from February 2012 for mail itself.

Two halves, two mechanisms

Internationalized domains

A domain label written in its native characters is a U-label. DNS stores it as an A-label: the prefix xn-- followed by the Punycode encoding of the label (RFC 5890, section 2.3.2.1). To look a name up, software converts it to Unicode in NFC form, validates it and then applies Punycode (RFC 5891, sections 5.2, 5.4 and 5.5).

U-label form:  info@bücher.example
A-label form:  info@xn--bcher-kva.example

Both lines name the same mailbox. RFC 6531, section 3.2, says explicitly that a domain in A-label form does not count as "internationalized" for SMTPUTF8 purposes. So an address with an ASCII local part and an internationalized domain can travel through any mail server once the domain is written as A-labels.

Non-ASCII local parts

RFC 6531, section 3.3, extends the address syntax so that the local part may contain UTF-8. There is no ASCII equivalent: the conversion between U-labels and A-labels applies to domain names only, and a provider that wants to give a user an ASCII address as well has to assign it separately, as the Universal Acceptance Steering Group's Quick Guide to EAI points out.

Nor can a server along the way rewrite the address. RFC 6530, section 9, recalls the SMTP rule that only the destination host may interpret a local part, so a downgrade in transit is ruled out. Earlier experimental versions of EAI did allow one; section 12 explains that this was dropped as more complex and less necessary than expected.

What happens on the wire

A receiving server that supports internationalized mail lists SMTPUTF8 in its reply to EHLO, and must also announce 8BITMIME (RFC 6531, section 3.1). A client sending a message that needs the extension adds the SMTPUTF8 parameter to its MAIL command (section 3.4):

S: 220 mx.example.net ESMTP
C: EHLO mail.example.com
S: 250-mx.example.net
S: 250-8BITMIME
S: 250 SMTPUTF8
C: MAIL FROM:<zoë@example.com> SMTPUTF8
S: 250 OK
C: RCPT TO:<info@bücher.example>
S: 250 OK

The EHLO names themselves stay ASCII, because the client cannot know whether the server supports the extension until it has read the reply (section 3.7.1).

When a server lacks SMTPUTF8

If the next server does not announce the extension, RFC 6531, section 3.2, forbids sending it an internationalized address or UTF-8 headers. The sending side then has three options:

• a submission server (the one your mail client or app hands the message to) may transform the message in its own way, for example by switching to an ASCII address it knows for the same person;
• otherwise it should reject the message, either during the SMTP session or by accepting it and then sending a non-delivery notification that follows RFC 6533;
• a client with better knowledge may queue the message and retry later, or try another MX host.

Unless the sending side knows another address for the recipient, the result is a bounce. RFC 6531, section 3.5, defines the replies:

A domain should run SMTPUTF8 on all of its MX hosts or on none, because a backup host without it causes rejections that look random to users (section 3.7.2). RFC 6533 adds a UTF-8 address type to bounce notices, so the bounce can still name the original recipient; see bounce processing and DSNs for how to read them. The UASG guide lists further transition problems: a message to several recipients can reach some and not others, and Reply-All can behave differently from the first send.

Which providers support it

Support has to exist at every hop: your sending platform, the recipient's provider and anything in between.

• Gmail. On August 5, 2014, Google's Official Gmail Blog announced that Gmail recognizes addresses with accented or non-Latin characters, so its users can send mail to and receive mail from them. Creating Gmail accounts with such addresses was named as a future step.
• Microsoft. The Exchange Team announced EAI support for Office 365 in December 2017, based on RFCs 6530 to 6533. The first release covered sending to and receiving from internationalized addresses, without EAI addresses for Office 365 users or IDN domains for organizations. The February 2018 update said EAI was enabled in Exchange Online and Exchange Online Protection, and for Outlook.com, including hotmail.com and live.com accounts.

For any other provider, and for your own email platform, look for SMTPUTF8 in its documentation or ask. The UASG guide's advice to software makers is the same rule from the other side: check that the next server announces SMTPUTF8, never send EAI mail to one that does not, and give users a readable error when that happens.

Handling these addresses in forms

The UASG's UA Readiness Framework (UASG 026) splits an application's handling of an address into steps: accept, validate, process, store and display. Applied to a sign-up form:

1. Accept every form. Allow UTF-8 in both halves, and a domain typed as U-labels or as A-labels. Note that the HTML Standard's rule for a valid address in a type="email" field allows only ASCII in the local part, so a browser can refuse a non-ASCII local part before your server sees it. If you need those addresses, use a text field and check on the server.
2. Normalize to NFC. The same visible text can be stored as different code points: é can be one character or e followed by a combining accent. RFC 6532, section 3.1, says NFC should be used and NFKC should not, because NFKC can lose information needed to spell some names. UASG 026 also suggests NFC when nothing more specific applies.
3. Do not fold or cut. Never turn é into e, and never truncate (UASG 026).
4. Store the local part as UTF-8. Store the domain either as U-labels or as A-labels, and compare addresses in one consistent form.
5. Do not lowercase the local part. RFC 6530, section 13, notes that lowercasing works for domain names but not for local parts, which are case sensitive.
6. Display Unicode. Show people the U-label form; keep the A-label for DNS lookups.
7. Watch for look-alikes. RFC 6530, section 13, warns that confusable characters allow spoofing in local parts as well as in domains, so take care where an address serves as a login or an account key.

Finally, confirm the address the way you would any other: a double opt-in message proves the mailbox works and that the person controls it. That only works if your sending platform supports SMTPUTF8. The general rules for the ASCII part of an address are in email address syntax.

Test addresses

The UASG's Test Domain Names and Email Addresses (UASG 004, November 2021) lists test domains and addresses in many scripts, set up to auto-reply when the sending domain is properly configured, including SPF. The UASG site says the site was archived in November 2025 and is no longer updated, so a listed address may no longer answer. Send test mail only to addresses published for that purpose, never to invented ones.

How our checks handle these addresses

• Internationalized domains are accepted. An address such as info@bücher.example is checked in its A-label form, and the result's email and domain fields show that ASCII form (validate endpoint). The DNS checkers in our free tools, for example the SPF checker, also accept a domain typed in Unicode and look up its A-labels.
• Non-ASCII local parts are outside the syntax we check. Such an address is answered invalid with the reason invalid_syntax and the action remove: our check accepts only an ASCII local part (syntax we accept). The result reflects what our check covers: we cannot confirm such a mailbox, so we tell you to remove it.
• Double opt-in is an extra option, not an override. If your audience uses these addresses and you decide to keep one anyway, a double opt-in message through a platform that supports SMTPUTF8 is a separate test you run yourself. It does not change our result.

Questions

Can an internationalized address be converted to ASCII?

The domain can: its A-label is the same domain. The local part cannot. A provider may give the user a separate ASCII address that reaches the same mailbox, but you cannot derive it from the internationalized one.

Should my form reject non-ASCII addresses?

The standards allow them, so a form should be able to take them and store them correctly. Whether you can mail them depends on your sending platform supporting SMTPUTF8, so check that before you rely on them for account mail. With our check, a non-ASCII local part comes back invalid, so our sign-up form recipe asks the person for another address; keep such an address only if you confirm it yourself.

Is an xn-- domain different from the Unicode one?

No. bücher.example and xn--bcher-kva.example are the same domain in two notations. DNS uses the A-label; people should see the Unicode form.

Try it

Check an address with an internationalized domain in the free email checker, or look up its records with the DMARC checker.

Related

• The invalid status: address syntax we accept.
• Validate endpoint: response fields.
• Sign-up form validation recipe.
• Glossary: syntax check.

Related guides

• Email address syntax explained
• Bounce processing and DSNs explained
• Double opt-in (confirmed opt-in)
• Email typos and did you mean suggestions
• What is email verification?
• All guides

Sources

• RFC Editor: RFC 6530, Overview and Framework for Internationalized Email: no downgrade in transit (section 9), the dropped experimental design (section 12), case sensitivity and confusables (section 13).
• RFC Editor: RFC 6531, SMTP Extension for Internationalized Email: SMTPUTF8 and 8BITMIME, A-labels, the MAIL parameter, behavior without the extension, reply codes, MX consistency.
• RFC Editor: RFC 6532, Internationalized Email Headers: NFC rather than NFKC (section 3.1).
• RFC Editor: RFC 6533, Internationalized Delivery Status and Disposition Notifications: the UTF-8 address type in bounce notices.
• RFC Editor: RFC 5890, IDNA Definitions and Document Framework: U-labels, A-labels and the xn-- prefix.
• RFC Editor: RFC 5891, IDNA Protocol: NFC and Punycode in domain lookup.
• Official Gmail Blog: A first step toward more global email (August 5, 2014): Gmail's support for internationalized addresses.
• Microsoft Exchange Team Blog: EAI support announcement (December 2017) and its update (February 2018): EAI in Office 365, Exchange Online and Outlook.com.
• UASG: UASG 014, Quick Guide to Email Address Internationalization: no mechanical ASCII conversion of local parts, server advice, transition problems.
• UASG: UASG 026, UA Readiness Framework (April 2020): accept, validate, store and display steps; NFC.
• UASG: UASG 004, Test Domain Names and Email Addresses (November 2021): published test addresses.
• WHATWG: HTML Standard, the input element: the ASCII-only local part in the valid email address rule for email fields.

How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.