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;

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).

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.

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.

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.

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.

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.