BIMI stands for Brand Indicators for Message Identification.
At a practical level, BIMI lets a domain owner publish the logo it wants participating mailbox providers to display next to authenticated mail. When it works, the recipient sees the brand logo in the inbox or message view instead of only a generic sender avatar.
That sounds cosmetic, but the real point is not decoration. The point is to tie visible brand identity to mail that is already passing strong authentication.
Email has had a long-standing identity problem.
Even when a message is legitimate, the inbox often gives the recipient only a display name and an email address to judge it by. That leaves a gap between technical authentication and visual trust. A brand may have done the hard work of deploying SPF, DKIM, and DMARC, but the recipient still has very little help recognizing that brand at a glance.
BIMI tries to narrow that gap.
It gives receivers a standardized way to say, in effect:
That does not mean BIMI is an anti-phishing silver bullet.
BIMI is not the control that stops spoofing. DMARC, SPF, and DKIM do that work first. BIMI sits on top of that foundation and adds a visual identity layer.
So the problem BIMI solves is narrower than people sometimes think:
It helps to clear up three common misunderstandings early.
BIMI relies on email authentication. It does not replace it.
The current BIMI draft is explicit here: BIMI depends on DMARC, SPF, and DKIM, and receivers first decide whether the message is properly authenticated before they even get to logo handling.
Mailbox providers and mail clients keep final control over whether they display a logo at all.
The BIMI draft leaves display policy to receivers, and the BIMI Group's implementation guidance says participating mailbox providers have their own criteria. So a valid BIMI record is not a promise that every recipient, every provider, and every client will show the logo.
If a domain has a good authentication posture and qualifies for BIMI, that still does not mean every message from that domain is desirable or harmless. Receivers can still factor in reputation, user experience, and their own local policies.
The easiest way to think about BIMI is this:
That is the broad flow. The details matter, though.
BIMI starts with DMARC, not with graphics.
The BIMI Group implementation guide says the domain must be at DMARC enforcement, meaning p=quarantine or p=reject, and pct cannot be below 100. The current BIMI draft is similarly strict: BIMI participation requires a strong DMARC policy, and quarantine cannot be partial.
This is why BIMI is often discussed as a reward for doing DMARC properly rather than as an independent project.
If the domain is still at p=none, BIMI is generally off the table.
If you need a refresher on those policy modes, see DMARC policy modes explained.
The core BIMI record lives in DNS as a TXT record under default._bimi.example.com.
The BIMI draft defines the record as tag-value data. The most important tags for a basic deployment are:
v=BIMI1 to identify the record as BIMIl= for the HTTPS location of the logo filea= for the HTTPS location of authority evidence such as a mark certificate, when usedA simple example looks like this:
default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/brand/logo.svg; a=https://example.com/brand/certificate.pem"The BIMI draft says the l= location is required and HTTPS-based. The a= tag is optional in the core record format, but real-world provider support is where the story gets more complicated.
The logo is not just any image grabbed from a website.
Google's BIMI documentation says the image must be an SVG, and it also summarizes BIMI-standard restrictions such as no scripts, no animations, no external references, and use of the secure SVG profile. Google's guidance also adds practical compatibility requirements such as minimum dimensions, absolute pixel sizing, and keeping the file reasonably small.
The BIMI Group implementation guide likewise points senders to SVG Tiny PS formatting for the official logo.
That matters because a lot of first attempts fail here. A normal marketing SVG often contains extra elements or metadata that are fine on the web but not valid for BIMI use.
This is the part that surprises many admins.
In theory, the BIMI record can point only to a logo. In practice, some major providers want stronger proof that the logo is legitimately tied to the brand.
Google's admin guidance says BIMI requires third-party certification for the domain and logo, specifically a Verified Mark Certificate (VMC) or Common Mark Certificate (CMC). The BIMI Group implementation guide says self-asserted logos have limited support and treats VMC or CMC as highly recommended, with provider support varying.
So when people ask, "Why is BIMI harder than publishing one TXT record?" this is usually the answer.
The certificate-backed model exists because logos are high-value abuse targets. A bad actor can register a lookalike domain, but it should be much harder for that actor to get a trusted certificate for someone else's mark.
Even after all of that, the receiver still makes the final call.
The BIMI draft says mailbox providers and mail user agents are free to define their own policies for using BIMI data and displaying indicators. That means successful publication is necessary, but not always sufficient.
Receivers may consider:
This is why two providers can behave differently even when the domain's DNS is correct.
BIMI only makes sense if the visible From domain has strong protection against impersonation.
Without DMARC enforcement, a receiver would have little reason to trust a domain-published logo as a visual identity hint. A spoofed message could otherwise try to borrow the same branding value.
That is why BIMI effectively says: first prove that this domain is serious about authenticated, aligned mail, then the receiver may consider showing the brand's logo.
If DMARC is the policy and alignment layer, BIMI is the presentation layer that becomes possible after that policy is credible.
For recipients, the main benefit is faster recognition of legitimate mail from known brands.
For brands, the benefits are usually described in three buckets:
That third point matters more than the first two in many real deployments. BIMI projects often expose weak sender inventory, inconsistent alignment, or subdomain-policy problems that had been tolerated while the domain remained at p=none.
BIMI is useful, but it is not magic.
Not every mailbox provider or client treats BIMI the same way. Support, certificate expectations, and display behavior vary.
You usually need more than a DNS change:
Receivers do not have to display a logo merely because a record exists. Authentication is one prerequisite, not the only signal.
If a sender has poor reputation, high complaint rates, or bad list hygiene, BIMI will not rescue that program.
If you want the shortest useful explanation, use this one:
DMARC answers whether mail is authorized to use your domain. BIMI gives participating receivers a controlled way to display your brand identity once that authorization posture is strong enough.
That is both what BIMI does and why it exists.
BIMI is a standardized way for a domain owner to publish a brand logo for use with authenticated email.
It works by layering on top of DMARC-enforced mail, using a DNS assertion record that points to a compliant logo and, in many real-world deployments, certificate-backed evidence such as a VMC or CMC. The receiver then decides whether the message qualifies and whether the logo should be shown.
The problem BIMI solves is not spoofing itself. It solves the visual identity gap that remains after authentication is already working.
If you are still at p=none, BIMI is a future goal. If you are already at strong DMARC enforcement, BIMI becomes a practical next step for brands that want more recognizable, standards-based sender identity in the inbox.