Define what the asset review must establish
A BIMI logo is not ready because its filename ends in SVG or because a browser can draw it. The useful handoff is a specific candidate whose structure, visual identity, receiver requirements and eventual hosted bytes can be reviewed independently. Begin with the approved brand artwork, identify its owner, and record which sending domain and receiving services the project targets. This prevents a technically tidy graphic from being mistaken for an approved company mark or a guaranteed mailbox indicator.
This article uses retained BIMI Group implementation guidance and Google's receiver documentation. BIMI remains draft work rather than an established IETF Standards Track RFC. The draft documents were not available for full primary-text verification in this review, so this is a source-scoped preparation workflow, not a complete normative conformance specification. Google's requirements are specifically Gmail requirements, not universal rules for every mailbox.
Separate the profile from the drawing
The BIMI Group describes Portable/Secure as a more restricted profile than SVG Tiny 1.2. Its creation guide calls for version 1.2, baseProfile tiny-ps and a title element. It excludes external references other than specified XML namespaces, scripts, animation, interactive elements and x or y attributes on the root svg element. Merely changing the profile label does not remove prohibited content elsewhere in the file. Review the actual XML structure and references, not just the opening line. BIMI Group creation guidance
Use a design export as an input, not an acceptance certificate. Inventory elements, attributes, embedded content and dependencies before simplifying. If the designer exported an image wrapper, resolve the artwork into genuine vector geometry through an approved design workflow. If the export includes filters or animation, replace the visual effect with an appropriately simple static construction or revise the design. BIMI Group troubleshooting specifically identifies embedded images and unsupported effects as problems. SVG troubleshooting
Apply receiver requirements without mixing their strength
For Gmail, Google requires both width and height to be at least 96 pixels, expressed in absolute pixels rather than percentages. Google separately recommends a centered square composition, a solid background, a file no larger than 32 KB and a description element for accessibility. Preserve that distinction between required dimensions and recommended presentation. A team can adopt a recommendation as its own acceptance rule, but should label that decision rather than attributing a stronger universal mandate to the source. Google SVG requirements
A square canvas does not mean the visible mark must touch every edge. Leave deliberate clearance around features that could be clipped by a circular or rounded presentation. Assess contrast and recognition at small sizes, including narrow strokes and internal negative space. These are proposed design-review criteria, not evidence that Gmail or another receiver has rendered this candidate. Record whether an inspection used a simulated crop, a local preview or a real mailbox so later reviewers can distinguish them.
Preserve identity through optimization
Ask the brand owner to compare the simplified candidate with the approved master. Optimizing path count or removing unused definitions can change a letterform, gradient or symbol. A cleaner file that depicts the wrong mark is not an acceptable outcome. Keep the original export and each candidate separately; assign a digest to the exact file presented for review, and note the tool version and transformations used. Do not overwrite the only copy of the approved source artwork.
For a certificate-backed deployment, coordinate the candidate with the issuer before treating the asset as final. Google explains that the SVG and VMC or CMC are embedded in the issued PEM file. Consequently, an independently edited standalone image should not be assumed to match the identity verified in an existing certificate. Obtain the issuer's instructions when the mark changes rather than simply replacing a public file and assuming the certificate remains suitable. Google certificate workflow
Use an acceptance worksheet tied to one candidate
The following is an original proposed worksheet, not a completed validation record. Give each row an owner, evidence location, date and state. Use unknown when evidence is absent rather than converting a planned task into a pass.
- Identity: approved artwork reference, legal or brand owner, intended domain and target receivers.
- File: candidate filename, byte count, digest and export or conversion history.
- Structure: declared profile, version, title, root attributes and prohibited-content findings.
- Receiver overlay: exact Gmail dimensions, units and applicable recommendations adopted locally.
- Visual review: small-size recognition, contrast, margins and proposed crop comparisons.
- Validator: tool name, version, exact input digest, full findings and unresolved warnings.
- Certificate dependency: proposed issuer, accepted asset version and status of matching PEM evidence.
- Hosting handoff: proposed HTTPS URL, deployment owner and outstanding public retrieval evidence.
Do not treat a green validator badge as a substitute for the worksheet. A validator can assess only the rules it implements and the file it receives. Preserve its complete findings, including warnings or unsupported checks. If an optimizer subsequently changes the bytes, validate and review the new candidate again. This makes the acceptance statement reproducible instead of depending on a screenshot detached from its input.
Fictional example: the correct logo with the wrong export
Consider fictional Harbor Lantern, preparing its lighthouse mark for a Gmail-facing pilot. Its designer supplies a visually correct SVG with percentage dimensions and an embedded bitmap. In this invented scenario, the engineer initially proposes changing only baseProfile. The reviewer instead separates two issues: structural suitability and Gmail's dimension requirements. Neither would be repaired by the profile label alone.
The proposed remedy is to obtain approved vector artwork, simplify it, set appropriate absolute dimensions, and recheck the complete file. The brand owner must then approve the resulting lighthouse shape and its small-size readability. A certificate application would use that reviewed candidate, not the earlier export. No validator was run for Harbor Lantern, no asset was generated, and no mailbox result exists; the example illustrates how evidence should guide the next decision.
Close the handoff without overstating completion
A useful review conclusion says exactly which candidate was inspected and which concerns remain. For example, the structural review may be complete while the public HTTPS fetch and issuer approval are still open. Keep these states separate from DMARC readiness and recipient display. Google's documented Gmail path requires a VMC or CMC and associated PEM, so a standalone SVG review alone cannot establish Gmail deployment readiness. Google setup prerequisites
The catalogue's original evidence requirement remains open: the candidate asset, validator findings and public HTTPS retrieval with content and certificate evidence have not been supplied or executed here. Human SME review, current source applicability, production routes, visual accessibility and owner release also remain open. This manuscript is a preparation guide and must not be promoted to publication-ready merely because its references and fictional worksheet are complete.