A smartphone showing a list of emails with company logos next to each message.đź…­

Get your logo into inboxes with BIMI and email best practices

The new Brand Indicators for Message Identification (BIMI) internet standards draft lets businesses display their logos next to their emails (as the sender/contact photo). The new standard is developed as a carrot to incentivize the adoption of existing email-sender best practices and verification schemes. Is a slight increase in branding prominence enough to push the email ecosystem towards adopting stricter email-sender policies?

Email sender verification has been an all-sticks game where senders have been beaten over the head by recipients (delivered to Spam or rejected) if they fail to comply with sender-verification schemes. These schemes include Domain-based Message Authentication, Reporting, and Conformance (DMARC); Sender Policy Framework (SPF); and DomainKeys Identified Mail (DKIM).

To comply with these email standards, you must maintain records that precisely describe which servers are allowed to send emails on behalf of your domain. These descriptions are stored as machine-readable records in the Domain Name System (DNS). In the case of DKIM, you must also commit to cryptographically signing every outgoing message.

BIMI is a new addition to the DNS record acronym soup. It puts aside the stick and offers senders a carrot instead. In exchange for configuring your domain with a strict DMARC policy built on SPF or DKIM (or both), you might have your brand’s logo show up next to your messages in recipient inboxes. The logo shows up in a square or round frame next to the message sender’s name; a spot typically reserved for contact photos from your address book.

The exact technical requirements for a BIMI logo to be displayed are up to the recipient mailbox provider or client application (e.g. Google Mail or Thunderbird). The BIMI specification outlines a set of requirements, but the enforcement is left entirely up to the recipient. Senders should aim to meet as many requirements as possible with as strict policies as achievable for the best chance of having their logos displayed.

FastMail and Pobox (collectively FastMail), Google Mail (GMail), and Yahoo! Mail and AOL Mail (collectively YMail) are on board with their web and mobile apps. YMail will show brand logos for bulk senders with a good sender reputation. FastMail hasn’t documented its BIMI policies, but appears to show BIMI logos for anyone that meets the basic requirements.

GMail is, as always, different. In addition to strict email sending policies, it also requires a Verified Mark Certificate (VMC) signed by a Certificate Authority (CA). A VMC is a digital file that confirms that the CA has verified that the logo is a registered trademark and that the domain in question is its rightful owner. The BIMI specification includes a framework for communicating this information to email recipients.

GMail’s VMC requirement introduce a significant legal, cost, and geographical restriction to BIMI adoption within its ecosystem. The BIMI specification can be abused to make scams look more legitimate. VMCs also raise the bar for scammers, so that not just any domain can claim its logo is the same as your bank’s or PayPal’s. However, a VMC is no guarantee of your logo being displayed — as outlined in the article VMCs Aren’t a Golden Ticket for BIMI Logo Display.

However, I believe that evaluating the sender’s reputation and the permanency of their DMARC policies and BIMI logo is the better approach that works at internet scale. This seems to be the approach YMail has adopted.

Ideally, recipients should retain records of the current and historical logos of high-profile targets like PayPal, banks, and cryptocurrency wallets and exchanges. They could then use this information to identify scams by looking for BIMIs from other domains that match or closely match these logos. It could be used as a tool to fight scams and not just enable them.

Google has a history of outsourcing the responsibility of verifying third parties to CA organizations with the introduction of new (and expensive) special-purpose digital certificates. The Signed HTTP Exchanges Certificate (CanSignHttpExchanges) extension comes to mind.

Microsoft Outlook, 1&1, Apple Mail, and Mail.ru are notable mailbox providers that don’t yet support BIMI. Microsoft has its own business-to-business program for getting brand indicators into its customers’ mailboxes. Unlike BIMI, Microsoft’s scheme requires senders to establish relationships with individual mailbox providers.

In addition to these large email providers, BIMI is supported by the FairMail email client app for Android. It’s off by default in the app, but users can enable BIMI indicators with any standard mailbox provider. The independent implementation verifies that BIMI isn’t just relevant for large mailbox providers. There are notably no plugins for the popular Roundcube or Thunderbird email clients.

BIMI allows for a domain-wide default logo or senders can suggest other logos by including a selector header in email messages (BIMI-Selector). This enables you to give your support desk, order updates/receipts, newsletter, and promotional emails different variations of your company logo. Or maybe something silly like changing the indicator to one with your logo featuring a Santa hat during Christmas.

Overly unique BIMI selectors could potentially be used to track whether a specific user has viewed the message or not. Mailbox providers can thwart this by proxying every request for a BIMI whether the mailbox exists or not. This way, BIMIs can’t be abused to check for active mail addresses no read confirmations.

These types of abuse are, probably, why YMail requires a certain volume of email before they allow BIMIs to load. Email apps like FairMail that can’t track sender-reputation at scale (since it only serves one person’ mailbox), so they can’t make reputation-based decisions on when to load BIMIs.

I surveyed the top 3 million domain names (according to Tranco list W9VK9) on and found that 6647 domains have published a default BIMI selector. I’ll write a follow-up article and more closely analyze the results of this survey next week.

Let me know in the comments if you see Ctrl blog’s BIMI in the newsletter! Not subscribed yet? Sign-up now, so you don’t miss my follow-up article where I examine BIMI adoption (and common mistakes) across the web!