RFC 6531 – 国际化电子邮件的SMTP扩展
ELI5: 传统电子邮件地址只能使用英文字母、数字和少数符号。这意味着全球数十亿人无法用自己的文字拥有电子邮件地址——没有汉字、没有阿拉伯文、没有西里尔文。SMTPUTF8 通过扩展 SMTP 来处理完整的 Unicode 从而解决了这个问题，这样人们可以拥有诸如 `émilie@exemple.fr` 这样的地址，或用印地语、日语或任何其他书写系统的地址。
这个RFC为什么存在
电子邮件设计于ASCII时代。原始SMTP规范（RFC 5321）将电子邮件地址和信封命令限制为7位ASCII字符。这对英文来说很好，但排除了世界上大多数语言。像田太郎@例.jp这样的电子邮件地址根本不可能。
RFC 6531定义了SMTPUTF8扩展，允许在SMTP信封中使用UTF-8编码——特别是在MAIL FROM、RCPT TO和EHLO域中。这是一套统称为电子邮件地址国际化(EAI)的RFC的一部分，也包括用于国际化邮件头的RFC 6532。
这个扩展为Unicode支持的每个文字系统开放了电子邮件，这对全球电子邮件采用至关重要。
工作原理
- 客户端发送
EHLO并确认服务器在其能力列表中通告SMTPUTF8。 - 发送包含非ASCII地址的消息时（在信封、头部或两者中），客户端将
SMTPUTF8参数添加到MAIL FROM命令。 MAIL FROM和RCPT TO地址现在可以包含UTF-8字符。- 消息头也可以包含UTF-8(根据RFC 6532)，替代旧的RFC 2047编码字变通方法。
- 如果下一跳服务器不支持SMTPUTF8，发送服务器必须降级消息或拒绝它——它不能默默地去除国际字符。
SMTP示例
发送具有国际化地址的消息：
S: 220 mx.example.com ESMTP
C: EHLO sender.example.net
S: 250-mx.example.com
S: 250-SMTPUTF8
S: 250-8BITMIME
S: 250-STARTTLS
S: 250 SIZE 52428800
# 使用国际化地址时需要SMTPUTF8参数
C: MAIL FROM:<émilie@exemple.fr> SMTPUTF8
S: 250 2.1.0 OK
C: RCPT TO:<田太郎@例.jp>
S: 250 2.1.5 OK
C: DATA
S: 354 Start mail input
C: From: Émilie Dupont <émilie@exemple.fr>
C: To: 田太郎 <田太郎@例.jp>
C: Subject: Meeting confirmation
C: Date: Wed, 11 Mar 2026 10:00:00 +0100
C: MIME-Version: 1.0
C: Content-Type: text/plain; charset=UTF-8
C:
C: Confirming our meeting for next week.
C: .
S: 250 2.0.0 OK, queued
关键技术细节
SMTPUTF8参数
MAIL FROM上的SMTPUTF8关键字表示此消息使用国际化内容。以下任何包含非ASCII字符时都必须存在：
MAIL FROM地址- 任何
RCPT TO地址 - 消息头(From、To、Cc、Reply-To等)
如果未声明SMTPUTF8参数且信封包含非ASCII字符，服务器必须拒绝该命令。
域名：IDN和UTF-8
国际化域名多年来一直使用Punycode编码存在(例如，xn--e1afmapc.xn--p1ai对应пример.рф)。SMTPUTF8允许在SMTP中直接使用域名的UTF-8形式，尽管Punycode(A-标签)仍然有效。对于DNS查询，域名仍必须转换为其A-标签形式。
降级和回退
SMTPUTF8最大的挑战是与不支持它的服务器的互操作性。将消息中继到非SMTPUTF8服务器时：
- 如果消息可以降级(例如，仅显示名称包含非ASCII，地址本身是ASCII)，服务器可以执行降级转换。
- 如果信封地址本身包含非ASCII字符，降级是不可能的——消息无法传递到该服务器。发送服务器必须生成退回。
与身份验证的交互
电子邮件身份验证机制需要针对国际化地址的更新：
- SPF：使用MAIL FROM中的域名。如果域名是国际化的，必须将其转换为A-标签形式以进行DNS查询。
- DKIM：签名和验证头部。使用SMTPUTF8，头部可能包含原始UTF-8，因此DKIM实现必须正确处理此问题。
- DMARC：域名对齐检查必须考虑同一域名的UTF-8和A-标签形式。
常见错误
-
遗漏SMTPUTF8参数。如果消息在地址或头部中包含任何非ASCII字符，必须在
MAIL FROM命令上包含SMTPUTF8。忘记它会导致服务器拒绝地址。 - 假设普遍的SMTPUTF8支持。采用率在增长但不普遍。截至2025年，Gmail和Outlook等主要提供商支持SMTPUTF8，但许多较小的服务器不支持。发送基础设施必须优雅地处理回退。
- 不为DNS查询转换域名。即使使用SMTPUTF8，DNS查询也需要国际化域名的A-标签(Punycode)形式。可以在SMTP信封中使用UTF-8，但MX/A/AAAA查询必须使用ASCII兼容编码。
- 存储国际化地址时不进行规范化。Unicode对相同字符有多种表示(例如，组合形式对分解形式)。对电子邮件地址使用NFC规范化以确保一致的匹配和去重。
- 默默地去除非ASCII字符。如果系统无法处理国际化地址，必须干净地拒绝它们——永远不要通过删除字符来默默修改地址。这会改变收件人。
- 遗忘退回地址。如果发件人地址是国际化的且消息退回，退回也必须通过SMTPUTF8发送。如果退回路径不支持SMTPUTF8，退回会丢失。
可传递性影响
- 覆盖全球受众。SMTPUTF8支持表明发送基础设施是现代和包容性的。随着国际化地址变得更加普遍，支持它们成为基线期望。
- 退回处理复杂性。发送到国际化地址的消息可能会以不同方式退回，如果中间服务器不支持SMTPUTF8。退回处理必须处理ASCII和UTF-8地址。
- 身份验证对齐。SPF、DKIM和DMARC都必须与国际化域名正确配合。UTF-8和A-标签表示之间的不匹配可能导致虚假身份验证失败。
- 主要提供商支持强劲。Gmail、Microsoft 365和其他主要平台接受SMTPUTF8消息。从国际化地址发送的支持在迅速扩展。
- 面向未来。使用非ASCII字符的电子邮件地址比例只会增长。现在投资SMTPUTF8支持可防止随着全球采用增加而出现的可传递性差距。