What Is BIMI? A Complete Guide to Brand Indicators for Message Identification

The Problem BIMI Was Built to Solve

Open almost any inbox and the sender list looks the same regardless of who's actually sending: a generic circular avatar, sometimes a first-letter initial in a flat color, occasionally a profile photo if the sender happens to be a known contact. A legitimate bank, a well-known retailer, and a brand-new throwaway domain spun up an hour ago for a phishing campaign all render with the exact same visual weight in most inboxes. That's not a bug in any individual mail client — it's simply the default state of an ecosystem where email addresses carry no inherent visual identity of their own. BIMI, short for Brand Indicators for Message Identification, exists specifically to close that gap by letting a domain publish its own logo and have supporting mailbox providers display it in place of the generic default, but only under conditions strict enough that the logo actually means something.

The "but only under conditions strict enough" part is the entire point, and it's worth sitting with before anything else. If any domain could simply request a logo be displayed next to its mail, BIMI would be worse than useless — it would hand attackers a ready-made brand-impersonation tool, letting a spoofed domain display a trusted company's exact visual mark. BIMI's actual design solves this by refusing to activate at all unless the sending domain has already proven, through DMARC enforcement, that its mail is genuinely authenticated. The logo is a reward layered on top of real security work already done, not a substitute for it.

Who Created BIMI, and Why Now

BIMI emerged from the AuthIndicators Working Group, a collaborative industry effort including major mailbox providers, brand protection vendors, and email infrastructure companies, rather than being invented and owned by any single organization. Its timing wasn't accidental — BIMI only became practical once DMARC itself had matured and gained meaningful adoption, because BIMI has no independent authentication mechanism of its own to lean on. Publishing a logo standard before a reliable authentication layer existed underneath it would have created exactly the abuse vector described above. In that sense, BIMI is less a new invention than a deliberate, later addition designed to give domains that had already done the hard work of DMARC enforcement a tangible, visible benefit for having done so.

How BIMI Actually Works, Step by Step

When a message arrives at a mailbox provider that supports BIMI, the provider first evaluates the message's authentication the same way it always would — SPF, DKIM, and critically, DMARC alignment and policy. If the message passes DMARC and the domain's published policy is enforced at quarantine or reject (not the monitoring-only none policy), the provider then looks for a BIMI TXT record at a predictable DNS location: default._bimi. followed by the sending domain, or a custom selector if one is specified in the message. That record, if present and correctly formatted, contains a URL pointing to an SVG logo file and, in most cases, a URL pointing to a certificate proving the sender's right to use that specific logo. The provider fetches both, validates them, and — if everything checks out — displays the logo in place of the default avatar for that message.

Every one of those steps is a potential point of failure, which is exactly why a technically "published" BIMI record so often fails to actually display anywhere. The DMARC policy might not be strict enough. The SVG might be hosted correctly but fail strict format validation. The certificate, if required by that particular provider, might be missing, expired, or simply not present because the domain owner didn't realize it was effectively mandatory for the providers they cared about most. Understanding BIMI well means understanding it as a chain of independent requirements, not a single on/off switch.

The BIMI Record Itself

A minimal BIMI record looks like this:

v=BIMI1; l=https://example.com/logo.svg;

Two tags matter in almost every real-world record. v= declares the protocol version and must read exactly BIMI1. l= points to the logo file itself, which must be served over HTTPS and conform to the SVG Tiny Portable/Secure profile. A third tag, a=, is technically optional per the specification but points to the Verified Mark Certificate or Common Mark Certificate that authenticates the sender's right to that specific logo — and as covered throughout this series, omitting it is the single most common reason a record resolves correctly in DNS but the logo never actually appears anywhere that matters. A fuller record with a certificate attached looks like this:

v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem;

BIMI's Relationship to SPF, DKIM, and DMARC

It's worth being explicit about what this table implies: BIMI has zero independent value if the domain hasn't already done the SPF, DKIM, and DMARC work first. A domain evaluating whether to pursue BIMI should treat that as the honest prerequisite checklist, not an afterthought — see BIMI vs DMARC for a full breakdown of exactly how the two specifications interact and depend on each other.

What a Compliant Logo Actually Requires

The logo referenced in the l= tag can't simply be any image file uploaded to a public URL. BIMI mandates SVG Tiny Portable/Secure, a deliberately restricted variant of SVG chosen because it strips out anything capable of executing code, reaching external resources, or behaving dynamically once rendered — a real concern given the logo is being rendered directly inside an email client's trusted UI chrome. Scripts, external image references, animation, and several other common SVG features are explicitly disallowed. Most logos exported directly from mainstream design tools fail this restricted profile on the first attempt, because those tools routinely embed editor metadata and namespaces the profile doesn't permit. The full technical requirements, along with a practical process for producing a compliant file, are covered in SVG Logo for BIMI.

Verified Mark Certificates, Briefly

A Verified Mark Certificate (VMC) is issued by an authorized Certificate Authority after confirming the requesting domain owner holds an active, registered trademark that matches the exact logo being published. It exists to solve the abuse problem described earlier: without it, nothing would stop a malicious domain from publishing someone else's logo as its own BIMI image, assuming it could also meet the DMARC enforcement bar. Gmail, Apple Mail, and several other major providers currently require a valid VMC before they'll display any logo at all, making it — despite being technically optional in the specification — the practical gatekeeper for BIMI actually working at scale. A more limited alternative, the Common Mark Certificate (CMC), exists for logos without a registered trademark but has far narrower provider support. The complete process, providers, and realistic cost expectations are covered in Verified Mark Certificate (VMC).

BIMI Adoption Across Mailbox Providers

What BIMI Looks Like in Practice

When everything is configured correctly and a supporting provider has picked up the record, the practical difference is straightforward: instead of a generic gray circle or a colored initial next to a sender's name in the inbox list, the recipient sees the brand's actual logo, consistently, on every properly authenticated message from that domain. This is genuinely subtle in isolation — a single message with a logo doesn't feel dramatically different from one without — but the cumulative effect across dozens of messages over time is a level of visual consistency and recognizability that a spoofed or newly registered lookalike domain simply cannot replicate, precisely because it can't obtain the certificate tying that specific logo to that specific, trademark-holding domain.

Common Misconceptions About BIMI

Real-World Use Cases

BIMI Compared to Other Sender Trust Signals

This comparison is useful for setting realistic expectations with non-technical stakeholders who may have seen a "verified" checkmark on a social platform and assume BIMI works the same way. It doesn't — BIMI is domain-controlled, standardized across participating providers, and tied to a real trademark verification process rather than a platform's internal, and often opaque, verification criteria.

How BIMI Interacts With Email Client Rendering Differences

Even among providers that support BIMI, the actual visual presentation isn't identical — logo size, shape (circular crop versus square), placement relative to the sender name, and whether the logo appears in the inbox list view versus only when a message is opened all vary by provider and sometimes by client version. This is a direct consequence of BIMI standardizing the data (the logo file and its verification) while deliberately leaving the presentation layer up to each provider's own design language, similar to how a favicon displays slightly differently across browsers despite being the same standardized file format. Brands publishing BIMI should design their SVG logo to work reasonably well when cropped into a circle, since that's the most common rendering treatment across major supporting providers, even though the specification itself doesn't mandate any particular crop shape.

What to Monitor After Going Live

A BIMI rollout isn't a configure-once task if it's being taken seriously as an ongoing brand asset. The things worth periodically re-checking are: whether the DMARC policy underneath it has remained enforced (a policy change made for unrelated reasons can silently break BIMI eligibility), whether the certificate is still within its validity window, whether the logo file's hosting is still reachable and serving the correct content type, and whether newly added mailbox providers have started or stopped supporting BIMI in ways that change your effective coverage. None of these require frequent attention, but a quarterly check with a tool like BIMI Checker is a reasonable cadence for catching drift before a stakeholder notices a missing logo and asks why.

Where BIMI Fits in a Broader Email Trust Strategy

BIMI should be understood as the last, optional, cosmetic layer of a trust stack that starts with SPF, builds through DKIM, gets enforced by DMARC, and only then becomes eligible for BIMI's visual reward. Skipping straight to BIMI without the foundational work isn't just unproductive, it's structurally impossible — no supporting provider will display a logo for a domain that hasn't proven itself through DMARC first, no matter how polished the logo file or how much budget has already been spent on a certificate. Teams new to email authentication should treat BIMI as a milestone marking the end of a rollout, not a starting point, and should expect the DMARC and reporting work that precedes it to take considerably longer than the BIMI configuration itself.

A Short History of Email Sender Identity Before BIMI

Long before BIMI existed, mailbox providers and third-party plugins experimented with various ways to give senders visual identity in the inbox — Gmail's own sender photo feature for personal contacts, Google's earlier "authenticated icon for verified senders" pilot, and a handful of proprietary badge systems from individual providers that never extended beyond their own platform. Each of these solved a narrow version of the same problem but suffered from the same structural weakness: they were provider-specific, meaning a brand had to configure and maintain a completely different system for every mailbox provider it wanted to appear branded in, with no shared standard, no shared verification requirement, and no portability between providers. BIMI's core contribution wasn't the idea of a sender logo — that had been tried in pieces already — it was standardizing the mechanism, the DNS location, the file format, and eventually the certificate-based verification model, so that a single published configuration could work consistently across every provider that chose to support the standard, rather than requiring a brand to maintain a dozen separate proprietary integrations.

Why DNS Was the Right Place to Publish This

It's worth pausing on why BIMI chose DNS as its publishing mechanism rather than, say, a centralized registry each mailbox provider would query independently. DNS was the obvious and arguably only sensible choice given how DMARC, SPF, and DKIM already work — all three live in DNS, all three are controlled directly by the domain owner without requiring permission or registration with any specific mailbox provider, and all three are queryable in real time by any receiving system without a special relationship or API key. BIMI inherits every one of these properties by following the same pattern: publish a record in a predictable, standardized location, and any supporting provider can independently discover and validate it without coordination. This is also precisely why BIMI reuses the DKIM-style selector mechanism — it's a proven pattern for allowing multiple concurrent records (for testing, rotation, or subdomain-specific branding) without requiring a redesign of how DNS-based email standards are typically structured.

The Cost Picture: What Actually Costs Money

This breakdown matters because it reframes a common misunderstanding: BIMI as a specification costs nothing, but BIMI as a reliably working feature across Gmail and Apple Mail specifically has a real, ongoing cost tied to trademark certification. Organizations budgeting for BIMI should budget for the certificate, not the DNS record — the DNS record was never the expensive part.

A Practical Implementation Timeline

For an organization starting from a domain that already has DMARC enforced (the common starting point for anyone seriously considering BIMI), a realistic timeline looks roughly like this: logo design and SVG Tiny PS conversion typically takes anywhere from a few hours for a simple existing mark to a couple of weeks if design revisions are needed to simplify a complex logo into a compliant vector file. Trademark verification and VMC issuance through a Certificate Authority is usually the longest single step, often taking one to several weeks depending on how quickly trademark documentation can be produced and verified. DNS publication itself takes minutes. End to end, a realistic first-time BIMI rollout for an organization with an already-registered trademark commonly spans four to eight weeks, dominated almost entirely by the certificate issuance process rather than any technical implementation step.

Expert Tips for a Smooth BIMI Rollout

BIMI and Brand Consistency Across Multiple Domains

Organizations operating multiple domains — a corporate domain, a product-specific domain, regional domains for different markets — need to treat BIMI as a per-domain configuration, not a one-time global setup. Each domain that sends mail independently needs its own DMARC enforcement, its own BIMI record, and in most cases its own certificate coverage, since a VMC is issued against a specific domain and logo pairing rather than an organization as a whole. Companies with a portfolio of domains commonly prioritize BIMI rollout by sending volume and brand visibility, starting with the primary customer-facing domain before extending the same process to secondary properties, rather than attempting a simultaneous rollout across every domain at once.

Frequently Overlooked Technical Details

A handful of details trip up otherwise well-executed BIMI rollouts often enough to be worth calling out directly. The SVG file must be served with an appropriate content type by the hosting server — some CDNs and static hosts default to serving .svg files as generic octet-stream data, which some validators treat as a failure even though the file itself is perfectly valid. The l= and a= URLs must both be stable, long-term URLs, not staging or temporary links, since mailbox providers may cache results for extended periods and a broken link discovered later can silently disable an otherwise-working setup. And because BIMI evaluation happens at the mailbox provider, not at send time, there's no error message or bounce that alerts a sender when something is misconfigured — the only way to know is to actively check, which is the entire reason a dedicated checking tool is worth using periodically rather than assuming a one-time setup stays correct indefinitely.

A Short Glossary for Newcomers

How BIMI Is Reported and Measured Internally

Unlike DMARC, which generates its own dedicated aggregate reporting feed, BIMI has no equivalent built-in reporting mechanism — there's no daily XML summary telling a domain owner how often its logo was actually displayed versus falling back to a default avatar. Teams that want to measure BIMI's real-world impact generally have to rely on indirect signals: engagement metrics (open rates, click-through rates) compared before and after rollout, direct customer feedback, or in some cases analytics offered by an email service provider that has built its own BIMI-adjacent tracking on top of delivery data. This absence of native reporting is worth setting expectations around too — BIMI's value is largely qualitative and brand-oriented rather than something that produces a clean, attributable dashboard metric the way DMARC's aggregate reports do for authentication visibility.

Who Should Prioritize BIMI First

Not every domain gets equal value from investing in BIMI right now, and being honest about that helps set priorities correctly. Domains with high-volume customer-facing mail — banks, retailers, airlines, SaaS platforms with large user bases — get the clearest benefit, since brand recognition compounds across the sheer number of messages recipients see. Domains that are frequent targets of phishing or lookalike-domain impersonation specifically benefit from the differentiation a verified logo provides. Domains sending purely internal, B2B, or low-volume transactional mail generally see far less practical benefit relative to the certificate cost, and are usually better served focusing further effort on DMARC enforcement quality and monitoring rather than rushing into BIMI. This isn't a permanent judgment — a small domain today may become a large one — but it's a reasonable way to sequence effort when resources are limited.

Getting Started: A Realistic First Step

If your domain doesn't yet have DMARC enforced, that's genuinely the first and only meaningful step — use DMARC Lookup to check your current status, and the DMARC Record Generator to build a correct starting record if you don't have one. Once DMARC is confirmed enforced at quarantine or reject with pct=100, prepare a compliant SVG logo, decide whether a VMC makes sense given your trademark status and target providers, and publish the BIMI TXT record. Use the BIMI Checker at each stage to confirm what's actually resolving and reachable before waiting on any specific inbox to reflect the change.

Setting Expectations With Stakeholders

One of the more underrated parts of a successful BIMI rollout is simply managing expectations before starting, especially when a marketing or brand stakeholder is the one requesting it. Communicate clearly, up front, that BIMI is gated on DMARC enforcement that may not yet exist, that the certificate step commonly takes weeks rather than days, that display isn't instant even after everything is published due to provider-side caching, and that coverage will never be universal since not every mailbox provider supports the standard. A rollout framed honestly this way tends to land as a successful, expected outcome; the same rollout framed as "we'll have logos everywhere by next week" tends to generate frustration regardless of how correctly the technical work was actually done, simply because the timeline and coverage expectations were never realistic to begin with. Setting the DMARC prerequisite conversation early, ideally before any logo design work even begins, also avoids the common situation where a finished, compliant logo sits unused for months while enforcement work that should have started first is only just getting underway.