Key takeaways
- BIMI (Brand Indicators for Message Identification) displays a verified brand logo next to mail that already passes DMARC with an enforced policy — it does not move mail out of spam by itself.
- Gmail’s via label appears when the visible
From:domain does not match the domain that authenticated the message (usually unaligned DKIM). Fix custom DKIM / return-path alignment; do not buy a VMC to clear “via”. - Most BIMI programs require DMARC at
p=quarantineorp=reject(Gmail also expectspct=100). Finish SPF, DKIM, and DMARC before logo work. - Gmail’s documented BIMI path expects a Verified Mark Certificate (VMC) or Common Mark Certificate (CMC) — plan for trademark lead time if you want the checkmark experience.
- For early-stage transactional senders, aligned authentication and clean reputation beat BIMI. Add BIMI when brand recognition in the inbox is a product requirement, not when placement is broken.
Two inbox decorations confuse operators more than almost any other email topic. One is a brand logo beside the sender name. The other is a small grey via some-provider.com next to the address. They look related. They are not the same system, they do not share a fix, and chasing the wrong one wastes weeks.
BIMI is the logo standard: publish a DNS record pointing at a qualifying SVG (and often a mark certificate), after DMARC is enforced. Supporting clients may then show your mark on authenticated mail. Via is Gmail’s (and sometimes other clients’) way of saying “this message claims to be from your domain, but the cryptographic identity that checked out belongs to someone else.”
This guide is for product and engineering teams sending transactional mail — password resets, receipts, alerts — who need a clear order of operations. Pair it with the authentication setup guide and the spam diagnostic guide when placement is the real problem.
What is BIMI email?
BIMI stands for Brand Indicators for Message Identification. It is an industry specification (see the BIMI Group) that lets mailbox providers display a brand’s logo next to messages that are already authenticated under DMARC. The AuthIndicators community includes major mailbox providers and security vendors; adoption is uneven by client, but Gmail, Yahoo, and others have public documentation for senders.
Mechanically, BIMI is a DNS TXT record at default._bimi.yourdomain (selector default is the common case). The record asserts a logo URL (l=) and optionally an authority evidence URL (a=) for a mark certificate. When a supporting client receives mail that passes DMARC for your domain, it may fetch and render that logo.
What BIMI is not: a substitute for SPF or DKIM, a reputation booster, or a guarantee that every recipient will see a logo. Clients that do not implement BIMI simply ignore the record. Clients that do implement it still apply their own trust and certificate rules.
BIMI logo vs the Gmail “via” label
Operators often search “via email Gmail” after a customer forwards a screenshot: Acme <noreply@acme.com> via sendgrid.net (or amazonses.com, mailgun.org, a bounce domain, and so on). That label is not BIMI failing. It is Gmail showing that the visible author domain and the authenticating domain disagree in a way Gmail chooses to surface.
In the common ESP case, the message From: is your brand, but DKIM was signed with the provider’s default domain (d=sendgrid.net) instead of yours. SPF may even pass against the provider’s bounce domain. Cryptographically the message is fine — it just is not aligned to your brand domain the way DMARC and Gmail’s display logic expect.
| Signal | What the user sees | What it usually means | Fix |
|---|---|---|---|
| BIMI logo | Your square brand mark beside the sender | DMARC enforced + BIMI DNS (+ often VMC/CMC) | Finish auth, then publish BIMI assets |
| Gmail via | via provider.example next to From | Author domain ≠ authenticating domain (often unaligned DKIM) | Custom DKIM on your domain + aligned return-path |
| Google profile image | Logo without BIMI DNS | Workspace / profile workaround — not BIMI | Do not confuse with BIMI security properties |
Clearing via is an authentication-alignment project. Publishing BIMI is a brand-presentation project that presupposes that alignment already works. If you buy a VMC while still showing via provider, you are spending money on the wrong layer.
On SuperSend TX, domain setup is designed so DKIM signs under your domain and a return-path CNAME keeps SPF alignment with the From: you send as — the same ingredients that remove via and unlock DMARC enforcement. Details live in the domains API and the SPF/DKIM/DMARC guide.
Prerequisites before any BIMI DNS
Every serious BIMI checklist starts the same way: BIMI only applies to mail that already passes DMARC. If DMARC fails or is stuck at p=none, logo work is premature.
- 1
SPF and DKIM that can align
Authorize your sending infrastructure in SPF without exceeding the ten-lookup limit, and sign DKIM with a
d=domain that aligns with your visibleFrom:domain. Prefer your own domain’s DKIM over a provider default. - 2
DMARC monitoring, then enforcement
Publish DMARC with a monitored
rua=mailbox. Movep=none→p=quarantine→p=rejectonly when aggregate reports show legitimate sources are aligned. BIMI expects enforcement — typicallyp=quarantineorp=reject. - 3
Full coverage for the domain
Gmail’s BIMI documentation expects DMARC
pct=100so the policy applies to all mail from the domain. Partial rollout (pct=10) is fine while learning, but it is not a BIMI end state. - 4
Then logo + certificates
Only after enforcement is stable should you invest in SVG Tiny PS artwork, hosting, and mark certificates for providers that require them.
How to implement BIMI (operator checklist)
Once DMARC is enforced, BIMI implementation is mostly asset and DNS work. Exact certificate products change over time; treat CA portals and Google’s BIMI setup guide as the live source for Gmail-specific rules.
- Produce a square logo as SVG Tiny PS (BIMI profile) — no scripts, external refs, or animations; keep file size small (Gmail recommends ≤32 KB and absolute pixel dimensions ≥96×96)
- Host the SVG (and certificate PEM if required) on HTTPS with a valid TLS chain
- Obtain a VMC (trademarked mark) or CMC where your target clients require evidence — Gmail documents both paths; VMC is the stronger / checkmark-oriented option
- Publish TXT at
default._bimi.example.com:v=BIMI1; l=https://…/logo.svg; a=https://…/certificate.pem(omit or adjusta=only when a client path allows SVG-only — Gmail’s primary path expects certificates) - Send test mail to supporting clients and allow DNS/cache time (hours to a couple of days)
- Re-check DMARC reports after go-live so a new marketing tool does not silently break enforcement
Example BIMI TXT (illustrative)
default._bimi.example.com. TXT "v=BIMI1; l=https://cdn.example.com/bimi/logo.svg; a=https://cdn.example.com/bimi/vmc.pem"- · Selector default covers typical mail. Do not invent multiple selectors until you have a real multi-brand reason.
- · SuperSend TX domain detail includes best-effort BIMI analysis after DNS verify — guidance only; we do not issue VMCs.
Decision tree for transactional teams
Not every product should chase BIMI in the same quarter they ship password resets. Use this tree.
| Situation | Do this | Skip for now |
|---|---|---|
| Mail shows via provider / DMARC failing | Fix aligned DKIM + return-path; finish DMARC rollout | BIMI, VMC, logo redesign |
| Auth green, spam issues remain | Reputation, list hygiene, spam diagnostics | BIMI (still not a placement fix) |
| Auth enforced, brand wants inbox recognition | SVG + BIMI DNS; evaluate VMC/CMC for Gmail | Nothing — this is the BIMI use case |
| No trademark, early stage, low volume | Keep DMARC healthy; optional SVG-only clients if any | Expensive VMC until trademark/legal is ready |
Banks, marketplaces, and consumer brands with phishing risk get more anti-abuse value from BIMI than a B2B SaaS sending three transactional templates. That does not mean SaaS should ignore it forever — it means sequence matters.
When this advice does not apply
If you operate your own mail servers end-to-end and already display logos through client-specific mechanisms, BIMI may still be worth adding for portability — but your ops runbook will differ from an API customer’s.
If your “logo in Gmail” already comes from a Google account profile image or annotations, that is not BIMI. It will not travel to Yahoo the same way, and it does not prove DMARC enforcement. Do not treat it as a substitute when security reviewers ask for BIMI.
If the product is cold outbound or purchased lists, stop. BIMI will not rehabilitate that traffic, and DMARC enforcement will correctly make spoofed/unauthorized streams harder. Transactional providers (including SuperSend TX) are the wrong tool for that job anyway.
How this maps on SuperSend TX
Adding a sending domain generates ownership, DKIM, return-path, SPF, and starter DMARC records so alignment is achievable without fighting a provider-default signature. After verify, domain detail includes best-effort DMARC and BIMI analysis with guidance — whether a BIMI record exists, logo URL if present, and whether enforcement is still required.
We do not sell mark certificates or host your BIMI SVG as a managed product. That work stays with your brand/legal and DNS. What we own is the transactional mail path underneath: Pool for production transactional reputation, Dedicated when you need managed servers and IPs.
- Verify the domain in the dashboard or via the Domains API
- Confirm test mail in Gmail shows no unwanted via label
- Monitor DMARC aggregate reports until enforcement is safe
- Only then publish
default._bimiand certificate URLs
Authenticate first. Logo second.
Verify a domain on SuperSend TX with DKIM under your name and an aligned return-path — then use dashboard BIMI guidance when you are ready for the logo layer.
Related reading