提出可以用证据回答的问题
企业认证调查问卷应将业务需求与支持的行为、运营责任和验收证据联系起来。一长串是或否的功能问题可能会掩盖重要的限制：供应商可能支持广泛的类别，但不支持买方所需的特定租户、生命周期或部署行为。因此，调查问卷应询问支持什么、在何种配置下、由谁操作以及如何验证答案。
本文提出了一个调查问卷结构，并未说明EmailAuth实现了任何列出的功能。没有联系供应商，也没有获得问卷答复。 Microsoft 的责任共担指南 和 Azure 的多租户身份指南 提供重要区别的官方示例，但它们不能替代正在评估的产品的当前证据。
从范围和决策所有权开始
记录建议的客户群、域、发送工作流程、部署选项、所需的集成和目标管理员。确定哪些要求是强制性的，哪些是偏好的，哪些需要合格的法律、安全或商业审查员。没有定义范围的调查问卷可能会产生在技术上适用于不同版本或环境的答案。保留产品版本并在每个响应旁边提供参考。
要求供应商区分已实施的支持、依赖于配置的支持、计划的工作和不支持的需求。不要将路线图日期转变为当前能力。如果响应依赖于另一个服务，请确定该依赖关系和责任方。买方还应记录其自己的义务；如果所需的客户DNS 、身份或访问决策仍未定义，供应商就无法演示完整的工作流程。
涵盖身份、角色和租户边界
询问用户如何进行身份验证、身份如何与租户绑定以及如何将权限分配给域、报告、导出和管理操作。 Azure 的身份指南将身份验证与基于角色或基于资源的授权和商业权利区分开来。在单独的问题中反映这些区别。支持 SSO 的声明不会建立客户隔离或角色减少对现有会话的影响。
包括有关服务身份、用户生命周期、供应商支持访问和审计证据的问题。需要对禁用和撤销行为的最新解释，而不是假设配置集成处理每个访问路径。要求进行授权的综合负面测试，证明一个租户无法读取、导出或更改另一租户的资源。仅产品屏幕截图或角色列表并不能提供该证据。
询问如何获得验证观察结果
记录平台摄取的来源、如何描述其覆盖范围以及如何表示不受支持或缺失的观察结果。 RFC 9990 定义 DMARC 聚合报告，有自己的报告发现和交付流程。平台解析报告的能力并不能保证每个接收者都发送这些报告，或者每个合法的发送者都在一个周期内得到代表。
询问产品如何保留原始报告出处、处理重复项并解释解释限制。如果它将提供者交付事件与身份验证报告结合起来，请询问哪些标识符允许链接以及结论是消息级还是流级。不要请求身份验证数据的通用传送保证。调查问卷应该使产品的观察边界清晰可见，而不是鼓励没有证据支持的完全覆盖的主张。
明确部署和运营职责
询问当前支持哪些部署选项以及每个选项包含哪些内容。定义谁修补基础设施、更新应用程序、管理身份、监控摄取、执行恢复和处理事件。 Microsoft 的责任共担框架说明了为什么义务因服务模型而异，但实际的供应商必须提供自己支持的分配。标记为共享的响应应描述移交和验证所有者，而不仅仅是在两方之间划分复选框。
对于私有或专用选项，请分别询问网络路径、数据处理、支持访问和外部依赖性。不要从架构标签推断隔离。需要相关边界的证据和透明的工作量假设来确定规模。调查问卷本身不应授权部署、防火墙更改或数据传输；这些行动需要单独批准的实施工作。
包括数据处理和审计要求
询问保留哪些数据、支持的配置将其放置在何处、谁可以访问这些数据以及如何保留、删除和导出操作。区分主要数据、日志、备份和支持工件。本文不会做出法律合规性确定或断言供应商的居住行为。适当的合格所有者应使用现有证据审查合同和监管要求。
为了可审核性，询问记录了哪些操作、是否包括被拒绝的尝试、如何表示参与者和租户上下文以及谁可以导出或更改保留设置。 Microsoft Entra 审核日志文档 是官方活动日志描述的示例，而不是其他产品覆盖范围的证明。需要特定于产品的样本和限制，而不是接受“审核”一词作为完整的答案。
使工作量和商业假设透明
使用批准的组织输入说明预期的域、租户、用户、报告量、保留和集成节奏。清楚地标记估计和未知数。部分月份的观察可能无法支持准确的年度工作负载预测。询问供应商哪些变量会影响报价以及如何计算更改，但不要从技术文档中推断价格或包装内含物。
将商业包容与技术接受分开。某个功能可能包含在报价中，但仍需要配置和证据；演示的功能可能超出了提议的包。仅当存在批准的报价时才记录报价的有效性、范围和排除情况。本手稿未提供价格、折扣、成本模型或采购建议。
要求和证据工作表
创建需求、业务原因、优先级、支持的配置、供应商响应、证据来源、审阅者、验收测试、限制和决策列。添加假设登记册，其中包含输入、来源、日期、置信度和影响（如果错误）。将每个强制性要求链接到具体的证据项目，而不是广泛的营销页面。将未回答的问题保留为空白，而不是将沉默解释为支持。
对于可测试的控制，描述授权的固定装置和预期结果。对于合同承诺，请确定相关批准的协议。对于操作职责，请确定指定的所有者和移交。这些证据类型可以相互补充，但不应随意替换。合同可以分配责任，而无需证明技术测试；成功的测试可以在不创建支持承诺的情况下显示行为。
虚构的诊断：一份完整的调查问卷
虚构买家收到有关 SSO、导出、私人部署和审核日志的肯定答案。审查最初标志着调查问卷的完成。第二位审阅者询问哪个版本支持这些功能、导出是否保留租户边界以及禁用后活动会话会发生什么情况。最初的答案并没有解决这些问题，因为它们描述的是类别而不是结果。
建议的应对措施是要求提供范围内的证据，并将受影响的要求保留到审核之前。买方无需指责供应商的虚假陈述；调查问卷可能过于模糊。此场景是虚构的，并不描述任何实际的供应商响应或产品差距。没有进行外部通信或测试。
公布与建议的差距
有用的评估可以确定支持的要求、可接受的限制、未解决的证据以及可能改变决策的工作量假设。技术所有者和业务所有者都应该能够阅读它，而不会破坏他们的不同职责。除非其方法和限制得到明确批准，否则应避免使用暗示精度超出证据的数字评分。
该目录需要一个需求和证据矩阵以及透明的工作量或成本假设。这些原始文物仍然开放。人类专家审查、来源适用性、生产路线、可访问性和所有者发布也保持开放。该草案提供了一个框架和虚构的练习，未完成供应商尽职调查或EmailAuth功能的断言。