BIMI Display Adoption: Why Your Perfectly-Configured Logo Might Still Not Show Up

You can configure BIMI perfectly — valid SPF/DKIM/DMARC, a correctly-formatted SVG logo, even a VMC — and still see no logo in most recipients' inboxes, because BIMI logo display is decided independently by each mailbox provider, and adoption has been a slow, inconsistent rollout rather than a single "turn it on" moment

The previous articles on this site covered BIMI's technical requirements and the VMC/CMC certificate chain. This article addresses a frequently frustrating gap: between "BIMI is correctly configured" and "the logo actually appears in the inbox" — because mailbox providers each independently decide whether, when, and under what conditions to display BIMI logos, and this decision-making has produced a genuinely patchy, evolving landscape.

BIMI is a specification — display is a provider choice

The BIMI specification defines how a domain publishes logo information (the BIMI DNS record, the SVG format requirements, the VMC/CMC certificate mechanism) — but the specification doesn't require any mailbox provider to display the logo, even for a perfectly-configured domain.

Each mailbox provider (Gmail, Yahoo, Apple Mail, and others) makes its own decision about:

• Whether to support BIMI display at all
• Which combination of BIMI requirements they enforce (e.g., requiring a VMC vs accepting self-asserted logos without a certificate)
• Under what conditions a logo is shown even for a technically-compliant domain (sender reputation, recipient engagement history, and other factors that may affect display independent of the BIMI configuration itself)

This means: "BIMI is correctly configured according to the specification" and "this logo will appear for recipients on [provider X]" are related but distinct claims — the first is something you can verify (via this site's BIMI Lookup, and similar validation tools); the second depends on decisions made by [provider X], which may not be fully documented, may change over time, and may differ significantly between providers.

Major provider landscape (general patterns, subject to change)

Given that provider policies evolve — specific, current details should be verified against each provider's own, current documentation — but general patterns that have characterized BIMI adoption:

Some major webmail providers have, at various points, required a VMC (or equivalent certificate) as a prerequisite for logo display — self-asserted BIMI records (a valid BIMI DNS record and SVG logo, but without a VMC) may be technically valid per the specification but not result in a displayed logo for recipients on such providers.

Other providers have, at various times, displayed logos based on self-asserted BIMI records (without requiring a VMC) — at least for some period, or under some conditions — though policies in this area have been subject to change, and the general industry trend has been toward increasingly favoring certificate-based (VMC) verification over time, as a response to concerns about self-asserted logos being potentially used for brand impersonation (if anyone could publish a BIMI record with any logo, without any verification, the "trust" signal that BIMI is intended to provide would be undermined).

Mobile mail clients (Apple Mail on iOS, and others) have, at various points, added BIMI support — often with their own, separate timeline from desktop/webmail clients — meaning a logo might display correctly in one client (say, desktop webmail for a given provider) but not yet in that same provider's mobile app, or vice versa, during periods where support is being rolled out incrementally across a provider's different clients/platforms.

The practical implication: testing BIMI display across multiple providers and multiple clients (desktop webmail, mobile apps, different email clients) is necessary to understand your specific logo's real-world display status* — no single "is BIMI working" check can answer this for all recipients, given the provider-by-provider, client-by-client variation.

SVG Tiny PS: the specific, restrictive SVG format BIMI requires

BIMI logos must be in a specific SVG profile called "SVG Tiny Portable/Secure" (SVG Tiny PS or SVG-PS) — a deliberately restricted subset of full SVG, excluding features that could pose security risks (most notably, scripting — <script> elements, event handlers, and similar interactive/executable content are prohibited in SVG Tiny PS, since an email-embedded logo executing arbitrary script would be a significant security concern).

Common reasons a "normal" SVG logo fails BIMI validation:

• Embedded <script> tags (even if unused/decorative, some design tools include script-related metadata/elements in exported SVGs by default)
• <style> elements with certain CSS features — SVG Tiny PS has restrictions on which CSS properties/features are permitted within <style> blocks
• External references (links to external fonts, images, or other resources referenced from within the SVG) — BIMI logos must be self-contained, not relying on external resources that might not be accessible/might introduce tracking/privacy concerns if fetched by email clients
• Certain XML namespaces/metadata that design tools (Illustrator, Figma exports, and others) commonly include by default, which aren't part of the permitted SVG Tiny PS subset

Converting a "normal" SVG logo to SVG Tiny PS compliance often requires manual cleanup — removing non-compliant elements/attributes that design-tool exports include by default — dedicated SVG-Tiny-PS validators (distinct from general-purpose SVG validators, which check against full SVG, not the restricted BIMI profile) are necessary to confirm compliance with the specific, restricted profile BIMI requires.

The chicken-and-egg adoption dynamic

A broader dynamic affecting BIMI adoption overall: mailbox providers have less incentive to invest in BIMI display support if few domains have configured BIMI (limited visible benefit to users from supporting a feature few senders use) — while domain owners have less incentive to invest in BIMI configuration (including the cost/effort of obtaining a VMC, where required) if few providers display the logo (limited visible benefit from configuring a feature few recipients would see).

This kind of "mutual-dependency" adoption dynamic is common for email-authentication-adjacent standards generally (similar dynamics have historically affected adoption curves for other email-standards, though each has its own specific trajectory) — BIMI's adoption has been gradual, with meaningful provider support existing but not yet, as of various points in its rollout, universal — the trend, over time, has generally been toward increasing support — but checking current, specific provider support (rather than assuming "BIMI is now universally supported," or conversely "BIMI isn't worth configuring since adoption is low") remains advisable given the ongoing, evolving nature of this adoption landscape.

How to use the BIMI Lookup on sadiqbd.com

1. Verify specification compliance — the BIMI DNS record, SVG format, and (if applicable) certificate references are correctly structured — this is what the tool directly checks, and represents the "your configuration is correct" side of the equation
2. For display verification, send test emails to accounts on each major provider you care about, and check, in each provider's client(s), whether the logo actually appears — this real-world testing complements, but isn't replaced by, specification-compliance checking
3. For SVG format issues specifically, if validation fails on the logo file itself — checking the SVG against SVG Tiny PS-specific validators (not general SVG validators) identifies the specific non-compliant elements/attributes that design-tool exports commonly introduce

Frequently Asked Questions

If BIMI doesn't reliably display yet, is it worth configuring at all? The underlying email-authentication components (SPF, DKIM, DMARC — covered in previous articles) — which BIMI depends on, and which BIMI configuration typically prompts organizations to review/tighten — provide deliverability/security benefits independent of BIMI logo display. Configuring BIMI as part of a broader email-authentication review can be worthwhile for these underlying benefits alone, with logo-display benefits as additional, if-and-when-supported, upside — rather than configuring BIMI purely for the logo-display aspect, which, as discussed, remains provider-dependent and evolving.

Is the BIMI Lookup free? Yes — completely free, no sign-up required.

Try the BIMI Lookup free at sadiqbd.com — check your domain's BIMI record, SVG logo, and certificate configuration instantly.