BIMI 仅当接收者可以使用预期的替代品并且仍然适合发送域和品牌时，证书续订才算完成。已付款的发票或颁发的证书是有用的管理证据，但都不能证明公共证书 URL 为新文件提供服务。将续订视为带有所有者、截止日期和验证记录的小型发布。
分离可能过期的资产
盘点标志证书、托管服务上的 HTTPS 证书、徽标文件、域名注册和相关品牌权利文档。这些是单独的依赖项。记录颁发文件中的实际证书有效期，而不是假设订阅周年纪念日就是技术到期日期。确定谁可以获取替代品以及谁可以发布替代品，尤其是当营销拥有发行者关系但基础设施拥有托管时。
DigiCert 的生命周期文档 续订（创建新证书和订单）与重新签发（替换订单中的证书）不同。当组织详细信息或域发生变化时，其工作流程可能需要重新验证。将当前的发行人程序应用于实际情况，而不是将这些术语视为可互换的。
建立发布记录
在请求续订之前，请将发送域名、徽标和组织与之前的发行进行比较。通过发行人解决任何所有权或品牌变更问题。保留先前公共文件的摘要和计划替换的摘要。记录哪个DNS断言指向证书、托管是由颁发者管理还是自我管理，以及如何确定正在提供哪个版本。
不要假设自动发布也会更新自托管 PEM 文件。相反，请勿通过不相关的托管工作流程覆盖发行者管理的文件。确认服务的责任边界。需要公共端点的明确证据，而不是仅在仪表板状态上关闭任务。
解决更新失败的问题
在一个综合示例中，现有证书将于 11 月 30 日到期。替换文件于 11 月 10 日发布，但公共 URL 仍于 11 月 11 日返回旧文件。说明性的发布清单包含预期_摘要=新和观察到的_摘要=旧。尽管已发出订单状态，但接受决策仍失败。这个简单的比较可以捕获发布失败，而无需假装验证证书本身。
运营商发布批准的替代品并匿名检索。清单现在记录匹配的摘要，但验收仍然需要使用适当的工具检查有效性、链、预期的域覆盖范围以及正确的徽标关联。最后，在目标接收器处观察受控消息。不要从一个邮箱屏幕截图推断出普遍的连续性，也不要承诺每个缓存的显示都会立即更改。
用有限的证据关闭更新
保留旧工件以供审计，并遵守保留政策。回滚绝不能仅仅因为证书之前显示过徽标而恢复过期、撤销或不再授权的证书。如果替换验证失败，则修复特定依赖项并升级时序风险而不是削弱 DMARC.
对于接收者的期望，请区分Gmail支持的证书类别和验证显示 Google 当前的设置指南 来自发行人续约机制。有效的替换本身并不能保证显示。关闭公共文件检查、证书验证和注明日期的接收者观察结果，单独列出未解决的表面。这个例子是综合的；本文未在实时邮箱中购买、续订、发布或测试任何证书。
续订移交工作表
每个证书和托管端点记录一个条目。这些字段是编辑建议，在收集证据之前保持空白。
- 发送域名、批准的标记和负责任的续订所有者：待处理。
- 发行人命令、证书有效期和重新验证问题：待决。
- 托管所有者和自动化责任：待定。
- 先前和替换文件摘要、提供的 URL 和检索时间：待定。
- 证书链、吊销、域名和徽标检查：待处理。
- 受控消息、接收者/客户端/日期和观察指标：待处理。
- 有效的恢复选项、升级所有者和剩余例外：待处理。
到期的多年订单和到期的证书不是同一事件。 DigiCert 文件在多年覆盖范围内重新颁发并更新为新订单。检查实际签发日期，而不是将预付费保险视为公共证书仍然有效的证据。