Deliverability · How-to

BIMI Setup: Publishing Your Verified Logo, Step by Step

This is the hands-on companion to the broader BIMI adoption picture: where that piece covers which inboxes display logos and whether a certificate is worth it, this one walks the actual implementation, command by command. The order matters, because each step gates the next — a perfect logo and certificate do nothing if your DMARC policy is still at p=none. Work top to bottom and you avoid the dead-ends that send people in circles.

What BIMI setup involves, end to end

Before the steps, hold the whole shape in your head. BIMI is a chain of dependencies: authentication has to pass, DMARC has to be at enforcement, the logo has to be a specific kind of SVG, the certificate (if you want one) has to be assembled and hosted, and the DNS record has to tie the pieces together with exactly the right syntax. A mailbox provider walks that chain on receipt, and if any link is missing it simply shows no logo rather than telling you why.

That is why setup is less about any single hard step and more about doing five ordinary steps in the right sequence and then validating each link before moving on. The realistic timeline is dominated by one step — DMARC enforcement — which is a project in itself; the remaining work is typically an afternoon once enforcement holds. Budget your effort accordingly, and resist the urge to publish the BIMI record before the foundation under it is solid.

Step 1: Get SPF and DKIM right for every sender

BIMI rests on DMARC, and DMARC rests on SPF and DKIM, so this is where you start. Inventory every system that sends mail as your domain — your marketing platform, transactional provider, CRM, helpdesk, invoicing tool, and any one-off scripts — because each must authenticate or it will fail once you enforce. For each sender, confirm SPF authorises its sending hosts and DKIM signs its mail with a published key, and crucially confirm alignment: the domain in the SPF or DKIM check must match the visible From domain that DMARC evaluates.

Get this wrong and the symptom appears two steps later as a BIMI logo that never shows, because DMARC quietly fails alignment even though mail still delivers. Read your DMARC aggregate reports — the rua address you will set next — to see every source sending under your domain, including the ones you forgot about. A single unaligned but legitimate sender is enough to keep you from enforcement, so resolve them all before moving on.

Pay particular attention to subdomains and third-party services that send “on behalf of” you. A help-desk tool mailing from a vendor’s infrastructure, or a marketing platform using a dedicated sending subdomain, each needs its own aligned SPF and DKIM, and BIMI’s enforcement requirement applies to those sending subdomains too. Map every From domain and subdomain you actually use, and confirm each one passes DMARC in its own right — gaps here are exactly what surface later as a logo that shows for some streams but not others.

Step 2: Move DMARC to enforcement

This is the step that takes weeks, and rushing it is how organisations block their own mail. Start with a monitoring policy, p=none with an rua reporting address, and leave it long enough to see a full picture of your senders — typically a few weeks. Use those reports to drive each sender to alignment, then tighten the policy in stages: from p=none to p=quarantine, often with a partial pct at first, and finally to your target. BIMI requires the policy at full strength, meaning p=quarantine or p=reject applied to all mail.

Two details matter for BIMI specifically. The percentage must be pct=100 — a partial percentage does not satisfy the requirement — and the enforcement has to hold on both the organisational domain and any subdomain you send from, with consistent alignment. For most teams this whole step runs six to eight weeks of careful tightening. It is worth doing for its own sake, since enforcement is what actually stops impersonators, and our DMARC enforcement rollout guide covers the staged sequence in detail. Do not publish a BIMI record until this is done.

How do you create a BIMI-compliant SVG logo?

The logo is not just any SVG — it must use the SVG Tiny PS (Portable/Secure) profile, which strips the features mailbox providers refuse to render or consider unsafe. In practice that means a square logo with no scripts, no external references, no animation, and a defined background, exported and then run through the Tiny PS conversion that tools and certificate vendors provide. The file is then hosted on your own web server over HTTPS, because the record will point to it by URL.

Gmail layers extra rules on top of the base specification, and they trip up otherwise valid files: the image must be a minimum of 96 by 96 pixels, and its dimensions must be declared in absolute pixels — width=“96” height=“96” — rather than relative values like width=“100%”. The logo should be centred within its square viewport for consistent rendering. Validate the SVG against the BIMI requirements with one of the free checkers before you go further; a logo that fails validation is the second most common reason a setup produces no visible result, after a non-enforcing DMARC policy.

A few practical notes save a second round trip. Start from a clean vector source rather than tracing a raster logo, since Tiny PS forbids embedded bitmaps. Strip metadata, editor cruft, and any <title> or external font references your design tool may have injected, because validators are strict about the profile. Keep the file small — a few kilobytes is normal — and flatten complex effects that the Tiny PS profile does not allow, like filters and gradients beyond the basics. If your logo is wider than it is tall, design a square variant specifically for BIMI rather than letting a provider crop it unpredictably; the inbox slot is square, and a logo built for it reads far better than one squeezed to fit.

Step 3: Decide on self-asserted, CMC, or VMC

Now choose how far you want display to reach, because that decides whether you need a certificate at all. The free option is self-asserted: publish the record with no certificate, and your logo displays on Yahoo, AOL, and Fastmail. It is the right first move for almost everyone — it proves your authentication and logo pipeline works at zero cost and no waiting. The limitation is that Gmail and Apple Mail ignore a self-asserted record entirely.

To reach Gmail and Apple you need a certificate. A Common Mark Certificate (CMC) requires only proof of twelve months of public logo use, is cheaper and faster, and works on Gmail — but without the blue checkmark, and not on Apple Mail, which accepts only a Verified Mark Certificate. A VMC requires a registered trademark, costs more and takes longer, and earns Gmail’s blue checkmark and Yahoo’s purple checkmark plus Apple display. Match the certificate to your audience: skip it if you are testing or mostly reach Yahoo, choose CMC if Gmail matters but you lack a trademark, and choose VMC if Apple and the verified checkmark are worth the cost. The adoption guide works through that decision in depth.

How do you assemble and host the certificate PEM?

If you obtained a VMC or CMC, the certificate authority — DigiCert or Entrust, the only issuers the BIMI Working Group recognises — gives you an entity certificate as a PEM file with your SVG logo embedded inside it. Your job is to assemble the full chain: append the intermediate CA certificate and then the root CA certificate to the entity certificate, in that issued order, into a single PEM file. Order matters; a chain assembled out of sequence will fail validation at the mailbox provider.

Host that combined PEM on your public web server over HTTPS, alongside (or instead of) the standalone SVG, and copy its URL — you will place it in the record’s a= parameter in the next step. Keep both the SVG and the PEM reachable without authentication, since providers fetch them anonymously. Note the renewal date in your calendar now: certificates are annual, and an expired PEM silently drops your logo from Gmail and Apple the day it lapses.

What goes in the BIMI DNS record?

The record itself is a single DNS TXT entry, published at the default._bimi selector under your domain — for example, the host default._bimi.example.com. Its value declares the BIMI version, the logo location, and optionally the certificate location. The minimal self-asserted form carries just the version and the logo; the full form adds the certificate URL that unlocks Gmail and Apple.

# Self-asserted (free): logo only, no a= parameter
default._bimi.example.com.  IN TXT  “v=BIMI1; l=https://example.com/bimi/logo.svg;”
 
# Full record: adds a= pointing to the assembled VMC/CMC PEM
default._bimi.example.com.  IN TXT  “v=BIMI1; \
   l=https://example.com/bimi/logo.svg; \
   a=https://example.com/bimi/mark.pem;”
 
# v=  BIMI version (always BIMI1)
# l=  HTTPS URL of the SVG Tiny PS logo  (required)
# a=  HTTPS URL of the certificate PEM   (omit = self-asserted)

Three syntax points cause most record errors. Use the exact default._bimi selector unless you have a deliberate reason to use a custom one (custom selectors require a matching header on your mail and are an advanced case). Both URLs must be HTTPS, not HTTP. And the value must be a single logical TXT string — if your DNS provider splits long records, make sure they are concatenated correctly rather than treated as separate records.

Step 4: Publish and validate the record

Publish the TXT record through your DNS provider, then verify the entire chain before declaring victory, because a record that resolves is not the same as a logo that displays. Confirm the record returns over DNS, that the SVG and PEM URLs are reachable and serve the right content types, and that DMARC actually passes for a real message. Only when all four links check out — authentication, record resolution, logo accessibility, certificate linkage — is the setup genuinely complete.

Mind DNS propagation while you test. Set a modest TTL on the record — an hour is reasonable — so that any correction you make during setup propagates quickly rather than lingering in resolver caches for a day. Remember that DNS propagation and BIMI display caching are two separate delays stacked on top of each other: the record can be globally resolvable within minutes while the provider still takes days to fetch, validate, and surface your logo. Confirm the DNS layer is correct first with a direct query, so that when you then wait on display you know you are waiting on the provider’s cache and not on a record that never propagated.

# 1. Does the record resolve at the default selector?
$ dig +short TXT default._bimi.example.com
“v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/mark.pem;”
 
# 2. Is the SVG actually reachable over HTTPS?
$ curl -sI https://example.com/bimi/logo.svg | grep -i “200\|content-type”
HTTP/2 200
content-type: image/svg+xml
 
# 3. Does the PEM chain parse, and how many certs are in it?
$ openssl crl2pkcs7 -nocrl -certfile mark.pem | openssl pkcs7 -print_certs -noout | grep -c subject=
3        <- entity + intermediate + root, as expected
 
# 4. Confirm DMARC passes on a real test send (read the headers)
Authentication-Results: mx.google.com; dmarc=pass (p=REJECT) header.from=example.com

How do you verify the logo actually displays?

DNS and certificate checks confirm the plumbing; only a real test send confirms the result. Send a message to live accounts on each provider that matters to you — a Gmail account, an iCloud or Apple Mail account, and a Yahoo account — and look at the inbox list and the opened message for your logo. Test from the actual sending systems you use in production, not a one-off SMTP client, so that the DMARC alignment you validated holds for your real mail flow.

Set expectations on timing: providers cache BIMI results, so a correct setup can take a few days to show rather than appearing instantly, and a logo that is absent an hour after publishing is not necessarily broken. If it has not appeared after several days, move to troubleshooting rather than republishing the record repeatedly. Free BIMI inspector tools will also render a preview and flag specific failures, which is faster than guessing from an empty inbox.

Troubleshooting: when the logo won’t appear

Almost every failure traces to a short, ordered list, and because later links depend on earlier ones, check them in order. First, DMARC: confirm it is genuinely at p=quarantine or p=reject with pct=100, since a lingering p=none blocks display everywhere. Second, alignment: read real message headers to confirm DMARC passes via aligned SPF or DKIM against your visible From domain — mail can deliver while alignment quietly fails. Third, the SVG: revalidate it against the Tiny PS profile and Gmail’s 96-pixel absolute-dimension rule, since a file with scripts, external links, or relative sizing gets refused.

Fourth, the record mechanics: verify the default._bimi selector, the exact logo and PEM URLs, and that the certificate chain is assembled in the right order. If you are testing on Gmail without a certificate, remember that is expected behaviour — Gmail ignores self-asserted records and shows a sender initial instead. And if you are testing on Outlook and seeing nothing at all, that is also expected: Microsoft does not support BIMI yet, so no configuration on your side will produce a logo there. Once the logo is live, keep the foundation healthy — monitor DMARC reports as your sender mix changes, and treat your wider sending hygiene, including bounce classification and complaint handling, as the ongoing work that protects the authentication BIMI depends on. The same fundamentals overlap heavily with the Gmail and Yahoo sender requirements, and owning your sending infrastructure makes keeping all of it aligned considerably easier.