Treat the published URL as a service dependency
BIMI hosting is more than putting a logo on a website. The published location must lead an automated receiver to the intended asset, with suitable HTTPS behavior and certificate material. A successful browser preview from an administrator's signed-in session does not establish that a public client receives the same response. Start with the actual asset location intended for the BIMI record and trace it independently of the company's homepage.
This article proposes a hosting acceptance process, not a record of a deployed service. The sources were retrieved on 8 November 2026. Google's setup and troubleshooting pages describe Gmail's receiver workflow. BIMI remains draft work, and unavailable draft text was not treated as verified normative evidence. In particular, this article does not invent a universal redirect count or claim that every receiver handles redirects identically.
Distinguish the two certificate responsibilities
The HTTPS server presents a transport certificate to establish the secure connection. The hosted PEM contains the VMC or CMC and associated certificate material used for the brand assertion. These are different objects with different owners and renewal dependencies. Repairing the web server's certificate does not renew the mark certificate, and replacing a PEM does not repair an invalid HTTPS connection. Google's documentation requires HTTPS hosting and separately explains the certificate-backed PEM workflow. Google setup guidance
Google recommends TLS 1.2 or later and describes a chain rooted in a trusted CA. For the hosted mark material, its workflow says to append the intermediate and root certificates provided by the issuer in the issued order, typically entity, intermediates, root. Follow the actual issuer's file instructions rather than assemble an arbitrary collection of certificates. Record which certificate is being examined whenever someone reports an expiry or chain problem.
Inspect the first response and every dependency
Prefer a stable, direct HTTPS asset URL as an operational design choice. If a redirect exists, preserve its status, target and subsequent responses, and confirm the actual receiver's supported behavior before relying on it. A redirect to a login page, a marketing homepage or a temporary signed URL can make a browser workflow seem successful while failing to deliver the required object to an automated client. Avoid asserting that all redirects are forbidden when the reviewed sources do not establish that rule.
The proposed acceptance check should distinguish DNS resolution, connection establishment, certificate validation, HTTP response and content validation. Record failures at their actual stage. A reachable server can return an HTML error document with an apparently successful status. A correct asset can be accessible only after a cookie challenge. A certificate chain can work in one client's trust environment while remaining incomplete for another. These are investigation hypotheses, not findings about any live host.
Compare deployed content with the approved artifact
Preserve the downloaded body and compare it with the approved release candidate. A filename or cache label cannot prove content identity. Record the response headers, final URL, retrieval time and digest of the bytes actually received. For SVG, repeat the relevant structural review on that object. For PEM, confirm that the intended certificate chain and embedded logo are present and match the reviewed issuer package. Google's troubleshooting guidance separately calls for public PEM accessibility, correct DNS URL, appended certificates and correct embedded SVG format. Google troubleshooting
Do not assume a website release preserves asset paths. A framework change can send unknown paths to a single-page application, a CDN rule can transform responses, and a security product can insert an interactive challenge. Put the BIMI endpoint under an explicit change owner. The proposed release check should retrieve the exact path without relying on a logged-in session and verify content, not merely confirm that the website is online.
Original hosting acceptance worksheet
Use this worksheet for each proposed asset location. The entries are evidence requests, not completed tests or instructions to bypass security controls. Any live retrieval, deployment or configuration change needs the appropriate authorization and an agreed environment.
- Assertion mapping: sending domain, selected BIMI record, intended asset type and exact published URL.
- Ownership: DNS editor, hosting team, CDN or edge owner and mark-certificate contact.
- Connection evidence: public lookup context, endpoint name, TLS result and presented chain.
- HTTP evidence: first status, redirect targets, final status, response headers and returned object type.
- Content identity: downloaded file, byte count, digest and comparison with the approved candidate.
- Certificate material: mark issuer, certificate status, embedded logo and required chain packaging.
- Accessibility: unauthenticated retrieval outcome and any challenge, login or geographic restriction.
- Continuity: renewal dates, monitoring responsibility, change window and approved restoration artifact.
For each failed row, name the responsible component and the next evidence needed. A chain error belongs with the relevant certificate or hosting owner. A mismatched logo belongs with release management and the issuer dependency. An incorrect DNS URL belongs with the record owner. This division prevents repeated logo edits from obscuring a simple path or access problem.
Fictional example: a website migration changes the asset path
Fictional Cedar Quay moves its corporate website to a new platform. The proposed BIMI URL still looks familiar, but the migration plan routes old paths through a homepage redirect. In this invented scenario, an employee sees the company website and assumes the file is available. The review asks a different question: what exact object would an unauthenticated request to the published asset URL receive?
The planned diagnosis separates the HTTPS certificate from the hosted PEM and the redirect from the final object. The team would retain the first response, follow only an approved diagnostic path, and compare the returned content with the issuer package. A direct stable endpoint is proposed to remove the unnecessary dependency. No request was made to Cedar Quay, no redirect trace exists, and no deployment or mailbox display was verified.
Plan changes and renewals together
Keep the URL, content and certificate identities in one release record. Before changing the asset, determine whether the issuer must review a new logo or issue replacement mark material. Before moving hosting, verify that DNS publication and endpoint continuity remain coordinated. Do not promise immediate receiver refresh or universal display after a change; retrieval and presentation behavior depend on the receiving service and its current policy.
Google's documented Gmail setup uses the PEM path and does not support a standalone SVG-only deployment. Its troubleshooting steps also distinguish recipient support from file and certificate problems. Therefore, a successful hosting check is necessary evidence for the chosen workflow, but not proof of message authentication, issuer approval or mailbox presentation. Google receiver workflow
The catalogue requires the candidate asset, validator findings and a public HTTPS fetch with content and certificate evidence. None has been supplied for a real deployment here, so original evidence remains open. Human SME, source applicability, production routes, visual accessibility and owner release remain open as well. Keep this manuscript in draft until those independent requirements are actually satisfied.