将列表视为第二个发送步骤
Simplelists 消息至少有两个相关阶段：成员提交帖子，然后列表重新分发它。对原始提交内容进行的身份验证可能无法描述交付给会员的副本。本指南解决了记录的多列表帐户上的自定义域以及重新分发消息的行为。它并不假设每个帐户类型、列表设置或原始发件人都使用相同的身份。
首先选择业务成果。公告列表可以始终代表该组织。讨论列表可能需要显示不同的成员并适当地直接回复。记录在更改发件人重写之前人们期望的行为。否则，技术上成功的更改可能会使对话变得混乱或泄露旨在隐藏的匿名列表的详细信息。
建立域和传入路由边界
Simplelists 的自有域指南 描述了通过常规设置添加域，然后在多个列表帐户中添加域，将其设置为主要域并检查生成的列表地址。这是提供商的 2017 年设置文章，因此在使用其导航之前请确认当前帐户控制。它还将管理员指向该帐户的 SPF 和 DKIM 信息。从正确的帐户和域检索值，而不是复制公共示例。
该指南分别将主要和次要传入MX命名为mx1.simplelists.com和mx2.simplelists.com ，并警告更改可能需要长达 72 小时的时间。确认当前帐户指令和实际缓存状态，而不是将经过的时间视为接受。将其视为传入路由决策。如果组织已在其根域收到员工邮件，则替换这些邮件 MX记录 影响可能远远超出清单。确定专用列表子域是否合适，识别现有邮件所有者并在发布之前记录批准的路由范围。
将传入路由和传出身份验证保留在单独的工作表行上。将帖子成功投递到列表中并不证明从该列表中发出的副本将经过验证。相反， DKIM问题本身并不能证明移动公司的入站邮件是合理的。
获取并查看账户发行记录
捕获每个已发布条目的完整记录所有者、类型、公共值和预期域。将提议的所有者与现有DNS数据进行比较，以避免 选择器 冲突或重复的域后缀。如果其他提供商托管DNS ，则查看权威区域中的更改，而不仅仅是注册商帐户中的更改。
对于SPF ，保留同一域中的其他合法发件人。 RFC 7208 定义了多 SPF记录 并处理与 DNS 相关的术语。在授权附加服务之前，请检查完整的策略和嵌套查找成本。不要创建竞争的SPF策略，因为设置屏幕显示独立示例。
对于DKIM ，将发布的选择器和公共记录与受控列表消息上生成的签名进行比较。 RFC 6376 定义 d= 和 s= 字段。仅当实际消息携带相应的有效签名时，已发布的密钥才有用。将每个观察到的签名（包括任何原始成员签名）保留在证据包中。
决定如何处理外部成员身份
Simplelists 的DMARC解释 区分从帐户域发送的邮件和重新分发源自另一个域的邮件。它描述了外部域的条件重写。它是 功能指南 还记录了一致重写的选项以及用于显示原始发件人详细信息的控件。
这些选择值得人类做出决定。委员会可以优先考虑稳定的列表地址；讨论组可以优先考虑表彰贡献者。记录所选的发件人显示和回复目的地，然后在交付的副本中检查两者。如果匿名很重要，请查看正文和引用的帖子。隐藏一个标头不能删除成员的签名块或先前引用的地址。
不要假设该列表可以作为不相关的外部成员的域进行签名。确定最终可见的 From 域以及支持它的身份验证路径。在调查任何不匹配的同时保留预期的对话行为，而不是一次更改多个设置。
在测试计划中包含内容修改
页脚、页眉插入或主题前缀可能会影响原始签名，具体取决于签名的内容。简单主义者 交付故障排除指南 在调查可疑的欺骗拒绝时讨论了这些变化。它还说 信封发件人 通常是列表地址，并指向收件人服务器详细信息的电子邮件传递视图。
构建一个小矩阵：组织发件人、具有严格策略的外部发件人以及实际列表修改设置。仅当组织使用摘要或其他不同的交付模式并且帐户支持它们时，才添加摘要或其他不同的交付模式。每行必须代表一个真实的工作流程，而不是理论上的功能清单。
使用无害的帖子并控制收件人。保留发送时间和消息标识符，以便列表日志可以与接收到的副本相匹配。当外部接收器和组织自己的网关相关时，测试两者。内部接受可能取决于外部成员不共享的本地异常。
记录最终身份和结果
对于每个交付的副本，记录可见的发件人、回复、信封域、所有DKIM d= 和 s= 对以及可信接收者的SPF 、 DKIM和 DMARC 结果。单独保留原始帖子的结果。这两个阶段回答不同的问题，并且不应在测试记录中相互覆盖。
RFC 9989 定义DMARC 结盟。确定传递机制和支持它的域关系。与最终发件人域无关的提供者域传递不会建立该关系。重写的发件人地址可能会更改相关比较，这就是检查最终副本至关重要的原因。
如果接收服务器拒绝消息，请保留其准确的诊断文本。如果它接受邮件但收件人找不到该邮件，请继续进行传递调查，而无需假设DNS出现故障。避免将广泛的白名单作为识别身份验证结果的初始替代。
使用列表重新分配工作表
Simplelists 路由和发件人行为工作表（使用此处描述的字段创建单独的审阅记录）记录传入列表域、原始发帖者类别、重写决策、内容更改和最终身份。它为企业主提供了批准回复行为的地方，为邮件管理员提供了附加技术结果的地方。
在签核之前，比较所有测试行。一项成功的组织公告并不验证外部成员的讨论帖子。明确保留未覆盖的路线待定，并说明需要进行哪些额外测试。将域配置和列表设置版本与结果一起保留，以便可以跟踪以后的更改。
涉及讨论页脚的虚构诊断案例
仅虚构的书面案例：SLS-01 规定原始 From member@outside.example具有原始传递签名d=outside.example.在重新分发的副本中，页脚更改后原始签名失败；最终发件人仍然是member@outside.example 。该列表的信封、任何其他签名及其结果均未知，因此DMARC不会做出完整的裁决。列表所有者必须检查最终副本和记录的重写设置，批准预期的回复行为，并测试确切的路由。在组织的域中添加SPF不会修复不相关的原始签名。没有检查真实的列表或消息。
恢复设置而不干扰会员邮件
记录受控更改之前的早期列表设置和DNS状态。如果回复或发件人演示出现错误，请暂停受影响的部署并在所有者审核时恢复批准的行为。协调任何记录的报废与剩余列表和排队消息。共享域可以支持具有不同操作时间表的多个列表。
在域更改、重写更改、新页脚、路由更改或迁移后重新测试。该未发布的草案仍需要真实账户检查、发布值、 DNS观察、接收消息证据、原始范围接受、目视审查和人类 SME 批准。
将传递的消息与执行准备情况分开
RFC 9989 第 7.4 节要求有效的DKIM才能进行域发布 p=reject 并对间接邮件互操作性提出警告。单个对齐的SPF结果本身并不能证明拒绝策略的推出是合理的。与此提供商设置分开审查所有合法路由和策略所有权。