ActiScan

DMARC

BIMI Rollout: What It Actually Takes to Get a Client's Logo in the Inbox

September 7, 2026

Rodney Hall, COO— AI-assisted and reviewed prior to publication.

A brass emblem stamp beside plain white envelopes, symbolizing a verified brand mark on email.

A client asks why their logo doesn't show up next to their emails the way a competitor's does. It sounds like a five-minute fix: upload a logo somewhere, add a DNS record, done. In practice, BIMI is the last visible step in a chain of authentication work that has to be fully in place first, and most domains that attempt it get some part of that chain wrong.

Getting a logo into the inbox requires three things working together: a DMARC policy already at enforcement (p=quarantine or p=reject, applied to all mail), a logo file built to a restrictive SVG profile, and in most cases a paid certificate that proves the organization legally controls that logo. Skip any one of these and the logo simply never appears, with no error message sent back to explain why.

What Does BIMI Actually Require Before a Logo Can Show?

The prerequisite that trips up the most clients is DMARC enforcement. Google's own setup documentation is explicit that BIMI depends on messages being authenticated by DMARC, and that a monitoring-only policy of p=none does not qualify. The domain has to be actively rejecting or quarantining unauthenticated mail, not just watching it, before any mailbox provider will consider displaying a logo.

That single requirement is why BIMI conversations at an MSP almost always start as DMARC conversations. A client who has never gotten past p=none because SPF and DKIM alignment kept breaking marketing tools or forwarders has months of cleanup ahead before BIMI is even a realistic topic. The getting-started guide walks through the staged move from monitoring to enforcement, which is the same groundwork BIMI sits on top of.

Once enforcement is stable, the logo itself has to meet a narrow technical spec. It must be built as SVG Tiny Portable/Secure, a restricted profile of SVG designed for consistent rendering, and most design tools do not export that format natively without extra conversion steps. A logo exported straight from Illustrator or Figma as a normal SVG will typically fail validation on the first attempt.

Why Do Most BIMI Records Still Fail?

Because the failure is silent. A 2025 analysis of the top one million domains by URIports found that the number of domains with a published BIMI record grew 28% year over year, but the share of those records containing at least one error that blocks display grew even faster, rising to 53.6% of all BIMI-enabled domains. More than half of the organizations that did the work are getting nothing back for it, and they usually have no idea.

That gap exists because there is no feedback loop. When a mailbox provider's fetch of the logo file or certificate fails, whether from an expired TLS certificate on the hosting server, a redirect in the chain, or a malformed DNS record, it does not bounce, log, or notify the domain owner. It just quietly declines to show the logo. The most common single cause identified in that same dataset was a non-compliant SVG file, a problem that barely improved between 2024 and 2025 despite adoption climbing.

For an MSP managing this across a client base, that silence is the real operational risk. A domain can look BIMI-ready in every internal checklist and still never render a logo in a single inbox, and nobody finds out until someone happens to check.

VMC or CMC: Which Certificate Does a Client Actually Need?

For any client targeting Gmail, the answer is one of the two, not neither. Gmail's help documentation states plainly that BIMI requires third-party certification of the domain and logo, in the form of a Verified Mark Certificate or a Common Mark Certificate, and that non-Gmail web apps don't support the feature at all without one.

The two certificate types serve different clients at different stages of brand maturity:

Verified Mark Certificate (VMC)Common Mark Certificate (CMC)
RequiresRegistered trademark12+ months of continuous logo use
Gmail checkmarkYesNo
Typical lead timeWeeks, once trademark existsFaster, no trademark needed
Best fitEstablished brands with IP already registeredNewer brands or those without a filed trademark

Google expanded BIMI access specifically to address the trademark barrier, announcing on September 24, 2024 that Gmail would begin accepting CMCs, a change described in the company's own Workspace update as helping more senders protect their brand through third-party verified logos even without a registered mark. That single change opened BIMI to a large population of SMB clients who would otherwise have been priced or process-blocked out of it by trademark registration alone.

Neither certificate is optional window dressing. Google's guidance recommends the VMC path whenever possible, precisely because it ties the logo to a verified legal claim rather than a self-declared one, which is the whole point of the anti-spoofing design behind BIMI in the first place.

The Entrust Disruption Nobody Budgeted For

Any MSP that helped a client buy a VMC before mid-2025 needs to check who issued it. Entrust's own transition notice confirms that as of May 12, 2025, the company stopped issuing new Verified Mark Certificates and S/MIME certificates, following the sale of its public certificate business, with existing customers pointed toward migrating to a different issuer. Certificates issued before that cutoff continue to work, but nothing new can come from that source, and the underlying trust chain has already caused rendering failures at Apple for some Entrust-rooted certificates issued after prior cutoff dates.

For a book of BIMI clients, this is exactly the kind of infrastructure churn that quietly breaks a deployment months after it was declared done. A certificate that validated cleanly at setup can stop validating at a provider without any change on the client's end, purely because the issuing CA exited the market or a root store update landed. This is the argument for treating BIMI as a monitored configuration rather than a one-time project, the same way SPF and DKIM records need periodic review rather than a single deployment and forget.

What a Realistic Rollout Actually Looks Like

Stitching this together for a client, the sequence generally runs in this order:

  • Confirm DMARC is fully at enforcement (p=quarantine or p=reject, pct=100) across the organizational domain and any subdomains that send mail.
  • Build the SVG logo to the Tiny PS profile and host it on HTTPS with a clean, non-redirecting URL.
  • Decide between VMC and CMC based on trademark status, and purchase from a currently active issuer rather than assuming last year's vendor list is still accurate.
  • Publish the BIMI DNS TXT record referencing the logo and certificate, per the current IETF draft specification governing the record format.
  • Verify actual rendering in a live Gmail inbox, not just DNS record presence, since the record can look perfectly valid and still fail the fetch stage.

None of these steps are difficult individually. The difficulty is that a single missed detail anywhere in that chain produces the identical outcome as skipping the whole project: no logo, no error, no explanation.

What This Means for How MSPs Scope the Work

BIMI is not a checkbox that gets added to a security package for free. It carries a real certificate cost, a real DNS and hosting maintenance burden, and an ongoing monitoring need given how often the underlying certificate landscape shifts. Framing it as a scoped, monitored offering on the pricing page rather than a bundled afterthought keeps expectations honest with clients who are picturing an instant logo and don't yet understand the DMARC enforcement work sitting underneath it.

The upside for MSPs willing to do this properly is that BIMI forces a client's authentication posture to a state most never reach on their own: full DMARC enforcement, verified SPF and DKIM alignment, and a documented, monitored DNS footprint. The logo is the visible payoff, but the enforcement work underneath it is the actual security improvement, and it is worth selling that way rather than promising a checkmark by a specific date.

For MSPs that haven't yet standardized how they track DMARC posture across a client base, that visibility is the starting point before any BIMI conversation makes sense. Firms that want a single view of where every client domain sits on that enforcement curve can sign up and run the scan before quoting the next phase of work.

Further Reading

← Back to all posts
BIMI Rollout for MSPs: The Real Requirements — ActiScan Blog