邮件列表的作用通常不仅仅是将邮件复制到另一个地址。它可能会更改信封、添加主题前缀、附加页脚、重写可见作者或添加自己的签名。这些选择会影响不同的身份验证路径和用户期望。将列表诊断为具有记录行为的重新分发服务，而不是作为无法解释的异常 DMARC.
盘点列表转换
参考： RFC 7960 §3.2.3.
获取一份经授权的原始提交内容和一份重新分发的副本。记录列表软件和配置、订阅或审核状态、信封身份和相关信息 消息头。比较处理前后的正文和签名标头。确定哪些更改对于社区来说是必要的，哪些是可以删除的偶然默认值。
RFC 7960 描述了间接流中的互操作性挑战。使用它进行问题分析，同时应用当前的DMARC规范 RFC 9989。缓解措施的历史讨论并不能证明特定的当前提供商接受该列表的实施。
单独的作者和再发行者身份
参考： RFC 9989 §4.4, RFC 7960 §4.1.3.1.
列表信封可以支持列表域下的退回处理。那 SPF 身份通常与原作者的发件人身份不同。列表域 DKIM签名 可以验证重新分发的消息，但同样不会自动与作者域对齐。如果原始对齐的DKIM签名保持不变，它仍然可以提供所需的路径。
将可见的 From 重写到列表控制的域中会更改评估DMARC所依据的身份。它还会改变收件人所看到的内容。检查回复行为、归属、可访问性和回复处理，而不是仅将重写视为DNS技巧。请勿暗示该列表拥有或可以签署作者的域名。
比较受控结果
参考： RFC 9989 §5.3.5.
检查点模型包含保留转发情况、页脚修改情况和列表重写情况。在最后一种情况下，可见的From、经过身份验证的信封和签名域都使用list.example ，因此严格的身份比较通过。结果并没有说明真实列表是否执行了加密签名，或者用户是否认为结果表示可以接受。
原始样本消息和哈希比较是合成的。它们不包含真实的列表提交、生产退回跟踪或接收者生成的身份验证结果。保留的证据包括下面的历史直接与列表本地交付对；生产清单行为仍未得到验证。在审查拟议的推出时，请明确这一差距。
选择支持的操作模式
参考： RFC 7960 §4.1.3.3, RFC 8617 §7.2.1.
首先测试列表是否可以保留签名内容而不删除所需的社区功能。如果不能，请与列表所有者一起评估支持的作者重写或特定于提供者的处理。 ARC 可能带有较早的断言，但链有效性本身并不能建立信任或需要接受。 RFC 8617仍然是实验性的，而活跃的草案提出了历史性的重新分类，并建议不要在不同的发送者和接收者之间建立依赖。在添加新的依赖项之前检查该提案；这还没有完成退休。不要引入通用允许列表作为默认修复。
试点变更需要同意名单参与者和可逆配置。测试回复、审核通知、摘要、附件和取消订阅流程，而不仅仅是纯文本帖子。保留原始配置并确定谁可以恢复它。单独测量交付 结盟 和用户可见的归因。
记录所选的身份策略，以便支持人员可以对其进行解释，而无需声称列表签名证明原始作者对修改内容的批准。当软件、接收者-提供者行为或身份验证规范发生变化时，重新考虑决策。可接受的社区工作流程需要可靠的操作和对重新分发的消息进行身份验证的组织的诚实帐户。
保留的实验室证据
参考： RFC 6376 §6, RFC 9989 §4.4.
保留的 2026 年 11 月 7 日本地列表实验通过list.example的列表重写了可见的 From 到 Alice，附加页脚，然后使用list.example进行签名。实际的SMTP携带来自127.0.0.3的消息，并以list@list.example作为信封。接收器观察SPF并 DKIM 通过并计算与list.example严格对齐。相反，原作者签名后附加的页脚会使该签名无效。原始直接输出和列表输出保留可见的归因变化。没有进行生产邮件列表软件或订户可用性测试。
对保留的赛跑者和2026年11月7日捕获的赛跑者进行了检查；本次审查没有重新运行网络实验。最初的实验仅使用环回并且不发送互联网邮件。它的接收者创建 Authentication-Results 根据其自己的检查，使这些字段具有已知的实验室来源。身份验证结果和处置保持独立：所有六个SMTP样本均在显式捕获策略下收到 250，包括失败样本。信任边界是这个受控实验室，而不是生产邮箱提供商。 DNS适配器提供保留的固定答案而不是查询公共DNS ，并且DMARC评估器仅使用严格的域相等。完整的组织域发现、生产策略解析和实时部署结果尚未经过测试。