Fix: BIMI Logo Not Showing in Gmail (Every Cause)

20 April 2026 · 12 min read

You have published a BIMI record, you have a logo file, perhaps you have even paid for a Verified Mark Certificate, and yet you open Gmail and there is still a grey circle with an initial where your brand mark should be. This is the single most common BIMI complaint, and almost every case comes down to one of a small number of preconditions that Gmail checks silently before it will render anything.

Gmail is unforgiving here. It does not show error messages, it does not tell you which check failed, and it caches its decision for a long time. So debugging BIMI in Gmail is really an exercise in working through the chain of requirements in order, because a single weak link anywhere stops the logo from appearing while every other piece looks perfectly healthy.

This guide walks through every reason a BIMI logo fails specifically in Gmail, in the order Gmail evaluates them, and how to fix each one. It is written for the Gmail and Google Workspace rendering rules as they actually behave, not the generic "publish a BIMI record" advice you will find elsewhere.

How Gmail actually decides to show a BIMI logo

Before troubleshooting, it helps to know the order of operations. When a message lands in a Gmail inbox, Gmail does roughly this:

Checks that the message passed DMARC with alignment, and that the From domain's DMARC policy is at enforcement (p=quarantine or p=reject), with a sufficient pct.
Looks up the BIMI record at default._bimi.<from-domain>.
Fetches the SVG logo referenced in the l= tag and validates it against the SVG Tiny PS profile.
For Gmail specifically, validates the Verified Mark Certificate (VMC) or Common Mark Certificate referenced in the a= tag, confirms it chains to a trusted root, and confirms the logo inside the certificate matches the logo you published.
Caches the result and renders the avatar.

If any step fails, the avatar falls back to the generic initial. Crucially, Gmail requires the VMC. Some other mailbox providers will show a logo from just a DMARC pass and an SVG; Gmail will not. That single fact accounts for a large share of "it works in Yahoo but not Gmail" reports.

Work down this list in order. Do not jump ahead. A VMC problem cannot be diagnosed until the DMARC and SVG layers underneath it are clean.

Reason 1: DMARC is not at enforcement

This is the most frequent cause by a wide margin. BIMI is built on top of DMARC, and Gmail will not even look at your BIMI record unless the From domain publishes a DMARC policy of p=quarantine or p=reject. A policy of p=none is monitoring only, and BIMI treats it as ineligible.

Check your current policy:

dig +short TXT _dmarc.example.com
"v=DMARC1; p=none; rua=mailto:dmarc@example.com"

If you see p=none, that is your answer. No logo will ever appear in Gmail while that record is live, regardless of how perfect the rest of your setup is. Run your domain through the DMARC checker to confirm the policy and alignment in one view.

There are three sub-cases worth separating:

p=none. Move to enforcement. Do not do this blindly: if any legitimate sending source is not yet aligned, raising the policy will cause real mail to be quarantined or rejected. Read your aggregate reports first, fix every source, then raise the policy. Our DMARC report analyzer turns the raw XML into a per-source pass/fail view so you can see exactly what would break.
p=quarantine; pct=20 or any pct below 100. Gmail honours pct. If you are only enforcing on a fraction of mail, BIMI eligibility is reduced or absent. For BIMI, you want full enforcement: pct=100 (or omit pct, which defaults to 100).
Subdomain sending. If you send from mail.example.com but DMARC is only published at the organisational domain, the subdomain policy (sp=) governs. A p=reject; sp=none combination leaves the subdomain at monitoring, so BIMI fails for mail from that subdomain. See the subdomain policy (sp) glossary entry.

The target state for BIMI is a clean enforced record:

"v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s"

p=quarantine is acceptable to Gmail for BIMI; p=reject is the stronger end state. If you are not there yet, the safe path from p=none to p=reject without dropping legitimate mail is exactly what the done-for-you service and our monitoring with change alerts are designed to handle.

A subtle trap: the message itself must also pass DMARC. A correctly enforced domain policy does not help if the specific message failed SPF and DKIM alignment. Every individual email that should carry the logo has to authenticate; BIMI is evaluated per message, not per domain.

Reason 2: The BIMI DNS record is missing, malformed, or in the wrong place

Once DMARC is at enforcement, Gmail looks for the BIMI record. It must live at a very specific hostname:

default._bimi.example.com

The default here is the selector. Unless a sender stamps a BIMI-Selector header on outbound mail (most do not), Gmail uses default. Publishing the record at _bimi.example.com or bimi.example.com will not be found.

Check it:

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

Common faults at this layer:

Wrong host. The label order matters: default._bimi, not _bimi.default.
Missing v=BIMI1. The version tag must be first and exactly BIMI1.
l= points to HTTP, not HTTPS. Gmail will not fetch a logo over plain HTTP. The URL must be https://.
The URL is not publicly reachable. Gmail's fetcher has to download both the SVG and the certificate anonymously. If either sits behind authentication, a firewall, geo-blocking, or a bot-protection challenge, the fetch fails silently. Test both URLs from a machine with no cookies, ideally from outside your own network.
The record is split or quoted wrong. A long TXT record split across strings must still concatenate cleanly. Stray quotes inside the value break parsing.
a= omitted entirely. Without a VMC reference, Gmail has nothing to verify and shows no logo. An l= only record works in some clients but never in Gmail.

Validate the published record end to end with the BIMI checker and, before you go live, model the final record with the BIMI generator so the tags are correct from the start.

Reason 3: The SVG logo does not meet the Tiny PS profile

BIMI does not accept arbitrary SVG. It requires the SVG Tiny Portable/Secure (SVG Tiny PS) profile, a deliberately restricted subset designed so that a logo cannot carry scripts, external references, or anything that could be abused in an inbox. A logo exported straight from a design tool will almost always violate the profile, even though it opens fine in a browser.

The profile rules that trip people up most often:

The root element must declare baseProfile="tiny-ps" and the correct SVG version.
No scripts. No <script> elements, no event handlers (onload, onclick).
No external references. No <image> linking to a raster, no external fonts, no xlink:href to other resources, no remote CSS.
No animation elements.
A single <title> element is required.
The artwork must be square (a 1:1 viewBox) because Gmail crops to a circle. A rectangular logo gets cut off badly or rejected.
Use a solid background rather than transparency. A transparent logo cropped into Gmail's circle often looks broken.
Keep the file small. Gmail and the wider BIMI ecosystem expect a logo well under roughly 32 KB.

A minimal compliant root looks like this:

<svg xmlns="http://www.w3.org/2000/svg"
     version="1.2" baseProfile="tiny-ps"
     viewBox="0 0 480 480">
  <title>Example Ltd</title>
  <rect width="480" height="480" fill="#0b5cff"/>
  <path fill="#ffffff" d="..."/>
</svg>

The catch that makes this layer especially painful: the SVG embedded inside your VMC must match the SVG you publish at the l= URL. So if you tweak the published SVG to fix a profile error after the certificate was issued, you can silently break the match and Gmail will refuse the logo even though the file now validates. Treat the logo as frozen once the VMC is issued. If the logo genuinely has to change, you reissue the certificate.

The BIMI glossary entry and the SVG Tiny PS glossary entry cover the profile in more depth, and the BIMI checker will flag profile violations rather than leaving you guessing.

Reason 4: There is no VMC, or the VMC is the wrong type or expired

This is the reason that catches teams who did everything else right. Gmail requires a Verified Mark Certificate. A BIMI record with a valid DMARC policy and a perfect SVG, but no a= certificate, will display in some mailbox providers and never in Gmail.

A VMC is an X.509 certificate issued by a small number of certification authorities (currently DigiCert and Entrust) after they verify that your organisation owns the trademark for the logo. The certificate embeds your logo and chains to a root that Gmail trusts. Things that go wrong here:

No VMC at all. You published l= but never obtained the certificate and so left a= empty. Gmail shows nothing. You must obtain a VMC.
Trademark not registered. A VMC is only issued for a logo that is a registered trademark in a recognised jurisdiction. If your mark is not registered, you cannot get a standard VMC. There is now a Common Mark Certificate (CMC) route for unregistered marks, but Gmail's support for CMCs is more limited and was rolled out later than VMC support, so a registered trademark plus a VMC remains the reliable path for Gmail. See the VMC glossary entry and CMC glossary entry.
Expired certificate. VMCs are issued for a limited term and must be renewed. An expired VMC fails validation exactly like a missing one. Check the validity dates.
Logo mismatch. As above, the logo inside the certificate must byte-for-byte match the served SVG.
Wrong PEM contents. The file at the a= URL must be the full certificate chain in PEM form, served over HTTPS, with the correct content type and no extra wrapping.

Validate the certificate, its chain, its expiry, and the logo-match using the BIMI VMC checker. If you want to preview how the logo will look once everything validates, the BIMI simulator renders it in an inbox-style mock.

Reason 5: Gmail is serving a cached negative result

This one fools people into thinking their fix did not work. Gmail caches BIMI results aggressively, including negative results. So immediately after you fix the real problem, Gmail may keep showing the generic avatar for hours, sometimes a day or more, because it is still serving the cached "no logo" decision and the DNS TTL has not expired.

How to avoid chasing your own tail:

Lower DNS TTLs before you change anything. Drop the TTL on the BIMI TXT record (and ideally the DMARC record) to 300 seconds a day before you make changes. Then propagation and cache turnover happen in minutes, not hours. You can watch propagation with the DNS propagation checker.
Send a fresh test message after the fix, to a new thread. Gmail's rendering can be tied to the cached state of a thread, so reply chains may keep showing the old avatar. A brand new message to a fresh subject line gives the cleanest test.
Test against a Gmail account that has never received your mail. A spun-up personal Gmail or a Workspace test user with no prior history of your domain avoids stale per-sender state entirely.
Confirm the logo is actually contact-card eligible, not just inbox eligible. Gmail shows the avatar in the message list and the open message. If you only checked one surface, you may have missed it.
Be patient after a genuine fix. Even with low TTLs, allow a few hours. If nothing has changed after 24 to 48 hours and every checker is green, the problem is not caching and you should re-walk reasons 1 to 4.

A useful trick: validation tools query live DNS and fetch the live assets, so they bypass Gmail's cache. If the BIMI VMC checker reports everything valid but Gmail still shows nothing, you are almost certainly looking at a cache or propagation delay rather than a configuration fault.

Reason 6: Per-message and account-level conditions

Even with the domain perfectly configured, some individual messages will not show the logo, and that is expected behaviour rather than a bug:

The specific message failed DMARC. If a particular send went out through a source that is not aligned, that message fails DMARC and loses the logo even though your other mail shows it. This is common with a new sending platform that was added after enforcement. Audit your senders with the SPF checker and DKIM checker, and watch your aggregate reports for new unaligned sources.
Forwarded and mailing-list mail. Forwarding frequently breaks SPF alignment, and unless DKIM survives or ARC is honoured, the forwarded copy fails DMARC and shows no logo. See the ARC glossary entry.
The recipient has a contact photo for the sender. If a Gmail user has saved a photo for your address in their contacts, Gmail shows that photo instead of your BIMI logo. This is per-recipient and entirely outside your control.
Google Workspace admin settings. A Workspace administrator can affect how external sender avatars are displayed. If logos appear for personal Gmail recipients but not for one particular Workspace tenant, the difference is likely on their side.
Gradual rollout. Gmail does not always enable BIMI rendering for every account simultaneously. A small lag across accounts is normal.

A clean order to debug it

When a logo will not appear in Gmail, resist the urge to randomly re-export the SVG or reissue the certificate. Work the chain top down, because a failure low in the stack masks everything above it:

DMARC at enforcement and the test message passes DMARC. Confirm p=quarantine or p=reject, pct=100, and that the actual message authenticated. Use the DMARC checker.
BIMI record present and well-formed at default._bimi. Confirm v=BIMI1, an HTTPS l=, and an a=. Use the BIMI checker.
SVG passes Tiny PS and is square. Confirm profile compliance and 1:1 aspect ratio.
VMC valid, unexpired, trusted chain, logo matches. Use the BIMI VMC checker.
Caching ruled out. Low TTLs, fresh message, fresh inbox, then wait.

If steps 1 to 4 are all green and you have waited out the cache, the logo will appear. If any step is red, you have found your reason.

The honest summary

Most "BIMI logo not showing in Gmail" cases are not exotic. In rough order of frequency they are: DMARC still at p=none, no VMC because Gmail demands one, an SVG that fails the Tiny PS profile or is not square, a logo-to-certificate mismatch introduced by a late edit, and finally Gmail caching a negative result while you assume the fix did not take. Two foundational truths cover the majority of failures: BIMI requires DMARC enforcement, and Gmail specifically requires a VMC. Get those two right, keep the SVG frozen once the certificate is issued, lower your TTLs before changing anything, and the rest is mechanical.

The fiddly part is the prerequisite, not the logo. Reaching p=reject safely, without quarantining a single legitimate message, is the work that actually unlocks BIMI, and it is exactly what our done-for-you DMARC service and BIMI product handle, with monitoring and change alerts so a future DNS edit does not silently knock your logo out again. Start by running the domain through the BIMI checker and the DMARC checker to see precisely which link in the chain is breaking.

Fix: BIMI logo not showing in Gmail