招标通知可能是真实的，但在帐户泄露后包含未经授权的银行详细信息更改。身份验证有助于评估域身份。采购权力来自批准的流程和负责人。设计这两项检查以相互加强，不允许其中一项替代另一项。
将通知映射到采购记录
对于招标发布、供应商通知和委托采购，记录记录系统、通知标识符、批准的发送者和责任承包角色。该通知应帮助供应商通过已知渠道找到权威的采购记录。避免将意外消息中的链接视为同一消息的独立验证。
记录应用程序租户、来自域、信封域、 DKIM 域和 选择器 对于每条路线。外包采购门户可能具有与当局工作人员邮件分开的发送基础设施。品牌页脚或回复地址不会建立一致的身份验证路径。将回复处理保留在路由图中，因为真正的通知可以将回复定向到不同的操作邮箱。
将相应的变更保留在他们自己的批准之后
根据通知要求收件人执行的操作对通知进行分类。开标公告、截止日期修改、授标通知和付款详细信息请求具有不同的操作后果。本指南建议使用已建立的联系记录（而不是有争议的电子邮件中提供的电话号码）对敏感供应商或银行变更进行单独的采购和财务验证。
DMARC 不检查投标条款或确定谁批准了中标。传递签名也不能证明银行账户属于目标供应商。在采购系统中保留变更权限、批准记录和独立审核结果。这些是工作流程建议，而不是任何司法管辖区采购法的声明。
在截止日期之前测试委托发件人
运行经批准的样本以进行初步通知、修改和取消，并附有虚构的招标详细信息。确认预期From身份、签名结果、适用 结盟，回复目的地并成功获取官方记录。签名测试无法确定通知是否在法定截止日期之前送达。相关交付、公布证据单独保存。
如果承包商在活跃招标期间更换平台，请保留旧路线，直到了解批准的切换和队列处理。设置失败通知的所有者和记录的备用通知流程。不要因为集成失败而通过新身份默默地重新提交通知。此类变更可能会让供应商感到困惑，必须在采购团队批准的沟通流程下进行处理。
重新评估面向供应商的边界
按采购部门审查报告，而不仅仅是整个部门的邮件总量。表面上健康的聚合可能会隐藏少量的修改发送者。升级意外的签名域、新的回复目的地和无主供应商帐户。在停用域或选择器之前，确定哪些招标记录和定期通知仍依赖于它。认证证据属于采购审核记录，而不是代替采购审核记录。
完成三份书面路线记录
这些保留的示例域、选择器、角色和传递的DKIM前提都是虚构的。对于这些情况，不提供或执行任何签名消息、密钥、加密验证、 DNS查找、 SMTP事务或实时服务测试。不需要测试代码或外部样本来检查以下推理。
- 招标发布：从域名tenders.civic.example可见； DKIM d=tenders.civic.example;选择器演示1；假设DKIM仅针对此书面案例通过。 SPF 邮件来自 身份和结果未知；其他签名未知；实际的政策发现和交付未知。拟议所有者：采购主管。下一步操作：获取该租户的授权样本和可信接收器结果。
- 供应商通知：可见来自域名suppliers.civic.example ； DKIM d=suppliers.civic.example;选择器演示2；假设DKIM仅针对此书面案例通过。 SPF MAIL FROM 身份和结果未知；其他签名未知；实际的政策发现和交付未知。建议所有者：供应商通讯所有者。下一步操作：确认此单独的路由及其业务事件，而不是继承第一个路由的结果。
- 委托采购：可见来自域名contracts.civic.example ； DKIM d=provider.example.net;选择器演示3；假设DKIM仅针对此书面案例通过。 SPF MAIL FROM 身份和结果未知；其他签名未知；实际的政策发现和交付未知。拟议所有者：订约当局。下一步行动：向经过验证的供应商询问该租户支持的一致签名路径；不要将授权扩大到整个网络。
对于前两个规定的签名，d= 恰好等于 From 域，因此标识符满足严格对齐和宽松对齐。鉴于规定的成功DKIM结果，这些假设消息存在一致的身份验证路径。第三个签名者故意与作者域无关，并且无法提供一致的路径。不要将第三条消息称为DMARC失败：对齐SPF或其他对齐传递 DKIM签名 仍然可以满足该机制，并且这些输入是未知的。不要从任何行推断真实的部署或收件箱位置。
加密签名验证签名域的责任，而不是每条指令的真实性或授权。对覆盖的规范化字节的更改可能会使签名无效；并非每个可见的编辑都必然会更改签名的输入。身份验证和应用程序级接受仍然是分开的。
使用通知专用的受理卡
对于虚构投标T-01修订版本2，需要批准的记录版本、授权承包角色、发件人身份、回复目的地、发布时间和收件人通知证据。如果认证通过但正式记录仍为版本1，则停止修改并与采购进行核对；不要将其标记为已批准。如果记录正确但通知失败，则调用已批准的替代通知流程并保留时间证据。无论结果如何，变更的受益人都会触发单独的财务验证流程。这些是拟议的决定，而不是采购法要求或已完成的测试。
应用标准而不声明合规
RFC 9989第 4.4 节和 5.3.5 节 支持对齐和机制区分。它的第 7.4 节警告了间接邮件互操作性：使用域 p=reject 必须使用有效的DKIM ，而不仅仅是SPF ，并且通用邮件列表的使用需要特别小心。路由清单本身并不具有强制拒绝的权限。 RFC 6376第 3.4–3.7 节和 6.1 节 描述签名的输入和验证。 RFC 9990第 3.1 节 提供报告背景，而不是每个收件人的到达证明。 RFC 5321第 4.2.5 节 将服务器接受责任与后来的交付结果区分开来。这里的部门工作流程选择是编辑建议；法律范围、因素适用性和当地授权需要进行自己负责任的审查。