What this RFC defines
RFC 6532 defines how UTF-8 can be used natively in email message headers for internationalized email. Before RFC 6532, non-ASCII characters in headers required RFC 2047 encoded-word syntax. RFC 6532 allows UTF-8 characters to appear directly in header values when the message is transmitted via a SMTPUTF8-capable SMTP path.
Where you see it in practice
In a fully internationalized email system, a From: header could contain the sender’s name in their native script without any encoded-word escaping, such as From: Yamada Taro <yamada@example.jp> with the name in Japanese characters directly. RFC 6532 makes this possible for EAI-capable mail paths. For systems that do not support EAI, RFC 2047 encoded-words remain the only option for non-ASCII in headers.
How it connects to other RFCs
RFC 6532 obsoletes RFC 5335 and is part of the EAI suite alongside RFC 6530 (framework) and RFC 6531 (SMTPUTF8). It extends RFC 5322 (message format) to allow UTF-8 in headers. Delivering messages with UTF-8 headers to non-EAI-aware systems requires downgrading per RFC 6533.
Current status
RFC 6532 is a current standard, published February 2012. It is the header complement to RFC 6531’s envelope changes for internationalized email. Full support requires end-to-end SMTPUTF8 capability across the delivery path, which limits its deployment to EAI-aware environments.
UTF-8 in message headers
RFC 6532 extends RFC 5322 (the message format standard) to allow UTF-8 directly in header field values. Before RFC 6532, non-ASCII characters in headers required RFC 2047 encoded-word syntax: Subject: =?UTF-8?Q?Caf=C3=A9?=. With RFC 6532, a mail client that knows both endpoints support it can simply write Subject: Café. This is cleaner, more efficient, and easier to debug in raw message traces.
When to use raw UTF-8 versus encoded-words
RFC 6532 does not deprecate encoded-words; both are permitted. The choice depends on knowledge of downstream support. For mail sent within an environment where SMTPUTF8 and RFC 6532 are known to be supported (enterprise Exchange, modern webmail providers), raw UTF-8 is cleaner. For internet-facing mail where any hop might lack support, encoded-words remain safer. Most modern mail libraries generate encoded-words by default and only produce raw UTF-8 when explicitly configured or when the receiving MTA advertises SMTPUTF8.
Interaction with DKIM
RFC 6532 UTF-8 headers interact with DKIM signing carefully. The signature covers the header bytes as transmitted; if any hop rewrites UTF-8 to encoded-word (or vice versa) for compatibility, the DKIM signature will fail. This is why RFC 8616 later clarified how DKIM should handle internationalized headers and why some receivers apply looser DKIM checking to messages with SMTPUTF8 involvement. If your DKIM signatures fail on internationalized mail, header canonicalization in transit is a likely cause.
RFC 6532 (February 2012) extends RFC 5322 Internet Message Format to allow UTF-8 directly in message headers. Complements RFC 6531 SMTPUTF8: RFC 6531 says the transport can carry UTF-8; RFC 6532 says the headers can contain UTF-8. Together they enable native internationalized email: From: 田中 <user@例え.jp> written directly rather than From: =?UTF-8?B?55Sw5Lit?= <user@xn--r8jz45g.jp>. Only valid when SMTPUTF8 was negotiated for the transaction.
RFC 6532 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Allow UTF-8 characters directly in RFC 5322 header field values |
| Scope | Header content only; message structure (CRLF, field-name colons, folding) unchanged |
| Prerequisite | SMTP session must have negotiated SMTPUTF8 |
| Alternative for non-SMTPUTF8 paths | RFC 2047 encoded-word syntax |
| Encoding | UTF-8 bytes directly in header values (no encoded-word wrapping) |
| Field names | Remain ASCII (only field values may contain UTF-8) |
| Published | February 2012 |
RFC 6532 UTF-8 vs RFC 2047 encoded-word
| Aspect | RFC 2047 encoded-word | RFC 6532 UTF-8 direct |
|---|---|---|
| Format | =?UTF-8?B?SGVsbG8=?= | Hello (raw UTF-8 bytes) |
| Requires SMTPUTF8? | No (7-bit safe) | Yes (must be negotiated) |
| Human readability in source | Encoded, hard to read | Native, easy to read |
| Size overhead | ~33-40% (base64) or higher (quoted-printable) | 0% (native) |
| Legacy client compatibility | Universal (since 1996) | Modern clients only (post-2015 broad adoption) |
| Where used | Display names, Subject, comments | Any header value once SMTPUTF8 in effect |
Header comparison: encoded vs UTF-8 direct
Common RFC 6532 handling mistakes
Related standards and further reading
- RFC 6531: SMTPUTF8 (the transport prerequisite)
- RFC 6533: Internationalized DSN and MDN
- RFC 5337: Internationalized DSN and Disposition Notifications
- RFC 5890: IDNA 2008 for domain names
- RFC 6530: Overview of internationalized email
- RFC 5322: Message Format (base standard extended)
- RFC 2047: Encoded-word syntax (legacy alternative)
- RFC 6531 SMTPUTF8 Guide: transport-side companion
- RFC 5322 Guide: message format base standard
- Message-ID Header: ASCII-safe correlation identifier
Frequently asked questions
Can I use UTF-8 in my Subject header?
Two paths. If SMTPUTF8 is negotiated (per RFC 6531), you can write UTF-8 directly in Subject per RFC 6532. If SMTPUTF8 is not available, encode with RFC 2047 encoded-word syntax (=?UTF-8?B?base64content?=). Modern mail clients render both identically. For maximum compatibility with older systems, use encoded-word.
Why do some UTF-8 messages fail DKIM verification?
Intermediate MTAs occasionally convert between UTF-8 direct and RFC 2047 encoded-word representations, changing the byte content of signed headers. This invalidates DKIM signatures covering those headers. Solutions: sign fewer headers (exclude Subject and display names from h= tag), use relaxed canonicalization (survives some but not all changes), or accept that internationalized mail has slightly higher DKIM failure rates through certain paths.
What is Unicode normalization and does it matter for RFC 6532?
Unicode allows the same visible text in multiple byte sequences (e.g., é as U+00E9 single code point vs U+0065 U+0301 combining). Normalization forms (NFC, NFD, NFKC, NFKD) standardize the representation. For header content, RFC 6532 recommends NFC when generating fresh headers. For equality comparison, normalize both sides to the same form before comparing. Do not aggressively normalize headers in transit; preserve what the sender wrote.
Can I mix UTF-8 direct and encoded-word in the same header?
Technically legal per RFC 6532, but discouraged. Parsers can get confused by mixed representations, particularly around whitespace between encoded-word segments. Emit consistently: fully UTF-8 direct (when SMTPUTF8 negotiated) or fully encoded-word (for legacy safety). Mixing produces messages that render correctly in modern clients but occasionally break in older ones.
Does RFC 6532 affect body content?
No. RFC 6532 covers header field values. Message bodies have always supported arbitrary content encoded per MIME (RFC 2045) with declared Content-Type and Content-Transfer-Encoding. RFC 6532’s contribution is header-level: it lets headers carry the same UTF-8 content that MIME already allowed in bodies.
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.
