A useful BIMI compatibility view answers a practical question: under which documented conditions should a particular receiver and client display a particular indicator? A list of provider logos labelled supported cannot answer that question reliably. Separate certificate eligibility, message requirements, client behavior and the evidence used to support each statement.
Define the columns before collecting claims
Record the receiving service, viewing application, platform or version, supported certificate category, expected indicator, prerequisite documentation, date checked and test status. Add a field for uncertainty. A provider can process the message while a separate application renders it, so one provider name is not always a complete description of the experience.
Use first-party pages for the claim being made. Google's current setup guidance describes VMC or CMC certification and a VMC-associated checkmark. Apple's server guidance adds requirements on the receiving provider's checks and headers. These are different dimensions, not interchangeable support badges. Do not infer a receiver's present behavior from a certificate vendor's broad marketing list.
Keep a small, defensible compatibility view
A documentation-only example has three rows. Gmail: Google documents VMC or CMC certification and a VMC-associated checkmark. Apple Mail: Apple documents a supported client plus a qualifying receiving-provider path. Zoho: the current administration guide describes a VMC-based configuration workflow. Mark all three as documentation reviewed and receiver test pending unless actual observations exist.
For Zoho, this documentation does not establish that every other certificate type is categorically rejected on every receiving surface. For Apple, a logo observed in iCloud does not establish the same result for an unrelated mailbox account viewed in the same app. Keep the row narrow enough that its evidence genuinely supports its claim.
Dated documentation matrix
The rows below record a documentary review on 8 November 2026 UTC, not mailbox observations.
- Gmail: current captured setup guidance requires VMC or CMC certification and describes the VMC-associated checkmark. Exact client/platform behavior remains untested. Source: Google setup guidance. Receiver test: not executed.
- Apple Mail: Apple documents support on macOS Ventura 13, iOS 16 and iPadOS 16 or later, conditional on the receiving mail provider being listed by the BIMI Group and verified by Apple, checking message and domain compliance, verifying a BIMI Evidence Document (for example, a VMC trusted by that provider), and adding the required headers. Compatibility of other certificate categories is not established here. Source: Apple server guidance. Receiver test: not executed.
- Zoho: the current managed-domain configuration workflow specifies a VMC. It is not a complete incoming-client or certificate-category display matrix. Source: Zoho administration guide. Receiver test: not executed.
Design observations that distinguish causes
Use authorised seed accounts and controlled messages with known From domains, authentication results and approved assets. Record whether the message was forwarded, whether a contact image was present and which client displayed it. A personal avatar can resemble the brand logo; do not treat a screenshot alone as proof of BIMI processing.
Repeat important observations on more than one message and retain the raw message evidence when available. Record missing visibility rather than assuming failure. A missing checkmark can be expected under a supported certificate category, while a missing logo can have several unrelated causes. Compare like-for-like configurations before concluding that the receiver changed policy.
Maintain the view as an operational record
Assign an owner and review interval based on how the view will be used. Recheck before certificate procurement, a brand launch or a public compatibility claim. Capture changed wording in the source and flag any discrepancy with existing observations. Do not erase an earlier result; retain its date and environment so changes can be investigated.
Avoid universal unsupported labels unless the provider explicitly establishes that scope. Use unknown or not tested when that is the honest state. Report coverage as documented conditions plus dated observations, not a promise of inbox placement or a guarantee against fraud. The three-row example here is a research design, not a completed client test matrix. No seed messages, screenshots or account-specific compatibility evidence were collected for this article.
Keep a reproducible observation row
Use one row per receiving account and client combination. Record the message identifier, UTC time, From domain, receiver-stamped authentication evidence, certificate category, client build, contact-image state and forwarding path. Then record the visible logo and any checkmark as separate outcomes. Leave unavailable fields unknown rather than filling them from a different client. No screenshot or message observation was produced for this guide.