What this RFC defines
RFC 6530 defines the framework for EAI (Email Address Internationalization), the set of standards that allow email addresses and message content to use Unicode characters beyond ASCII. It is the overview RFC that describes the problem space, the architecture, and the relationship between the individual EAI RFCs (6531, 6532, 6533).
Where you see it in practice
EAI enables email addresses like user@example.jp with non-ASCII characters to function as valid addresses that can send and receive email. RFC 6530 defines when and how these addresses can be used. If your ESP or MTA advertises SMTPUTF8 support, it is implementing the EAI framework described here.
How it connects to other RFCs
RFC 6530 obsoletes RFC 4952 and serves as the overview for the EAI suite: RFC 6531 (SMTPUTF8 SMTP extension), RFC 6532 (UTF-8 email headers), and RFC 6533 (internationalized DSN/MDN). It builds on RFC 5321 (SMTP) and RFC 5322 (message format) as the protocols being extended.
Current status
RFC 6530 is a current standard, published February 2012. EAI support is growing but not yet universal. Major mailbox providers support receiving internationalized email addresses, but full end-to-end EAI deployment requires all intermediate MTAs to support SMTPUTF8, which is not yet the case everywhere.
The internationalized email framework
RFC 6530 is the roadmap document for internationalized email, published in February 2012. It does not define wire formats itself; it explains how the family of RFCs (6531 for SMTP, 6532 for headers, 6533 for delivery status, and others) fit together to enable end-to-end delivery of email with non-ASCII addresses and content. Reading RFC 6530 before diving into individual specifications provides essential context about which pieces solve which problems.
The three-part scope
Internationalized email has three parts: internationalized mailbox names (the local part before @, addressed by SMTPUTF8), internationalized domain names (after @, addressed by IDNA), and internationalized message content (addressed by MIME 8BITMIME plus UTF-8 in headers). All three must be supported end-to-end for a fully-internationalized message to work. If any hop lacks support, either the message is rejected or downgraded, depending on the specific missing capability.
Downgrade rules and their absence
RFC 6530 originally sketched a downgrade mechanism where messages could be converted to ASCII-compatible form if the delivery path did not fully support internationalization. Later work concluded that reliable downgrade is impractical; the current approach is to reject internationalized mail at the first hop that cannot handle it. This means an internationalized address is either fully deliverable end-to-end or is bounced. Senders that need to reach non-ASCII addresses must verify SMTPUTF8 support at each hop.
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.
