撰写验收合同
概念验证应回答具体的操作问题，例如提议的工作流程是否可以在保留证据的同时区分对齐的邮件、未对齐的合法服务和未解决的来源。定义测试人群、允许的操作、输入版本和负责的操作员。在演示之前设定成功标准，包括如何计算不完整的观察和中断的任务。
不要让供应商在看到结果后只选择有利的案例。冷冻一小份代表性包装，并保留保留的阴性对照（如果适用）。指定目标是文件审查、本地模拟还是在授权租户内执行。每种模式都证明了不同的事情。缺乏租户访问是执行证据的限制，而不是记录功能的自动失败。
测量整个工作流程
分别记录预期的解释、观察到的解释、证据输出和操作员的努力。如果发件人所有者仍然未知，则正确的身份验证标签无法完成调查。清理输入、请求访问或纠正导入所花费的时间应包含在操作工作负载测量中，而不是在没有解释的情况下作为设置噪音被删除。
一个有用的拟议验收包包括一个规定的一致身份、一个未一致的合法服务案例和一个身份证据不足的案例。将最后一个案例保留为未知。即使导出仍然打开，故意将其重新标记为对齐也必须使评估失败。这是建议的阴性对照，而不是观察到的产品故障。
以负责任的决定结束
对于每个失败的标准，记录问题是否是产品缺陷、不受支持的功能、测试设计错误或缺少访问。允许在新版本下进行更正后的重新运行，而不删除第一个结果。如果标准发生变化，请解释原因并重新运行受影响的案例；不要仅仅为了获得有利的分数而移动大门。
召开退出会议，审查原始证据、未解决的风险、保留的内部努力和变更权力。该决定可以是继续、在较小范围内继续、延长特定测试或停止。 RFC 9989 和 RFC 9990 提供协议和报告基础，但不定义购买接受阈值。本指南中的阈值是建议的评估控制。通过的模拟无法授权生产DNS更改或建立交付、法律合规性或保证收件箱放置。
使用明确的验收分类账
对于每个案例，记录输入版本、预期标签、观察到的标签、下一个证据请求、所需所有者、更改权限和导出位置。正确的未知标签与自动DNS更改配对仍然不符合权威标准。删除未知行的导出无法保存证据。缺少租户连接会使执行标准未经测试、无法通过或诊断为产品缺陷。
假设所有分类检查都通过，但导出的文件省略了其输入引用。保持证据导出标准，保留第一次运行并重新测试更正的版本。不要用高分来平均掉未通过的强制门。验收合同必须明确哪些标准是强制性的，哪些标准允许范围内的例外。此书面示例没有运行本地工作流程、租户试用或变异执行。
协议范围和评估限制
RFC 9989第 4.4、5.3.5 和 5.4 节 区分经过身份验证的标识符， 结盟 和接收器处理。单独有效的签名并不完整 DMARC 判决，而通行证并不验证业务内容。 RFC 9990第 3.1、3.5.1、3.5.4 和 7 节 描述汇总证据、报告身份、副本和隐私。这里提议的商业评估、人员配置和权限门限是编辑建议，而不是 RFC 规定的产品功能。阅读这些书面示例不需要缺少可执行补充；操作声明需要单独授权的观察测试。