RFC 5322 – 网络邮件格式

Current Standard Core SMTP & Message Format Obsoletes RFC 2822 Published March 2026

ELI5: 如果RFC 5321（SMTP）是运送信件的邮政卡车，那么RFC 5322就是信件本身的格式——在这里你写上回邮地址、收件人地址、日期、主题行，然后是下面的实际信息。你在收件箱中打开的每封电子邮件都是根据这个规范构建的。

为什么存在这个 RFC

RFC 5322 定义了电子邮件的语法——在 SMTP DATA 阶段流动的文本。它的前身 RFC 822（1982）是最早的互联网标准之一。RFC 5322 用更严格的语法规则、更清晰的过时语法处理和与现代实践的一致性更新了这种格式。

这个 RFC 纯粹关于消息格式——它对消息如何被传输（这是 RFC 5321）或附件如何工作（这是 RFC 2045 和 MIME 系列）一无所知。它定义了头字段、正文以及地址、日期和消息识别的规则。

工作原理

电子邮件分为两部分，由空白行分隔：

头部分：一系列头字段，每个格式为 名称: 值，以 CRLF 结尾。
正文：消息内容，只是非结构化的文本（MIME 在其上添加结构）。

消息结构

# 头部分 From: Alice Smith <alice@example.com> To: Bob Jones <bob@example.net>, Carol White <carol@example.org> Cc: Dave <dave@example.com> Subject: Quarterly Report Date: Wed, 11 Mar 2026 15:30:00 -0500 Message-ID: <unique-id-12345@example.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" # 空白行将头与正文分隔 Hi Bob and Carol, Please find the quarterly report attached.

必需头字段

RFC 5322 规定每条消息都必须包含这些字段：

字段	说明	示例
`From:`	消息的作者	`From: Alice <alice@example.com>`
`Date:`	消息的撰写时间	`Date: Wed, 11 Mar 2026 15:30:00 -0500`

此外，每条消息都应该包含 Message-ID 字段——全局唯一标识符。没有 Message-ID 的消息会导致线程化、去重和 DKIM 签名的问题。

常见头字段

字段	用途
`To:`	主要收件人
`Cc:`	抄送收件人
`Bcc:`	密件抄送（传递前删除）
`Subject:`	消息主题
`Reply-To:`	回复地址（覆盖 From:）
`Sender:`	实际发件人，当 From: 包含多个作者或与传输代理不同时
`In-Reply-To:`	被回复消息的 Message-ID
`References:`	用于线程化的 Message-ID 链
`Message-ID:`	此消息的全局唯一标识符
`Return-Path:`	由最终传递系统从 MAIL FROM 添加
`Received:`	由处理消息的每个服务器添加的跟踪头

关键技术细节

地址格式

RFC 5322 定义了两种有效的地址格式：

地址规范：alice@example.com——仅邮箱。
名称地址：Alice Smith <alice@example.com>——显示名称加尖括号括起的地址。

包含特殊字符的显示名称必须加引号："O'Brien, Alice" <alice@example.com>。本地部分（@ 前）在规范中区分大小写，但实际上被几乎所有邮件系统视为大小写不敏感。

日期格式

日期格式是特定且严格的：

Date: Thu, 11 Mar 2026 15:30:00 -0500

格式为：星期几, DD Mon YYYY HH:MM:SS 时区。星期几是可选的但约定俗成。时区必须是数字偏移（-0500），不是像"EST"这样的名称。虽然规范容忍旧时区缩写作为过时语法，但生成它们不被推荐。

Message-ID 格式

Message-ID 必须全局唯一，格式如下：

Message-ID: <unique-part@domain>

最佳做法是使用基于 UUID 或时间戳的唯一部分与您的发送域结合：<20260311153000.a1b2c3@mail.example.com>。

头折叠

长头值可以通过插入 CRLF 后跟至少一个空格或制表符（空白）来"折叠"。这是长收件人列表或主题行保持在 998 字符行限制内的方式：

To: Alice <alice@example.com>, Bob <bob@example.com>, Carol <carol@example.com>

解析器必须通过连接以空白开头的行来"展开"这些。

跟踪头

处理消息的每个邮件服务器都会添加一个 Received: 头。这些形成从上到下的跟踪——最顶部的 Received: 头最后添加。Return-Path: 头仅由最终传递系统添加，包含来自 MAIL FROM 的信封发件人。

常见错误

缺少或格式错误的 Date 头。一些垃圾邮件过滤器会处罚没有适当 Date 头或日期在未来/过去的消息。始终在发送时生成它。
缺少 Message-ID。没有唯一的 Message-ID，回复不会正确线程化，DKIM 签名可能不覆盖该字段，一些垃圾邮件过滤器会标记消息。
不正确的地址引用。包含逗号、句号或特殊字符的显示名称必须加引号。O'Brien, Alice <alice@example.com>无效——必须是 "O'Brien, Alice" <alice@example.com>。
使用密件抄送不正确。BCC 头在传输前应被剥离。如果在传递的头中包含密件抄送收件人，您已破坏密件抄送的目的。
超过行长度。头行和正文行不得超过 998 个字符。对长头使用头折叠，对长正文内容使用适当的 MIME 编码。
混淆 From 和 Sender。Sender: 头仅在实际传输实体与 From: 作者不同时才需要。不要添加与 From 匹配的冗余 Sender 头——它是不必要的，会令过滤器困惑。
时区格式错误。使用 EST 而不是 -0500 是过时语法。始终使用数字偏移。

可递送性影响

DKIM 签名取决于头。DKIM（RFC 6376）签名特定头字段。缺少或格式错误的头意味着签名可能不覆盖您期望的内容，或消息可能验证失败。
DMARC 对齐检查 From 头。DMARC（RFC 7489）将 From: 头中的域与 SPF 和 DKIM 结果进行比较。不匹配或缺少 From 头意味着自动 DMARC 失败。
线程化和用户体验。适当的 Message-ID、In-Reply-To 和 References 头确保您的消息在收件人邮件客户端中正确线程化。损坏的线程使您的消息看起来不专业。
垃圾邮件过滤器启发式。过滤器检查 RFC 5322 合规性。缺少必需头、格式错误的日期和非标准格式都是增加垃圾邮件评分的负信号。
显示名称欺骗。邮箱提供商越来越多地在 From 地址看起来可疑时显示警告。使用干净、一致的 From 头和可识别的显示名称提高打开率和信任度。