DNS & Domain Setup

BIMI Setup — Show Your Logo in Gmail (and Beyond)

BIMI (Brand Indicators for Message Identification) shows your verified logo next to your messages in Gmail, Yahoo, Apple Mail. Recipients see brand trust at glance — open rates measurably rise. This guide walks the prerequisites + the setup.

March 1, 2026 7 min read Advanced

What BIMI does + why it matters

BIMI shows your verified brand logo next to your messages in supporting inboxes. Recipients see your logo (not the generic envelope icon) before they open. The effect:

Open rate lift of 7-15% measured across multiple senders (Yahoo published case study; matches our customer reports)
Trust signal — receivers learn "this is the real brand" at glance
Phishing resistance — fake-brand emails can't display the real logo

Supported clients (as of 2026): Gmail (US/EU), Yahoo, Apple Mail (iOS 16+, macOS Sequoia+), Fastmail. Microsoft / Outlook implementation is in pilot.

The 4 prerequisites

Prerequisite	Required state
DMARC at p=quarantine or p=reject	Not p=none. Receivers won't show BIMI if your DMARC is in monitor-only mode.
SVG-formatted logo	SVG Tiny PS profile (a specific BIMI variant). Most agency logos need re-exporting.
DNS record for BIMI	TXT record at `default._bimi.yourdomain.com`
VMC (Verified Mark Certificate)	Required for Gmail; optional for Yahoo / Apple. ~$1500/yr per domain from Entrust or DigiCert. See BIMI with VMC cost walkthrough.

If you don't have all 4, BIMI won't display. Start with DMARC enforcement → SVG export → DNS record → VMC (if going to Gmail).

Step 1: Confirm DMARC enforcement

Open your sending-server detail and verify DMARC chip is Green:

The auth chips on the sending-server detail

Open Settings → Sending servers → click your active server. The toolbar shows the live SPF / DKIM / DMARC chip status:

Sending server detail with auth chips

Green chips on all three = receiving servers can confirm you're authorized to send from this domain.
Any chip red = receiving servers immediately downgrade reputation. Click Verify domain in the toolbar to walk through the DNS-fix wizard.

Your DMARC policy must be p=quarantine or p=reject (NOT p=none). Check with:

dig TXT _dmarc.yourdomain.com +short
# Look for: v=DMARC1; p=quarantine; rua=...
#       or: v=DMARC1; p=reject; rua=...

If still on p=none, see DMARC enforcement migration for the staged progression.

Step 2: Export your logo as BIMI-compatible SVG

BIMI requires SVG Tiny 1.2 Portable Secure (SVG Tiny PS). Standard SVG won't work — Gmail/Yahoo will reject.

Constraints:

Aspect ratio: 1:1 (square)
No scripts (no <script> tags)
No external font references (embed paths instead)
No <image> elements with external URLs (embed inline base64 if needed)
Single XML element root
Total file size <32KB

Most agency-exported logos need rework. Either:

Ask your designer to re-export as SVG Tiny PS (most adobe-illustrator users handle this with the right preset)
Use a BIMI logo conversion service (Entrust + DigiCert both offer paid prep services)
Self-validate via the BIMI Inspector — free online tool

Host the SVG at a publicly-accessible URL on your domain, e.g. https://yourdomain.com/bimi/logo.svg.

Step 3: Publish the BIMI DNS record

At your DNS host, add:

Type:  TXT
Name:  default._bimi.yourdomain.com
Value: v=BIMI1; l=https://yourdomain.com/bimi/logo.svg; a=https://yourdomain.com/bimi/vmc.pem
TTL:   3600

Two parameters:

l= — the URL of your SVG logo (Step 2)
a= — the URL of your VMC certificate (Step 4; OPTIONAL for non-Gmail)

If skipping VMC (Yahoo / Apple only): omit the a= parameter:

v=BIMI1; l=https://yourdomain.com/bimi/logo.svg

Step 4: Get a VMC (for Gmail support)

VMC = Verified Mark Certificate. Issued by Entrust (~~$1500/yr) or DigiCert (~~$1500/yr). Required for:

Gmail (US/EU)
Yahoo (recommended; not strictly required)
Apple Mail (recommended; not strictly required)

Process: trademark verification (your logo must be a registered trademark in your jurisdiction). 4-8 weeks from application to issued certificate.

After issuance:

Host the VMC at https://yourdomain.com/bimi/vmc.pem (or any URL on your domain)
Add the a= parameter to your BIMI DNS record

Step 5: Verify in Gmail

Send a test email to a Gmail address you control. After ~30 seconds (Gmail's BIMI lookup cache), open the message — your logo should appear in the sender column.

If not appearing:

Check DMARC pass at receiver (open "Show original" → look for "DMARC: PASS")
Verify BIMI DNS record is published: dig TXT default._bimi.yourdomain.com +short
Verify SVG is publicly accessible: curl -I https://yourdomain.com/bimi/logo.svg
Verify VMC is publicly accessible (if going Gmail): curl -I https://yourdomain.com/bimi/vmc.pem
Wait 1-2 hours — Gmail's BIMI cache takes time to refresh on first publish

Common UI signals + fixes

Symptom	Likely cause	UI fix
BIMI DNS record published but logo not showing	DMARC still at p=none	DMARC must be quarantine/reject
Some Gmail recipients see logo, others don't	Cache propagation in progress	Wait 24-48h; verify your test recipient's Gmail account isn't cached
Logo appears in Yahoo/Apple but not Gmail	Missing VMC	Apply for VMC via Entrust or DigiCert
SVG file 404s	Hosted at wrong path	Confirm public access: `curl -I https://yourdomain.com/bimi/logo.svg` returns 200
SVG file accessible but Gmail says "BIMI logo invalid"	Not SVG Tiny PS format	Re-export with the BIMI-compatible profile; validate via bimigroup.org
Logo appears for some campaigns but not others	Different sending domains used per campaign — check BIMI record on each	Each unique From: domain needs its own BIMI record

Cost-benefit math

Cost	Benefit
VMC: $1500/yr	10% open rate lift on Gmail (largest share of B2C email)
DesignerSVG rework: 2-4 hours	One-time cost
DNS record setup: 30 min	One-time cost
Trademark application (if not yet registered): $250-$2000	Required for VMC anyway; useful for brand protection
Ongoing maintenance: minimal	Just renewal of VMC each year

For a list of >100k subscribers, BIMI typically pays back within 3-6 months from incremental open rate alone.

Advanced: multi-subdomain BIMI, fallback patterns, and BIMI without VMC limits

Per-subdomain BIMI:

If you send marketing from mail.brand.com and transactional from txn.brand.com, each subdomain needs its own BIMI record:

TXT default._bimi.mail.brand.com    "v=BIMI1; l=https://yourdomain.com/bimi/marketing-logo.svg"
TXT default._bimi.txn.brand.com     "v=BIMI1; l=https://yourdomain.com/bimi/txn-logo.svg"

Different logos per subdomain if branding requires (e.g. marketing logo vs corporate logo).

Selector-based BIMI for fine-grained control:

TXT selector._bimi.brand.com  "v=BIMI1; l=https://.../variant-a.svg"

In your AcelleMail email headers, set:

BIMI-Selector: selector

Receivers query the matching DNS record. Allows A/B testing different BIMI logos.

BIMI without VMC — supports Yahoo + Apple Mail; NOT Gmail. Some senders skip VMC initially to get partial adoption + revisit Gmail-VMC after measuring impact:

TXT default._bimi.brand.com  "v=BIMI1; l=https://yourdomain.com/bimi/logo.svg"

Result: Yahoo + Apple display the logo; Gmail shows the default initial-letter circle.

SVG accessibility checklist:

✅ Single root <svg> element
✅ viewBox attribute set (e.g. viewBox="0 0 64 64")
✅ Aspect ratio 1:1
✅ <title> element for accessibility
✅ No scripting
✅ No external resources
✅ <32KB total

Multi-region BIMI — Gmail caches the DNS lookup per-domain globally; can't serve different logos per region from one BIMI record. If you need per-region logos, use selector-based BIMI (above) with per-region selector values in email headers.

Performance impact — BIMI lookup adds ~50-100ms latency at receive time. Gmail caches aggressively after the first lookup. For high-volume senders this is invisible.

Tagged

Acellemail

10 comments

Join the conversation. Comments are open to AcelleMail community members.

Create an account Sign in

Anna 3 months ago

Our DKIM rotation broke for 2 days because we updated the active selector first, then waited to delete the old. Should be the other way — publish new, wait 48h for cache, switch sending, THEN remove old.

2
Priya 4 months ago

What's your recommendation for sub-domains? We send from mail.example.com AND notifications.example.com. Same DKIM selector or separate?

2
1. Admin 4 months ago
  
  Separate selectors, one per subdomain. There's no technical requirement to split them, but rotating or revoking a key for notifications.example.com without touching your transactional mail is worth the extra DNS record. Selectors are cheap. The part that actually bites people with subdomains is BIMI itself. The BIMI record is looked up at default._bimi.<the exact d= domain in the DKIM signature>, so mail.example.com and notifications.example.com each need their own TXT record. There's no inheritance from the org domain the way DMARC has sp=. Your VMC is issued for example.com and covers both, so you point both records at the same l= and a= URLs. Also check what you're aligning to. If both streams sign with d=example.com and just use different selectors, you only need the one BIMI record at the org domain. Which way you go depends on how you've set up the sending domain in the sending server config.
  
  0
Quân 2 months ago

Worth noting: our DNS provider (Cloudflare) caches negative responses for 1 hour. We added a TXT record, dig showed it, but mail-tester said missing for another 40 minutes. Almost lost our minds. TTL was set to 300 but the parent zone NS cache held. :)

0
1. Admin 2 months ago
  
  Negative caching is the part nobody warns you about. The TTL on your new record doesn't matter if a resolver already cached the NXDOMAIN for default._bimi, and that lifetime comes from the SOA minimum on the zone, not from the record you just added. Cloudflare's SOA minimum is 3600, hence your 40 minutes of staring at dig output that looked correct. Two things that help next time: query the authoritative nameserver directly (dig default._bimi.yourdomain.com TXT @ns1.yourprovider.com) to confirm the record is actually published, then treat any checker that disagrees as a cache issue rather than a config issue. mail-tester and most BIMI validators go through public resolvers, so they'll lag. I'll add a note about SOA minimum vs record TTL to the article, it belongs in the troubleshooting section right next to the "dig shows it but Gmail doesn't" bit.
  
  0
Chen 2 months ago

DNS setup is one of those things where you don't know what you don't know. This article should be required reading for anyone running their own mail.

0
Akira 3 months ago

How do you handle DNS for clients in white-label setups? The customer would need to add records to their domain — is there a clean way to bulk-verify those?

0
1. Admin 3 months ago
  
  There's no bulk BIMI verifier today. The sending domain screen checks records one domain at a time, and BIMI isn't part of that check anyway, it only looks at SPF/DKIM/DMARC. So for white-label you're on your own for the BIMI TXT lookup at `default._bimi.<their-domain>`. What people usually do is script it. `dig +short default._bimi.example.com TXT` in a loop over your customer list, then flag anything missing `v=BIMI1` or pointing at a URL that 404s. Worth checking the VMC PEM URL resolves too, Gmail will silently skip the logo if it doesn't. Fair ask though. A batch check across a customer's domains is a reasonable thing for us to add, and the DNS-lookup plumbing already exists for the DMARC check, so it's mostly UI. I'll put it on the list. If you build the script version first, happy to look at it.
  
  0
David 3 months ago

The SPF flattening explanation finally made it click for me. I'd been hitting the 10-lookup limit and didn't understand why nesting includes counted. tbh

0
Isabella 4 months ago

quick question: do receivers actually enforce the spf -all hard fail, or do most just downrate? i've heard mixed things and i'm hesitant to switch from ~all...

0
1. Admin 3 months ago
  
  Most feed it into DMARC and let your policy decide, so -all alone rarely bounces. BIMI doesn't need it either, just DMARC at quarantine/reject with SPF aligned. Stay on ~all.
  
  0
Daniel 4 months ago

Hit the 10-lookup SPF limit when we tried to layer SES on top of an existing Google Workspace setup. Flattened with a tool (spfwizard.com) and it's been fine since. That tool's worth a mention

0
Ahmed 4 months ago

thanks for the explicit cautionary tales. the alignment-vs-pass distinction is exactly where i lost a week last year.

0
1. Admin 4 months ago
  
  That distinction eats a lot of people, and BIMI is where it finally bites because nothing else in the stack cares. SPF can pass on a bounce domain that has nothing to do with your From header and every deliverability tool will show you a green check. Then you set p=quarantine, watch it hold, and assume you're done, but BIMI wants an enforced DMARC policy sitting on top of an *aligned* pass, and the logo just never appears with no error anywhere telling you why. The only reliable read is the DMARC aggregate reports, where the alignment columns are broken out per source. If you have a short write-up of what that week actually looked like, I'd fold it into the article as a worked example. The current caution section is a bit abstract for something this expensive to learn.
  
  0
Nadia 4 months ago

If you use Vercel or Netlify for the apex, watch out — they sometimes override TXT records via their auto-DNS feature. Bit us once with a stripped SPF record.

0
1. Admin 4 months ago
  
  Netlify's DNS in particular will happily rewrite the apex zone when you re-link a site, and TXT records are the first casualty. Same risk applies to the BIMI record itself since default._bimi is just another TXT, so if your logo silently stops showing in Gmail after a redeploy, check the record still exists before you go debugging the SVG or the VMC. Worth adding a note to the DNS section of this article, I'll do that.
  
  0