How To Set Up BIMI So Your Logo Shows In Supporting Inboxes

BIMI is a DNS-based standard that lets participating mailbox providers display your brand’s logo next to messages that pass strong authentication. To make it work, your domain needs aligned SPF and DKIM plus an enforced DMARC policy set to quarantine or reject, not monitoring-only. You’ll also need a properly formatted SVG logo hosted over HTTPS and a BIMI TXT record, often under default._bimi, that points to the logo and, for many inboxes, a Verified Mark Certificate. Most “it’s not showing” headaches come down to the logo failing provider checks or the authenticated domain not matching the visible From address.

What BIMI does for inbox logo display and trust

Which inbox providers currently support BIMI

BIMI (Brand Indicators for Message Identification) is a way to help your brand logo show up in the inbox UI (usually as the sender avatar) when your email passes strong authentication. It works by letting receiving mail systems check your domain’s DMARC status and then fetch a logo you publish specifically for BIMI. When it’s working, recipients get a consistent, recognizable logo next to your messages, which can reduce “Is this legit?” hesitation during quick inbox scans.

It’s also important to set expectations: BIMI is not a universal standard that every inbox shows today, and it does not force logo display. Even in supporting inboxes, the provider can choose when to show (or not show) your logo based on their own safety rules, reputation signals, and caching behavior.

As of early 2026, the most commonly referenced consumer inboxes that support BIMI in some form include:

Gmail, where brands typically need a VMC or CMC for their logo to display, and VMCs can unlock a verified checkmark in some Gmail surfaces (Gmail BIMI setup).
Yahoo Mail and AOL Mail, which support BIMI logo display for eligible authenticated senders.
Apple Mail (iOS, iPadOS, macOS, and iCloud.com in supported versions), which supports BIMI and ties logo display to strong authentication and logo verification (Apple Mail BIMI support).
Fastmail, which supports BIMI for both received and sent mail.

Microsoft Outlook and Outlook.com are still commonly cited as not showing BIMI logos, so BIMI should be treated as a “supporting inboxes” win, not a guaranteed everywhere feature.

SPF, DKIM, and DMARC settings required before BIMI

DMARC policy requirements: quarantine or reject

BIMI only gets evaluated when your domain is already doing the basics well: SPF, DKIM, and DMARC. The non-negotiable piece is DMARC enforcement. If your DMARC policy is set to p=none (monitoring mode), most providers will not display BIMI logos, even if everything else looks correct.

For BIMI readiness, publish DMARC with:

p=quarantine or p=reject (not p=none)
A reporting address (rua=) so you can watch for breakage as you tighten controls
If you send from subdomains (like news.example.com), set an enforced sp= policy too, or publish separate DMARC for those subdomains

Some inboxes and validators also expect DMARC enforcement to apply broadly (often effectively 100% of mail), so if you are using pct= during rollout, treat that as a temporary step. For the DMARC policy definitions themselves, the canonical reference is DMARC.org.

Domain alignment and common authentication gotchas

BIMI depends on DMARC alignment, which is where many setups fail. Alignment means the domain the user sees in the From: header must match (or “align” with) the domain used by SPF and/or DKIM.

Common gotchas to check:

SPF aligns to the Return-Path domain, not the From domain. If your ESP uses a different bounce domain, SPF may pass but fail alignment.
DKIM aligns to the d= domain in the DKIM signature. If your ESP signs with their own domain instead of yours, DKIM can pass but not align.
DMARC only needs one of SPF or DKIM to pass and align, but relying on just one is fragile. Most senders aim for aligned SPF and aligned DKIM.
If you use strict alignment (aspf=s / adkim=s), small domain differences can break DMARC. Relaxed alignment is more forgiving and is common in production.

Creating a BIMI-ready SVG logo that passes validation

SVG Tiny PS requirements and common export mistakes

Your BIMI logo is not a regular SVG. It must be a tightly restricted profile called SVG Tiny P/S (Portable/Secure). If your logo looks fine in a browser but fails BIMI, the file format is usually the reason.

At a minimum, the root <svg> element needs:

baseProfile="tiny-ps"
version="1.2"

It also needs a non-empty <title> element (typically your brand name). Many BIMI validators also expect a simple, square logo that stays legible when shown very small. Gmail is especially strict about logos being perfectly square and commonly expects at least 96 × 96 dimensions, even though it is vector. The most practical approach is to build for Gmail’s stricter rules so you do not maintain multiple files.

Common export mistakes that break BIMI validation:

Leaving text as fonts instead of converting to paths (external font behavior can cause rejections).
Including scripts, animation, or interactivity.
Using external references (linked images, stylesheets, remote resources).
Having x= or y= attributes on the root <svg> element.
Exporting with a messy header and extra metadata that bloats the file size.

If you want the canonical checklist for the profile, the BIMI Group’s guide is the most direct: Creating BIMI SVG Logo Files.

File hosting requirements for the logo URL

Where you host the SVG matters as much as how you create it. Your BIMI logo URL should be:

HTTPS only, publicly accessible, and fetchable without logins, WAF challenges, or IP allowlists.
Stable (avoid URLs that change, and avoid query strings if possible).
Served with the correct MIME type (image/svg+xml) and a normal 200 OK response.

In practice, hosting the SVG on a reliable subdomain of the same brand domain you send from keeps things simplest, especially when you later add a VMC/CMC.

Publishing the BIMI DNS TXT record (default._bimi)

BIMI record tags explained: v, l, a

Your BIMI setup becomes “visible” to inbox providers when you publish a DNS TXT record at the right hostname. For most brands, that hostname is:

default._bimi.yourdomain.com

That default part matters. If you publish the TXT record at _bimi.yourdomain.com by accident, many receivers will not find it.

A standard BIMI TXT value is a short list of semicolon-separated tags:

v: The version tag. Use v=BIMI1. This is required.
l: The logo location. This is the HTTPS URL to your BIMI-ready SVG (SVG Tiny P/S). This is required.
a: The authority evidence location. This is the HTTPS URL to your certificate file (VMC/CMC) in PEM format. This is optional in the spec, but required by some inboxes for logo display.

Keep the formatting clean. Use a lowercase l (it is easy to confuse with I). End tags with semicolons. If your DNS provider splits long TXT records into multiple quoted strings, that’s usually fine as long as the combined value is correct.

Example BIMI TXT records for common setups

1) Logo only (no certificate listed): v=BIMI1; l=https://brand.example.com/bimi/logo.svg;

2) Logo + certificate (common for stricter inboxes): v=BIMI1; l=https://brand.example.com/bimi/logo.svg; a=https://brand.example.com/bimi/mark.pem;

When you add the record, most DNS consoles want the “Name” or “Host” field as just default._bimi (not the full domain). After you save it, plan for DNS propagation, and keep a shorter TTL while you’re testing so changes take effect faster.

Verified Mark Certificates (VMC) and provider-specific requirements

Gmail BIMI requirements and the VMC requirement

A Verified Mark Certificate (VMC) is an X.509 certificate that proves your organization has the right to use a specific logo, and that the logo is tied to the sending domain. In BIMI terms, it is “evidence” you publish via the a= tag in your BIMI DNS record. The BIMI Group maintains the core overview of how VMCs fit into BIMI and why some providers require them (Verified Mark Certificates (VMC) and BIMI).

For Gmail, plan on needing a certificate if you want consistent BIMI logo display. Gmail recognizes two certificate paths:

VMC: Typically requires a registered trademark (or certain government marks). In Gmail, a VMC can also unlock the verified checkmark experience in supported views.
CMC (Common Mark Certificate): Introduced to broaden access for brands that do not have a registered trademark. In Gmail, a CMC can display the avatar logo, but without the verified checkmark reserved for VMCs.

In other words: if your goal is “logo only,” a CMC may be enough. If your goal is “logo plus the strongest verification signal Gmail offers,” a VMC is usually the target.

Yahoo and other inbox caveats for logo display

Yahoo Mail supports BIMI, but logo display can still vary by message and by recipient context. A few practical caveats matter:

Self-asserted BIMI can work in some ecosystems (logo URL in l= with no certificate in a=), but it is not universal. If you want the broadest coverage, budget for a certificate.
Passing DMARC is table stakes, and it must be aligned with the visible From domain. A forwarding path or an unsigned mail stream can quietly break alignment.
Logo display is discretionary. Even with perfect DNS records, inboxes may suppress logos for low-reputation traffic, newly authenticated domains, or unusual sending patterns.
Changes take time to show up. Providers cache BIMI lookups and logo fetches, so updates to your SVG or cert can take days to fully propagate in real inbox views.

Testing BIMI setup and fixing common problems

How to validate your BIMI record and logo URL

Start by testing in two layers: DNS first, then the logo fetch.

Confirm the DNS record is published at the right name. The record should be a TXT record at default._bimi.yourdomain.com. A very common mistake is publishing it at _bimi (missing default) or on the wrong domain (for example, on a parent domain while mail comes from a subdomain).
Check the TXT value is well-formed. You should see v=BIMI1; plus an l= URL, and optionally an a= URL. Typos, missing semicolons, or a pasted smart quote can break parsing.
Fetch the logo URL exactly as the receiver will. Open the l= URL in a private/incognito browser session. It must load without redirects to a login page, bot challenge, or a blocked country/IP. If the URL redirects, keep it to a simple, direct HTTPS 200 response.
Validate the SVG itself. If the file fails, it is usually not SVG Tiny P/S, contains unsupported features (fonts, external links), or is not square. Re-export with BIMI settings and keep it simple.
Confirm DMARC is enforced and aligned. If your message is failing DMARC (or passing but not aligned), BIMI will not display. Check an actual received message’s authentication results header in a supporting inbox.

When your logo should start showing in inboxes

Even after everything is correct, logo display is rarely instant. DNS changes can propagate within minutes to hours, but inbox providers may cache BIMI lookups and logo files for longer. A realistic expectation is anywhere from 24 to 72 hours for initial display in some inboxes, and longer after you change the SVG or certificate.

If it still does not show after several days, treat it as a debugging signal: one stream is not DMARC-aligned, the SVG is being rejected by the provider, or a certificate requirement (VMC/CMC) is not met for that inbox.