BIMI needs more than a logo: the DMARC gate in front of it

You’ve had the logo drawn as an SVG, someone has published the default._bimi record, and the logo still isn’t showing in Gmail. If your DMARC record says p=none, that’s the reason, and nothing you do to the logo file will change it. BIMI sits at the top of a chain of checks. A receiver works up that chain from the bottom, and for most domains the rung it stops on is DMARC enforcement.

The order a receiver checks in

A mailbox provider that renders BIMI doesn’t start with your logo. It authenticates the message first, then reads your DMARC policy, and only if that policy is at quarantine or reject does it go looking for a BIMI record. Whatever happens, it writes the outcome into the Authentication-Results: header of the delivered message, so you can see where it stopped.

On a message from a domain at p=none, Gmail writes this:

bimi=skipped (DMARC Policy is not at enforcement)

When the whole chain holds, the same line reads:

bimi=pass header.d=example.com header.selector=default policy.authority=pass

Send a campaign test to a Gmail mailbox, open the message, choose Show original and find the bimi= line. It’s the one diagnostic that names the rung you fell off, and it costs nothing.

The rungs, from the bottom, are an authentication pass that aligns with your From address, a DMARC policy at enforcement with nothing watering it down, a BIMI record pointing at a logo in the right format, a certificate for the receivers that want one, and a sending history the receiver trusts. Each rung depends on the one below it, and the receiver won’t look at a higher rung while a lower one is missing.

Rung one is authentication that carries your own domain

DMARC passes when SPF or DKIM passes for a domain that aligns with the domain in the From: header. For BIMI the signature that matters is DKIM, because a campaign platform’s SPF pass is for the platform’s own envelope domain and says nothing about yours. Look at the dkim= part of the same header:

dkim=pass [email protected] header.s=k1 header.d=example.com

The header.d= value is the domain that signed. If it’s the platform’s domain rather than yours, the signature is valid and it aligns with nothing, so DMARC fails on that message and the BIMI check is never reached.

Most campaign platforms will sign with your domain once you add the CNAME records they hand you during setup. The ones that won’t leave you with a signature you can’t use, and no BIMI record fixes that. The DKIM page shows how to read a signature and confirm whose domain is in it.

If a message fails DMARC, the receiver applies your policy to it and skips BIMI. If it passes, the receiver moves to the next rung, which is the policy itself.

Rung two is p=quarantine or p=reject, with nothing watering it down

This is the rung the question is about. Pull the record the way a receiver does:

dig +short TXT _dmarc.example.com
"v=DMARC1; p=none; rua=mailto:[email protected]"

That record disqualifies the domain from BIMI outright. So does the record below, which looks like enforcement and isn’t, because pct=10 tells the receiver to apply quarantine to one failing message in ten:

"v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]"

Receivers that render BIMI require pct= to be absent or set to 100. A p=quarantine with no pct= tag clears the rung and so does p=reject. Anything else, including a p= value the receiver can’t parse, counts as no enforcement, and a misspelt p=quarentine is read as p=none when a rua= is present.

There’s a subdomain trap on the same rung. If your campaigns go out from news.example.com, the receiver applies the policy that covers that subdomain, which is sp= if you’ve set it and p= if you haven’t. A parent record of v=DMARC1; p=reject; sp=none puts the parent at enforcement and the subdomain at none, so the logo shows on mail from example.com and vanishes on mail from news.example.com.

The subdomain policy page covers when sp= earns its place. For BIMI the safe answer is to leave it out.

Of the 78,444,857 domains that publish a DMARC record in the September 2026 census, 36,602,897 are at quarantine or reject, and 16,716,061 of those say reject. The remainder have published a record and still can’t clear this rung. The scan reads your live _dmarc record and shows the p= value along with the rest of the domain, so you know which side of that line you’re on before you spend anything on the logo.

Rung three is the BIMI record and the file it points to

Once the policy is at enforcement, the receiver looks up a TXT record under a selector. It uses default unless the message carries a BIMI-Selector: header naming another one, which is how a group with several brands serves a different logo per sending stream:

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

l= is the logo and a= is the certificate. The a= tag can be empty where the receiver doesn’t ask for one, and both URLs have to be HTTPS on a certificate the receiver’s fetcher trusts, because the receiver downloads the logo itself rather than taking your word for it.

The logo has to be an SVG in the Tiny Portable/Secure profile, which is a narrower thing than the SVG your design tool exports. The root element has to read:

<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny-ps">

It needs a <title> element, no <script>, no external references, no embedded raster images, no x= or y= attributes on the root, a square viewBox, and a file under 32 KB. An export straight from a design tool fails on the profile attribute alone, so run the file through a validator before you publish the record. A logo that fails validation produces a bimi=fail line where bimi=skipped used to be, and the chain stops again one rung higher.

The record itself is quick to check with the same dig command a receiver uses. If it returns nothing, look at the selector name and the _ in front of bimi; default.bimi.example.com and _bimi.example.com are the two shapes people publish by mistake, and neither is where any receiver looks.

Rung four is the certificate, and only some receivers ask for it

Gmail won’t render a logo on the strength of the DNS record alone. It wants a Verified Mark Certificate or a Common Mark Certificate at the a= URL, issued by a certificate authority that checks the logo against your organisation. A VMC needs the logo to be a registered trademark. A CMC accepts a logo you can show has been in use for twelve months or more, and Gmail then displays it without the blue verified tick beside the sender name.

Either way the certificate binds a hash of the exact SVG to your domain, so a logo refresh means a reissue, and the reissue has to land before the new file goes live at the l= URL or the hash check fails in between.

Yahoo renders a BIMI logo with no certificate at all, so it’s the place to confirm that rungs one to three hold before you pay for rung four. Apple Mail wants a certificate too. Outlook has never rendered BIMI, so a share of your list will see no logo whatever you publish, and that share is worth knowing before the budget conversation.

Above the certificate sits the rung nobody can inspect from outside. Gmail also wants a sending history it trusts, and a domain that started sending last month can clear every other rung and still see nothing for a while. If the bimi= line says pass and the logo still isn’t there, this is what’s left, and time is the only fix.

Getting to enforcement without bouncing your own campaign

The DMARC move is the only rung that takes weeks, and it’s the one marketing can’t do alone, because each system that sends as your domain has to pass before the policy can bite. Put an address in rua= and read a month of the aggregate reports that arrive. Each source IP that fails both SPF and DKIM in alignment is either a forger or a tool of yours, and the reports won’t tell you which; the person who owns the platform list will.

Get each legitimate source signing with your domain, then change p=none to p=quarantine with no pct= tag. Wait a fortnight and watch the reports for a legitimate source you missed. Then change quarantine to reject. The DMARC page walks through each tag and what a receiver does with it.

With the policy at enforcement, publish the default._bimi record, put the SVG and the certificate at the URLs it names, send a test to a Gmail mailbox and read the bimi= line. Then run the scan on the domain and check that the p= value it reports is the one you meant to publish.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.