[ BIMI及品牌 ]

BIMI资格、身份验证和接收者自行决定权

将BIMI理解为一系列身份验证、断言、资产和接收者决策,而不是发布徽标使其出现的保证。

由EmailAuth研究团队提供 · 6 分钟阅读

[ 要点 ]

  • DMARC强制策略和单个邮件的DMARC结果是不同的事实。
  • 通用断言语法不会覆盖接收者证书或显示要求。
  • BIMI草案 15 正在进行中,而RFC 9989是当前的DMARC协议源。
在此页面上

将BIMI视为一组依赖项

用于消息识别的品牌指示符可帮助域所有者表达其希望与经过身份验证的消息关联的品牌指示符。它不会添加新的消息验证方法或强制每个接收者显示徽标。部署可以具有有效的DNS断言,但其图稿、证据文件或接收者资格仍悬而未决。

所保留的 BIMI 这里使用的文档是互联网草案版本 15,日期为 2026 年 10 月 31 日。它是一项正在进行的工作,而不是 RFC。它的概述将BIMI与底层身份验证机制分开,并且它的引入使邮箱提供商和客户可以自由应用自己的显示策略。因此,当前的部署决策必须将草案的机制与接收器文档结合起来。 BIMI Internet-Draft 15,第 1-2 节.

将域策略与消息结果分开

强制策略表达了域所有者希望如何处理故障。它并不能证明特定消息已通过 DMARC。对于每个发送流,保留可见的From域,经过身份验证 SPF 身份, DKIM 签名域和可信接收方结果。通过不相关域的身份验证仍然可能失败 结盟 与作者域。 RFC 9989 ,第 4.3–4.4 节.

BIMI集团实施指南要求强制执行 组织域 和子域。该要求应在政策更改之前提示合法发件人的清单。薪资、支持和交易系统可以与请求徽标的营销流共享一个域。项目不得为了满足艺术作品的截止日期而牺牲交付。 BIMI实施指南.

有一个标准版本的问题需要保留在记录中。 Google当前的设置页面和保留的BIMI草案仍然提到 pct=100; RFC 9989 已删除 百分率。将接收器的兼容性预期与当前DMARC规范分开记录,并且不要使用百分比设置来保证只有选定的故障份额会受到影响。 Google BIMI设置; RFC 9989 ,附录 A.6.

区分断言、艺术作品和证据

DNS断言通告相关的指示符或证据位置。标志是视觉资产。标志证书提供了根据接收者规则接受的证据。这些对象可以由不同的团队维护,并且可以独立失败。成功的DNS查找并不能证明公共 URL 返回了预期的字节,并且公共文件也不能证明证书涵盖了预期的域。

默认断言与关联 默认。 _bimi 在记录的默认选择器案例中的相关域下。草案 15 还描述了其他选择器和发现行为。将此介绍性工作流程保留在默认路径上,除非发送平台和目标接收器已针对更复杂的安排进行了验证。 BIMI Internet-Draft 15,第 4.3–4.4 节.

对于资产,检查 SVG 微型 便携式/安全 一致性而不是依赖浏览器预览。 BIMI Group 确定所需的结构属性以及对脚本、外部参考和交互内容的限制。通过审核的文件必须是实际托管或认证的文件,而不是具有相同文件名的早期导出文件。 BIMI SVG 指南.

使资格特定于接收者

本文附带的拟议资格矩阵对于Gmail 、Apple Mail 的BIMI路径和任何其他目标接收者有单独的行。每行标识来源、预期证据类型、相关客户或提供商条件以及仍然缺失的操作证据。未知的支持仍然未知;它不是使用其他提供商的策略来填充的。

谷歌目前需要一个 VMC 或者 CMC 其BIMI实施并使用基于 PEM 的路径。其VMC复选标记声明不得推广到 CMC 或每个邮件应用程序。因此,不能仅仅因为通用断言语法允许徽标 URL,就假定未经认证的独立 SVG 满足Gmail要求。 Google BIMI设置.

Apple Mail 记录的BIMI路径取决于邮箱提供商执行所需的检查并添加适当的标头。 Apple 描述了 VMC 和其他证据文件,但实际接收提供商的信任政策仍然很重要。安装受支持的 Apple Mail 版本并不能使每个连接的邮箱都符合资格。 Apple BIMI服务器指南.

使用观察来定位失败的依赖项

假设一个虚构的团队发表了一个断言 example.com 并可以在浏览器中打开其 SVG。其Gmail行缺乏证书证据,其 Apple Mail 行缺乏邮箱提供商的参与确认。下一步是完成这些特定要求,而不是重新发布相同的要求 TXT记录 反复。该虚构示例报告没有真实的DNS或显示结果。

对于实际测试,请保留准确的消息、发送者身份、接收者、客户端版本、UTC 时间和可信身份验证结果。与认证证据分开捕获显示观察结果。如果徽标不存在,则对已知内容进行分类:消息身份验证、断言发现、资产检索、证据验证或接收者显示资格。丢失的徽标本身并不能识别哪个阶段失败了。

可见的标志也是一种有限的观察。它不能证明来自该域的每条消息都是合法的、防止相似域攻击或证明消息中链接的安全性。品牌团队应该准确地描述该指标,而不是将其变成安全保证。

保留完成门

确切的目录要求是“特定于接收者的资格矩阵以及DNS 、徽标、证书和消息身份验证的证据”。本文提供了一个文件矩阵和提议的验证方法。没有收集真实的DNS答案、候选徽标、标记证书、租户配置、收到的消息或显示观察。这些原始证据项目与技术审查和所有者发布批准一起保持开放。本文是私人教育草案,而不是完整的BIMI部署。

[ 外卖 ]

证明每个接收者的每个依赖性;有效的主张只是标志资格的一部分。

[ 按角色 ]

这对您意味着什么

选择您的角色以执行后续实际步骤。

邮件安全工程师

证明消息依赖性

策略记录不能替代对预期发件人的消息进行一致的身份验证。

后续步骤

  1. 检查范围内的每个发送流并保留接收器结果。
  2. 将执行资格与每条消息的身份验证区分开来。

品牌项目经理

设置接收者限制的结果

证书和批准的艺术品可以支持资格,但不保证展示。

后续步骤

  1. 在验收计划中列出目标提供商和客户界面。
  2. 避免承诺每个收件人都会看到徽标或徽章。

交付能力分析师

诊断缺失阶段

缺少徽标本身并不能识别失败的依赖项。

后续步骤

  1. 将DNS 、资产、证据和显示结果保留在单独的字段中。
  2. 记录未知提供商的支持,而不是借用其他提供商的规则。

[ 常见问题解答 ]

常见问题

BIMI是除SPF和DKIM之外的另一种身份验证机制吗?

不。保留的草案将BIMI描述为依赖于底层身份验证,而不是添加新的消息身份验证协议。

p=reject是否证明邮件已通过DMARC ?

不会。策略规定了对故障的处理偏好。消息结果取决于通过身份验证以及与其作者域的对齐。

自断言的 SVG 记录是否可以视为 Gmail 就绪?

不可以。Google 当前的BIMI指令需要VMC或CMC ,并描述基于 PEM 的路径。允许徽标 URL 的通用语法不会消除这些Gmail要求。

CMC 和 VMC 会生成相同的Gmail徽章吗?

不要这样认为。 Google 将其复选标记与经过 VMC 验证的发件人相关联; CMC接受并不是复选标记保证。

draft-brand-indicators-for-message-identification-15是 RFC 吗?

否。保留的文档是日期为 2026 年 10 月 31 日的互联网草案。其版本和正在进行的状态应随附基于该文档的声明。

支持的 Apple Mail 版本是否可以完成收件人资格检查?

不可以。接收提供商还必须满足 Apple 记录的参与、证据验证和标头要求。

一次测试中缺失的徽标告诉我什么?

只是在接收环境中没有观察到该指标。在分配原因之前调查身份验证、断言发现、检索、证据并显示资格。

在成为部署证据之前,文件接收者矩阵必须附带什么?

指定发送者和接收者的原始DNS 、准确的徽标、证书和消息身份验证证据,以及声明的日期显示观察结果。该草案没有收集到任何内容。

[ 来源 ]

来源

  1. Apple:准备您的电子邮件服务器以支持 Apple Mail 中的BIMI
  2. BIMI Internet-Draft 15(2026 年 10 月 31 日;正在进行中)
  3. Google Workspace :设置BIMI
  4. BIMI集团实施指南
  5. RFC 9989 :基于域的消息身份验证、报告和一致性
  6. BIMI Group:创建BIMI SVG 徽标文件

[ 词汇表 ]

词汇表

BIMI断言
域名所有者通过其公布指标和证据偏好的DNS TXT记录。
作者域
RFC5322的域。DMARC 用于评估DMARC和一致性的发件人地址。
标识符对齐
适用的DMARC模式下经过身份验证的标识符与作者域之间所需的关系。
自断指标
一些接收提供商要求不提供附加标记证据的徽标声明。
接收者资格
在接收服务考虑使用BIMI指标之前必须满足的一组特定于提供商的条件。

企业出处

为什么顶级金融机构和政府 退役了他们的电子邮件安全仪表板。

传统的电子邮件身份验证平台会向您出售仪表板并要求您的工程师来完成这项工作。在高风险环境中,手动监督意味着延迟执行、配置漂移和不受监控的影子域。

EmailAuth是代理电子邮件来源平台。 我们的代理人强制执行 p=reject,保持第三方发件人一致并将您的域名移至完整状态 RFC 9989 合规性、新的DMARC标准,以及人机交互审核能力。

政府 大型企业 一级金融机构

SaaS · 专用租赁 · 气隙本地部署 · BYOK 加密

知识库