SMTPUTF8 and internationalized email, end to end — where Unicode addresses actually break
Flipping on SMTPUTF8 is a one-line change. Surviving the delivery path is not. EAI is all-or-nothing at the envelope level: one hop that doesn't advertise SMTPUTF8 bounces the whole message with 5.6.7, and there's no silent downgrade for a Unicode local part. Here's how to make it work across all five layers of your stack, and exactly where it can't.
EvilMail TeamJuly 31, 202612 min read
A user signs up as señor.josé@correo.example, your platform stores it cleanly, and then the welcome mail bounces:
550 5.6.7 SMTPUTF8 required but not supported by remote host
Nothing is misconfigured on your side. The address is valid per RFC 6531. Your MTA advertised SMTPUTF8 in its EHLO. The problem is the next hop — a mid-market gateway or an old Exchange build — didn't, and a Unicode local part cannot be written onto a wire that hasn't agreed to carry it. That single bounce is the whole EAI story: the standard is over a decade old, the code ships in every modern MTA, and the failure mode is a cliff, not a slope.
The job isn't "turn on SMTPUTF8." The job is making Unicode survive five layers — submission, envelope, headers, transport, and mailbox/IMAP — and knowing precisely where it can't. This is a plumbing problem, and the plumbing has two halves that people constantly conflate.
The three things EAI changes (and the one it doesn't)
First, kill the most common confusion.
Internationalized Domain Names (IDN)
and
Email Address Internationalization (EAI)
are different machines.
IDN is the domain half only. It's been solved since IDNA2008: münchen.example is stored and displayed as a U-label but always converted to the ASCII A-labelxn--mnchen-3ya.example before it touches DNS. Nothing about the SMTP transport changes. This has worked in browsers and resolvers for fifteen years.
EAI is the harder half. It adds three genuinely new things:
UTF-8 in the local part — the bytes before the @. josé@… where josé is real UTF-8, not encoded. This is what requires SMTPUTF8 (RFC 6531).
UTF-8 directly in header field bodies — From:, To:, Subject: carry raw UTF-8 per RFC 6532, replacing the old RFC 2047 =?utf-8?B?…?= encoded-words.
UTF-8 mailbox names and retrieval — IMAP UTF8=ACCEPT (RFC 6855) and POP3 UTF8 (RFC 6856), so the mail server can hand you a message whose envelope was never ASCII.
And the thing it does not change: the domain half is still ASCII on the wire. Always. The local part goes out as UTF-8; the domain gets A-labeled for the DNS query. señor@münchen.example travels as a UTF-8 local part señor plus the A-label xn--mnchen-3ya.example. Two encodings, one address, and if you treat them the same you will corrupt one of them.
The RFC family, so you can map features to specs:
RFC 6530 — the EAI framework and overview
RFC 6531 — SMTPUTF8, the SMTP extension
RFC 6532 — internationalized email headers
RFC 6533 — internationalized DSNs and the ALT-ADDRESS parameter
RFC 6855 / 6856 — IMAP UTF8=ACCEPT and POP3 UTF8
RFC 6857 / 6858 — downgrade and post-delivery downgrade
RFC 5890–5894 + UTS-46 — IDNA2008 and the mapping rules for the domain half
The SMTP dialogue: EHLO → SMTPUTF8 → MAIL FROM
SMTPUTF8 is a single per-message flag, negotiated once, not per-recipient. The server advertises it in the EHLO response; a client that has any non-ASCII byte anywhere in an envelope address — or in a header it will send as raw UTF-8 — must append the SMTPUTF8 parameter to MAIL FROM. Here's a real session:
EHLO client.example
250-mx.evilmail.pro
250-8BITMIME
250-SMTPUTF8
250 SIZE 52428800
MAIL FROM:<señ[email protected]> SMTPUTF8 BODY=8BITMIME
250 2.1.0 Ok
RCPT TO:<[email protected]>
250 2.1.5 Ok
Note the coupling with 8BITMIME. A UTF-8 header body is 8-bit content, so you assert BODY=8BITMIME alongside SMTPUTF8. And here's the trap that surprises people: a UTF-8 subject line forces SMTPUTF8 even when both addresses are pure ASCII. If [email protected] mails [email protected] with Subject: tëst emitted as raw UTF-8 per 6532, the message is now an EAI message and needs the flag. That's why "we don't have any international users" is not a reason to leave SMTPUTF8 off.
The domain half is a different machine: IDNA2008 and A-labels
DNS never sees Unicode. When your MTA resolves the MX for münchen.example, it queries the A-label:
The rule that keeps you sane: do the A-label conversion at the DNS lookup boundary only. Not in your database, not in your account records, not in the visible envelope. Store and display the U-label; punycode it the moment before you hit the resolver, and nowhere else. If you punycode into storage you'll be decoding it back for every UI render and every comparison, and you'll get it wrong on the edges.
Those edges are real. IDNA2008 is not idempotent under naive lowercasing. German ß, Greek final sigma ς, and zero-width joiners behave differently under IDNA2008 versus the older IDNA2003/UTS-46 mapping. str.lower() followed by a punycode call will silently produce a label that resolves to the wrong host or fails to round-trip. Use a real IDNA library that implements IDNA2008 with the UTS-46 mapping you've deliberately chosen — never hand-rolled lowercase-and-encode.
One operational aside: mixed-script and confusable labels (раypal.example with a Cyrillic а) are a homograph risk. Decide your policy — reject mixed-script labels at registration, or flag them — before someone uses your platform to spoof one.
Turning it on: Postfix and Dovecot config that works
Postfix has shipped SMTPUTF8 on by default since 3.0 (2015). Confirm it rather than assuming:
smtputf8_autodetect_classes governs when Postfix asserts SMTPUTF8 for locally-submitted mail — the sendmail and verify classes cover sendmail(1) submission and address verification probes. On Exim, SMTPUTF8 is advertised via smtputf8_advertise_hosts (default *) and downgrade behavior is controlled by utf8_downconvert; keep accept_8bitmime on and don't gate the extension behind an over-zealous ACL.
Dovecot must advertise UTF8=ACCEPT so IMAP clients can request internationalized mailbox names and messages:
bash
doveconf -n | grep -i utf8
Maildir stores UTF-8 filenames natively — on ext4 or xfs there is no problem keeping a Unicode local part in the path. The legacy trap is folder names: classic IMAP (RFC 3501) encodes mailbox names as modified UTF-7. Do not double-encode. If your provisioning writes a modified-UTF-7 folder name and then Dovecot re-encodes, you get garbage folders.
For storage layout — on evilmail the vhosts live under /var/mail/vhosts/{domain}/{user}/, owned by uid/gid 5000 — key the {domain} directory on the A-label and keep {user} as NFC-normalized UTF-8. And normalize on ingest, always: é can arrive as a single code point U+00E9 or as e + combining acute U+0301. They render identically and are different byte strings. Without NFC normalization at signup you will create two mailboxes for what the user thinks is one account.
The downgrade cliff — this is the section that matters
Here is the core asymmetry of EAI, and the reason it's operationally dangerous.
An 8-bit body can always be downgraded. If the next hop lacks 8BITMIME, the sending MTA re-encodes the body to quoted-printable and delivers it. Lossless, automatic, invisible.
A Unicode envelope address cannot be downgraded. If the next hop's EHLO lacks SMTPUTF8 and your message has señor@… in MAIL FROM or RCPT TO, that address literally has no ASCII representation to put on that wire. RFC 6533 defined an optional ALT-ADDRESS parameter so a sender can supply an ASCII alternative — but in practice almost nobody populates it, so treat it as unavailable. The result is a hard bounce:
550 5.6.7 Internationalized addresses require SMTPUTF8,
not supported by remote host
You'll also see 5.6.9 and occasionally a 553. This is the diagram below made concrete.
The practical consequence: don't accept EAI-only signups for accounts you'll need to reach at arbitrary third parties unless you also capture an ASCII contact address. If a customer's only address is a Unicode local part, every one of your transactional mails is one non-EAI hop away from a permanent bounce, and you have no fallback path.
Provider reality check for 2026: Gmail and Google Workspace accept inbound EAI broadly. Full send-and-reply round trips remain uneven across mid-market providers, older Exchange builds, and the security gateways that sit in front of them. The receiving story is good; the "reply lands back in your Unicode inbox" story is still patchy.
One more downgrade hazard: DSNs. RFC 6533 status reports use UTF-8 fields. If a non-EAI reporting MTA generates the bounce, it downgrades the DSN and can mangle the original Unicode recipient in the report you receive — so the bounce that tells you an address failed may itself misrender that address.
Then check the delivered message: headers must arrive as raw UTF-8, not =?utf-8?B?…?=. Mixing an RFC 2047 encoded-word display name with an RFC 6532 Unicode address is a classic bug — pick one, and when SMTPUTF8 is negotiated, always emit raw UTF-8. The Message-ID right-hand side, however, must stay ASCII/A-label. Finally, idn2 the domain to sanity-check the exact A-label your MTA will query.
Operator checklist
Advertise SMTPUTF8 and 8BITMIME; verify with postconf smtputf8_enable and a swaks … --quit-after EHLO.
NFC-normalize local parts on ingest — before storage, before dedup, before mailbox creation.
Convert domains to A-labels at the DNS lookup boundary only; store and display the U-label.
Use a real IDNA2008 library, never lower() + punycode — ß, final sigma and ZWJ do not round-trip naively.
When SMTPUTF8 is negotiated, emit raw UTF-8 headers; never RFC 2047-encode. Keep the Message-ID domain ASCII.
Capture an ASCII fallback contact for any account whose primary address has a Unicode local part.
Alert on 5.6.7 / 5.6.9 bounce-rate spikes — a spike means a downstream hop dropped SMTPUTF8.
Confirm Dovecot advertises UTF8=ACCEPT, avoid double-encoding modified-UTF-7 folder names, and eyeball the webmail UI for mojibake — that's where clean UTF-8 quietly dies.
