大学可以拥有健康的中央工作人员邮件，而校友转发器或部门名单却无法到达收件人。这些路由改变消息的不同部分。货运代理改变交货路径并可以使 SPF 不适合原来的域名；列表可以添加页脚或重写主题，从而可能破坏签名。诊断实际的转变，而不是授予每个校园广泛的权力。
遵循三种学术路线
将教员申请分配给教员 IT，将校友转发器分配给校友服务主管，将部门列表分配给其列表管理员。记录原作者域名、出站信封域名、签名域名、中间主机和最终收件人。捕获同一虚构事件通知的原始消息和后中介副本。保留最终接收者的可信身份验证结果（如果可用），而不是从不受信任的上游消息复制的标头。
对于教师申请，请测试系统本身，而不是从教授的邮箱发送手动消息。包括学期开始自动化和服务帐户。对于校友，测试直接交付和转发到测试团队控制的帐户。对于列表，将未修改的过帐与接收配置的页脚的过帐进行比较。在未检查成员期望和可访问性需求的情况下，请勿禁用有用的列表功能。
解释一下幸存的认证路径
保留对齐 DKIM签名 可以继续支持 DMARC 转发后，即使SPF不再起作用。如果转发器更改签名正文或标头，则该特定签名可能会失败。重写的转发器信封的SPF成功不会自动与原始作者的发件人域对齐。 RFC 7960 记录间接邮件问题。 ARC ，在RFC 8617中定义，可以跨中介机构进行认证评估，但接受程度取决于接受者的评估和信任；它不是通用的覆盖。
对于下面的书面页脚情况，假设原始签名覆盖整个正文而没有 l= 限制，并且添加的非空页脚更改了规范化的签名字节。在这些假设下，原来的 正文哈希 不再匹配。这是协议推理，而不是执行的签名测试；仅空白的更改可能在以下情况下表现不同 规范化.
为每条路线选择缓解措施
如果可能，通过简单转发保留签名内容。如果列表必须转换消息，请评估支持的列表行为，包括列表拥有的发件人身份和适当的回复安排。这种重写改变了读者可见的身份，因此在采用之前测试回复、审核、存档和可访问性。不要伪造原作者的签名或假设大学范围内的SPF条目修复了列表修改。
如果受支持的路线尚不能满足预期政策，则记录例外情况，包括所有者、审核日期和受影响的接收人群。与直接教员邮件分开监控实际故障。学生和校友数据访问、记录保留和同意规则仍然是单独的机构审查；协议验证不符合法律或教育政策。
比较三种转发状态
这些是reviewer@recipient.test的书面前提，而不是发送的消息或测试。所有域名和所有者都是虚构的。
- 直接院系路线：来自 coach.campus.test， 邮件来自 教师.校园.测试, DKIM d=faculty.campus.test with 选择器 演示1；假设DKIM通过。 SPF未知。规定的DKIM路径完全对齐。 IT学院拥有实际的应用测试。
- 校友转发：来自alumni.campus.test保持不变；最终跃点 MAIL FROM 变为具有规定SPF通行证的relay.forwarder.test。原始DKIM d=alumni.campus.test,选择器demo1，规定保持有效。重写的SPF与 From 无关，但保留的对齐DKIM仍然提供机制路径。 Alumni服务拥有最终跳观察和转发配置。
- 院系列表：来自faculty.campus.test，原DKIM d=faculty.campus.test,选择demo1；假设没有 l= 的全身签名和更改规范化字节的页脚。原始签名预计会失败。 MAIL FROM relay.list.test 规定SPF通过，与 From 无关。其他签名和 ARC 证据未知，因此不要推断完整的接收者决定。列表所有者必须检查支持的转换和最终可信结果。
不提供实际的策略查找、密钥验证、 ARC链或接收者观察。如果以后获得有效的ARC链，仍然需要接受者信任评估，而不是自动恢复原始DKIM签名。
选择有界缓解决策
对于虚构列表 EDU-01，将保留签名内容与受支持的列表拥有的 From 重写进行比较。重写lists.campus.test需要为该新身份提供实际一致的身份验证路径，并单独检查回复、审核、存档和可访问性。重写消息的新签名不会修复原始签名。如果没有接收者证据，请将提案标记为未经验证，并保留其所有者和审核日期；不要要求校园范围内的修复。
保持证据边界明确
RFC 9989 第 4.4 节和第 5.3.5 节区分身份验证和 结盟;第 5.4 节将消息处理留给接收者策略。第 7.4 节要求有效的DKIM而不是单独的SPF来进行域发布 p=reject 并警告不要拒绝其用户向 Internet 邮件列表发帖的域。所涵盖的规范化字节决定了RFC 6376第 3.4–3.7 节和 6.1 节中的DKIM完整性。这两种机制都不能验证临床、教育或法律权威。收集实际部署的授权当前证据；这里的操作清单是建议，而不是特定管辖区的合规评估。