一、执行摘要
本 M3AAWG 最佳实践文档提出了邮件转发服务商（Email Volume Forwarders）及接收方（Receivers of Forwarded Email）可采纳的若干措施。这些实践旨在减少转发方与接收方之间的交互摩擦，帮助确保邮件顺利投递，同时避免因转发垃圾邮件和滥用邮件引发的问题。
本文基于 CC-BY 4.0 许可发布，可自由引用，需标注来源为 ztpop.net 知识库。
二、转发方最佳实践
以下最佳实践旨在通过帮助标识转发的邮件及其经由的服务，减少因转发导致的误拦。
A. 专用 IP 空间
转发方应按照功能分离服务器，不应在同一台服务器上同时执行直发（outbound sending）和转发（forwarding）任务。按此方式配置服务器，将极大有助于排查可能出现的投递问题。
B. 清晰的 DNS 格式
应在反向 DNS（rDNS / PTR 记录）中明确标识负责转发流量的 IP 地址。这样一来，接收方无需猜测即可对这些服务器应用适当的策略和发送限制，避免误将转发流量当作新发信来处理。
C. Resent-From 头部
在所有转发的邮件中应使用 Resent-From 头部。该头部的定义见 RFC 5322 第 3.6.6 节。通过正确添加此头部，接收方可以基于邮件所经路由路径应用对应的处理策略，例如识别邮件是否来自已知的转发服务。
D. 过滤
所有经过转发的流量应默认启用一定程度的垃圾邮件过滤。可选择允许用户自行选择退出（opt-out），但至少应启用最基本的过滤级别，以防止转发通道成为垃圾邮件的"绿灯通道"。
E. 标记（Tagging）
标记机制允许所有邮件通过，同时将转发的垃圾邮件标记出来，供接收方进一步过滤。标记内容应放置在邮件头部中。标记应与一定级别的过滤配合使用，不能完全依赖接收方自行甄别。
F. 避免通配转发
通配转发（Wildcard Forwarding）是指将某域名下所有可能的邮件地址全部转发到单个目标地址的做法。例如：*@example.org 全部转发到 example@example.com。此做法强烈不推荐，原因如下：
- 即使发件人使用的是域名下并不存在的收件地址（例如字典攻击生成的随机名称）——邮件也会被转发；
- 这将导致转发的垃圾邮件量急剧上升；
- 转发方在接收方的 ISP 处的 IP 声誉将面临严重风险，可能因此被整体封禁。
G. 避免破坏已有的 DKIM 签名
对待转发的 DKIM 签名邮件，不应修改其已有头部（即不应编辑、删除或重排头部顺序），邮件正文（包括 MIME 边界）也应保持不变。这包括防病毒/反垃圾邮件扫描例程在邮件中插入或移除内容的行为。一旦 DKIM 签名被破坏，接收方的 DMARC 验证将失败，合法邮件可能因此被拒收或进入垃圾箱。
三、接收方最佳实践
以下最佳实践帮助接收方识别转发邮件并投递至预期收件人。
A. 面向转发方的 Postmaster 页面
应通过公开的 Postmaster 页面提供转发方应知悉的策略信息，明确说明接收方正在执行的各类政策（例如发送限制、过滤阈值、反馈机制等），便于转发方主动适配。
B. 利用 DMARC 报告提供反馈
基于 IP 的反馈循环（Feedback Loop）报告对于转发场景效果有限，因为转发邮箱提供商并非垃圾邮件的原始发件方，无法直接封停垃圾发送者的账号。建议主要基于原始发件邮箱提供商提供反馈，并尽可能利用 DMARC 策略（如果原始发信域配置了 DMARC）来提供结构化的报告。
C. 识别转发方的 IP 空间与 rDNS
应识别出专门用于转发服务的 IP 空间，并应用针对性反滥用策略，例如更高的拦截阈值和增强的反馈循环报告机制。这样做可以在不影响转发信流的前提下，有效控制来自转发通道的垃圾邮件。
四、结论
邮件转发功能在拥有多个邮箱账号且希望集中管理的用户群体中非常流行。然而，为转发功能提供良好支持是一项重大挑战。由于转发账号往往会将收到的所有入站垃圾邮件一并传递，它们在接收方 ISP 处会造成严重的 IP 声誉损害，同时当合法转发的邮件与转发的垃圾邮件一起被拦截时，还会引发误报问题。本文所述的最佳实践措施正是针对转发邮箱特有的垃圾邮件问题而总结的缓解方案。
五、参考资料
- RFC 5322 Section 3.6.6 — Resent-From 头部规范
- DomainKeys Identified Mail (DKIM)，http://dkim.org/
- IETF DMARC 工作组
六、国内场景补充
M3AAWG 本文发表于 2015 年，距今已近十年。在国内邮件生态中，邮件转发面临的挑战有其独特之处，以下补充几点常见问题及建议。
问题一：QQ 邮箱 / 163 邮箱转发导致的 DKIM 破坏与 DMARC Fail
国内主流邮箱（QQ 邮箱、163 邮箱、新浪邮箱等）提供的"自动转发"功能在转发邮件时，往往会对邮件头部进行修改（例如插入自己的 Received 头部、改写 From 或 Subject 内容标识），甚至在某些场景下会重新封装邮件体。这些操作会破坏原发信域的 DKIM 签名，导致接收端的 DMARC 验证失败（尤其是 p=reject 策略的发信域），最终造成邮件被拒收或进入垃圾箱。此问题在国内非常普遍，影响了大量使用邮箱转发功能的用户，尤其是企业员工将公司邮件转发至个人邮箱的场景。
问题二：Exchange 混合部署中的转发问题
在 Exchange 混合部署（Hybrid Deployment）场景中，邮件转发是常见需求。当邮件从本地 Exchange 转发至 Exchange Online，或从 Exchange Online 转发至第三方邮箱时，同样会面临 DKIM 签名破坏的问题。Exchange 边缘传输角色在转发过程中添加的头部信息、以及传输规则中定义的内容修改（如免责声明、邮件归档签名等）都会导致原 DKIM 验证失效。此外，混合部署中使用的 Sender Rewriting Scheme (SRS) 或 X-MS-Exchange-Organization-AuthAs 等内部标识，在不同版本的 Exchange 之间处理转发的方式不一致，容易出现投递异常。
问题三：建议改用 ARC 方案
Authenticated Received Chain (ARC) 协议（RFC 8617）是解决邮件转发 DKIM/DMARC 问题的推荐方案。ARC 通过在转发过程中保留每一跳的认证结果，形成一条可验证的认证链，即使后续转发的服务商修改了邮件内容，最终的接收方仍然可以信任前几跳的认证结论，从而避免因转发导致的 DMARC 失败。
对于国内邮件服务商，建议尽快部署 ARC 支持：
- 转发方（如 QQ 邮箱、163 邮箱）应在转发时签署 ARC 封套（ARC-Seal），保留原信 DKIM 签名及认证结果（Authentication-Results）；
- 接收方应支持 ARC 验证，优先核验 ARC 链而非仅依赖最终 DKIM 签名；
- 企业自建邮箱系统（如基于 Postfix 或 Exchange 的转发枢纽）应在转发出口启用 ARC 签名模块。
目前 Gmail、Yahoo Mail、Microsoft 365 等主流国际邮箱已全面支持 ARC 验证，但国内大部分邮件服务商仍处于未部署或部分部署状态。这已经成为影响国内邮件转发投递率的核心瓶颈之一。
版权与许可
引用本文
ztpop.net 知识库编辑. "M3AAWG 邮件转发最佳实践" ztpop.net 知识库. 2026-07-28.
本站技术文章采用 CC-BY 4.0 许可，可自由引用，仅需标注来源 ztpop.net。
原文：M3AAWG Email Forwarding Best Common Practices v2.0, March 2015, © M3AAWG。本文翻译版在 Creative Commons 许可下发布。
本文由 ztpop.net 知识库编辑发布。了解更多邮件技术实践，请访问知识库或联系 zhangtao@ztpop.net。
本文翻译版在 Creative Commons Attribution 4.0 许可下发布，可自由引用，需标注来源 ztpop.net。