BIMI explained: how to publish your logo record, and how to verify it before you ship

BIMI — Brand Indicators for Message Identification — is the mechanism that puts your logo next to your messages in Gmail, Yahoo Mail, Apple Mail and a growing list of clients. It is often sold as a branding feature. It is better understood as the last step of an authentication chain: a mailbox provider will only show a logo for mail it can prove came from you, and BIMI is how you tell it which logo.

This article walks the chain end to end: what the record looks like, what the logo file must be, why DMARC enforcement is a hard prerequisite, what a Verified Mark Certificate adds, and — the part most guides skip — how to verify that a real message from your real sending path passes every check, before your customers are the ones testing it.

What BIMI is, precisely

BIMI is a DNS record plus a logo file. When a receiver that supports BIMI accepts a message, it:

1. Evaluates DMARC for the domain in the From: header.
2. If DMARC passes and the domain's policy is enforcing (quarantine or reject), it looks up a TXT record at default._bimi.<from-domain>.
3. It fetches the SVG the record points to, validates it against a strict profile, and — depending on the receiver — validates the certificate the record also points to.
4. If everything holds, it renders the logo beside the message.

Nothing in that list improves inbox placement directly. BIMI is not a deliverability signal in the way SPF or DKIM are. What it does is force you to finish authentication properly, and reward you with something visible when you do.

The DNS record

The record lives at default._bimi. under the domain in your From: header — not your envelope sender, not your DKIM d= domain, the visible one. default is the selector; you can publish others and reference them from a BIMI-Selector header, but almost nobody needs to.

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

Three tags:

An empty l= (v=BIMI1; l=;) is valid and means "no logo" — useful for a subdomain you want to opt out explicitly.

Two details that catch people:

• The URLs must be HTTPS, served with a valid certificate, and publicly reachable. A logo behind a CDN that blocks non-browser user agents will silently fail.
• The record is looked up on the exact From domain first. If mail.example.com has no record, receivers fall back to the organizational domain (example.com). That fallback is a convenience, not a substitute for aligning your From domain with what you actually publish.

The logo: SVG Tiny Portable/Secure

The logo is not "an SVG". It has to conform to SVG Tiny 1.2 Portable/Secure (SVG P/S), a deliberately restricted profile. The restrictions exist because the receiver is going to render a file supplied by a stranger inside a mail client, and SVG is a document format that can embed scripts, external references and animations.

What the profile requires, in practice:

• baseProfile="tiny-ps" and version="1.2" on the root element.
• A <title> element — the brand name is the usual content.
• Square viewBox, solid background (transparency renders unpredictably across clients).
• No <script>, no external references (xlink:href to a URL, @import), no animation, no <image> with raster data, no <text> in most validators' interpretation.
• Kept small: under 32 KB is the common guidance.

A minimal, valid file:

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny-ps"
     viewBox="0 0 512 512">
  <title>Example Co</title>
  <rect width="512" height="512" fill="#0f0f0f"/>
  <path d="M128 352 256 160 384 352z" fill="#c4b5fc"/>
</svg>

Most design tools export SVG 1.1 with <defs>, <style> blocks and xlink namespaces. Expect to hand-clean the export, or run it through a converter that targets Tiny P/S specifically. Validate the result — the BIMI Group publishes a validator, and several vendors do too — but treat those as lint, not proof. The proof is a receiver rendering it.

DMARC enforcement is not optional

This is the part that stops most rollouts, and it is the one that has nothing to do with BIMI itself.

Receivers require your DMARC policy to be p=quarantine or p=reject, at pct=100, on the From domain or its organizational domain. p=none — the monitoring mode nearly everyone starts with — disqualifies you. A policy of quarantine with pct=50 also disqualifies you at most receivers.

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=s; aspf=s"

Moving to enforcement means every legitimate source of mail for the domain must pass DMARC alignment: your application, your marketing platform, your helpdesk, the CRM someone in sales connected two years ago. Each one needs SPF or DKIM — ideally both — with a domain that aligns with the visible From.

The safe path is the boring one: publish p=none with rua= reporting, read the aggregate reports for a few weeks, fix every source that fails, then move to quarantine. Trying to skip to reject for the sake of a logo is how legitimate password-reset mail ends up in spam.

The certificate: VMC and CMC

The record's a= tag points to a certificate that binds the logo to your organization. There are two kinds:

• A Verified Mark Certificate (VMC) requires a registered trademark on the logo. The certificate authority verifies the trademark registration and your ownership of the domain, and embeds the SVG itself in the certificate.
• A Common Mark Certificate (CMC), introduced in 2024, drops the trademark requirement in favor of evidence the logo has been in use for at least a year. Support is narrower than VMC, but growing.

Whether you need one depends on where you want the logo to show:

In short: Gmail and Apple require a certificate. Given Gmail's share of consumer mailboxes, a BIMI record with no a= is mostly a Yahoo feature.

A certificate costs real money per year and takes a few weeks of paperwork. It is worth doing after the DNS and SVG are already known-good — not as the first step.

Verifying the chain on a real message

Here is where most guides hand you a link to a "BIMI checker" and stop. A checker tells you that your DNS record parses and your SVG validates. It does not tell you whether the message your application actually sends — from your actual server, through your actual provider, with the From: header your actual code sets — will earn the logo.

Those are different questions, and the gap between them is where BIMI rollouts fail:

• The application sends from noreply@app.example.com while the record was published on example.com and the subdomain has its own p=none.
• The DKIM signature is on the ESP's domain, so DMARC passes on SPF alone — until a forwarder breaks SPF.
• A staging build sets From: "Example" <hello@example.com> but the envelope sender is the provider's bounce domain; alignment holds in relaxed mode but the team has just switched adkim=s.

The check you want runs against a captured message, not a form field. Send a real message from the environment you are validating into a sandbox, then read what a receiver would read:

From: "Example Co" <hello@example.com>
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2026; ...
Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=bounce.example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

Then, for the domain in that From: header, resolve the chain the way a receiver does:

# 1. DMARC policy on the From domain (and its organizational domain)
dig +short TXT _dmarc.example.com

# 2. The BIMI record
dig +short TXT default._bimi.example.com

# 3. The logo and the certificate, fetched over HTTPS with no browser tricks
curl -sSfI https://example.com/brand/logo.svg | head -1
curl -sSf  https://example.com/brand/vmc.pem | openssl x509 -noout -subject -dates

This is exactly the sequence Mailclutch runs on every message it captures. Point your staging SMTP at the sandbox — four environment variables, no code change — and each captured message shows the From domain's DMARC policy, whether a BIMI record exists, whether the logo and certificate URLs resolve, and how the whole thing lands in the deliverability score: a record with a logo and a certificate earns the full BIMI credit, a logo alone earns partial credit, and a record with neither is reported as incomplete rather than pretended to work.

The point is not the score. The point is that the check runs against the message your code produced, so the answer is about your code.

A rollout order that works

1. Authenticate everything. SPF and DKIM on every sending source, with DKIM signing on your own domain (not just your provider's).
2. Publish DMARC at p=none with reporting. Read the reports. Fix the sources that fail.
3. Move to p=quarantine, then p=reject. At pct=100. Keep watching the reports.
4. Produce the SVG Tiny P/S logo. Validate it, host it over HTTPS on a URL you control.
5. Publish the BIMI record with l= only. Confirm Yahoo renders it.
6. Obtain a VMC or CMC. Add a=. Confirm Gmail renders it.
7. Keep a sandbox in your CI or staging path so a future change to the From address, the DKIM selector or the DMARC record shows up as a failed check before it shows up as a missing logo.

Steps 1 through 3 are ninety percent of the work and a hundred percent of the risk. BIMI is what you get for finishing them.

Further reading

• Why your BIMI logo is not showing in Gmail — the debugging guide for when the record is published and nothing happens.
• Gmail's sender requirements, for developers — the authentication baseline BIMI sits on top of.
• SMTP setup — capturing your staging mail so the checks above run on every send.