Your email authentication does its job where no one can see it. SPF, DKIM, and DMARC run at the receiving server, decide whether a message is genuine, and leave no mark the recipient ever notices. BIMI, short for Brand Indicators for Message Identification, is the layer that makes that invisible trust visible: a verified version of your brand logo, shown beside your name in the inbox, displayed only for senders whose authentication is in order.
That used to be a pure branding play. In 2026 it is more than that, because Gmail, Yahoo, and Microsoft now require high-volume senders to meet stronger authentication requirements, including DMARC. However, those sender rules can generally be met with a monitoring policy such as p=none, while BIMI requires DMARC enforcement at p=quarantine or p=reject. In other words, bulk-sender compliance is the starting point, but BIMI requires the extra step to enforcement. BIMI is the visible reward for finishing that stronger authentication work.
This guide covers what BIMI is and how the logo actually reaches the inbox, which providers support it today, the choice between a Verified Mark Certificate and a Common Mark Certificate, the strict SVG and DNS requirements, who should prioritise it (B2B outbound teams included), and what it takes to keep your logo showing once it is live.
What is BIMI?
BIMI, or Brand Indicators for Message Identification (say it "bih-mee"), is an email specification that lets a brand show a verified logo beside its authenticated messages in inbox providers that support it. The logo is the whole point: it gives the recipient a visible signal that the message genuinely came from you.
BIMI does not work on its own. It sits on top of SPF, DKIM, and DMARC, the three checks that prove an email really came from the domain it claims to. It does not replace any of them; it rewards senders who have set them up correctly with a visible badge in the inbox. No authentication, no logo.
The specification is maintained by the AuthIndicators Working Group, whose members include Google, Yahoo, Mailchimp, and Valimail. The project behind it began in 2015 to push wider DMARC adoption, the formal working group and first published spec followed in 2019, and the group still develops the standard today.
One honest note, because it shapes what you should expect from BIMI: it is not an authentication protocol itself. It is a visibility layer that depends entirely on the authentication underneath it. The protection it offers against logo spoofing is real but indirect; the security comes from the DMARC enforcement BIMI forces you to reach, not from the logo on its own.
Why BIMI matters for senders in 2026
BIMI is worth the effort for three connected reasons. None of them is decoration; each is about what a verified logo signals to the systems and the people on the other end.
It makes authentication visible
This is the heart of it. As DigiCert frames it, "since SPF, DKIM, and DMARC email authentication checks are not immediately visible to email recipients, the validated logo display makes trust visible and apparent." All the authentication work you have done lives in headers nobody reads. BIMI is the one place it surfaces where a human can see it. For senders who have pushed DMARC to enforcement, especially the bulk senders Gmail, Yahoo, and Microsoft now hold to that bar, BIMI turns invisible compliance into a recognisable mark in the inbox.
It helps recipients recognise legitimate senders
A verified logo gives the recipient a fast visual cue that a message is from who it claims to be. That matters most in the inboxes attackers target, where a phishing email spoofing a familiar sender name sits one line away from the real thing. The logo is the difference your reader can actually see. It is especially valuable in industries that get impersonated constantly, such as banks, retailers, social platforms, and healthcare.
Be clear about the limit, though. BIMI does not stop phishing on its own. A determined attacker can still send from an unrelated domain; that message simply will not carry your logo. The protection is recognition-based, which means it helps your recipients spot the genuine sender rather than block the fake one.
It supports inbox standout and engagement
The benefit marketers raise most is also the simplest: a branded logo in a column of plain sender names stands out. In a crowded inbox, that visual differentiator is something your unbranded competitors do not have. Whether it lifts opens, and by how much, depends heavily on your audience and how recognisable your brand already is, so treat the large engagement-uplift figures often quoted around BIMI with caution unless they come from primary research on a comparable sender. The honest case for BIMI is recognition and trust; engagement is a plausible follow-on, not a guarantee.
How BIMI actually works
BIMI looks like magic in the inbox, but the mechanism is straightforward. It comes down to one prerequisite, one DNS record, and a sequence the receiving server runs every time your email arrives.
The DMARC prerequisite
BIMI is only available to senders whose DMARC policy is set to p=quarantine or p=reject, the two settings that tell receiving servers to actively filter or refuse mail that fails authentication. A policy of p=none, which only watches and reports, does not qualify. For Gmail BIMI support, Google also requires pct=100, meaning the enforcement policy applies to all mail from the domain.
This is the gate, and it is where most of the work actually lives. Publishing a BIMI record takes minutes; getting your domain safely to p=quarantine or p=reject without catching your own legitimate mail is the real project. If you are not there yet, our guides to email authentication and reaching a DMARC reject policy are the place to start.
The BIMI DNS record
Once DMARC is enforced, BIMI itself is a single DNS record. You publish a TXT record, a small text entry in your domain's DNS settings, at default._bimi.<yourdomain.com>.
Its value depends on whether you are using a certificate-backed PEM file or a standalone SVG. For Gmail-style VMC/CMC-backed BIMI, Google's current example uses a PEM file that contains both the SVG logo and the certificate:
v=BIMI1; l=; a=https://yourdomain.com/certificate.pem;
In this setup, v=BIMI1 declares the BIMI version, a= points to the PEM file, and the validated SVG logo is embedded inside that PEM file. Some BIMI implementations also reference a standalone SVG through l=, but Gmail does not support standalone SVG-only BIMI, so certificate-backed senders should follow the requirements of the mailbox providers they care about. If you send from more than one subdomain, each can carry its own record (for example, default._bimi.marketing.yourdomain.com), which matters for teams that split sending across subdomains.
The verification flow at the recipient's mail server
Here is what happens, in order, when one of your emails reaches a supporting inbox provider:
- It verifies SPF, DKIM, and DMARC on the message.
- It confirms your DMARC policy is at quarantine or reject.
- It queries your BIMI record at default._bimi.<yourdomain>.
- It fetches the BIMI evidence referenced in the DNS record (the PEM file in the a= parameter for Gmail-style certificate-backed BIMI, or the standalone SVG in the l= parameter where the provider accepts it).
- It validates the embedded logo and certificate chain inside the PEM file (or, for standalone SVG, the certificate referenced separately in a=).
- If every check passes, it displays your logo beside the message.
Fail any step and the logo simply does not appear. That failure does not affect delivery, though: your email still arrives, just without the badge.
What BIMI does not guarantee
Here is the caveat most BIMI explainers skip: configuring everything correctly still does not guarantee your logo will show. Inbox providers reserve the right to withhold it based on your sender reputation, anti-abuse signals, user complaints, or criteria they never publish. A correct BIMI setup is a precondition for the logo, not a promise of it. Reputation still has to be there, and that thread runs through the rest of this guide.
VMC vs. CMC: which mark certificate do you need?
This is the part most BIMI guides gloss over, and it is where the real decision sits. To display a logo in the inboxes that require one, you need a Mark Certificate, and there are two kinds: a Verified Mark Certificate (VMC) and a Common Mark Certificate (CMC). They differ on one thing that drives everything else: whether your logo is a registered trademark.
Verified Mark Certificate (VMC)
The VMC is the original BIMI mark certificate and the higher-assurance option. It requires a logo that is a registered trademark in an approved jurisdiction, and the issuer verifies that trademark before granting the certificate. In return, the VMC is the only certificate that unlocks Gmail's blue verified checkmark beside your sender name, the strongest trust signal BIMI offers.
VMCs are issued by an approved Mark Verifying Authority. DigiCert and Entrust were the original two. Entrust exited the BIMI mark certificate market in May 2025 after selling its public certificate business to Sectigo in January 2025, and Entrust is no longer listed on the BIMI Group's current Mark Certificate issuer page. As of the BIMI Group's current issuer list, the listed Mark Verifying Authorities are DigiCert, GlobalSign, and SSL.com. Because mailbox providers decide independently which certificates they honor, buyers should confirm issuer acceptance with the providers that matter most to their audience before purchasing. Expect from around $749 a year, rising toward $1,300 to $1,500 with some authorities and shorter terms. A VMC suits established brands that already hold a trademark, especially in high-impersonation industries like banking, retail, and healthcare.
Common Mark Certificate (CMC)
The CMC is the newer, lower-barrier option, created for the many brands whose logos are not formally trademarked. Instead of a trademark, the issuer verifies your organisation's identity and your ownership of the logo through other means, such as incorporation documents, domain ownership, and a history of using the mark. The same authorities issue it.
Here is the update that matters: as of September 2024, Gmail accepts CMCs in addition to VMCs, so a CMC unlocks Gmail logo display (without the blue checkmark, which stays exclusive to the VMC). Apple Mail's current position is less consistent across sources — most BIMI documentation, including Apple's own guidance through certificate authorities, indicates Apple Mail still requires a VMC and does not yet accept CMCs. Yahoo Mail, AOL, and Fastmail display logos without requiring any certificate. If Apple Mail coverage matters to your audience, treat CMC support there as not guaranteed and confirm directly with your chosen certificate authority before purchasing.
On cost, a CMC starts a little lower, from around $649 a year, but the gap is often smaller than people expect, and at some authorities a CMC runs close to VMC pricing. The real reason to choose a CMC is usually the absence of a trademark, not a dramatic saving. It fits brands without a registered trademark, smaller companies, and B2B teams whose logos were never formally trademarked.
Which should you choose?
The decision usually comes down to two questions: do you hold a trademark, and where do your recipients read their mail?
If your logo is already trademarked and you send meaningful volume to Gmail, the VMC is the stronger choice: the same logo, plus the blue checkmark that a CMC cannot give you, and reliable Apple Mail coverage. If you do not hold a trademark, the CMC is your way in, with confirmed Gmail logo display (without the checkmark) and Apple Mail coverage that varies by issuer, so confirm with your chosen certificate authority if Apple recipients matter.
BIMI logo requirements: the SVG Tiny PS specification
BIMI is strict about the logo file, and this is where most first attempts fail. Your logo has to be in a specific, locked-down format, sized and built to exact rules. Get the file wrong and the whole thing silently fails to display, so it pays to get it right the first time.
Format and structure
Your logo must be an SVG, but not just any SVG. It has to be SVG Tiny PS (Portable/Secure), a deliberately restricted subset of the SVG format that strips out scripts, external references, animation, and anything else that could carry a security risk. The "secure" part is the whole point: inbox providers will not render a logo file that could do anything other than draw itself.
The catch is that a standard SVG exported from Illustrator or Figma is almost never SVG Tiny PS-compliant out of the box, so it usually needs converting. The BIMI Group publishes validation tooling, and platforms like PowerDMARC offer SVG conversion utilities that handle the cleanup for you.
Visual requirements
Beyond the format, the design itself has to suit a small, cropped space:
- Square, 1:1 aspect ratio. The logo is shown in a small circular or square crop, so anything wider or taller gets cut off.
- A solid background colour. Transparency is not supported at all, and a transparent background is a guaranteed failure.
- Legible at tiny sizes. In an inbox list the logo often renders around 32 by 32 pixels, so fine detail vanishes; a simple, bold mark works best.
- Logo only, no text. Your sender name sits right beside it and supplies the words, so the mark should stand on its own.
File constraints
The file itself has a few hard limits. It must stay under 32KB, and smaller renders more reliably, since logos with complex paths often blow past that ceiling. It has to be hosted over HTTPS at a stable, publicly accessible URL that any receiving server can fetch. The URLs in your BIMI DNS record must point to publicly reachable HTTPS locations for the required BIMI files. For certificate-backed BIMI, the validated SVG logo is embedded in the PEM file, so changing the logo itself generally requires reissuance. Moving files to a new URL requires updating the BIMI DNS record and confirming the new location fetches correctly; whether certificate reissuance is needed can depend on the certificate authority's process.
Common implementation pitfalls
When a BIMI logo will not show, it is almost always one of these:
- The file was never converted to SVG Tiny PS. This is the single most common cause of validation failure.
- Transparency was left in. Even partial transparency fails, so flatten to a solid background.
- The file exceeds 32KB, usually because of complex vector paths.
- The hosting URL has an HTTPS or certificate error, so the logo cannot be fetched.
- The DNS record points to the wrong, unreachable, or outdated BIMI file URL.
Run your record through a BIMI inspector before assuming the logo works; the failure is almost always somewhere in this list.
Which inbox providers currently support BIMI?
Provider support is the most out-of-date detail in most BIMI write-ups, so here is the current 2026 picture, confirmed against current sources. Because providers do change their stance, check the BIMI Group's support tracker before you rely on any single row.
A few things the table cannot capture. Microsoft is the notable gap: it does not support BIMI in Outlook.com or Hotmail and has signalled no near-term plans to, so a meaningful slice of your audience will not see your logo no matter how clean your setup is. Beyond the providers listed, a handful of others (Zoho Mail, GMX, and Web.de among them) support BIMI in some form. And the certificate column is the practical headline: Gmail and Apple Mail need a Mark Certificate to show the logo, while Yahoo and Fastmail can display one without, though they still recommend it.
How to implement BIMI, step by step
With the pieces understood, here is the actual sequence. The order matters, because each step depends on the one before it, and the first is by far the longest.
Step 1: Confirm DMARC is at p=quarantine or p=reject
Nothing else counts until this is true. If your DMARC policy is still at p=none, no logo will display no matter how perfect the rest of your setup is, so start by confirming your policy is at quarantine or reject and that it is passing cleanly for your real mail. If you are not there yet, our guide to setting up DMARC in Office 365 walks through reaching enforcement safely. This is the step measured in weeks, not minutes, so budget for it.
Step 2: Prepare your SVG Tiny PS logo
Convert your logo to SVG Tiny PS with a validation tool, as a square, with a solid background, and under 32KB. For certificate-backed BIMI (which is what Gmail requires), your SVG logo will be embedded inside the PEM file your certificate authority issues, and the PEM file is what you host at a stable HTTPS URL. Changing the actual logo file generally requires certificate reissuance because the certificate is bound to the validated logo. Moving the hosted PEM file to a new URL requires updating your BIMI DNS record and confirming the issuer's policy. Treat both the logo and the hosting URL as long-term decisions.
Step 3: Obtain a VMC or CMC
Decide which certificate you need: a VMC if your logo is trademarked and you want Gmail's blue checkmark, or a CMC if it is not trademarked. Purchase it from a current Mark Verifying Authority and confirm that the issuer is accepted by the mailbox providers you care about. The BIMI Group's current issuer list includes DigiCert, GlobalSign, and SSL.com.
Verification usually takes two to four weeks and involves confirming your identity, your domain ownership, and, for a VMC, your trademark. The certificate is tied to the validated logo and organization. Changing the actual logo generally requires reissuance; changing where the same BIMI files are hosted requires updating the BIMI DNS record and confirming the issuer's policy.
Step 4: Publish the BIMI DNS record
Add a TXT record at default._bimi.<yourdomain.com>. For Gmail-style certificate-backed BIMI, the value follows Google's PEM format: v=BIMI1; l=; a=<your PEM file URL>;. For providers that accept standalone SVG (Yahoo, AOL, Fastmail), you can publish v=BIMI1; l=<your SVG URL>; a=<your certificate URL>; instead, but Gmail will not honor the standalone-SVG form. DNS changes typically propagate within 24 to 48 hours. Once it is live, test it with a BIMI validation tool, such as those from the BIMI Group, PowerDMARC, or MX Toolbox, to confirm the record parses and the logo fetches.
Step 5: Monitor logo display
Send a test email to a Gmail, Yahoo, and Apple Mail account to see whether the logo appears, and use a BIMI inspector to confirm the record and logo are being read correctly. Be patient here: providers often take days, sometimes weeks, to begin showing a logo after everything is configured, so an absent logo on day one is not necessarily a fault. If it still has not shown after that, work back through the pitfalls list above.
BIMI and the 2024-2025 enforcement context
BIMI did not arrive in a vacuum. It lands in the middle of the biggest authentication shift the inbox has seen in years, and that context is what makes it worth doing now.
In February 2024, Google and Yahoo began requiring bulk senders to authenticate with SPF and DKIM and to publish at least a basic DMARC policy. Google defines a bulk sender as anyone sending 5,000 or more messages a day to personal Gmail accounts; Yahoo does not publish a specific threshold but classifies any domain sending significant volume to Yahoo users as a bulk sender. Microsoft followed on May 5, 2025 with the same bar for high-volume Outlook senders (5,000+ messages per day to consumer Outlook, Hotmail, and Live accounts). The floor those rules set is a DMARC policy of p=none, which monitors but does not enforce.
Here is where BIMI fits. That p=none floor is the minimum, and it is not enough for a logo, because BIMI needs DMARC at p=quarantine or p=reject. The direction of travel is unmistakable, though: the major inboxes are steering senders toward enforcement, and p=reject is becoming the expected end state rather than the ambitious one. BIMI is the visible reward waiting at that endpoint.
That reframes the work. A team sitting at p=none just to tick the compliance box has already done the hard part of authentication; advancing to enforcement is the remaining stretch. For anyone weighing whether that stretch is worth it, BIMI is a concrete return, since the same move that satisfies the inbox providers' direction of travel also earns you a logo in the inbox. If you want the full picture of what the bulk-sender rules require, our Google bulk sender guidelines cover it.
BIMI for B2B outbound and sales engagement
BIMI was built with marketing email in mind, but nothing about it is exclusive to marketers. A B2B outbound team running cold sequences through Outreach, Salesloft, or HubSpot is just as eligible, provided the authentication underneath those sends is configured correctly. The catch is that B2B outbound has a few wrinkles BIMI guides written for marketers never address.
When BIMI makes sense for B2B outbound
BIMI is not automatically worth it for every outbound program; it pays off most in three situations. It helps when your brand is already recognisable, because the logo only reinforces legitimacy if the recipient knows your name, which means an established B2B brand gets far more from it than an unknown startup. It helps when volume is high, because the certificate is a fixed annual cost that amortises well across heavy sending and poorly across a trickle. And it helps most in industries where impersonation is common, such as financial services, software, and payments, where attackers routinely spoof vendor names and the recognition value is highest.
Subdomain considerations
This is where B2B outbound diverges from marketing. Most outbound teams send cold email from a subdomain, like outreach.company.com or sales.company.com, to keep bounce and complaint activity away from the root domain's reputation.
The operational implication is the part teams miss. If you send from several subdomains, each sending subdomain needs DMARC enforcement and BIMI configuration that the receiving provider can validate. However, you do not necessarily need a separate certificate for every subdomain when the same logo and domain structure are covered; certificate needs depend on the logo, domain structure, and issuer rules.
Our guidance on email subdomain best practices and subdomain and alternative domains covers how to structure this.
Sales engagement platform compatibility
The platform you send from is rarely the blocker. Outreach, Salesloft, and HubSpot all support custom DKIM signing and SPF inclusion, and BIMI sits on top of correctly configured authentication regardless of which one is doing the sending. The real limitation is the same gate as everywhere else: the sending domain or subdomain has to be at DMARC p=quarantine or p=reject. Many B2B teams running these platforms are still at p=none, so for them the work is not BIMI itself; it is advancing DMARC to enforcement first. If deliverability from these platforms is the priority, start with our guides to Outreach email deliverability and Salesloft email deliverability.
Why BIMI is not a set-and-forget achievement
Getting your logo to appear is the milestone everyone aims for. Keeping it there is the part the project plans tend to skip. BIMI eligibility is not a one-time achievement; it rides on your DMARC staying at enforcement and passing, every single day. The moment the authentication underneath it breaks, DMARC starts failing and your logo can quietly disappear.
Authentication drifts for ordinary, undramatic reasons:
- You add a new sending tool but forget to include it in your SPF record, so its mail fails SPF and can drag down DMARC.
- You rotate a DKIM key without overlapping the old and new selectors, so signatures fail during the switch.
- Someone spins up a new sending subdomain without DMARC enforcement, so its mail is not BIMI-eligible even though your root domain is.
- Your Mark Certificate quietly expires; VMCs and CMCs renew annually, and an expired certificate stops the logo until it is renewed.
Any one of these can pull your logo without anyone noticing, because BIMI fails silently: the email still arrives, just without the badge, so nothing flags that something broke.
This is the case for monitoring rather than spot-checking. Allegrow checks your SPF, DKIM, and DMARC every hour, so configuration drift surfaces while it is still a quick fix, not weeks after your logo vanished and your deliverability slipped with it. For a team that has spent the time and money to earn a BIMI logo, that ongoing watch is what protects the investment. Our work on safeguarding domain health and email deliverability best practices puts that monitoring in the wider context of keeping a sending program healthy.
Conclusion
BIMI is best understood as the visible reward for work the major inboxes now expect anyway. SPF, DKIM, and DMARC at enforcement are no longer optional for serious senders, and BIMI is what turns that invisible groundwork into a logo your recipients actually see.
Keep the honest framing in view, though. BIMI is a precondition for the logo, not a promise of it. Your sender reputation, the health of your authentication, and each inbox provider's own discretion all still decide whether the logo shows on any given day.
For a B2B team whose sending spans several ESPs, sales engagement platforms, and subdomains, that is the real challenge: BIMI is achievable, but only while the authentication underneath stays healthy across all of it. Allegrow's hourly SPF, DKIM, and DMARC monitoring is what keeps that authentication, and the BIMI eligibility riding on it, intact over time. Start a 14-day free trial and watch Allegrow track your own authentication across every inbox, so the logo you worked to earn does not quietly disappear when something drifts.
Frequently asked questions
What is BIMI?
BIMI (Brand Indicators for Message Identification) is an email specification that displays a verified version of your brand logo beside your authenticated messages in supporting inbox providers. It is not an authentication method itself; it sits on top of SPF, DKIM, and DMARC and rewards senders who have configured them correctly.
What does BIMI require?
BIMI requires a full authentication stack plus two BIMI-specific pieces. You need SPF, DKIM, and DMARC configured, with DMARC at enforcement (p=quarantine or p=reject, not p=none, and pct=100 where required); a supported Mark Certificate such as a VMC or CMC for providers that require certification; an SVG Tiny PS logo; and a BIMI DNS TXT record that points to the required BIMI file or certificate location.
What is the difference between VMC and CMC?
A VMC requires a registered trademark and is the only certificate that unlocks Gmail's blue verified checkmark. A CMC does not require a trademark and unlocks Gmail logo display (without the blue checkmark). Apple Mail's CMC support is not consistently documented across sources — most BIMI guidance indicates Apple Mail still requires a VMC, so confirm with your chosen issuer before purchasing a CMC if Apple coverage matters. Both certificates are issued by approved Mark Verifying Authorities. The BIMI Group's current issuer list includes DigiCert, GlobalSign, and SSL.com, with the VMC costing a little more.
How much does BIMI cost?
The main ongoing cost is the Mark Certificate. A VMC typically starts around $749 a year and a CMC around $649, varying by issuer and contract term, with some authorities charging up to $1,300 to $1,500. Budget also for converting your logo to SVG Tiny PS and for the implementation time, most of which is DMARC work.
Which inbox providers support BIMI?
Gmail, Yahoo Mail, Apple Mail, Fastmail, AOL, and La Poste all support BIMI as of 2026, with Gmail and Apple Mail requiring a Mark Certificate to show the logo. Gmail accepts both VMCs and CMCs; Apple Mail's CMC support is not consistently documented, so a VMC is the safer choice if Apple Mail coverage matters. Microsoft does not currently support BIMI in Outlook.com or Hotmail. Provider support shifts, so check the BIMI Group's tracker for the latest.
Does BIMI guarantee my logo will display?
No. A correctly configured BIMI record is a precondition for logo display, not a guarantee of it. Inbox providers reserve the right to withhold the logo based on your sender reputation, anti-abuse signals, user complaints, or criteria they do not publish, so a clean setup still has to be backed by a healthy reputation.
Why isn't my BIMI logo showing up?
Other frequent culprits are a missing or expired Mark Certificate, an SVG that is not in SVG Tiny PS format or is over 32KB, a DNS record pointing to the wrong or unreachable BIMI file URL, recent changes still propagating, or a reputation issue with that specific provider.
Can B2B outbound emails use BIMI?
Yes, as long as the sending domain or subdomain is at DMARC p=quarantine or p=reject and has a Mark Certificate in place. Sales engagement platforms like Outreach, Salesloft, and HubSpot support the underlying authentication BIMI needs. The main B2B wrinkle is subdomains: each sending subdomain needs its own DMARC enforcement and BIMI record.
How long does BIMI implementation take?
Realistically two to four months from a standing start, and most of that is DMARC. Advancing DMARC to enforcement is the long pole (weeks to months, depending on where you begin); Mark Certificate issuance takes about two to four weeks, DNS propagation 24 to 48 hours, and the logo itself can take days to weeks to appear once everything is live.

.jpg)

.jpg)
.jpg)
.jpg)