BIMI setup: show your brand logo in the inbox

You see other companies' logos sitting next to their mail in Gmail and you want yours there too. Then you read the BIMI spec, hit "SVG Tiny PS" and "Verified Mark Certificate", and the whole thing feels deliberately obscure. It is not magic, but it is fussy, and the steps have to happen in a specific order.

BIMI (Brand Indicators for Message Identification) is the standard that puts your logo in the inbox. When it works, a supporting mail client shows your brand mark next to your messages instead of a generic letter or a colored initial. It looks like a small thing. It is a real trust signal, and it is one of the few inbox affordances you can actually control as a sender.

The catch is that BIMI is not a setting you toggle. It is the visible reward at the end of an authentication chain, and every link has to be in place before anything renders. This guide walks the whole chain the hard way, with the real files and DNS records, then shows where Tinbox publishes the record for you so you can skip the plumbing.

The certificate gotcha: HTTPS is not BIMI trust

There are two certificates in this setup, and confusing them is a very common failure mode:

1. HTTPS/TLS certificate. Cloudflare issues this for the deployment hostname so browsers and mailbox providers can fetch public files over HTTPS. It encrypts the connection; it does not authenticate your logo.
2. BIMI VMC/CMC certificate. A mark-verifying authority issues this separate public PEM after validating the logo and sending domain. Gmail uses it to decide whether the logo is trustworthy.

Tinbox can host the second certificate and generate the exact a= URL, but it must not fabricate one. A self-signed PEM, a Cloudflare edge certificate, or a certificate served from the master tinbox.dev domain will not turn into a Gmail-trusted VMC/CMC. The public BIMI files should be served from the tenant's sending domain; Google calls out same-domain hosting as part of troubleshooting BIMI fetches. See Google's BIMI setup requirements and Cloudflare's edge certificate documentation.

This is why the Tinbox flow has two separate actions: upload the brand SVG, then upload the public VMC/CMC PEM received from the issuer. Tinbox hosts both and tinbox doctor --fix-bimi can publish the DNS record, but certificate issuance and mark/domain validation remain with the issuer.

What do you need before BIMI will work at all?

BIMI requires four things, and the order matters: DMARC at an enforcement policy, a compliant SVG logo, optionally a Verified Mark Certificate, and the _bimi DNS record tying them together. If DMARC is not at enforcement, nothing else you do matters, because every BIMI implementation checks DMARC first and bails out at p=none.

Here is the dependency chain, which is worth internalizing before you touch anything:

1. SPF and DKIM must pass and align. DMARC is built on top of these.
2. DMARC must be published at p=quarantine or p=reject. This is the gate.
3. A BIMI-compliant SVG must be hosted over HTTPS. Strict format, not any SVG.
4. A VMC is needed for Gmail and Apple Mail. Yahoo and AOL render without one.
5. The _bimi TXT record points at the SVG and (if you have it) the certificate.

Steps 1-3 and 5 are free. Step 4 is where the money and the weeks of waiting go. You can ship a working BIMI logo to Yahoo today for the price of an afternoon; getting it into Gmail involves a trademark and a certificate authority.

If your authentication is not in place yet, stop here and fix it first. The SPF, DKIM, and DMARC setup guide covers the records BIMI sits on top of, and how to verify your authentication is actually passing shows how to confirm they align before you go further. If the acronyms themselves are the wall (BIMI, VMC, DMARC, DKIM), the email authentication acronyms explained in one sentence each is a quick decoder before you wade in.

How do I get DMARC to an enforcement policy for BIMI?

Set your DMARC policy to p=quarantine or p=reject with pct=100. A policy of p=none is monitoring only, and every BIMI evaluator treats it as "not enforced", so your logo will never appear no matter how perfect your SVG is.

Check your current policy first. Look up the TXT record at the _dmarc subdomain:

dig +short TXT _dmarc.yourdomain.com

A typical monitoring-only record looks like this, and it is the most common reason BIMI silently fails:

"v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"

p=none means receivers report on failures but take no action. BIMI needs teeth. Move to quarantine (or reject, if you are confident every legitimate stream is aligned):

"v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com"

Do not jump straight to p=reject on a domain that sends real mail unless you have already read your aggregate reports and confirmed every legitimate source aligns. Going to enforcement before you have verified alignment will bounce or quarantine your own newsletters and transactional mail. Spend a couple of weeks at p=none reading reports first; reading DMARC aggregate reports without a paid tool walks through the XML so you know what is actually failing before you turn on enforcement, and the three DMARC policies explained lays out the safe none-to-quarantine-to-reject climb that BIMI is waiting at the top of.

One subtlety some validators enforce: a few BIMI checkers historically wanted pct=100 to be present and not reduced, and some discourage the sp (subdomain policy) being weaker than the main policy. Keep your enforcement uniform.

What are the BIMI SVG logo requirements?

BIMI accepts exactly one image format: SVG Tiny Portable/Secure (SVG Tiny PS), a deliberately restricted SVG profile. A logo your designer exports from Illustrator or Figma will almost never validate as-is. The profile bans everything that could carry executable content or external dependencies.

The hard requirements:

• Square aspect ratio. The viewBox width and height must be equal (for example 0 0 512 512).
• baseProfile="tiny-ps" declared on the root <svg> element.
• A <title> element as a direct child of the root, describing the mark.
• A solid, non-transparent background. Transparency is rejected; fill the canvas.
• No <script>, no animation (<animate>, SMIL), no external references (xlink:href to remote resources, embedded fonts, <image> raster data).
• version="1.2" on the root element.
• Small file size (keep it well under 32 KB).

A minimal compliant file looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<svg version="1.2" baseProfile="tiny-ps"
     xmlns="http://www.w3.org/2000/svg"
     viewBox="0 0 512 512">
  <title>Acme Corp</title>
  <rect width="512" height="512" fill="#0b3d91"/>
  <path d="M256 96 L416 416 L96 416 Z" fill="#ffffff"/>
</svg>

Note what is missing: no width/height attributes on the root (use viewBox only), no xmlns:xlink, no <defs> with filters, no gradients that reference external resources. If you must use a gradient, define it inline and keep it simple.

Validate the SVG before you publish it

Do not trust that it works because it opens in a browser. Browsers render almost anything; BIMI validators are strict. The reference checker is the one Cloudflare and the BIMI Group host. You can also lint locally for the obvious disqualifiers:

# Quick sanity checks for the common BIMI SVG failures
grep -l "baseProfile=\"tiny-ps\"" logo.svg || echo "FAIL: missing baseProfile=tiny-ps"
grep -q "<title>" logo.svg || echo "FAIL: missing <title> element"
grep -qE "<script|xlink:href|<image|<animate" logo.svg && echo "FAIL: forbidden element present"
grep -qE 'fill="none"|fill-opacity="0"' logo.svg && echo "WARN: possible transparent background"

Real failure output from a freshly exported logo usually reads like a wall of disqualifiers: missing baseProfile, an <image> tag wrapping an embedded PNG, and a transparent background. Strip them one at a time. The most reliable path is to rebuild the mark as clean vector paths rather than trying to clean up an export.

Host the validated file at a stable HTTPS URL with the right content type:

# The SVG must be served as image/svg+xml over HTTPS
curl -sI https://assets.yourdomain.com/bimi/logo.svg | grep -i content-type
# content-type: image/svg+xml

Do I need a Verified Mark Certificate, and how do I get one?

You need a Verified Mark Certificate (VMC) if you want your logo in Gmail or Apple Mail. Yahoo and AOL will display a BIMI logo from the DNS record and SVG alone. Gmail and Apple require cryptographic proof that you own the mark, and that proof is the VMC.

A VMC is an X.509 certificate that binds your logo to a verified trademark. Only a handful of CAs are authorized to issue them, currently DigiCert and Entrust. The process:

1. Register your logo as a trademark with a recognized trademark office (USPTO, EUIPO, and others), or hold an existing registration. The CA validates against the registration, so the SVG you publish must match the registered mark closely.
2. Apply with the CA, submitting your trademark registration number, the SVG, and organizational identity documents.
3. Pass verification. Expect identity vetting similar to an EV certificate, often a few weeks.
4. Receive a PEM bundle (the certificate plus chain), which you host over HTTPS alongside the SVG.

Budget realistically: a VMC runs roughly 1,000-1,500 USD per year, and the trademark itself (if you do not already have one) is months and several hundred dollars more. For some logos a Common Mark Certificate (CMC) is now available, which relaxes the trademark requirement but currently has narrower inbox support.

This is the honest pivot point of BIMI: the technical work is an afternoon, but Gmail support is a real procurement project. If your goal is "logo in Yahoo" you are nearly done. If your goal is "logo in Gmail" you are signing up for a certificate authority relationship.

Host the certificate the same way you hosted the SVG:

curl -sI https://assets.yourdomain.com/bimi/vmc.pem | grep -i content-type
# content-type: application/pem-certificate-chain

How do I publish the _bimi DNS record?

Add a TXT record at default._bimi.yourdomain.com containing the BIMI version, the SVG location, and (if you have one) the VMC location. The selector default is what receivers look up unless a message specifies a different BIMI-Selector header.

Without a VMC (Yahoo path):

default._bimi.yourdomain.com.  IN  TXT  "v=BIMI1; l=https://assets.yourdomain.com/bimi/logo.svg;"

With a VMC (Gmail and Apple path):

default._bimi.yourdomain.com.  IN  TXT  "v=BIMI1; l=https://assets.yourdomain.com/bimi/logo.svg; a=https://assets.yourdomain.com/bimi/vmc.pem;"

The tags:

• v=BIMI1 is the version and must come first.
• l= is the HTTPS URL of the SVG logo.
• a= is the HTTPS URL of the VMC PEM bundle. Leave it empty (a=) or omit it entirely if you have no certificate; do not point it at a placeholder.

Verify the record resolves before testing mail:

dig +short TXT default._bimi.yourdomain.com
# "v=BIMI1; l=https://assets.yourdomain.com/bimi/logo.svg; a=https://assets.yourdomain.com/bimi/vmc.pem;"

Then run it through a BIMI inspector (the BIMI Group and several CAs host free ones) to confirm the SVG and certificate fetch and validate end to end. Finally, send a test message to a Yahoo address and a Gmail address. Yahoo should show the mark fairly quickly. Gmail evaluates your sending and authentication history, so the logo may take time to appear even when everything validates, and it requires the VMC.

Why isn't my BIMI logo showing up?

Work the checklist in dependency order, because each step gates the next. The failure is almost always upstream of where you are looking.

• DMARC is still p=none. This is the number one cause. Re-check dig +short TXT _dmarc.yourdomain.com and confirm p=quarantine or p=reject.
• DMARC is at enforcement but your mail is not aligning. The policy must be enforced and your messages must actually pass DMARC. Check headers on a real sent message.
• Gmail with no VMC. Gmail will not render a logo without a Verified Mark Certificate. Yahoo will; do not conclude BIMI is broken from a Gmail-only test.
• The SVG fails SVG Tiny PS validation. Run it through the reference validator, not just a browser. Transparent backgrounds and embedded raster images are the usual culprits.
• The _bimi record is malformed or on the wrong selector. Confirm it is at default._bimi and the l= URL returns image/svg+xml over HTTPS.
• Propagation and re-evaluation lag. Mailbox providers re-evaluate periodically. A correct setup can take days to surface, especially in Gmail.

BIMI rewards a clean, consistent sending reputation, so a domain that has just moved to enforcement may need a warm-up period of well-authenticated sending before logos appear. If your domain is new or recently changed, warming up the sending domain helps establish the history BIMI wants to see.

Or skip the plumbing: let Tinbox publish the record

Everything above is doable by hand, and now you understand each moving part, which is the point. But the BIMI chain is exactly the kind of multi-step DNS-plus-asset workflow that is tedious to wire and easy to get subtly wrong: a non-square viewBox, a stray transparent background, a p=none you forgot to bump.

Because Tinbox runs your sending domain on your own Cloudflare account, it already manages your SPF, DKIM, and DMARC records, so the authentication foundation BIMI depends on is in place by the time you get here. When you provide a compliant SVG (and a VMC if you are targeting Gmail), Tinbox publishes the default._bimi record alongside the DMARC enforcement it already configured, on the same domain, with the SVG hosted on infrastructure you control. No separate asset host, no DNS console round-trips, no guessing whether your DMARC policy is strict enough.

To be clear about scope: a VMC is still a certificate you procure from DigiCert or Entrust against your own trademark. Tinbox cannot shortcut a certificate authority. What it removes is the assembly: the record, the hosting, and the dependency on a DMARC policy that is actually enforced.

If you have not stood up the sending domain yet, the deliverability pillar guide is the place to start; BIMI is the last mile of a stack that begins with clean authentication.

Deploy this yourself: npx tinbox init <domain>, point your logo at the BIMI config, and the record ships with your domain. The docs cover the SVG constraints and the VMC fields end to end.