BIMI Record Explained: Setup, SVG, and VMC Costs

BIMI (Brand Indicators for Message Identification) is the standard that lets Gmail, Yahoo, and Apple Mail display your brand logo next to authenticated messages in the inbox. It is not a deliverability boost on its own — it is a trust signal that only renders when your authentication is already clean.

This guide walks through the BIMI record format, the SVG profile your logo must conform to, the Verified Mark Certificate (VMC) the major providers require, and an honest take on whether it is worth the effort for smaller senders.

What BIMI actually does

BIMI is a DNS-published pointer that says: "here is the logo for mail authenticated as coming from this domain, and here is a certificate proving the brand owns it." Mailbox providers that support BIMI fetch the logo, verify the certificate, and render the logo in the avatar slot of the inbox list and the message header.

Three things have to be true before any of that happens:

Your domain passes SPF and DKIM, with DKIM aligned to the From header.
Your DMARC policy is at p=quarantine or p=reject (with pct=100).
A default._bimi TXT record exists at your domain.

If any one of those is missing, the logo does not show. BIMI does not bypass spam filters; it sits on top of working authentication.

The BIMI DNS record format

The BIMI record is a single TXT record published at the default._bimi selector under your sending domain. The format is similar to DMARC: semicolon-separated tag-value pairs.

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

The tags:

v=BIMI1 — the version. Always this value.
l= — HTTPS URL to your SVG logo. Must be reachable, served over TLS, with a correct Content-Type: image/svg+xml.
a= — HTTPS URL to your Verified Mark Certificate (a PEM file). Required by Gmail, Apple Mail, and Yahoo. Optional only on a handful of smaller providers.

You can verify the record from the command line:

dig +short TXT default._bimi.example.com

If you send from multiple subdomains (mail.example.com, notify.example.com), each one needs its own default._bimi record. BIMI does not inherit down the tree the way some senders expect.

Selectors beyond `default`

The spec allows custom selectors (e.g. marketing._bimi), referenced from a BIMI-Selector: header on the message itself. In practice, almost no senders use this. Stick with default._bimi unless you have a concrete reason.

SVG-Tiny PS: the logo constraints

The logo file referenced by l= cannot be any SVG. BIMI requires a tightly restricted profile called SVG-Tiny 1.2 Portable/Secure (SVG-Tiny PS). The constraints exist so that mailbox providers can render the logo without executing scripts or fetching remote assets.

The rules that catch most senders out:

Square aspect ratio. Width and height in the root <svg> must be equal. Most providers crop to a circle, so put the brand mark in the centre with safe-area padding.
Background must be solid or transparent. No gradient backgrounds. A single fill colour or fill="none" is fine.
No scripts. No <script> tags. No onload, onclick, or any event attributes.
No animation. No <animate>, <animateTransform>, no SMIL, no CSS transitions.
No external references. No <image> linking to a PNG, no external fonts, no xlink:href to anything off-document.
Required metadata. A <title> element with the brand name, and a baseProfile="tiny-ps" attribute on the root <svg>.

A minimal conforming file looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg"
     version="1.2"
     baseProfile="tiny-ps"
     viewBox="0 0 64 64"
     width="64" height="64">
  <title>Example Brand</title>
  <rect width="64" height="64" fill="#0a0a0a"/>
  <path d="M16 16 L48 16 L48 48 L16 48 Z" fill="#ffffff"/>
</svg>

Validate before you publish. The BIMI Group hosts a public conformance checker; running your SVG through it surfaces the dozen subtle rules this article does not cover.

The Verified Mark Certificate

The VMC is the part that costs money. It is an X.509 certificate, issued by a small set of certificate authorities (currently DigiCert and Entrust), that binds your SVG logo to your domain. The issuing CA verifies that you actually own the trademark on the mark — usually via a registered trademark in a recognised jurisdiction (USPTO, EUIPO, UK IPO, JPO, and a few others).

What that process means in practice:

You must have a registered trademark for the exact logo you want to use. A pending application does not qualify.
The CA performs identity verification on the legal entity, similar to an EV TLS cert.
Issuance takes one to several weeks.
Pricing is not published as a flat number, but the annual cost sits in the four-figure range for most issuers. Renewal is yearly.

Google and Apple have also begun accepting Common Mark Certificates (CMCs) for unregistered marks under stricter conditions, but support is uneven; check the current state at each provider before banking on a CMC.

Which inboxes actually display the logo

Support is real but not universal:

Gmail — displays in web and the official mobile apps. Requires a valid VMC. The most visible payoff for most senders.
Yahoo Mail and AOL — displays for senders with VMC. Yahoo was the original BIMI champion.
Apple Mail (iOS 16 / macOS Ventura and later) — displays in Mail, contingent on a VMC.
Fastmail — supports BIMI, will render without a VMC for some senders.

Outlook.com and Microsoft 365 do not display BIMI logos. That alone is a strategic consideration if most of your audience is on Microsoft mail.

Prerequisites you cannot skip

BIMI assumes you have already done the boring authentication work. Specifically:

SPF passes for the sending IPs.
DKIM signs every message with a key aligned to the From domain.
DMARC record exists with p=quarantine or p=reject and pct=100. A p=none policy disqualifies you outright, no matter how clean your sending is.

If your DMARC is still at p=none because you are mid-rollout, finish that project first. Trying to add BIMI on top of weak authentication is the equivalent of bolting a hood ornament onto a car you have not yet registered. Our guides on SPF records and DMARC policy choices cover those steps in detail.

Is BIMI worth it for your sender?

The honest answer depends on three variables: brand value, audience inbox mix, and volume.

BIMI is probably worth it if:

You send to consumers, and Gmail/Yahoo/Apple together represent the majority of your recipients.
Your brand has a registered trademark already (the VMC cost is then mostly the annual cert fee, not the years of legal work).
You send enough high-stakes mail — receipts, security alerts, account notices — that visible trust signals meaningfully reduce support load and phishing.
You are a recognisable consumer brand where the logo in the inbox is itself a defence against lookalike domains.

BIMI is probably not worth it if:

You are a small B2B sender where most recipients open mail on Microsoft 365 — Outlook does not render the logo at all.
You do not have a registered trademark and would have to spend a year and several thousand dollars getting one purely to qualify.
Your authentication is not yet at p=quarantine or stronger. Fix that first; the deliverability gain from a strict DMARC policy is real and free.
You send under a few hundred thousand messages a year. The cert fee dominates the per-message economics.

For most early-stage senders, the right sequencing is: get SPF, DKIM, and DMARC clean, leave DMARC at p=quarantine for at least a quarter, then revisit BIMI once the brand and trademark are in place. The bimi record itself takes ten minutes to publish — the underlying work and the VMC are where the real investment lives.