What this RFC defines
RFC 5890 defines IDNA 2008 (Internationalized Domain Names in Applications), the standard for encoding non-ASCII domain names for use in DNS and internet protocols including email. It specifies how Unicode labels are converted to their ASCII-compatible encoding (ACE) form using the Punycode algorithm.
Where you see it in practice
When you send email to an address with a non-ASCII domain, for example, a German domain like bucher.de with an umlaut, the domain is encoded as an xn-- Punycode form in DNS and SMTP. RFC 5890 defines the rules for this encoding. Email validation systems that check whether an internationalized domain name is valid follow the character set restrictions and validation rules in this RFC.
How it connects to other RFCs
RFC 5890 obsoletes RFC 3490 (IDNA 2003) and is part of a suite with RFC 5891 (IDNA processing), RFC 5892 (Unicode code point rules), and RFC 5893 (Bidi rules). In the email context it works with RFC 6530-6532 (EAI) for fully internationalized email addresses. DNS resolution of internationalized domains always uses the Punycode-encoded ACE form defined here.
Current status
RFC 5890 is a current standard, published August 2010. IDNA 2008 is supported by major DNS resolvers and email systems. Some deployments still use the older IDNA 2003 (RFC 3490) rules, which can cause interoperability issues for certain Unicode characters where the two standards differ.
Internationalized Domain Names
RFC 5890 defined the IDNA2008 framework for Internationalized Domain Names in Applications in August 2010, replacing the earlier IDNA2003 (RFC 3490). IDNA lets domain names contain non-ASCII characters (Cyrillic, Chinese, Arabic, Hebrew) while remaining compatible with the ASCII-only DNS protocol via Punycode encoding. A domain like пример.рф is transmitted through DNS as xn--e1afmkfd.xn--p1ai, but displayed to users in its Unicode form when the client supports it.
IDNA2008 versus IDNA2003
The two IDNA versions differ in how they normalize input. IDNA2003 mapped uppercase to lowercase and applied various Unicode transformations before encoding. IDNA2008 relies on the application to pre-normalize and enforces stricter rules on which characters are allowed. This shift caused compatibility issues: some domains valid under IDNA2003 became invalid under IDNA2008. UTS 46 (Unicode Technical Standard 46) was published to bridge the two, defining a transitional processing mode that accepts both. Most modern software (browsers, mail clients) use UTS 46 in transitional mode.
Impact on email
IDNA enables addresses like alice@例え.jp, but requires supporting infrastructure: the DNS lookup works via Punycode (xn--r8jz45g.jp), the SMTP transport requires SMTPUTF8 (RFC 6531), and the local part may require RFC 6532 header support. Sending mail to a fully-internationalized address requires all three pieces plus IDNA in the client. In practice, mail providers in Japan, China, Russia, and the Middle East drove IDNA adoption; adoption in the English-speaking world remains uneven.
RFC 5890 (August 2010) defines the terminology and framework for IDNA 2008 (Internationalized Domain Names in Applications): how internationalized domain names (like 例え.jp, müller.de, рф.ru) are represented in ASCII-only contexts via Punycode encoding with the xn-- prefix. Companion RFCs 5891, 5892, 5893, 5894 complete the specification. Replaces IDNA 2003 (RFC 3490). Foundation for internationalized email addresses in the domain part, used by SMTPUTF8, DNS, HTTPS, and every application handling international domains.
RFC 5890 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Define terminology and framework for internationalized domain names |
| U-label | Unicode form (e.g., 例え.jp) |
| A-label | ASCII Punycode form (e.g., xn--r8jz45g.jp) |
| Companion RFCs | RFC 5891 (protocol), 5892 (code points), 5893 (right-to-left), 5894 (background) |
| Predecessor | IDNA 2003 (RFC 3490), which had security issues addressed by IDNA 2008 |
| Related to email | Domain part of internationalized email addresses per RFC 6531 |
| Published | August 2010 |
U-labels and A-labels
| Aspect | U-label (Unicode) | A-label (ASCII / Punycode) |
|---|---|---|
| Example | 例え.jp | xn--r8jz45g.jp |
| Example (German) | müller.de | xn--mller-kva.de |
| Example (Cyrillic) | россия.рф | xn--h1alffa9f.xn--p1ai |
| Where used | User-facing displays, URL bars, address inputs | DNS queries, wire protocols (unless SMTPUTF8), certificates |
| Case-sensitivity | Normalization required (NFC) | ASCII case-insensitive per DNS convention |
| Length limits | Per script; converted A-label must fit DNS 63 octets per label | 63 octets per label (DNS limit) |
Punycode conversion mechanism
Changes from IDNA 2003 (RFC 3490)
| Aspect | IDNA 2003 | IDNA 2008 |
|---|---|---|
| Character mapping | Case-folded, applied Nameprep (StringPrep-based) | No mapping in protocol; application decides |
| Unicode version | Fixed at Unicode 3.2 | Version-independent via property-based rules |
| Excluded characters | Explicit list | Categorical rules (marks, formatting characters, punctuation) |
| Sharp s (ß) | Mapped to “ss” | Preserved as ß |
| Final sigma (ς) | Mapped to lowercase sigma | Preserved |
Common IDNA implementation mistakes
а (U+0430) looks identical to Latin a (U+0061). Attackers register look-alike domains (раyраl.com with Cyrillic а) to phish users. Applications should detect mixed-script labels and warn or refuse. Browsers implement this; email clients should too, particularly for displayed From addresses.user@例え.jp works over standard SMTP with A-label conversion (user@xn--r8jz45g.jp). An address like 用户@example.com requires SMTPUTF8; no ASCII fallback exists for the local part.Related standards and further reading
- RFC 5891: IDNA 2008 protocol (conversion rules)
- RFC 5892: The Unicode Code Points and IDNA
- RFC 5893: Right-to-Left Scripts for IDNA
- RFC 5894: Background, Explanation, and Rationale
- RFC 3492: Punycode algorithm
- RFC 3490: IDNA 2003 (obsoleted)
- RFC 6531 Guide: SMTPUTF8 companion
- RFC 5322 Guide: message format base
Frequently asked questions
What is the difference between U-label and A-label?
U-label is the Unicode form of a domain label (例え, müller). A-label is the ASCII Punycode form (xn--r8jz45g, xn--mller-kva). Both represent the same domain; they are different encodings for different contexts. U-labels are for user-facing display; A-labels are for wire protocols like DNS. Conversion is reversible and lossless.
Why does DNS not support Unicode directly?
Historical: DNS was designed in the 1980s as an ASCII protocol. Retrofitting Unicode throughout every DNS server, resolver, and application was infeasible. Punycode’s ASCII-only representation lets Unicode domains coexist with legacy DNS infrastructure. Every DNS query for 例え.jp is actually a query for xn--r8jz45g.jp; the domain owner sees the U-label form, but the wire uses the A-label.
What are IDN homograph attacks?
Exploits that use visually-similar characters from different scripts to create look-alike domains. Cyrillic а (U+0430) looks identical to Latin a (U+0061), so раyраl.com (with three Cyrillic characters) is visually indistinguishable from paypal.com but resolves to a different domain. Modern browsers detect mixed-script labels and display the A-label form as warning. Email clients should apply similar detection to From displays.
Should I convert domains to A-label before storing them?
Recommended. A-labels are ASCII, case-normalized per DNS convention, and unambiguous. Storing U-labels risks Unicode normalization issues (NFC vs NFD, homograph variants). Convert to A-label at input, store A-label, convert back to U-label at display. Most modern IDN libraries provide bidirectional conversion.
Does IDNA 2008 affect email delivery?
Yes for the domain part of addresses. user@例え.jp is delivered via SMTP as user@xn--r8jz45g.jp (A-label) unless SMTPUTF8 is negotiated. The MX record for xn--r8jz45g.jp returns the receiving MTA, delivery proceeds normally. Local-part is unaffected by IDNA (that requires SMTPUTF8). Every mainstream ESP handles A-label conversion transparently.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
