IDNs and email

In previous surveys, we have noted the problems associated with using an IDN as part of an email address. In 2017, our research continues to discover isolated initiatives that attempt to provide Email Address Internationalisation (EAI), but no internet-wide success. It is simply not possible for two people, using different email providers, to exchange internationalised email.

Components of an email address - broken into user portion and the domain name

Email addresses consist of two parts separated by an “@” symbol. At the front of the “@” symbol is a string called the user portion. Behind the “@” symbol is usually a domain name. To achieve universal acceptance of IDNs we should be able to use any IDN as the domain name and also use the non-ASCII script for the user portion. Not only should we be able to address email with these internationalised addresses, but we should be able to send and receive them as well. A system that allows a user to address email, and send and receive it with IDNs is often referred to as Email Address Internationalisation (EAI).

We should be able to use email addresses that look like:





It is crucial to understand that this does not just apply to the top-level of the domain name. In a fully EAI compliant system, we should be able to use IDNs anywhere in the domain name string where they are legally permitted by IDN and registry standards.

The challenges

There are two, crucial challenges that need to be overcome, before EAI is achievable:

  • The client software (for instance, Outlook or Thunderbird) needs to be able to display, process and store the internationalised address. For instance, the client software should display EAI addresses in Unicode, while passing the domain name to the mail server in Punycode.
  • The server software must support EAI and allow for the transfer of the mail in a manner that preserves the EAI address.

Whenever an email is sent, it passes through mail servers at different stages of delivery. Traditional mail servers, mail clients, and web-based email services will usually only handle message headers containing ASCII characters.

Correspondents trying to receive email from senders with addresses using extended character sets would not be able to do so in a traditional mail client, or through a web-based mail system. In the past, mail servers would try to re-encode data in a non-native way that caused the recipient to receive incomplete headers or information within an email. This would occur because a mail system would first take a message header and convert it to the character set native to the system, which is not always successful.

Native EAI support has appeared in a variety of settings

In 2014 came the support for both the transport and addressing of internationalised email at Gmail. This was an important development because mail servers need to be standards compliant just as much as mail clients. Support for ‘transport’ of internationalised email means that internationalised email can be passed through and delivered using Google’s servers.  However, as we have seen above, there is no guarantee that internationalised email passing through other servers will be forwarded correctly.  Indeed, Google continues to not allow users to use an internationalised email address for a Gmail account.

In 2016, we also saw Yandex.Mail, a service with over 300 million users, begin to provide support for transport of internationalised email.  Unlike Gmail, Yandex allows for registration of addresses with an IDN as the domain-part of the address (it does not yet support registration of internationalised strings in the user portion). In looking at its incoming email, Yandex reports that is seeing more than 1 billion incoming email messages a week.

In August of 2017, the Indian government announced plans to issue fully Hindi-script email addresses to some five million civil servants.  The Ministry of Electronics and Information Technology announced the move, which will see each government employee given an @सरकार.भारत email address.

According to the Ministry, सरकार.भारत transliterates as “sarkar.bharat”, or “government.india”. The press release for the announcement indicates that exploiting local scripts in India is less of a motivation than regaining local control of information. The Ministry states, “the primary trigger behind the policy was Government data which resides on servers outside India and on servers beyond the control of the Government of India.” While this development means that civil servants in India will be able to exchange internationalised email with each other, it does not mean that they will be able to use EAI with every correspondent outside the system.

This is consistent with the deployments we have found on the server-side. We find a group of systems, sometimes with large subscriber bases, that allow for the exchange of EAI mail between subscribers on the same system. When exchanging email with compatible external systems, for instance, Gmail, the EAI features of the mail can be preserved. However, general purpose support for broad use of EAI email is still not available.

On the client side, Microsoft provides support for EAI addresses for both Outlook 2016 and Office 365, although like Google, Microsoft does not let you set up an Office 365 account using an internationalised email address. The Thunderbird and Opera email clients continue support of EAI for the IDN but not yet for the user portion of an email address.