BIMI Checker
Your Record, Your Logo File, and Why It Is Not Showing

What This BIMI Checker Tests, and Why the Record Is the Easy Half

BIMI — Brand Indicators for Message Identification — puts your logo next to your name in someone’s inbox. Setting it up takes three pieces: one TXT record in DNS, one SVG file on a web server, and usually one certificate on a web server too. The record is trivial. The SVG is a file in a format almost no drawing tool exports correctly, served over HTTPS from infrastructure with a certificate and a deploy pipeline of its own. That is where setups die.

The evidence is not a hunch. On 23 September 2026 we resolved default._bimi across 196 large, well-known domains. Ninety publish a record. Every one of the 87 logo URLs among them is HTTPS, as the draft requires, and every one of the 90 sits behind a DMARC policy of quarantine or reject — not a single one at p=none. The DNS half is the half everybody gets right, which is exactly why a checker that stops there tells you almost nothing about whether your logo will appear.

So this one does not stop there. It reads the record, then reads DMARC on your domain and on its organisational domain, then downloads the file at your l= URL and parses it against the SVG Tiny Portable/Secure profile, element by element. If you publish an a= URL it fetches that too and tells you whether a certificate is genuinely being served there. You can watch each step pass or fail in the panel above, in the order a mailbox provider performs them.

Two things a receiver does that almost nobody sees

It looks twice. Section 7.2 of the draft tells a receiver to query <selector>._bimi at the domain in the From address and, if that comes back with nothing, to query the same name at the organisational domain instead. That is why mail.yourbrand.com usually publishes no BIMI record at all and still shows a logo: it inherits yourbrand.com’s. This checker follows the same two steps and tells you which one answered, so a sending subdomain is never reported as unconfigured when it is simply inheriting.

DMARC does exactly the same thing, and this is where the wrong answer usually comes from. If a subdomain publishes no _dmarc record, the policy that applies to it is the parent’s — the sp= tag if the parent sets one, and p= if it does not. So email.yourbrand.com with no DMARC record of its own is not unprotected; it is governed by yourbrand.com. The trap is sp=none: a parent at p=reject; sp=none looks strong and leaves every subdomain at none, which disqualifies them from BIMI entirely. We resolve both names and tell you which policy is actually in force.

It can look a third time, per recipient. A record may carry an lps= tag — a local-part selector. With lps=news,billing, the logo applies only to mail whose From address begins with one of those prefixes, and the receiver then does a further lookup using the normalised local-part as the selector. That is a per-message decision, so no domain-level checker can perform it — but if your logo appears for one sending address and not another, this tag is where to look first. We report it whenever it is present and say plainly that we cannot follow it.

Two things it does not do, stated here rather than buried. It does not validate the certificate at your a= URL — not the chain, not the trademark, not the expiry. That is the certificate authority’s job and pretending otherwise would be dishonest. And it cannot tell you whether a particular mailbox provider will choose to display your logo, because that also depends on your sending reputation, which no external tool can see. If you would rather look the record up yourself first, that works too — it is an ordinary TXT record. What a plain lookup cannot tell you is whether the file behind that record is valid, and that is the part that breaks. The underlying question of whether your mail is trusted at all is a broader one, covered in our guide to what actually decides whether your mail reaches the inbox.

The Logo File Is Where BIMI Actually Fails

BIMI does not accept an SVG. It accepts SVG Tiny Portable/Secure, a deliberately stripped-down profile with no raster images, no hyperlinks, no scripting, no animation, no multimedia and no external references of any kind. The reasoning is obvious once you say it out loud: a logo that can fetch, animate or execute is a logo that can be used against the person reading the mail.

A file can render perfectly in every browser you own and still fail the profile. In practice it fails on one of these:

The checker above lists each of these separately, quoting the wording from the profile it comes from. It also draws the logo twice, on white and on dark. A single-colour mark disappears into one of them, and this is a better place to discover that than a customer’s inbox.

It checks the quieter rules as well, because those are the ones a validator built from a blog post misses. The profile constrains six attributes on the root element — zoomAndPan, externalResourcesRequired, focusable, snapshotTime, playbackOrder and timelineBegin — each of which should not be there at all and must carry one exact value if it is. It also flags an editable attribute that is not none, and a <title> longer than the 64 characters the profile asks for. None of these will be the reason your logo is missing today, but each one is a real conformance failure that a certificate authority can refuse you over.

The preview, and why it is an image rather than the file

Drawing a stranger’s SVG is the most dangerous thing a page like this can do. An SVG placed inline becomes part of the document, and anything executable inside it would run with the page’s privileges. So the preview above is an <img>, which browsers treat as secure and static — no scripts, no external fetches — and it is only drawn after our own parse has confirmed there is nothing executable in the file. If the bytes contain anything that merely looks like active content, you get the report without the picture. Withholding a preview costs you nothing; drawing the wrong file costs a great deal.

One more thing worth checking while you are here: the logo is served over HTTPS, so its host has a certificate, and an expired certificate breaks BIMI as thoroughly as a malformed file. If the fetch above failed on TLS, grade the certificate on the host serving it before you go looking for anything else.

The DMARC Gate, Including the Tag the Standard Deleted

BIMI is not an authentication mechanism. It is a display rule that sits on top of one, and the one it sits on is DMARC. The draft asks for “a strong [DMARC] policy (quarantine or reject)”, and Google states it without ambiguity: “BIMI doesn’t support DMARC policies that have the p option set to none.” If your policy is p=none, everything else on this page is irrelevant until you fix that. Our DMARC checker will tell you what you currently publish.

Three details catch people out, and the first is the only one most people have heard of:

1. The organisational domain counts too. The draft requires a qualifying policy on the Author Domain and the Author Organisational Domain. A subdomain cannot qualify on its own while its parent sits at p=none.
2. sp=none disqualifies you. A domain that leaves its subdomains unprotected does not get a logo, however strong the main policy is.
3. The pct rule. This is the strange one, and it needs a section of its own.

BIMI requires a DMARC tag that no longer exists

The BIMI draft says that if the policy is p=quarantine and the DMARC record defines a percentage tag, that tag must be pct=100. Google’s setup page says the same in its own words: “The percent option (pct) must be set to 100.”

But RFC 9989 removed pct from DMARC entirely in May 2026, and IANA now lists it as historic. So BIMI and Google are both pointing at a tag the DMARC standard has deleted. That sounds like a contradiction you are stuck inside, and it is not, because of one word: the BIMI rule applies only if the record defines the tag.

This is not a rare situation. Re-resolving _dmarc across the same 196 domains on 23 September 2026, 195 publish a DMARC record and 77 of them still carry pct — every single one at pct=100, so harmless, but every one of them also carrying a tag the standard no longer defines. The checker above tells you which case you are in and says so in plain terms rather than passing you silently.

VMC, CMC, and What Each Provider Actually Requires

The a= tag points at a BIMI Evidence Document: a certificate proving the logo is yours. There are two kinds, and which you need depends on whether your logo is a registered trademark.

That table is why the same domain shows a logo in one inbox and not another, and it is the single most common source of confusion about BIMI. There is no universal answer to “do I need a VMC”. There is only an answer per provider.

In our survey, 67 of the 87 domains publishing a logo also published an a= certificate. Twenty did not — a logo with no evidence document at all. Yahoo may still show those, since it states it does not require a certificate; Gmail will not. If that is a deliberate choice it is a reasonable one; if it is an accident, it explains a year of confusion.

One thing worth doing once your record is live: send yourself a message and read what the receiving server recorded. The Authentication-Results header is where DMARC alignment is stated as fact rather than predicted, and you can read those results out of a message you have received in a few seconds. BIMI sits on top of that result, so if DMARC is not passing there, nothing above matters yet.

BIMI Is Not a Standard, and That Explains Almost Everything

BIMI is almost always described as a standard, and most pages about it say so without qualification. It is not one, and the distinction is not pedantry — it is the reason the rules keep moving under you.

BIMI is an Internet-Draft: draft-brand-indicators-for-message-identification, revision 14, dated 1 May 2026. It is an individual submission with no working group behind it, its IESG state is “I-D Exists”, and it has never been published as an RFC. The SVG Tiny Portable/Secure profile it depends on is a second Internet-Draft in exactly the same position. The IETF Datatracker states the position plainly for documents like these: such a draft “is not endorsed by the IETF and has no formal standing in the IETF standards process.”

Which is why:

• Each mailbox provider applies its own variation — Yahoo needs no certificate, Gmail does, Apple documents almost nothing.
• A logo that passes one vendor’s validator can still be refused by a provider.
• The specification can require a DMARC tag that the DMARC standard has since deleted, and nothing in the process forces the two documents to agree.

None of that makes BIMI useless. It works, it is widely deployed, and the checks above are real. It means you should treat vendor claims about “the BIMI standard” with the scepticism they have earned, and re-verify after any provider announcement.

The inversion nobody talks about

We ran a second survey of the same 196 domains for MTA-STS, the record that tells other mail servers to encrypt in transit. Putting the two side by side produces the most interesting number in either dataset.

Across the whole sample, 74 domains publish a logo but no transport-security policy. Twelve do the reverse. The finance row is the sharpest version of it: banks pay for a trademark and a verified certificate so customers see a logo, and skip a free TXT record that tells senders to encrypt mail on the way in. Mailbox providers are the mirror image, because they are receivers rather than brands — encryption is their job and logos are not.

Draw your own conclusion about what that says about how security budgets get approved. The practical point is smaller: if you have just set up BIMI, you are statistically likely to have skipped the cheaper protection, and our MTA-STS checker will tell you in one lookup.

Survey method, so you can judge it: 196 large, well-known domains resolved live on 23 September 2026, the same sample for both records. It is a convenience sample of well-run domains, so every adoption figure is a ceiling rather than an average — the internet as a whole does far worse.

Setting BIMI Up in the Order That Does Not Waste Money

The expensive mistake is buying a certificate first. A VMC is a real annual cost, and it is worth nothing until DMARC is enforcing and your logo is in the right format — both of which are free to get right. Do it in this order:

1. Get DMARC to quarantine or reject first. Not partially: the whole policy, on the domain and on its organisational domain, with sp either absent or set to something other than none. If you are still at p=none, everything after this step is premature. Our guide to finding out whether SPF, DKIM and DMARC are passing at all is the place to start if you are not sure.
2. Delete pct if it is still in your record. RFC 9989 removed it. Leaving pct=100 is harmless; leaving anything else disqualifies you from BIMI entirely.
3. Produce the SVG Tiny P/S file and validate it before you go near a certificate authority. Add version="1.2", add baseProfile="tiny-ps", add a non-empty <title>, remove anything raster, keep it under 32 KB. Host it over HTTPS.
4. Publish the record with just l= at first. Yahoo will start showing it without a certificate, which gives you a live confirmation that the file and the gate are right before you spend anything.
5. Then buy the evidence document. A VMC if the logo is a registered trademark, a CMC if it is not. Append the whole chain into the PEM file, host it over HTTPS, and add a= to the record.
6. Re-check. Run the domain through the checker above again. The most common late failure is a PEM file that is not reachable at the URL in the record — the certificate is fine, the web server is not.

That last form is worth knowing. The draft defines an empty l= together with an empty a= as “an explicit refusal to participate in BIMI” — a way of telling mailbox providers not to go looking. Two of the mailbox providers in our survey publish exactly that record.

BIMI Checker: Frequently Asked Questions