BIMI in 2026: your logo in the inbox, what it really costs, and the CMC that changed the math.

BIMI, Brand Indicators for Message Identification, puts your verified brand logo beside your messages in supported inboxes, and it is best understood as the visible half of email authentication rather than a feature in its own right. BIMI displays nothing for mail that fails authentication; it is a DNS record that tells a mailbox provider where to find your logo and how to verify it, and providers only honour it for domains running DMARC at enforcement, a policy of quarantine or reject. So the logo in the inbox is the part recipients see of work they otherwise never notice, the SPF, DKIM and DMARC underneath, and BIMI's real function is to give that invisible work a visible, business-friendly payoff. Four things gate it: DMARC at enforcement, a logo in the exact SVG Tiny PS format, a mark certificate that vouches for your right to the logo, and control of your DNS. The certificate is where the economics used to break, because the only option was a Verified Mark Certificate that demanded a registered trademark, and the arrival of the Common Mark Certificate, which asks instead for twelve months of public logo use, is the change that turned BIMI from a large-enterprise project into something most established brands can reach. This note covers the prerequisites, the certificate decision, the logo rules, the costs and the provider support, with a generator to build the record and a readiness check, and it sits at the top of the authentication stack the rest of this cluster builds.

First, DMARC at enforcement. Your domain needs a DMARC policy of quarantine or reject, not p=none, and the providers verify this before they will fetch your logo. This is the prerequisite that takes real time, because reaching enforcement safely means working through the DMARC journey, getting every legitimate sender authenticated and aligned, watching the aggregate reports, and moving from none to quarantine to reject without quarantining your own mail. Everything else in BIMI is days of work; this is the one that is weeks or months, and it is the one worth doing for its own sake regardless of BIMI. Second, the logo in SVG Tiny PS format, the constrained SVG profile BIMI mandates, which almost always means deliberate conversion rather than a normal export. Third, a mark certificate, a VMC or a CMC, for the inboxes that require one. Fourth, control of the sending domain's DNS to publish the record.

The order matters because the prerequisites have wildly different lead times, and a missing one discovered late stalls everything downstream. The certificate authorities will not issue against a domain that is not at DMARC enforcement, and the trademark route to a VMC adds its own multi-week or multi-month timeline if you do not already hold the mark. The disciplined sequence is to confirm all four before spending money: verify DMARC is at enforcement and has been stable there, validate that your logo can be made compliant as SVG Tiny PS, decide VMC versus CMC and confirm you can meet whichever evidence it needs, and check you have DNS access. Teams that order a certificate first and check the prerequisites later are the ones whose BIMI project takes a quarter instead of a fortnight, because each missing piece is discovered in series rather than cleared in parallel.

The mark certificate is the main line item, running roughly from the high hundreds to around 1,700 US dollars per year depending on the authority, with some resellers at the lower end and the larger certificate authorities higher. The approved issuers include DigiCert, Entrust, GlobalSign and Sectigo, and because pricing varies between them it is worth comparing rather than defaulting to the first. If you are pursuing a VMC without an existing registered trademark, the trademark is an additional cost and an additional timeline, on the order of a few hundred dollars at the USPTO or several hundred euros at the EUIPO, plus the months a registration can take, which frequently makes the trademark, not the certificate, the expensive part of a VMC. The certificate itself is issued as a PEM file, and hosting that file can be free, since some services host it at no cost, so the hosting is rarely where the money goes.

Where the cost lands therefore depends heavily on two decisions. Choosing a CMC over a VMC removes the trademark cost and timeline entirely, which is most of why the CMC reshaped the economics. And the inboxes you target change the calculus from the other side: one major provider displays BIMI logos without requiring any certificate at all, so a sender whose audience is concentrated there gets a logo for the price of a compliant SVG and a DNS record, while the full VMC-and-checkmark experience in Gmail is the most expensive end of the range. The honest way to budget BIMI is to decide first which inboxes matter for your audience and which trust signal you actually need, then price the certificate path that delivers it, rather than assuming BIMI means the maximum-cost VMC route by default. For many brands the right answer is a CMC and a few hundred dollars a year; for a few it is a VMC and a trademark; and for some the free Yahoo display is enough to start.

The deployment sequence follows the prerequisites in order. With DMARC already at enforcement and stable, you prepare the logo: take a clean vector of your mark, convert it to the SVG Tiny PS profile, validate it against the BIMI requirements with a checker, and host it at a stable HTTPS URL. You then obtain the certificate, choosing VMC or CMC, providing the trademark evidence or the twelve-month public-use evidence the chosen type requires, and receive it as a PEM file which you host at its own HTTPS URL. Finally you publish the BIMI DNS record at the selector under _bimi, with the v=BIMI1 tag, the l= tag pointing to the SVG, and, where you use a certificate, the a= tag pointing to the PEM. Each step depends on the one before, and skipping the validation at any step pushes the failure downstream where it is harder to diagnose.

Validation after publishing is its own discipline, because DNS propagation and the multi-part chain mean a record that looks published may not yet be live or correct everywhere. Walk the chain end to end: confirm the authentication results show DMARC passing at enforcement on real sent mail; confirm the BIMI record resolves at its selector and parses correctly; confirm the SVG URL is reachable over HTTPS and the file genuinely validates as SVG Tiny PS, not merely as SVG; and confirm the certificate links correctly and matches the logo it vouches for. A break anywhere, a logo URL that 404s after a site migration, an SVG that drifted out of compliance, a certificate that expired, a DMARC policy that someone relaxed, takes the logo down without any error message reaching you, which is why BIMI is not a set-and-forget deployment but a small standing piece of monitoring. The logo's absence is the only symptom, and noticing it before your recipients do means checking the chain on a schedule rather than assuming a successful launch stays successful.

The BIMI record lives at a selector under _bimi, and the default selector, named default, serves the default logo for any mail that does not specify otherwise. A message can point at a different selector by including a BIMI-Selector header naming it, which directs the receiver to a selector._bimi record with its own logo and, where required, its own certificate. The mechanism lets a brand display different marks for different streams or sub-brands, a parent brand on corporate mail and a product brand on that product's notifications, for instance, mapping naturally onto the stream-per-subdomain architecture where each stream already has its own identity. It is the same design logic as DKIM selectors: a way to manage multiplicity under one domain without the marks colliding.

In practice most senders use the default selector and a single logo, and the reason is the same maintenance arithmetic that governs the rest of BIMI. Each additional selector is another DNS record, potentially another certificate to purchase and renew, and another link in the chain to validate and monitor, so the multiplicity is worth it only when the brands genuinely differ enough that showing the same logo across them would be wrong. A single company with one consistent brand has no use for multiple selectors and should not create them. A holding company with distinct consumer brands, or a business whose product brands are deliberately separate from its corporate identity, is exactly the case the selector mechanism was built for, and there it lets each brand show its own verified mark while sharing the underlying authentication discipline. The principle, as everywhere in this stack, is to add complexity only where a real distinction justifies it, and to keep the default simple where it does not. A useful test before creating a second selector is whether a recipient would be confused or reassured by seeing two different marks from the same company; if the honest answer is confused, the streams belong under one logo, and the selector mechanism is solving a problem the brand does not have. The maintenance saved by resisting an unnecessary selector is small per record and compounds across the years a deployment runs, which is the same quiet arithmetic that rewards a clean SPF record and a documented DKIM register: fewer moving parts, fewer silent failures, less to validate each time something upstream changes.

The most expensive mistake is buying the certificate before the prerequisites are met. A team that orders a VMC while still at DMARC p=none, or before validating that its logo can be made SVG Tiny PS compliant, or without confirming it holds the trademark a VMC needs, has bought a credential it cannot yet use and will spend weeks unblocking, sometimes discovering only then that a trademark registration adds months. The fix is the discipline this note keeps returning to: clear all four prerequisites before spending, in parallel rather than in series. The second common mistake is choosing the VMC reflexively when the CMC would do, paying for a trademark and a higher-tier certificate to chase a blue checkmark the brand does not actually need, when a CMC would have put the same logo in the same inboxes for less money and less time. The third is treating BIMI as a launch rather than a standing concern, publishing the record, seeing the logo, and never checking again until a site migration breaks the logo URL or a certificate quietly expires and the logo vanishes unremarked. And the fourth is deploying BIMI at all while the authentication underneath is shaky, chasing the visible logo before the invisible foundation that makes it trustworthy is solid, which is effort spent in the wrong order.

Against those costs sits a return that is genuine but specific, and worth stating honestly rather than in the inflated terms BIMI marketing tends to use. The measured effects of a verified logo cluster around engagement and trust: studies report a meaningful lift in consumer confidence, single-digit to low-double-digit percentage improvements in open rates, stronger click-through, and a marked increase in brand recall, all flowing from recipients recognising and trusting a message at a glance. None of that is deliverability in the technical sense, the logo does not get a message into the inbox, but engagement of that kind is exactly what feeds the sender reputation that does drive deliverability over time, so the second-order effect is real even though the direct one is cosmetic. The ROI calculation is therefore concrete: weigh the certificate and setup cost, modest for a CMC, higher for a VMC with a trademark, against the share of your audience in BIMI-displaying inboxes and the value of a few percentage points of additional engagement across your sending volume. For a brand with significant volume into Gmail, Apple and Yahoo and the authentication already in place, that calculation usually favours BIMI comfortably; for a small sender, a niche-inbox audience, or a domain not yet at enforcement, it often does not yet, and the honest answer is to wait. BIMI rewards the prepared and wastes money for the unprepared, and knowing which you are is the whole decision.

Every prerequisite BIMI imposes is something a well-run sending operation should already have or want. DMARC at enforcement is the security project worth doing regardless, the subject of the DMARC journey, resting on the SPF and DKIM foundations and the subdomain architecture that gives each stream a clean identity. A sender who has done that work has already cleared the hardest BIMI prerequisite as a by-product, which is why BIMI is best framed not as a new project but as a reward to claim once the authentication stack is complete. On a self-hosted stack the picture is the same with more of it in your own hands: per-stream subdomains map onto BIMI selectors if you want different marks per stream, the DMARC enforcement is yours to reach and hold, and the BIMI record and certificate linkage are a small addition once the foundation is solid, with the SVG hosted on your own infrastructure and the chain verifiable in your own logs.

So the operator answer to "should we do BIMI?" is a sequence rather than a yes or no. If you are already at DMARC enforcement, read heavily in Gmail, Apple and Yahoo, and have a logo with a year of public use, a CMC is inexpensive and the recognisability is a genuine, measurable benefit, do it. If you are not yet at enforcement, the valuable work is reaching enforcement, and BIMI is the carrot waiting at the end, not a reason to rush the DMARC journey or, worse, to chase the logo before the authentication that makes it trustworthy is real. BIMI rewards the senders who finished the foundational work and is largely pointless for those who have not, which makes it a useful forcing function and a poor shortcut. That is the lens we bring, because we build and run the full authentication stack rather than bolting a logo onto the top, and BIMI is the visible last step of work that matters most where it is invisible. Where it helps to have the whole stack, from SPF and DKIM through DMARC enforcement to the BIMI logo, built and operated by people who do it daily, that is what our deliverability audit and email infrastructure practice exist to do.