Getting a BIMI Logo Into the Inbox: DNS, SVG, and the Verified Mark Certificate
You published the BIMI TXT record three weeks ago and Gmail still shows a gray circle with an initial. BIMI is not a DNS trick — it is the visible tip of a passing DMARC-at-enforcement stack plus a cryptographically-attested trademark. Here is the exact chain a receiver evaluates, in order, and where real deployments break.
EvilMail TeamJuly 18, 202611 min read
You added the default._bimi TXT record three weeks ago. You spent an afternoon exporting the logo. Gmail still shows a gray circle with a capital letter in it.
The record is not the problem. BIMI is not a DNS trick that lights up a logo — it is the visible tip of an authentication stack. A receiver only reaches the BIMI step after your mail has already passed DMARC at enforcement, and it only renders the logo after fetching an SVG in a very specific profile and — for Gmail's blue checkmark — validating a certificate that cryptographically binds that exact file to a registered trademark. Miss any link and the receiver silently falls back to the initial-in-a-circle.
This walks the chain in the order a receiver evaluates it, and points at where production deployments actually die.
What has to be true before BIMI does anything
BIMI has hard gates, not recommendations. Fail one and nothing downstream matters.
SPF and DKIM must pass and align to the From: domain. A message that passes SPF on a mailchimp.com return-path but sends from your domain earns a DMARC pass only if DKIM aligns. BIMI needs that DMARC pass, so alignment is not optional.
BIMI Setup 2026: DNS Record, SVG Tiny P/S, and the VMC Explained — EvilMail Blog
DMARC must be at enforcement.p=quarantine or p=reject. p=none renders nothing — full stop. This is the single most common reason a correct BIMI record still produces a gray circle. Receivers read p=none as "the domain owner is still monitoring," and they will not attach a brand identity to mail the owner has not committed to protecting.
No `pct` below 100. If your DMARC record still carries pct=50 from a staged rollout, most receivers treat the policy as not fully enforced for BIMI. Drop the tag — the default is 100 — once you are confident.
Watch the subdomain policy. BIMI is evaluated against the organizational domain's DMARC unless a subdomain publishes its own record. If your org policy is p=reject but you send from a subdomain and set sp=none, that subdomain's mail sits at none for BIMI. Check sp=.
A DMARC record that clears these gates looks like this:
dns
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s"
Gmail adds one gate the spec does not: reputation and volume. Even with flawless records, a domain that sends a trickle of mail or carries spam complaints will not get the logo. BIMI is a reward for a warm, well-behaved sender, not a switch.
The BIMI DNS record, tag by tag
The record lives at default._bimi.<domain> and is a plain TXT record:
dns
default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/vmc.pem"
`v=BIMI1` — version. Must come first.
`l=` — HTTPS URL of the SVG. Plain HTTP is rejected outright.
`a=` — HTTPS URL of the VMC (or CMC) PEM bundle. Omit it and you have a certificate-less record: Apple Mail may still show the logo, but Gmail will not attach its verified checkmark.
A minimal, cert-less record is legal:
dns
default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/logo.svg;"
Selectors.default is the selector used when the message carries no BIMI-Selector: header. To run a second logo — a seasonal mark, a sub-brand — the sender adds a header to the outbound message:
BIMI-Selector: v=BIMI1; s=brand2
The receiver then looks up brand2._bimi.example.com instead of default._bimi. A record with empty `l=` and empty `a=` is a declared opt-out: it tells receivers this domain deliberately has no BIMI, which suppresses any inherited record.
Hosting rules that bite people: both the l= and a= URLs need valid TLS, must return the file directly with no 301/302 redirect, and the SVG must be served as image/svg+xml. A CDN that "helpfully" redirects logo.svg to a versioned path, or an S3 bucket serving application/octet-stream, breaks BIMI even though the file downloads fine in a browser.
The SVG your design tool won't export by default
BIMI does not accept arbitrary SVG. It requires SVG Tiny Portable/Secure (SVG P/S), a locked-down profile of SVG Tiny 1.2. Illustrator's "Save As SVG" gives you SVG 1.1 with editor metadata, filters, and often an embedded raster — none of which is valid P/S. The receiver fetches it, fails validation, and moves on.
The mandatory bits live on the root element:
xml
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny-ps" viewBox="0 0 512 512">
<title>Example Inc</title>
<!-- solid background rect + your vector paths -->
</svg>
`version="1.2"` and `baseProfile="tiny-ps"` on the root.
A single `<title>` as the first child — required, not cosmetic.
A square `viewBox`.0 0 512 512, 0 0 400 400 — width must equal height. Receivers crop to a circle; a non-square canvas gets rejected or clipped wrong.
The banned list — any one of these fails validation:
<image> or any embedded raster, base64 PNG included
external references — remote xlink:href, external stylesheets, web fonts
filters (<filter>, feGaussianBlur, drop shadows)
Practical guidance from shipping these: a solid background beats transparency. Transparent logos get composited onto whatever avatar background the client uses and often look broken. Keep the file under 32KB. Center the mark on the square canvas with real padding — the client draws it inside a circle, and edge-to-edge art gets clipped.
How to actually get a compliant file:
bash
# strip editor cruft, metadata, and unsafe elements
svgo --multipass logo.svg -o logo.min.svg
# then hand-edit the root: set version="1.2" baseProfile="tiny-ps",
# ensure a square viewBox and a <title> as the first child
# well-formedness check
xmllint --noout logo.min.svg
xmllint only confirms the XML parses — it does not enforce P/S rules. Run the file through the BIMI Group SVG validator at bimigroup.org before you publish. It catches the banned elements and the missing profile attributes that silently kill rendering.
The VMC: binding the logo to a real trademark
Why does a certificate exist at all? To stop a phisher from publishing your logo on their passing-DMARC domain. The Verified Mark Certificate is the mechanism that ties a logo to an entity that legally owns it.
The core requirement is a registered trademark. The exact logo in your SVG must be a granted trademark at a recognized IP office — USPTO, EUIPO, UKIPO, IP Australia, JPO and a handful of others. "Applied for" does not count; the CA verifies the mark is registered and live. The logo you file and the logo you publish must match, which in practice means designing the BIMI SVG to be pixel-faithful to the registered mark.
Issuers as of 2026: DigiCert and Entrust. Entrust's public TLS/CA business was acquired by Sectigo in late 2024, so that lineage now sits under Sectigo. Expect ~$1,000–1,500 per year, with annual re-validation — this is an ongoing operational cost and a recurring legal-review task, not a weekend DNS edit.
No trademark? The CMC. The Common Mark Certificate covers logos that are not registered trademarks — government entities, non-profits, or marks with documented prior use. Apple Mail accepts a CMC. Gmail's blue verified checkmark still requires a VMC. A CMC gets you a logo in Apple's clients but no checkmark in Gmail. Decide which matters for your audience before spending.
What is physically inside the PEM is the thing that breaks most often. The certificate carries a logotype extension (OID 1.3.6.1.5.5.7.1.12) that holds a SHA-256 hash of your exact published SVG. The certificate and the file are cryptographically married. Change one byte of the SVG after issuance and the hash no longer matches: the receiver validates the chain, computes the hash of the file it fetched, compares, and silently declines to render. No error reaches you. The logo just stops appearing.
Wire it up and prove it renders
Publish the SVG and the PEM first, confirm they serve correctly, then publish the TXT record. Verifying in that order means the first receiver to fetch your record already sees a working setup.
bash
# 1 · DNS record present and correct
dig +short TXT default._bimi.example.com
# 2 · SVG serves with the right type and no redirect
curl -sI https://example.com/bimi/logo.svg
# expect: HTTP/2 200
# content-type: image/svg+xml
# (no location: header, no 301/302)
# 3 · VMC serves and is a real PEM
curl -sI https://example.com/bimi/vmc.pem
# 4 · the cert carries the logotype extension and is in date
openssl x509 -in vmc.pem -noout -text | grep -A2 "1.3.6.1.5.5.7.1.12"
openssl x509 -in vmc.pem -noout -dates
Then send test mail to a Gmail account and an Apple Mail account. Yahoo, AOL, Fastmail and La Poste also honor BIMI. Gmail shows the logo as the sender avatar and reveals the checkmark when you tap the sender; Apple renders the logo in the message header on iOS 16+ and macOS Ventura+.
Set expectations on timing: this is hours to days, not minutes. DNS caches, receivers cache BIMI lookups, and Gmail's reputation gate can hold the logo back for a brand-new sending pattern even when every record validates. Do not conclude the setup is broken on day one.
Troubleshooting the usual failures
Gray initial, everything else looks fine → DMARC is at p=none, carries pct<100, or your sending reputation is too weak. Also check sp= on the org domain.
Logo ignored entirely → the SVG failed P/S validation (wrong profile, banned element) or is served with the wrong content-type. Re-run the BIMI Group validator and curl -sI.
Apple shows the logo, Gmail has no checkmark → you published a CMC, not a VMC. Only a VMC earns Gmail's blue mark.
Intermittent rendering → a redirect on the l= or a= host, or expired/misconfigured TLS there. Some fetches hit a healthy edge node, others do not.
Was working, now gone → the SVG was edited after the VMC was issued, so the logotype hash no longer matches. Reissue the certificate against the new file, or restore the exact published byte stream.
Deployment checklist
DMARC published at p=quarantine or p=reject, no pct<100, sp= verified on the org domain.
SPF and DKIM both passing and aligned to the From: domain across every real sending source.
Logo is a registered trademark for a VMC — granted, not pending.
SVG converted to SVG Tiny P/S: version="1.2", baseProfile="tiny-ps", square viewBox, a <title>, no banned elements, solid background, under 32KB.
SVG passes the BIMI Group validator, not just xmllint.
Both SVG and PEM hosted over HTTPS with valid TLS, no redirects, image/svg+xml on the SVG.
VMC (or CMC) obtained; renewal reminder set for the annual re-validation.
TXT record at default._bimi with correct v=, l=, a= syntax.
Post-publish verification done: dig, curl -sI on both URLs, openssl x509 confirming the logotype extension and validity dates.
Test mail sent to Gmail and Apple Mail, logo confirmed rendering — with patience for the reputation and propagation lag.
