The little brand logos next to emails in Gmail and Apple Mail look like a cosmetic feature. They're not. BIMI — Brand Indicators for Message Identification — is a deliberately constructed incentive scheme: the logo is the carrot, and strict DMARC enforcement is the price of admission. Understanding how it works tells you a lot about how email authentication actually gets adopted.

Email authentication has a chronic adoption problem. SPF, DKIM, and DMARC have existed for well over a decade, and the cryptography works — but a DMARC policy of p=none (monitor, don't enforce) is where many domains stall, because moving to enforcement risks breaking legitimate mail flows. Nobody gets promoted for tightening a DMARC policy. That's the gap BIMI was designed to close: it offers something marketing departments measurably want — a verified logo in the inbox — and hands it over only when the security team finishes the DMARC work.

How BIMI Works: One DNS Record, Three Prerequisites

Mechanically, BIMI is simple. You publish a DNS TXT record at a well-known location under your domain:

default._bimi.example.com  TXT
"v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem"

The l= tag points to your logo file; the optional a= tag points to an evidence certificate that proves you have the right to use that logo.

When a participating mailbox provider receives a message from your domain, it checks three things before showing the logo:

1. The message passes DMARC — meaning it passed SPF or DKIM with alignment to your domain.
2. Your DMARC policy is at enforcement. p=quarantine or p=reject — not p=none. Gmail additionally requires that the policy covers the full mail stream (no percentage carve-outs that exempt most mail).
3. The logo meets the format and evidence requirements — and for the strongest treatment, a certificate vouches for it.

Fail any check and the logo simply doesn't render. That's the enforcement mechanism in its entirety: no logo for domains that haven't done their authentication homework.

SVG Tiny PS: A Logo Format Designed Not to Be an Attack Surface

The logo file itself can't be an arbitrary image. BIMI requires SVG Tiny Portable/Secure (SVG Tiny PS) — a deliberately restricted profile of SVG Tiny 1.2. Full SVG is a rich format that can embed scripts, external references, and animations; rendering attacker-controlled SVG inside a mail client would be a gift to phishers. The PS profile strips that surface: no scripting, no external resource loading, no interactivity. The file must also declare a square aspect ratio so providers can render it consistently in circular or square avatar slots.

This is a small but instructive piece of security engineering: when you're about to let millions of domains inject content into one of the most-attacked UI surfaces on the internet — the inbox — you constrain the format until the dangerous capabilities are structurally absent, not just policy-forbidden. The same philosophy shows up in Content Security Policy and other allowlist-by-construction designs.

VMCs and CMCs: Who Vouches for the Logo?

DMARC proves a message came from your domain. It says nothing about whether the logo you publish actually belongs to your brand. Without an evidence layer, a phisher who registers examp1e-support.com could pass DMARC for their own throwaway domain and publish your logo. BIMI's answer is the Verified Mark Certificate (VMC).

A VMC is an X.509 certificate issued by an authorized certification authority (Entrust and DigiCert were the initial issuers) that binds your logo to a registered trademark. The CA verifies the trademark registration and the organization's identity before issuing — a process closer to extended-validation TLS certificates than to free domain-validated ones, with pricing to match (typically four figures per year).

Because trademark registration is a high bar for smaller senders, the ecosystem added Common Mark Certificates (CMCs) in 2024. A CMC doesn't require a registered trademark; instead, the CA verifies that the logo has been in established prior use. The trade-off is visible in Gmail's UI: VMC-backed senders get the logo plus a blue verified checkmark, while CMC-backed senders get the logo without the checkmark.

Provider support is real but uneven: Gmail, Yahoo, and Apple Mail (since iOS 16 / macOS Ventura) render BIMI logos, with varying certificate requirements. Some major providers still don't participate, so your logo's visibility depends on where your recipients read mail.

What BIMI Does and Doesn't Protect Against

It's worth being precise about the security value, because BIMI is sometimes oversold as an anti-phishing technology.

What it genuinely does: it makes exact-domain spoofing visibly fail. An attacker forging mail from your actual domain will fail DMARC, and no logo appears — and the absence is conspicuous once recipients are habituated to seeing it. More importantly, the carrot effect is real at the ecosystem level: BIMI has pushed many large senders from p=none to enforcement, which raises the cost of domain spoofing for everyone, logo or not.

What it doesn't do: stop lookalike-domain phishing. A phisher who sends from their own yourbank-alerts.com domain, with their own valid SPF/DKIM/DMARC, simply has no logo — or registers their own innocuous mark. Users who've been trained to look for a logo's presence may not notice its absence, and homograph and lookalike domains remain entirely out of BIMI's scope. BIMI authenticates the domain's mark; it cannot authenticate the user's mental model of which domain they're talking to.

The honest framing: BIMI is a DMARC adoption incentive with a useful side effect, not a phishing solution. The security work it rewards — enforced DMARC — is where the actual protection lives.

Setting It Up (and Where the Effort Really Goes)

For a domain that already has clean email authentication, BIMI itself is an afternoon of work: produce the SVG Tiny PS logo, obtain the certificate if you want one, publish the TXT record. The real effort is everything upstream — full SPF and DKIM coverage of every legitimate sending source, DMARC reports analyzed, policy ratcheted to p=quarantine or p=reject without breaking transactional mail. If you're hardening the transport layer too, MTA-STS and TLS-RPT are natural companions, and ARC handles the forwarding cases that DMARC alignment breaks.

We went through this exact pipeline for Haven's own domain — SPF, DKIM, DMARC at enforcement, DNSSEC, then BIMI on top — not for the logo (though it's nice), but because a private email service that can't prove its own mail is authentic has no business asking users to trust it. If you run a domain that sends mail, the BIMI checklist is a reasonable forcing function for hygiene you should have anyway. The logo is the receipt, not the product.

Originally published at havenmessenger.com