Publishing a BIMI record, and the certificate most senders do not need yet

The record went in, the syntax checker went green, and 48 hours later the messages still arrive with a grey circle and a capital letter in it. Nothing is broken. BIMI is working exactly as specified, and what it specifies is that almost nothing happens until several other things are true.

Most of the writing about BIMI is about why you want the logo. This is about what the standard actually requires, in the order a receiver checks it, and about the one decision with real money attached.

What the record contains

BIMI is a TXT record on a selector, the same shape as DKIM. The default selector is default, and unless a sender stamps a BIMI-Selector header on its messages, that is the only one anybody looks up.

default._bimi.yourapp.com.  TXT  "v=BIMI1; l=https://assets.yourapp.com/logo.svg; a="

Two attributes carry everything. l= is the HTTPS URL of the logo. a= is the HTTPS URL of a PEM file holding a certificate that vouches for it. Either may be empty, and which one you leave empty decides what the record is worth:

dig +short TXT default._bimi.yourapp.com

A record with l= filled and a= empty is a self-asserted logo. You are stating that the logo is yours, and nothing beyond the record supports the claim. A record with a= populated points at a certificate an authority issued after checking. Google’s own documentation shows the certified form with l= blank, because the PEM file contains the logo as well as the certificate.

The prerequisite that stops most domains

Before a receiver fetches anything, it checks DMARC. BIMI applies only to messages that passed DMARC, and only for domains whose policy is at enforcement. The requirement is specific:

That last row catches people who did everything else right. A policy on mail.yourapp.com is not a policy on yourapp.com, and BIMI reads the organisational domain.

If you are at p=none today, this is the whole project, and it is a good project regardless of whether a logo ever appears. Getting to enforcement means inventorying every system that sends as your domain and fixing the ones that fail alignment — which is the work described in reading DMARC aggregate reports. Nothing about BIMI shortens it. BIMI is what you may choose to do afterwards.

The SVG you have is not the SVG it wants

BIMI does not accept general SVG. It requires SVG Tiny Portable/Secure, a deliberately reduced profile designed so that a mailbox provider can render a stranger’s image without executing anything.

<svg xmlns="http://www.w3.org/2000/svg"
     version="1.2" baseProfile="tiny-ps"
     width="96" height="96" viewBox="0 0 96 96">
  <title>Your Company</title>
  <desc>Company logo</desc>
  …
</svg>

What gets a file rejected:

Gmail also recommends a square logo on a solid background, a file of 32 KB or less, and a <desc> element for accessibility. Transparent backgrounds may not render as you expect. The host serving the file must use HTTPS with TLS 1.2 or later, and must resolve publicly — a file behind an allowlist is a file the receiver cannot fetch.

Exporting from a design tool will not produce this. Converting an existing logo is a manual pass over the XML, and the design department’s file usually needs simplifying before it conforms.

VMC and CMC, and what each one buys

This is the decision with a cost attached.

Both are annual certificates, priced accordingly, and both are bought from a certificate authority rather than configured. The VMC’s real cost is upstream of the certificate: you need the logo registered as a trademark first, and Google’s own guidance puts that process at six to twelve months, before anybody’s legal fees.

The CMC exists precisely because that requirement excluded almost everyone. It is the route for an organisation whose logo is real and in use but never registered — which describes most software companies under a certain size.

What each mailbox provider actually does

The standard is one thing and deployment is another, and this is where a self-asserted record either works or does nothing at all.

Yahoo and AOL accept a self-asserted record: publish the SVG, leave a= empty, and a qualifying message can display the logo. Gmail does not. Gmail requires the PEM file, so a self-asserted record produces exactly the grey circle you started with, and the check mark beside the sender name appears only for a VMC — not for a CMC, and not for a self-asserted logo.

So “does BIMI work without a certificate” has two correct answers depending on where your recipients read their mail, and for most transactional senders the answer that matters is the Gmail one.

Why most transactional senders should wait

Work backwards from what a logo does. It is a recognition signal for a brand a recipient already knows, in an inbox where several messages from you sit together. That describes a retailer’s mail. It does not describe a password reset, which arrives once, is opened within ninety seconds because the person just asked for it, and is deleted.

There is also a sequencing argument. Everything BIMI requires before the logo — SPF, DKIM, DMARC at enforcement, alignment on every sending system — is doing the entire job of getting mail delivered. The logo does not add to delivery. Receivers do not treat a BIMI record as a positive reputation signal, and nothing in the standard asks them to.

So the honest order is: reach p=reject because it protects the domain and it is what the Gmail and Yahoo sender requirements already expect. Then, if you send enough recognisable mail to enough consumers that a logo would be recognised, look at a certificate. If you send password resets and receipts, publish nothing yet and spend the certificate budget somewhere it changes an outcome.

The exception is worth naming: if your brand is impersonated in phishing aimed at your own customers, a verified logo is a genuine countermeasure, because its absence becomes a signal too. That is a real reason, and it has nothing to do with open rates.

Where Pharos fits

Pharos verifies four DNS records on every sending domain before the first message leaves — SPF, DKIM, DMARC and an aligned return path — and re-checks them daily, which is the groundwork BIMI sits on top of and the part that actually decides whether mail arrives. Pharos does not issue certificates and does not host logo files; BIMI is a record you publish on your own domain, at your own registrar, whoever sends your mail. If you reach DMARC enforcement and decide the logo is worth the certificate, nothing about sending through Pharos stands in the way.