制造电子邮件库存通常从员工邮件开始，而忽略了 ERP 调度程序、采购工具和供应商门户。这些应用程序可以在服务帐户下运行，仅在隔夜批次后发送，或使用工厂团队拥有的中继。认证工作必须遵循生产流程，不得干扰生产流程。
映射应用程序、中继和所有者
将 ERP 通知分配给 ERP 服务所有者，将采购请求分配给采购技术，将供应商门户邮件分配给供应商集成主管。记录触发器、工厂或业务单位、提供商帐户、中继、作者域和签名 选择器。包括计划作业和特殊流程，例如返工、取消订单和使用不同路线的供应商帐户恢复。
使用测试工单和明确的非约束性采购请求样本。切勿仅仅为了收集信息而做出真正的供应商承诺 电子邮件标头。要求采购确认测试无法批准支出或进入实时履行队列。避免在保留的消息样本中包含机密的物料清单、定价或银行详细信息。
追踪最终签字点
ERP 可以通过内部中继提交，在外部网关签名之前添加通知。另一条路线可能会先签名，然后更改消息。映射序列，而不是假设在一个控制台中配置密钥覆盖整个路径。签名后插入的实质性页脚会更改规范化的签名正文，并使全文签名无效。 规范化 可以容忍一些格式差异，因此诊断实际的签名字节和签名设置，而不是对每个更改都一视同仁。这里没有执行页脚测试。
虚构的采购服务使用 buy.factory.test 作为发件人，使用采购供应商.test 作为签名者。即使假设密码学上有效的签名，这些假设的域也无法严格通过 DKIM 结盟;这不是观察到的验证结果或完整的 DMARC 判决。确认预期的域和实际的服务租户，然后评估支持的配置更改。不要通过授予工厂范围的中继不受限制地使用每个公司域来解决不匹配问题。
业务审批分开
身份验证并不能证明购买请求已获得批准、供应商帐户是真实的或付款目的地是正确的。独立维护采购系统的授权和付款验证控制。已授权但受到损害的应用程序可以发送经过充分验证的恶意指令。
为了验收，触发真正的测试作业，保留收到的样本并将其与应用程序日志进行核对。比较正常作业和异常作业，而不是将单个手动发送作为证据。如果系统是批量驱动的，则在所有者的批准下遵守适当的周期；安静的时间并不能证明应用程序从未发送。
改变运营限制
与工厂和 ERP 所有者一起计划维护。记录特定服务的恢复路径，保留批准的配置证据并在更改后监视待处理的作业。当发件人或租户未知时，将发件人报告为未解决，而不是授予推测权限。合同、保密、出口管制和记录保存要求需要经过合格的审查。该技术示例没有确定这些义务，也没有授权任何购买行为。
虚构的路线图
以下显式身份是说明性输入，而不是真实的客户配置。身份和责任角色是假设的，而不是客户批准或提供的消息。未进行签名测试或网络交付。
- Erp通知：ERP服务所有者；来自 erp.factory.test；信封和DKIM签名者 erp.factory.test。
- 采购体系：采购技术领先；来自购买.工厂.测试；信封和DKIM签名者采购-供应商.测试。
- 供应商门户：供应商整合主导；来自供应商.工厂.测试；信封和DKIM签名者供应商.工厂.测试。
解决批处理路径差异
假设手动触发的 ERP 测试通过，但隔夜采购批次使用另一个中继，在全身签名后插入实质性通知。保持采购路径未解析，并将其收到的标头和签名内容证据与应用程序日志进行比较。更改手动路由的密钥不会解决批量路由的更改问题。这些是假设条件，而不是对实际工厂的诊断。
RFC 6376第 3.4、3.5 和 3.7 节 解释规范化、签名标签和消息哈希。 RFC 9989第 4.4、5.3.5 和 5.4 节 单独的对齐和接收器决策。其他对齐的身份验证可能会影响消息判决，而 p=reject 部署需要第 7.4 节和第 8 节中规定的有效DKIM ，而不是 SPF 独自的。未执行采购订单、签名者更改或生产邮件测试。