BIMI记录并非显示保证
A BIMI记录 生成器可以帮助格式化提议的DNS断言，但它不能保证接收者将显示徽标。公开、资产有效性、标记证据、认证资格和接收者政策是单独的条件。构建者应解释每个字段背后的决策，并确定哪些内容尚未验证。没有这些边界的可复制记录可以将有用的配置帮助变成不受支持的承诺。
所保留的 BIMI集团实施指南 描述了实际设置，同时 Google 的设置文档 描述其接收器特定要求。两个来源都没有证明EmailAuth实现了构建器，也没有证明每个接收者的行为都是相同的。本手稿提出了输出和测试要求；没有为真实域生成、发布或扫描记录。
建立域和选择器上下文
记录预期的发送域， 选择器、 DNS出版物所有者和批准的徽标身份。构建者不应默默地假设默认选择器代表每条消息或每个品牌工作流程。 BIMI集团的选择指南 解释了选择器的使用及其与消息信号的关系。适用的选择器必须连接到预期的发送进程，而不是仅仅因为其DNS名称熟悉而选择。
保持 BIMI 选择器名称与 DKIM 选择器。它们服务于不同的目的并占据不同的查找上下文。构建者应解释其建议的发布所有者名称，包括DNS编辑器如何期望相对名称或完全限定名称。它不应该盲目地复制域名后缀或声称某个提供商的输入约定适用于所有地方。现有的状态和提供者行为需要在发布前经过授权审查。
解释每个提议的字段
注释应标识版本断言、徽标位置字段以及目标指南或规范版本支持的任何证据位置字段。它应该说明提供哪些值、哪些是占位符以及为什么目标接收者需要它们。未经域所有者批准且没有证据表明端点为预期资产提供服务，请勿插入真实 URL 或证书位置。
未知或不支持的字段需要在构建器自己的验证中进行显式处理。由于BIMI指南和提案不断发展，该工具应识别其支持的规则集，而不是为每个标签发明通用处理规则。测试计划应该区分构建器拒绝生成的输入和关于每个接收器如何处理不熟悉的断言的声明。此处未测试不支持的标签行为。
验证资产和 HTTPS 先决条件
BIMI集团 SVG 指南 描述了更严格的 SVG 便携式/安全配置文件。构建者不应接受任何图像 URL 作为等效证据。提议的输出应引用已批准的资产，并保留内容哈希和验证记录，同时保持结构和视觉审查分开。浏览器中显示的徽标仍可能不符合相关的配置文件要求。
Google 在其记录的设置中要求使用 HTTPS 托管BIMI文件。构建器应确定托管端点是否已被检查以及获取的字节是否与批准的资产匹配。 HTTPS 传输证据不建立标记证书资格或接收器显示。如果未执行任何提取，则输出应显示未验证，而不是将 https 前缀视为成功的连接测试。
范围标记证据和接收者要求
Google 保留的指南指出Gmail需要受支持的 VMC 或者 CMC 并描述了VMC相关的复选标记区别。其他接收者可能有不同的资格规则。构建者应该询问哪些接收器很重要，并在提出证据位置字段普遍足够或不必要之前引用他们当前的要求。输入 URL 并不意味着证书购买或颁发者批准。
这 Yahoo BIMI指南 说明了不同的接收者范围，包括其对VMC要求的处理和其他资格考虑因素。这种对比支持针对特定接收者的仔细审查，而不是声称符合已发布清单的每条消息都将显示徽标。建筑商应避免将不完整的配置标记为有保证的品牌知名度。
将DMARC资格和发件人准备情况分开
BIMI接收方指导可以施加 DMARC 相关条件，但构建者不得假设DNS强制策略证明每个合法发送方都是一致的。 RFC 9989 定义当前 DMARC 行为及其界限。拟议的BIMI输出应链接到单独的准备情况评估，而不是默默地更改身份验证策略以满足徽标设置形式。
如果接收方文档使用与当前协议词汇不同的约定，请保留源日期和适用性问题。不要自动重写策略或发明新版本令牌。 BIMI构建者的任务不是修改DMARC 、购买标记证据或更改供应商的发送配置的权限。这些决定需要其自己批准的范围和验证。
准备准确记录的变更计划
检查现有状态和准备预期的差异与发布是分开的。建筑商应区分更换已批准的记录和在同一所有者处添加竞争主张。 RFC 1035 定义TXT结构，包括内部字符串的区别 一个记录 并单独记录。在变更计划中保留不相关的TXT数据和完整的受影响记录集。
记录恢复材料、业主批准和变更后观察计划。生成的字符串不应自动授权DNS写入。如果该工具支持发布，则该功能需要租户绑定、批准和验证的单独证据；本手稿并未声称EmailAuth提供此功能。此练习没有读取或更改DNS状态。
带注释的构建器工作表
创建一个包含域、选择器、确切发布所有者、提议的断言、每个字段的用途、资产哈希、端点证据、标记证据状态和预期接收者的工作表。添加源规则版本、当前状态参考、预期差异、批准所有者和未解决的先决条件。将输出有效性、操作准备状态和接收器显示保持为单独的状态。
所需的测试用例应涵盖肯定支持的断言、无效输入、重复记录和不支持的字段。一旦运行授权测试，每个案例都需要原始输入、预期行为和实际工具输出。不要标记已通过的装置，因为建议的输出看起来似乎合理。文档示例不是执行的构建器测试，并且该草案既不包含生产记录也不包含测量结果。
虚构的诊断：没有证据的有效断言
一个虚构的团队生成一个语法上合理的BIMI记录，指向一个徽标，并假设每个接收者现在都会看到它。拟议的审查询问资产是否符合配置文件、HTTPS 检索是否经过验证、存在哪些标记证据以及适用哪些接收器要求。记录的格式本身并不能回答这些问题。
该团队将不解决显示准备问题，并收集缺失的授权证据。它不会仅仅为了使构建器状态变为绿色而购买证书或更改身份验证策略。此场景是虚构的，并不描述真实的接收器故障或产品限制。它演示了为什么输出必须保持注释和条件。
仅发布已证明的声明
该目录需要带注释的记录以及肯定的、无效的、重复的和不支持标签的测试用例。这些原始文物仍然开放，人类专家审查、来源适用性、生产路线、可访问性和所有者发布也是如此。该草案提供了要求和虚构的练习，而不是实现的工具行为或徽标显示的承诺。可发布的示例必须保留实际支持的输出和测试，同时保持接收者判断力可见。