Non-English Email Addresses: IDN Domains and Unicode
Addresses with accents, Cyrillic or Chinese characters are real. What works, what breaks, and what a verifier can honestly tell you.
An address such as info@münchen.example or contact@пример.рф looks unusual to an English-language sign-up form, yet millions of people use them. If your list serves customers outside the English-speaking world, you will meet these addresses, and how your systems treat them decides whether those customers hear from you.
Two different things
People often mix up two features:
- Internationalised domain names (IDN). The part after the @ contains non-ASCII letters, like münchen.example. Behind the scenes the name is converted to an ASCII form called Punycode (for example xn--mnchen-3ya.example). Because of that conversion, mail servers and DNS handle IDN domains without trouble.
- Internationalised email addresses (EAI). The part before the @ contains non-ASCII characters, like jü[email protected] or пользователь@example.com. This needs mail servers that support the SMTPUTF8 extension on every step of the way. Support is growing but still uneven.
What this means in practice
| Address type | Typical situation |
|---|---|
| Plain ASCII address on an IDN domain | Works everywhere. Only the domain needs converting to Punycode for DNS lookups. |
| Non-ASCII before the @ | Works only if the sending and receiving servers support SMTPUTF8. Many do not, and the message bounces or never leaves. |
| Accents typed in the wrong place | Common typo or a form that converted the character. Worth a second look. |
Problems we see in real lists
- Forms that reject valid input. Older regular expressions only allow
a-z, digits and a few symbols. They block customers with legitimate addresses. - Forms that accept anything. At the other extreme, a field with no checks lets emoji, spaces and half-pasted text through.
- Mixed encodings. A file saved in the wrong text encoding turns ü into garbled characters. Always export CSV as UTF-8.
- Lookalike letters. A Cyrillic а looks like a Latin a. Addresses made of lookalikes are sometimes used to impersonate a brand.
Handling them sensibly
- Store addresses as UTF-8 and treat them as text, not as ASCII-only strings.
- Convert the domain to Punycode before DNS or SMTP work, and keep the original for display.
- Use a loose syntax check on the form, then rely on a real verification step instead of a clever pattern.
- Decide how you will send. If your mail provider does not support SMTPUTF8, an address with non-ASCII before the @ will not be deliverable from your side, no matter how valid it is.
What a verifier can tell you
For addresses on IDN domains, a verifier looks up the Punycode form of the domain, finds its mail servers and asks them about the mailbox, exactly as for any other address. For non-ASCII local parts the honest answer is often unknown or risky: the receiving server may not support SMTPUTF8 or may refuse to confirm. Treat those results as a prompt to decide, not as proof either way. If the contact is important, ask the person for an ASCII alternative.
Run a small sample through the free single check to see how your own contacts behave, then use bulk verification for the rest. Remember to export your file as UTF-8 first.
