Review the file that will actually be used
A logo that looks correct in a design application can still be unsuitable for BIMI. The preview may hide an external image reference, depend on an unavailable font or render features that the required SVG profile excludes. A validation process must inspect the candidate file, the bytes delivered from its public URL and any mark-evidence relationship, not just the artwork's appearance.
Begin by identifying a single candidate version. Record its filename, byte size, cryptographic hash, brand approval and intended domains. Keep the design source separately from the exported indicator. When an exporter or editor modifies the SVG, calculate a new hash and repeat the checks. A previous result for another file with the same name does not validate the replacement.
Check the SVG profile rather than the extension
BIMI Group describes SVG Portable/Secure as a stricter profile of SVG Tiny 1.2. Its guidance identifies baseProfile="tiny-ps", version="1.2" and a required title element. Merely renaming a PNG or changing an SVG attribute does not prove conformance. Inspect the actual document structure and use a validator appropriate to the chosen profile. BIMI Group SVG guidance.
The same guidance excludes scripts, animation, interactive elements and external references other than the specified XML namespaces. It also excludes x and y attributes on the root SVG element. Keep that last restriction scoped to the root: a checklist that mechanically deletes every coordinate throughout the document can damage the artwork instead of validating it.
A proposed structural review should identify each finding by location and rule. If an external resource is referenced, determine how the approved artwork can be made self-contained using the designer's supported workflow. Do not run unknown embedded content or accept a validator's unexplained warning just because the browser preview still looks attractive.
Separate requirements from compatibility recommendations
Gmail adds its own documented dimensions: a minimum width and height of 96 pixels, expressed in absolute pixels rather than percentages. Its compatibility recommendations include a centered square composition, a solid background, a file of 32 KB or less and a description element for accessibility. The distinction matters: a provider-specific minimum is not automatically a universal BIMI rule, while a recommendation should not silently become a hard protocol requirement. Google BIMI setup, SVG requirements.
BIMI Group likewise recommends a square, centered design and a solid background because display can use a circle or rounded square. Review the logo at small sizes and in plausible crops. Fine lettering that is technically valid may become unreadable. This visual review complements structural validation; neither one substitutes for the other. BIMI Group SVG guidance.
Keep the intended brand treatment explicit. The designer may need to choose an approved simplified mark instead of compressing a full corporate lockup into a tiny avatar. Obtain that approval before treating the technically convenient variant as the organization's authorized identity.
Test delivered bytes and HTTPS independently
The local candidate and the public URL are two different evidence targets. A hosting layer may return an older file, require cookies, rewrite content or serve an HTML error with a successful-looking page. A proposed unauthenticated fetch should retain the request time, requested and final URLs, HTTP status, headers, content type, content length where available and a hash of the downloaded body.
Compare the retrieved body with the approved candidate and investigate differences rather than assuming the deployment tool preserved it. A successful download is only the retrieval check. It does not establish SVG conformance, accepted mark evidence or logo display. Google's web-server guidance requires HTTPS and describes its TLS expectations. Record the TLS certificate's identity and chain result without confusing that certificate with the VMC or CMC. Google BIMI setup, public web-server requirements.
Use a full content fetch for this proposed verification rather than treating a HEAD response as proof of the body. Do not bypass certificate errors, authentication or other access restrictions to make an asset appear publicly accessible. Fix the hosting requirement through the responsible owner and repeat the authorized test.
Preserve the connection to mark evidence
For Gmail's documented route, a VMC or CMC and associated PEM file are part of the setup. A standalone SVG preview cannot satisfy that evidence requirement. Before updating a certified logo, ask the certificate operator or issuer how the exact new asset is handled, which domains are covered and whether updated evidence must be issued. Google BIMI setup, steps 2–3.
The retained BIMI version-15 text addresses indicator discovery and validation, but it is an Internet-Draft rather than a finalized RFC. Its generic mechanics do not override a receiving provider's accepted certificate types or asset policies. Keep the draft version and receiver guidance with the review so the conclusion can be revisited when either changes. BIMI Internet-Draft 15, sections 7.3–7.6.
Turn findings into a reproducible acceptance record
Imagine a fictional candidate that looks fine but uses percentage dimensions and references an external resource. The correct record would list those as unresolved findings, assign the designer a self-contained export, and request a new hash after revision. It would not say “BIMI validated” because the logo rendered on the reviewer's laptop. No such candidate or validation run was actually supplied for this article.
The proposed acceptance packet should include the approved candidate, validator name and version, full findings, visual-review notes, public-fetch evidence, TLS checks and the applicable mark-evidence decision. A later controlled message test remains necessary to observe receiver behavior; even a technically eligible logo does not guarantee display.
The exact catalogue requirement is “The candidate asset, validator findings and a public HTTPS fetch with content and certificate evidence.” All three original evidence categories remain open. This article is a documentary validation workflow, with no uploaded asset, live fetch, certificate execution, tenant change or publication performed.