BIMI certificate renewal is complete only when the intended replacement is available to receivers and remains suitable for the sending domain and brand. A paid invoice or an issued certificate is useful administrative evidence, but neither establishes that the public certificate URL serves the new file. Treat renewal as a small release with an owner, a deadline and a verification record.
Separate the assets that can expire
Inventory the mark certificate, the HTTPS certificate on its hosting service, the logo file, domain registration and relevant brand-rights documentation. These are separate dependencies. Record actual certificate validity dates from the issued files rather than assuming a subscription anniversary is the technical expiration date. Identify who can obtain replacements and who can publish them, especially when marketing owns the issuer relationship but infrastructure owns hosting.
DigiCert's lifecycle documentation distinguishes renewal, which creates a new certificate and order, from reissue, which replaces a certificate within an order. Its workflow may require renewed verification when organisation details or domains change. Apply the current issuer procedure to the actual case instead of treating these terms as interchangeable.
Establish a release record
Before requesting renewal, compare the sending domains, logo and organisation with the previous issuance. Resolve any ownership or brand change through the issuer. Retain the prior public file's digest and the planned replacement's digest. Record which DNS assertion points to the certificate, whether hosting is issuer-managed or self-managed, and how to determine which version is being served.
Do not assume automated issuance also updates a self-hosted PEM file. Conversely, do not overwrite issuer-managed files through an unrelated hosting workflow. Confirm the service's responsibility boundary. Require explicit evidence for the public endpoint rather than closing the task on a dashboard status alone.
Work through a renewal failure
In a synthetic example, the existing certificate expires on 30 November. A replacement is issued on 10 November, but the public URL still returns the old file on 11 November. An illustrative release manifest contains expected_digest=new and observed_digest=old. The acceptance decision is fail, even though the order state is issued. This simple comparison catches a publication failure without pretending to validate the certificate itself.
The operator publishes the approved replacement and retrieves it anonymously. The manifest now records matching digests, but acceptance still requires checking validity, chain, intended domain coverage and the correct logo association with appropriate tooling. Finally, controlled messages are observed at the target receivers. Do not infer universal continuity from one mailbox screenshot or promise that every cached display changes immediately.
Close renewal with bounded evidence
Keep old artifacts for audit, subject to retention policy. A rollback must never restore an expired, revoked or no-longer-authorised certificate simply because it previously displayed a logo. If replacement validation fails, repair the specific dependency and escalate the timing risk rather than weakening DMARC.
For receiver expectations, distinguish Gmail's supported certificate categories and verification display in Google's current setup guidance from issuer renewal mechanics. A valid replacement does not itself guarantee display. Close with the public file check, certificate validation and dated receiver observations, listing unresolved surfaces separately. This example is synthetic; no certificate was purchased, renewed, published or tested in a live mailbox for this article.
Renewal handoff worksheet
Record one entry per certificate and hosted endpoint. These fields are editorial recommendations and remain blank until evidence is collected.
- Sending domains, approved mark and accountable renewal owner: pending.
- Issuer order, certificate validity dates and revalidation questions: pending.
- Hosting owner and automation responsibility: pending.
- Prior and replacement file digests, served URL and retrieval time: pending.
- Certificate-chain, revocation, domain and logo checks: pending.
- Controlled message, receiver/client/date and observed indicator: pending.
- Valid recovery option, escalation owner and remaining exceptions: pending.
An expiring multi-year order and an expiring certificate are not the same event. DigiCert documents reissue within multi-year coverage and renewal into a new order. Check the actual issued dates rather than treating prepaid coverage as proof that the public certificate remains valid.