Understanding the Significance of BIMI Selectors and Their Implementation

Brand Indicators for Message Identification (BIMI) is a developing email protocol that allows domain owners to put their logos next to emails sent to participating mailbox providers.

Most domain owners that participate in BIMI use just one default logo, but BIMI permits the specification of conditional use of other logos by using what’s known as BIMI selectors.

Learn how to use these BIMI selectors and which use cases make the most sense.

BIMI Basics

To fully participate in BIMI and enable the display of one logo for all of its mail, a domain owner must do all of the following:

• Configure DMARC at enforcement for its organizational domain.
• Configure DMARC at enforcement for its sending domain(s) (the domain(s) shown in the visible From header of its email) if different from the organizational domain.
• Decide on a logo that the domain owner wishes to have displayed next to its email and generate a representation of this logo in a specific graphical format (SVG Tiny/PS). The domain owner usually trademarks this logo, but there are circumstances where a trademark is not required. The file in which this representation is stored is called an “Indicator File.”
• Secure a Mark Certificate (formally called a “BIMI Evidence Document”) from a Mark Verifying Authority. This document attests to the domain owner’s right to use the logo.
• Publish a TXT record at a specific location in the DNS that references the Indicator File and BIMI Evidence Document.

An example DNS TXT record for the domain “example.com” with its logo stored online at https://cdn.example.com/bimi/logos/exampleCom.svg and its Mark Certificate stored at https://cdn.example.com/bimi/certs/exampleCom.pem would look like this:

default._bimi.example.com IN TXT “v=BIMI1; l=https://cdn.example.com/logos/exampleCom.svg; a=https://cdn.example.com/bimi/certs/exampleCom.pem;”

BIMI Selectors

Just like DomainKeys Identified Mail (DKIM) before it, BIMI supports the use of selectors. Like DKIM, the selector is the leftmost label of the DNS name where the information is published. A DKIM public key published at the name “s1._domainkey.example.com” has the selector name “s1”, while a BIMI record published at “default._bimi.example.com” has the selector name “default”.

DKIM’s selectors are used for publishing multiple public keys for use in signing email, perhaps by different sending entities, while BIMI’s selectors are intended to be used to allow a domain owner to use different logos with the same domain name or brand. 

One key difference between DKIM and BIMI is that the draft BIMI protocol spec mandates a default selector name for BIMI – specifically, “default”. A domain owner participating in BIMI will go through the steps outlined above and typically publish their BIMI DNS record using the “default” selector. Doing so requires no alteration to their email content and is the easiest way for a domain owner to gain the benefits of BIMI. 

Using the default selector also makes it easy for a brand to know whether or not other brands in its vertical are participating in BIMI, as the brand can just issue a DNS query for a known name to see if a record exists.

How To Implement BIMI Selectors

The first step to using BIMI selectors is for a domain owner to publish a BIMI DNS record that references an Indicator File and a BIMI Evidence Document that differ from those referenced by the default record. In nearly all cases (see below), this will mean generating an Indicator File for a different logo and securing a different Mark Certificate. To illustrate, the domain example.com might publish the following two records in DNS:

default._bimi.example.com IN TXT “v=BIMI1; l=https://cdn.example.com/logos/exampleCom.svg; a=https://cdn.example.com/bimi/certs/exampleCom.pem;”

altLogo._bimi.example.com IN TXT “v=BIMI1; l=https://cdn.example.com/logos/altExampleCom.svg; a=https://cdn.example.com/bimi/certs/altExampleCom.pem;”

For these two logos, the first has the selector “default”, while the selector for the second is “altLogo”.

The second step for using BIMI selectors is for the domain owner to reference the non-default selector in the email it sends. This referencing is done by inserting a header into every message for which the domain owner wants to use the non-default logo. The header is named “BIMI-Selector” and has two values – The BIMI version (BIMI1) and the selector name. A typical use would look like this:

From: sales@example.com
BIMI-Selector: v=BIMI1; s=altLogo;

This BIMI-Selector header, along with the From header shown here, would instruct a BIMI-participating mailbox provider to look in DNS at the label “altLogo._bimi.example.com” for a record containing the necessary information to show a logo with this message. 

NOTE: A BIMI-Selector header is unnecessary if the selector is “default”. Mailbox providers that support BIMI will always look at “default._bimi.domainName” for a BIMI record if no BIMI-Selector header appears in the message.

The last step for the domain owner is to not only insert the BIMI-Selector header in messages, but also to include that header in the DKIM-Signature. This means that the h= tag in the DKIM-Signature header must include “BIMI-Selector” in the list of headers, and the contents of the header must be included in the calculation of the hash that is calculated as the value of the b= tag in the DKIM-Signature.

Why Implement BIMI Selectors?

There are two main reasons for implementing BIMI selectors.

1. Alternate Logos

The first use case is a domain wishing to use an alternate logo for a particular mailing, perhaps because of a holiday or other occasion. Rather than changing the primary BIMI DNS record to temporarily point to the alternate Indicator File and BIMI Evidence Document, the domain would publish a different DNS record and add the proper headers described above.

The domain could then send the special holiday-themed campaign and be confident in the knowledge that the alternate logo was only shown for that campaign at mailbox providers that participate in BIMI and support selectors in this fashion.

2. A/B Testing

The other use case involves a domain wanting to do A/B testing, perhaps either with a new primary logo or just to see whether BIMI is providing a worthy return on investment through a lift in engagement. The method for testing an alternate primary logo is identical to the “Alternate Logos” use case above; the method for testing BIMI’s ROI relies on a special BIMI DNS record.

The BIMI specification includes a special record called a “declination to publish” record, the value of which looks like this:

“v=BIMI1; a=; l=;”

Such a record can be deployed for A/B testing as follows:

1. Publish a “declination to publish” record at “default._bimi.example.com”.
2. Publish an alternate BIMI record at any other selector, e.g., “bimiLogo._bimi.example.com”.
3. Perform A/B testing, with one cohort having no BIMI-Selector header, and the other having the BIMI-Selector header referencing the “bimiLogo” selector.
4. Compare results from the two campaigns using standard engagement measuring metrics.

Set Up BIMI

Are you ready to unlock the power of BIMI and experiment with your BIMI selectors? Amplify is your fast track.