Email Encoding: From ASCII to Internationalized Domain Names

Email is one of the oldest internet protocols, and its encoding rules reflect decades of backward compatibility requirements. From the original 7-bit ASCII constraints of SMTP to modern internationalized email addresses, the encoding of email headers and bodies has evolved considerably.

The 7-Bit ASCII Legacy

The original SMTP specification (RFC 821, 1982) required all message content to use 7-bit ASCII. This was a significant constraint for international email. The immediate workaround was MIME (Multipurpose Internet Mail Extensions, RFC 2045, 1996), which defined transfer encodings for representing non-ASCII content within the 7-bit constraint.

MIME Transfer Encodings

MIME defines two transfer encodings for non-ASCII message bodies. Quoted-Printable encodes non-ASCII bytes as =XX (hex) while leaving ASCII characters readable — suitable for text that's mostly ASCII with occasional non-ASCII characters. Base64 encodes arbitrary binary data as ASCII characters — suitable for attachments and text that's mostly non-ASCII. Both are still widely used today.

Header Encoding

Email headers (Subject, From, To) are also traditionally ASCII. RFC 2047 defines "encoded words" for non-ASCII header values: =?charset?encoding?encoded-text?=. For example, a Japanese subject line encoded in UTF-8 with Base64 might look like =?UTF-8?B?5pel5pys8BEA?=. Modern mail clients decode these transparently.

Internationalized Email

RFC 6530-6532 (2012) and the EAI (Email Address Internationalization) standard finally allow non-ASCII characters in email addresses themselves — both in the local part (before the @) and the domain. The domain uses Punycode encoding for DNS compatibility. An address like 用户@例子.广告 is now technically valid, though support in mail servers and clients is still uneven.