What is an internationalized email?

Two standards do different halves of the job. IDNA covers the domain and converts it to an ASCII form for DNS. SMTPUTF8 covers the local part and requires both servers to negotiate support during the handshake.

Gmail can receive them. Many corporate mail systems and a great many validation libraries cannot, so a user with such an address meets rejection regularly enough to expect it.

Validation needs care here. A regex written for ASCII rejects these outright, and for a service with users outside the Latin alphabet that is a real accessibility failure rather than a technical nicety.

There is a security dimension too. Characters that look identical across scripts allow a domain that reads like yours to be registered with different code points entirely.

People picture this as a problem for addresses in Chinese or Arabic script. It starts much closer to home. Say a customer signs up as josé@acme.example. That single accented letter is outside ASCII, so the whole address needs the SMTPUTF8 extension defined in RFC 6531.

Here's what that means on the wire. Your sending server connects and says EHLO. The receiving server lists its extensions, and your server looks for a line reading 250-SMTPUTF8. If it's there, the sender adds the SMTPUTF8 keyword to its MAIL FROM command and carries on.

If it isn't there, the message can't go to that recipient through that server. There's no standard way to downgrade the address into ASCII, so the sending server has to fail it and report back. José, meanwhile, never gets your confirmation email and has no idea why.

An address like that passes through four places in your system, and any one of them can break it.

The form's validation pattern comes first. If it only allows ASCII letters, José is turned away at the door. Next is storage: the column needs a Unicode encoding, and you should normalize text to one Unicode form so the same name always produces the same bytes. Third is your sending platform. Ask support directly whether they send with SMTPUTF8, because documentation is often silent on it. Last is every tool downstream, such as your CRM, your helpdesk and your exports to CSV.

You can test the outbound hop yourself. Connect to your relay, send EHLO, and read the list of extensions it prints.

If a link in the chain can't handle these addresses, say so at the form. A clear message asking for an alternative address is kinder than accepting the signup and silently failing to reach the person. Don't try to strip the accents yourself, since jose@ may be a different person's mailbox.