编辑DNS之前验证依赖关系
发布一个 BIMI 断言是一个小的DNS更改，具有多个外部依赖项。该记录可能引用另一个团队托管的徽标或证据文档，并且接收提供者可能会拒绝其他可读文件，因为其证书或身份验证条件不满足。从批准的域、接收者特定的计划和确切的资产版本开始，而不是通用的TXT字符串。
本指南涵盖了记录的默认选择器工作流程。保留的BIMI版本 15 文档描述了其他选择器和发现规则，但它仍然是互联网草案，而不是 RFC。不介绍先进的 选择器 行为仅仅是因为发送平台可以插入标头；首先确认预期的发送者和接收者实现。 BIMI Internet-Draft 15，第 4.3–4.4 节.
建立正确的所有者和断言值
对于简单的默认情况 example.com，断言所有者是 default._bimi.example.com。版本标签是 v=BIMI1;指示器位置使用 l=，并且权威证据位置使用 a=。该草案将证据位置定义为可选语法，但这并不意味着证据对于每个接收者都是可选的。 BIMI Internet-Draft 15，第 4.3 节.
一个虚构的双位置插图是 v=BIMI1; l=https://assets.example.com/brand/logo.svg; a=https://assets.example.com/brand/mark.pem。这不是生产记录、托管资产或证书推荐。不要用这些示例值替换真实的断言或真实的证书 URL。
Google 记录了Gmail的基于 PEM 的设置，包括一个空的示例 l= 值和证书位置 a=。仅 SVG 记录不是相同的实现路径。选择目标接收者支持的形式和提供的证据，而不是将每个已发布的示例视为可互换的。 Google BIMI设置，步骤 2-4.
检查适用的身份验证策略
使用当前的确认作者域和适用的组织域策略 DMARC 发现规则。然后检查来自预期路由的实际消息以进行一致的身份验证。 BIMI集团呼吁强制执行，并指出对自我断言记录的支持有限，但政策文本和记录构建结果都不能证明发送者已准备好。 BIMI实施指南; RFC 9989 ，第 4.4 和 4.10 节.
必须结合其版本上下文来阅读提供程序文档。当前的Google页面仍然包括 pct=100， 然而 RFC 9989 删除了那个标签。将此差异保留为邮件管理员的兼容性问题。请勿使用百分比设置或测试模式作为声称的BIMI资格捷径，并且在调试不相关的资产问题时不要削弱现有的执行力度。 RFC 9989 ，附录 A.6.
验证断言将通告的资源
托管所有者应提供准确的公共 HTTPS URL、预期字节及其哈希值。建议的提取应确认响应是预期的资产或证书包，而不是登录页面、品牌错误页面或重定向到不相关的资源。记录状态、最终 URL、内容类型、大小和TLS结果。这些观察结果必须来自实际的生产路径，而不仅仅是本地文件预览。
对于标记证书路径，根据目标提供商的要求验证已颁发的证据和链。 Google 的说明描述了其 PEM 捆绑包和发行人提供的链式订单。 HTTPS服务器证书保护检索；它不是 VMC 或者 CMC 这提供了标记证据。独立检查这两种关系。 Google BIMI设置、网络服务器要求和步骤 2-3.
此处未获取代表真实部署的公共 URL。如果团队无法提供已批准的资产或证书，请保留该依赖关系未解决，而不是构建可能被误认为有效证据的占位符。
通过正确的DNS权威机构发布
确定确切所有者的权威DNS服务，并在进行更改之前检查现有记录。确认编辑器是否需要相对主机标签或完全限定名称。保留以前的值和 TTL，并使用经过审查的更改请求，其中指定了预期所有者、类型和值。避免在同一发现名称上出现重复的竞争断言。
授权发布后，建议的检查包括 挖掘@AUTH_IP default._bimi.example.com 。 TXT +norecurse 和 挖@RESOLVER_IP default._bimi.example.com 。 TXT。大写端点是占位符。保存时间戳、完整响应、记录边界和实际值。这些命令是建议的，而不是执行的观察结果。
在将分歧解释为缓存之前检查权威一致性。然后比较与可用观察结果的预期接收器相关的递归路径。 DNS TTL 或提供商的估计显示窗口并不能保证每个接收器都已刷新或将显示徽标。
验证消息并计划恢复
仅在其先决条件准备就绪后，才能通过确切批准的工作流程发送受控消息。保留作者域、签名身份、可信身份验证结果和任何相关的BIMI诊断。分别记录显示观察结果以及邮箱提供商、客户端版本和日期。例如，Apple Mail 的BIMI路径取决于提供 Apple 指定的支票和标头的接收提供商。 Apple BIMI服务器指南.
如果检索失败，请修复托管依赖项或恢复变更计划下已批准的先前断言。如果身份验证失败，请调查发件人和策略。如果仅缺少显示，则在不检查接收方行的情况下不要推断DNS错误。维护安全、授权回滚所需的旧证据；不要广泛减少DMARC保护来恢复徽标。
确切的证据门是“特定于接收者的资格矩阵和DNS 、徽标、证书和消息身份验证的证据”。本草案提供了文献矩阵和虚构记录插图。没有发生实时发布、 DNS查询、证书验证、租户更改或消息/显示测试，因此操作门和所有者发布批准仍然开放。