Why is my BIMI logo not showing?

21 June 2026 · 17 min read

A BIMI logo that refuses to appear is one of the most frustrating failures in email authentication, because nothing tells you it has failed. There is no bounce, no error in your DNS console, no warning in your sending platform. You publish a record, you point it at a logo, perhaps you pay for a certificate, you send a test message to yourself, and the avatar circle next to your name shows the same generic initial or coloured blob it always did. Everything you can see looks correct, and yet the inbox stays stubbornly blank. The reason is that BIMI is not a single setting. It is the visible tip of a chain of dependencies that runs all the way down to your DMARC policy, and a mailbox will only draw your logo when every link in that chain holds simultaneously. Break any one of them and the mailbox quietly does nothing, which from your seat looks identical to "BIMI is broken".

This article is a complete fault tree for the missing logo. It walks every layer in the order a receiving mailbox actually evaluates them, so you can find the specific link that is failing rather than guessing. The layers, top to bottom, are: your DMARC policy is not at enforcement; the message itself failed DMARC; the BIMI record is missing, malformed, or at the wrong selector; the SVG does not meet the strict profile or cannot be fetched; the certificate is missing, invalid, expired, or does not match the logo; and finally caching and per-mailbox support, which explain why a fix you made an hour ago still has not shown up. Work down them in order and you will find the cause.

First, understand why it fails silently

It helps to know what a mailbox does with an inbound message before it decides whether to paint a logo. When mail arrives, the receiver authenticates it, evaluates DMARC, and only if DMARC passes against an enforced policy does it even begin to think about BIMI. It then looks up your BIMI record, fetches the logo, validates the certificate if one is referenced, confirms the logo inside the certificate matches the logo being served, and only then renders. At every one of those steps the safe default is to draw nothing. A logo is a trust signal, so a mailbox that is unsure will always choose to show no logo rather than risk showing the wrong one. That design choice is correct for security and miserable for debugging, because it converts six different failure modes into one identical symptom.

The practical consequence: you cannot debug BIMI by staring at the inbox. You have to inspect each layer with the right tool. The free BIMI checker fetches your record, parses the tags, retrieves the SVG, and reports whether it passes the profile and whether a certificate is referenced, which collapses most of the guesswork. But the very first thing to check is not BIMI at all.

Reason 1: DMARC is not at enforcement (the most common cause by far)

BIMI does not work on a domain publishing p=none. Full stop. Every supporting mailbox, without exception, requires that the sending domain has a DMARC policy of p=quarantine or p=reject before it will render a logo. This single requirement is responsible for more missing logos than every other cause combined. The artwork is perfect, the record is published, the certificate is bought and paid for, and nothing shows, because the domain is still sitting at monitoring level.

The reasoning is deliberate and worth internalising rather than resenting. A logo is a brand trust mark. If any domain could attach a recognisable logo to its mail without enforcing authentication, the logo would become a phishing tool: an attacker spoofing your domain would get your logo on their fraud. So the BIMI specification makes enforced DMARC the non-negotiable price of entry. There is no override, no flag, no exception for "but my logo is ready". Enforcement first, always.

Some mailboxes are stricter still. Gmail in particular expects, at minimum, a policy of p=quarantine with pct=100, and most senders end up at p=reject regardless because that is where the actual anti-spoofing protection lives. A record reading p=quarantine; pct=10 is effectively a monitoring policy for ninety percent of mail and will not satisfy the requirement.

Check where your domain stands right now with the free DMARC checker. If it reports p=none, stop here: BIMI is premature and no amount of record or SVG fiddling will produce a logo. The fix is to complete the enforcement journey first, and to do it without losing legitimate mail, which is the entire point of the staged rollout described in the DMARC product overview and in reach p=reject without breaking email. The danger of p=none is precisely that it feels safe and finished while protecting nothing, a trap covered in the false security of p=none. If your pct is set below 100, raise it to 100 as part of reaching genuine enforcement; the sampling mechanics are explained in DMARC pct sampling.

Reason 2: the specific message failed DMARC

This one catches people who have done everything right at the domain level and still see the logo missing on some messages but not others. BIMI is gated per message, not just per domain. Even with a flawless BIMI setup, enforced DMARC, valid certificate and all, a mailbox will not render the logo on an individual message that itself failed DMARC.

So the question shifts from "is my domain configured?" to "did this particular message authenticate and align?" A message fails DMARC when neither SPF aligns nor DKIM aligns with the visible From domain. The usual culprits are:

The message went through a forwarder that broke the DKIM signature and changed the envelope so SPF no longer aligns. This is the classic forwarding failure described in why forwarding breaks authentication. The logo will be absent on the forwarded copy even though your direct mail shows it perfectly.
The message came from a sender you never aligned. A marketing platform, helpdesk, CRM or invoicing system that authenticates with its own domain rather than yours will pass SPF or DKIM for that vendor but fail alignment for you, so DMARC fails and BIMI does not render.
The message came through a mailing list that rewrote it, which is a known interaction covered in mailing lists, DMARC and ARC.

The way to diagnose this is not to look at the message in isolation but to look at your aggregate reports, which tell you exactly which sources pass and fail DMARC alignment. Run a report through the DMARC report analyzer and you will see whether the source that sent your "missing logo" message is actually passing. If a legitimate source is failing alignment, that is a DMARC problem to fix before it is a BIMI problem, and fixing it usually means enabling DKIM signing with your own domain on that source. You can sanity-check the underlying mechanisms with the SPF checker and the DKIM checker. The general pattern of "everything seems set up but DMARC still fails" is unpacked in DMARC fails but SPF and DKIM pass.

The takeaway: a logo that shows on your direct mail but vanishes on mail to certain recipients, or from certain systems, is almost always a per-message authentication failure, not a BIMI misconfiguration.

Reason 3: the BIMI record is missing, malformed, or at the wrong selector

Assuming DMARC is enforced and your test message passes, the next layer is the BIMI DNS record itself. BIMI is advertised through a single TXT record at a specific, easily mistyped location:

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

The failures at this layer are mostly about getting the name and the tags exactly right:

Wrong record name. The default selector lives at default._bimi under your domain, with the underscore prefix, just like _dmarc and _domainkey. A record published at bimi.example.com or at the apex is invisible to every receiver and produces total silence. This is the BIMI equivalent of the _dmarc host mistake and it is just as common.
v=BIMI1 not first. The version tag must be the first tag in the record. If it is missing or misspelled, the whole record is ignored and the domain behaves as if it has no BIMI at all.
A broken l= value. The l= tag is the HTTPS URL of your SVG logo. If the URL is wrong, points to a moved file, or uses plain HTTP instead of HTTPS, the mailbox cannot fetch the logo and renders nothing.
A broken or absent a= value. The a= tag is the HTTPS URL of your certificate. Leaving it empty is legal syntax, but in the mailboxes most people care about it means no logo, which is covered in detail under Reason 5 below.
Two BIMI records at the same selector. As with DMARC, more than one TXT record beginning v=BIMI1 at the same name is treated as ambiguous and ignored.

There is a second, subtler record problem: the wrong selector. Just as DKIM uses selectors to publish multiple keys, BIMI uses selectors to let one domain publish multiple logos, chosen per message via a BIMI-Selector header. Most senders only ever need default. But if a message carries a BIMI-Selector header pointing at a selector you have not published a record for, the mailbox looks up a record that does not exist and shows no logo, even though your default._bimi record is perfect. If you are not deliberately using multiple brands, make sure no system in your sending path is injecting a stray BIMI-Selector header. The mechanism is explained in the BIMI selector explained.

Confirm exactly what is published, on any domain, with the free BIMI checker. It will tell you whether the record is found at the right name, whether the tags parse, and whether the URLs resolve. If you have just edited the record, remember DNS propagation, which Reason 6 covers.

Reason 4: the SVG is the wrong kind of file, or cannot be fetched

Even with a valid record pointing at a real URL, the logo will not render if the file at that URL is not exactly the right kind of SVG, or cannot be retrieved cleanly. BIMI does not accept a PNG, a JPEG, or an ordinary SVG exported from a design tool. It requires a deliberately restricted flavour called SVG Portable/Secure, written SVG P/S, based on the SVG Tiny 1.2 profile. The restrictions exist because the file is rendered inside an email client and must not be able to do anything dangerous or unpredictable.

The constraints that most often cause a silent failure:

Any <script> element disqualifies the file outright. Design tools sometimes inject scripting or interactivity; it must be stripped.
Any external reference. No linked images, no remote fonts, no external stylesheets, no xlink:href pointing off the document. The file must be entirely self-contained.
Any animation. SMIL animation elements are forbidden.
The root element must declare the profile. A single root <svg> with baseProfile="tiny-ps" and the correct version. Missing or wrong base profile is a frequent reason an otherwise clean SVG is rejected.
A <title> element describing the mark is expected.
A square viewBox. The aspect ratio must be square, for example 0 0 200 200. Wide wordmarks have to be reworked into a square lockup, often just the brand symbol rather than the full name.
A solid background, not transparent. Transparency renders unpredictably against the coloured avatar circles different clients draw, so a defined background colour is expected.
Small file size. Keep it lean. Large embedded path data, unused metadata and editor cruft cause problems.

Beyond these machine rules, there are fetch-level problems that look identical from the inbox. The SVG must be served over HTTPS with a valid, trusted TLS certificate on the web server, with an appropriate content type. A logo served over plain HTTP, from a host with an expired or self-signed TLS certificate, or returning the wrong MIME type, will not be fetched, and so will not render. A file behind authentication, a redirect chain, or a host that blocks the mailbox's fetcher fails the same way.

There is one more trap that becomes critical the moment a certificate is involved: the SVG you serve must be byte-for-byte the same mark the certificate was issued against. If you tweak the logo after the certificate is issued, the image in your DNS no longer matches the image inside the certificate, validation fails, and the logo stops showing even though both the record and the file look fine in isolation. Treat your final SVG as a versioned, locked asset, not a draft. The design decisions that make a logo survive being shrunk into a thirty-pixel circle are covered in designing a BIMI logo, worth reading before you finalise anything.

When you onboard a domain to DMARC Engine, the platform validates the SVG against the P/S profile before anything else, checks for forbidden elements, confirms the square viewBox and tiny-ps base profile, flags transparency, and stores the canonical file. That validation catches the overwhelming majority of "my logo will not show" problems before they cost you a certificate fee. You can read the full hosted flow in hosted BIMI end to end and the setup steps in the BIMI setup doc.

Reason 5: the certificate is missing, invalid, expired, or does not match

For the inboxes that matter most, Gmail and Apple Mail among them, a valid record and a perfect SVG are still not enough. They require a Verified Mark Certificate (VMC), or in some cases a Common Mark Certificate (CMC). The certificate is a special X.509 certificate, issued by a small number of approved certificate authorities, that cryptographically binds your specific logo image to evidence that you are entitled to use it. This is the most expensive and slowest part of BIMI, and it fails in several distinct ways, each producing the same blank avatar.

No certificate at all. If your a= tag is empty, Gmail and Apple Mail render nothing. A few other mailboxes will show a logo from the record and SVG alone, which is why people are surprised to see their logo in one client and not another. The honest summary is "in a few places a certificate-free logo shows, in the places you care about it does not", covered in BIMI without a VMC.
The certificate has expired. VMCs and CMCs are paid certificates with annual renewal. When one lapses, the logo disappears overnight with no warning, and because nobody is staring at the inbox the day it expires, it is often discovered weeks later. This is one of the most common causes of a logo that "used to work and just stopped".
The certificate does not match the served SVG. As noted under Reason 4, any change to the logo after issuance breaks the match and stops rendering. The image in the certificate, the image in your DNS record, and the image on your trademark registration must all be the same mark.
The certificate is from an issuer the mailbox does not trust, or is otherwise structurally invalid. Only certificates from approved VMC and CMC authorities are accepted.
The underlying trademark requirement is not met. A VMC requires, in the standard case, a registered trademark for the actual logo image, in a recognised trademark office, matching what you publish. A pending application or a mere company name is usually not sufficient. If your logo is not a registered trademark, you may need the CMC route, which relaxes the strict registration requirement and is explained in the CMC explainer and, for logos with no registration, in CMC for unregistered logos.

Diagnosing a certificate problem usually means confirming three things: that an a= URL is present and resolves over HTTPS, that the certificate it points to has not expired, and that the logo it was issued against is the logo you are currently serving. The BIMI checker will tell you whether a certificate is referenced and reachable. Whether the certificate is still valid and still matches is the part most worth monitoring continuously, because expiry and drift are silent.

What DMARC Engine handles around the certificate: it builds the certificate signing request against your canonical SVG so the image inside the request matches the published logo exactly, hosts the issued certificate over a monitored HTTPS endpoint, wires it into the a= tag automatically, and watches for approaching expiry so renewal happens before the logo vanishes rather than after. What no platform can do for you is own the trademark, pay the certificate authority, and pass the authority's identity vetting; those depend on facts about your business. That division of labour is laid out in full in hosted BIMI end to end and on the BIMI product page.

Reason 6: caching and per-mailbox support (why your fix has not shown up yet)

You have checked every layer, fixed the fault, re-run the BIMI checker, and it all passes, and the logo still is not in your inbox. Before assuming something is still broken, account for caching and for the simple fact that support is not universal.

DNS caching. Your BIMI record, like any DNS record, is cached by resolvers for the length of its TTL. A change you make is not visible everywhere instantly; resolvers continue serving the old value until the TTL expires. If you just published or corrected the record, a stale cached answer can keep the logo missing for as long as the previous TTL. Confirm what different resolvers actually return rather than trusting one cached lookup, and give propagation time before concluding the change failed.

Mailbox-side caching. Mailbox providers also cache BIMI lookups and fetched assets on their own side, sometimes for considerably longer than your DNS TTL. Gmail in particular can take a meaningful amount of time, often a day or more, to pick up a newly valid configuration and start drawing the logo. A correct setup that shows nothing for the first day is normal, not a failure. Patience is part of the process here; re-checking the inbox every five minutes will only frustrate you. For Gmail-specific symptoms and timing, see fixing a BIMI logo not showing in Gmail.

Per-mailbox support and rendering differences. BIMI is not implemented identically, or at all, across every mailbox. Gmail and Apple Mail are the headline implementations and both want a certificate. Other clients vary: some render from the record and SVG without a certificate, some do not support BIMI yet, and some place or shape the logo differently. So a logo that shows in Apple Mail but not in an older desktop client is not necessarily broken; that client may simply not implement BIMI. Test against the mailboxes you actually care about, on a freshly received message from a properly aligned sender, and treat anything beyond Gmail and Apple Mail as a bonus.

Test conditions matter. Make sure you are testing on a newly received message rather than an old one in a thread, that the message you are looking at actually passed DMARC (Reason 2), and that you are not viewing it through a forwarder or alias. A logo absent on a months-old message in your archive tells you nothing about today's configuration.

Working the fault tree in order

When a logo is missing, resist the urge to jump straight to the SVG or the certificate, because the cause is statistically most likely to be lower down the stack. Run the checks in the order a mailbox evaluates them:

Is DMARC at enforcement? Run the DMARC checker. If it shows p=none, or pct below 100, that is your answer. Reach genuine enforcement first using the staged path in the DMARC product. Nothing below this matters until this passes.
Did the specific message pass DMARC? Check your aggregate reports through the DMARC report analyzer. If the source that sent the message is failing alignment, fix that source; a forwarded or unaligned message will never show a logo regardless of BIMI.
Is the BIMI record correct? Use the BIMI checker. Confirm it is at default._bimi, that v=BIMI1 is first, that there is exactly one record, and that no stray BIMI-Selector header is pointing at a selector you have not published.
Is the SVG valid and fetchable? The same check reports whether the SVG passes the P/S profile and whether it retrieves over HTTPS. Confirm square viewBox, tiny-ps base profile, no scripts, no external references, no animation, solid background.
Is the certificate present, valid, unexpired, and matching? Confirm a= resolves, the certificate has not lapsed, and the logo it was issued against is the logo you serve. For Gmail and Apple Mail, no valid certificate means no logo.
Have you allowed for caching? Give DNS and mailbox caches time, test on a freshly received and properly authenticated message, and accept that not every client supports BIMI.

For the wider context of how all five records, SPF, DKIM, DMARC, MTA-STS and BIMI, fit together and what "compliant" means across them, the requirements page is the map, and unfamiliar terms like selector, alignment and VMC are defined in the glossary.

Where DMARC Engine fits

Most of the reasons above share a single property: they fail silently and stay failed until a human happens to notice. A p=none domain offers no logo and no warning. A certificate expires and the logo vanishes without a bounce. A record drifts, an SVG host's TLS certificate lapses, a sender starts failing alignment, and in every case the inbox simply shows nothing while you assume it is still working.

That continuous, silent-breakage problem is exactly what the hosted model is built to remove. DMARC Engine drives the domain to enforcement safely so the precondition is actually met, validates and hosts the SVG over a monitored HTTPS endpoint, publishes the record with the correct selector and syntax alongside your other authentication records, builds the certificate request against the exact published logo so the images always match, hosts and renews the certificate before it expires, and watches all of it so that when something drifts you are told rather than discovering it months later. You manage the lot from the dashboard at app.dmarcengine.com. The parts that genuinely require you, owning the trademark and paying the certificate authority, stay with you because they cannot be delegated; everything that is technical, repetitive and silently breakable becomes a monitored responsibility. A missing logo stops being a mystery you re-investigate by hand and becomes a condition the platform catches and explains.