将协议与接收者资格分开
BIMI 资格不是通过查找单词来确定的 DMARC 在DNS记录中。在显示徽标之前，运营商必须确定适用的身份验证策略、实际消息是否通过所需的检查以及预期接收者当前的要求。这些是相关但又不同的问题。当前的协议规范和提供商的操作帮助页面在术语或迁移时间方面也可能有所不同，因此证据需要日期和明确的范围。
本文比较了保留的主要来源。 Google 的设置页面已于 10 月 26 日更新；检索Yahoo的BIMI页面时没有相应的可见修订日期。 RFC 9989 提供当前DMARC协议上下文。本文不会测试租户或推断提供商已实现新 RFC 的各个方面。 BIMI仍处于草案阶段，接收器显示并不是通用协议保证。
记录Google实际公布的情况
Google 的BIMI设置页面显示消息必须经过DMARC验证并列出 p=quarantine 或者 p=reject，其中pct=100.它还需要一个 VMC 或者 CMC 其记录的证书支持的工作流程，并且不支持在Gmail中独立的仅 SVG 部署。将这些声明记录为 Google 发布的资格指南，而不是作为DMARC的完整定义或特定邮件结果的证明。 谷歌设置要求
它的 SVG 要求和托管指令形成了额外的门。合适的DMARC策略不会使无效映像变得合适、获取证书或使 PEM 公开访问。相反，有效的证书不会修复失败的发件人的一致身份验证。使用包含单独行的清单，这样团队就不会在仅完成 DNS 策略行后意外地将整个项目标记为就绪。
公开而不是隐藏 PCT 差异
RFC 9989废弃了早期的DMARC规范并删除了 pct 标签。其附录解释了历史百分比机制，并介绍了带有 y 和 n 值的测试标签 t。这是一个有意义的协议更改，而保留的 Google BIMI页面仍然明确提及pct=100.这两个观察结果都应该保留，而不是默默地重写任一来源以使它们看起来相同。 RFC 9989 ，附录 A.6
操作响应是在根据不匹配情况更改生产策略之前确认当前接收器的适用性。请勿声称 Google 忽略、在线要求或内部翻译特定标签，除非当前证据证实该行为。不要仅仅因为 RFC 解释了它们的历史关系，就将 t 视为 PCT 的普遍证明的BIMI资格替代品。提供者实施和提供者文档可以按不同的时间表发展。
因此，源适用性记录应包括 RFC 版本、提供商页面日期、确切的争议条件和未解决的问题。要求负责的审核员使用当前的提供者证据或授权的、适当范围的观察来解决该问题。本文不进行该确认。冲突是设立大门的原因，而不是削弱执法或即兴提出兼容性声明的原因。
独立比较Yahoo规定的条件
Yahoo自己的BIMI页面需要隔离或拒绝DMARC政策， BIMI记录 指向有效的 SVG、批量邮件以及发送地址的足够声誉和参与度。它表示目前不需要 VMC，但提供的VMC会告知总体资格。它的页面尊重子域BIMI记录，同时更喜欢组织域设置。这些是 Yahoo 特有的声明，并非Gmail共享相同证书或显示政策的证据。 Yahoo BIMI要求
不要将该页面上缺少 pct 条件的Yahoo解释为每种可能的标记处理行为的证据。记录来源实际陈述的内容以及未指定的内容。同样，其批量邮件和声誉条件意味着单个个人测试消息可能无法代表记录的徽标显示群体。当审查的来源未提供数字发送阈值时，请勿发明数字发送阈值。
将策略连接到实际的消息身份验证
DMARC评估 结盟 可见的 From 域和传递的域之间 SPF 或者 DKIM 其规则下的身份。已发布的强制执行偏好并不强制每个合法发件人通过。在提出更严格的处理之前，清点发送服务并确定它们验证的身份。策略的更改可能会影响合法的工作流程，因此徽标截止日期不得绕过邮件团队的准备和批准流程。 RFC 9989身份验证和对齐
为了以后的受控观察，保留实际收到的消息和可信的身份验证结果。在未识别生产系统和信任边界的情况下，不要接受来自任意标头的声明通行证。将策略发现、消息认证和徽标显示作为单独的结果；消息无需满足接收者的附加显示条件即可通过认证。 RFC 8601信任边界
原始接收者资格工作表
每个接收者和邮件流创建一行。以下建议字段可防止通用的“ BIMI就绪”状态隐藏重要差异。此工作表尚未评估任何实际部署。
- 来源：接收者页面、检索日期、可见修订日期和协议参考版本。
- 域政策：确切适用的记录以及任何组织或子域问题。
- 文件不匹配：有争议的标签或条件、证据和未解决的适用性所有者。
- 消息证据：可见的发件人、经过身份验证的身份、一致性和可信结果源。
- 资产：批准的 SVG 版本、接收器尺寸和结构发现。
- 证书：所需类别、颁发者状态和托管 PEM 依赖性。
- 检索和显示：公共端点证据、接收者客户端、观察时间和限制。
- 决定：符合此流条件、不符合条件或未知，还有剩余条件。
将监控和执行决策与显示实验分开。如果现有发送器无法对齐，请解决发送器配置和业务影响，而不是重复更改徽标文件。如果身份验证通过但没有出现徽标，请调查证书、托管、支持和酌情资格，而不要仅因缺少图形而声明DMARC已损坏。
虚构示例：一张清单隐藏了两个接收者
虚构的 Silver Orchard 准备了一份启动清单，上面写着“ DMARC pass，证书可选”。该措辞将Yahoo的证书位置与Gmail不同的记录工作流程合并在一起。审阅者还注意到，较旧的内部指南将 pct 视为未更改的通用协议要求，而RFC 9989删除了它，并且 Google 的当前页面仍然列出了pct=100.该团队有两个文档问题，但没有证据表明任一接收器出现故障。
建议的下一步是将清单拆分为源日期接收者行，并在更改生产DNS之前升级标签适用性问题。每个流都需要实际的消息证据及其自己的资产和证书检查。未测试 Silver Orchard 消息、 DNS记录或接收器。该示例说明了通用清单如何隐藏未解决的假设。
该目录需要特定接收者的资格矩阵以及DNS 、徽标、证书和消息身份验证的证据。本手稿提供了拟议的矩阵和记录的差异，而不是操作证据。原始证据、人类 SME、来源适用性、生产路线、视觉可达性和所有者发布均保持开放。不暗示任何政策变更、现场测试或资格保证。