BIMI is the mechanism behind the brand logo that appears beside a message in some mail clients. The record is trivial. The prerequisites are not, and the certificate question has a different answer depending on who your recipients are.
One framing point first, because it changes how much weight to put on any BIMI advice you read. BIMI is not a published standard. It is an Internet-Draft, currently draft-brand-indicators-for-message-identification, which is why mailbox providers differ from one another in ways a finished RFC would have settled.
What does BIMI actually publish?
A pointer, not a picture.
You publish one TXT record at a BIMI selector under your domain. It carries a version tag, an l= URL for the logo, and optionally an a= URL for a certificate. That is the whole protocol surface a sender touches. The mailbox provider fetches the logo, evaluates the certificate if there is one, checks your authentication, and then decides for itself whether to render anything.
That last clause carries most of the disappointment in BIMI rollouts. A perfectly formed record entitles you to nothing. Bird's BIMI guide has the record shape and the logo profile, and the BIMI record generator validates one in the browser before you publish it.
Why does my correct record show no logo?
Almost always because DMARC is not at enforcement.
BIMI sits on top of DMARC, and it requires a policy that actually does something. The BIMI Group's implementation guide states the bar without hedging:
DMARC policy MUST be at enforcement on the organizational domain and subdomains: Quarantine (p=quarantine; sp=quarantine) Reject policy (p=reject; sp=reject) Note: “None” policies or ‘pct’ less than 100 percent are not accepted
Two details in that quotation cause more failures than the logo format does. The policy is read at the organizational domain, so enforcing on the subdomain you send from does not help while the apex is still monitoring. And an apex record that weakens subdomains with sp=none disqualifies you even though the p= tag looks right.
Since a monitoring policy is where most domains sit, and moving to enforcement means first accounting for every legitimate sender using your domain, this is the part of a BIMI project that takes weeks. What is a DMARC policy covers the ladder.
So do I need a VMC?
The standard says no. Your recipients' mailbox providers may say yes.
In the BIMI Group's own implementation guide the certificate is step three, and the heading is explicit about its status:
Step 3 (Highly recommended, but Optional) Acquire a Verified Mark Certificate (VMC) or a Common Mark Certificate (CMC) for Your Logo
with a warning attached to the alternative:
Note: Self-Asserted BIMI records have limited support across the various Mailbox Providers
So "optional" means optional in the protocol and frequently mandatory in practice. The decision is a question about your audience rather than about BIMI: if your list is largely at providers that require a certificate, you need one, and if it is not, you can publish a record with only l= and see what renders. Bird's guide has the current per-provider position.
What is the difference between a VMC and a CMC?
What the certificate is allowed to attest.
The draft defines both as kinds of Mark Certificate, issued by a Mark Verifying Authority:
A Verified Mark Certificate is an MC issued by an MVA in support of BIMI Indicators that are representations of either Registered Trademarks or Government Marks.
and, in the section beside it:
A Common Mark Certificate is an MC issued by an MVA in support of BIMI Indicators that are representations either of Prior Use Marks or Modifications of Registered Trademarks.
The practical reading is that a VMC needs a registered trademark and a CMC exists for the cases where you do not have one, or where the logo you want to display is a variant of the mark you registered. If your logo is not a registered trademark anywhere, a VMC is not something you can buy, and the trademark registration becomes the long pole in the project rather than the certificate.
Is BIMI worth doing?
It depends entirely on whether you already run DMARC at enforcement.
If you do, BIMI is a small amount of work: produce a logo in the constrained SVG profile, publish one record, and add a certificate if your audience needs one.
If you do not, BIMI is a reason to do a DMARC enforcement project, and the enforcement project is worth far more than the logo. Getting to p=reject means you have inventoried every sender using your domain and stopped the unauthenticated ones, which is a real anti-spoofing outcome. The logo is the visible reward for work whose actual value is elsewhere.
Treat a claim that BIMI improves deliverability with suspicion. Nothing in the draft asks a receiver to filter differently, and the providers that show logos are the same ones already judging you on authentication and reputation.