Using an idea borrowed from DomainKeys Identified Mail (DKIM), BIMI supports the use of selectors, which are intended to allow a brand to easily use different logos for the same domain. In this guide, we’ll explain BIMI selectors, discuss why a brand might want to use BIMI selectors and describe how to use them.
BIMI – Minimum Participation Requirements for Domain Owners
Any brand or domain wishing to participate in BIMI and have a logo displayed with email they send to BIMI-supporting mailbox providers, must do the following:
- Create an Indicator File that contains a graphical representation in a specific format of the logo to be used for BIMI. The Indicator File is commonly referred to as a logo.
- Optionally obtain a BIMI Evidence Document from a Certificate Authority that attests to the domain’s right to use a given logo. The Evidence Document is commonly called a VMC, after the first iteration of such documents, but other formats exist. Note: While the BIMI standard allows for a domain to “self-assert” its right to use a given logo, most mailbox providers that support BIMI require that domain owners have Evidence Documents in place for each logo.
- Publish a BIMI Assertion Record referencing the Brand Indicator file and the optional Evidence Document as a DNS TXT record at default._bimi.domainName, where domainName is either the visible From: domain in the message, or the organizational domain of the visible From: domain, if different.
The DNS TXT record with an Evidence Document will look like this:
“v=BIMI1; l=https://full/path/to/logo/file.svg; a=https://full/path/to/evidence/document.pem”
Meanwhile, a DNS TXT record for BIMI with no Evidence Document (a.k.a., a self-assertion) will look like this:
“v=BIMI1; l=https://full/path/to/logo/file.svg; a=;”Mail sent to BIMI-supporting mailbox providers that passes DMARC validation checks using these domains, including the policy specification requirements, will meet the technical requirements for BIMI logo display at those mailbox providers. However, each mailbox provider may apply other criteria to the messages to determine whether or not to actually display the logo. If the message passes all criteria for logo display at a given mailbox provider, the Evidence Document and Indicator File will be retrieved by the mailbox provider and the logo will appear with the message.
How Selectors Work
For both DKIM and BIMI, the basics of selectors are fundamentally the same. A selector is used in concert with a domain name and a specific term to construct a DNS label, and a DNS TXT record is then queried at that label to find information pertaining to the protocol.
For DKIM, the label in question is of the format selectorName._domainkey.domainName, where the selectorName and domainName are specified in the s= and d= tags in the DKIM-Signature header in a DKIM signed email message. A mail receiver would look up the DKIM public key at the label and use that key to validate the DKIM signature in a message.
With BIMI, the label in question is of the format selectorName._bimi.domainName, and a mail receiver that supports BIMI would look up a domain’s BIMI Assertion Record at that label in DNS. Unlike DKIM, a selectorName does not necessarily have to be specified in the message at all, because BIMI has support for a default selector name, specifically the name “default”, which allows domain owners and mail senders to participate in BIMI with no alteration of their mail server configuration. That said, a message can contain a specially crafted header to announce a sender’s preference for a different BIMI selector to be applied for the message.
Using Selectors with BIMI – The BIMI-Selector Header
One of the key pieces of information in a BIMI Evidence Document is a representation of the image or logo for which it was issued. While BIMI Evidence Documents can and do support multiple domains, they can only support one logo. This means that for each logo that a brand wants to use with BIMI, the brand will need to obtain a separate Evidence Document, and it also means that the designers of the BIMI specification were left with a choice to implement support for multiple logos.
Those choices boiled down to two:
- Require a domain owner to update a DNS record each time the domain owner wanted to use a different logo, or
- Write the specification such that multiple BIMI records could exist for a domain, each identified by a unique name.
Given the difficulty that can be inherent in DNS changes at many organizations, the designers made the wise choice to support multiple records, and to do so with selectors, not unlike DKIM.
The name of the header used to support selectors in BIMI is the BIMI-Selector header, and its format is quite simple. There are only two key/value pairs: v= for the BIMI version and s= for the selector name, and it looks like this:
BIMI-Selector: v=BIMI1; s=selectorName;That header, coupled with the domain in the visible From: header of a message instructs a BIMI-supporting mailbox provider to look for a BIMI Assertion Record at a location other than the default location.
Let’s look at the two most common use cases for BIMI selectors…
Selector Use Case 1 – Alternative Logos
The most common use case for BIMI selectors is to allow a brand or domain to use a logo other than its default logo for mailings, perhaps for holiday-themed campaigns or other special occasions.
Once the Indicator File for this other logo has been generated and the optional Evidence Document for it has been obtained, a domain owner must publish a BIMI Assertion Record in DNS referencing the new Evidence Document and the associated Indicator File at selectorName._bimi.domainName, where selectorName is anything other than “default”. When the record has been published, using it involves inserting a BIMI-Selector header into each message for which the alternative logo is desired.
As an example, for the domain weSellStuff.com wanting to use a separate logo at holiday time, that domain might send mail that includes these two headers:
From: deals@wesellstuff.com
BIMI-Selector: v=BIMI1; s=holidaylogoThe DNS TXT record to support this would be published as holidaylogo._bimi.wesellstuff.com and would look like this:
“v=BIMI1; l=https://full/path/to/holiday/logo/file.svg; a=https://full/path/to/evidence/document/for/holiday/logo.pem”A BIMI-supporting mailbox provider would then query the DNS for an Assertion Record at holidaylogo._bimi.wesellstuff.com, and if the message meets the provider’s criteria for logo display, then the alternative logo would be retrieved and displayed with the message.
Selector Use Case 2 – A/B Testing
Brands and domain owners almost always want to know if one piece of marketing content is driving better results than another, or if the content is having any effect on their campaigns. Many times they will use A/B testing to suss out that answer, splitting an email campaign into two streams with nearly identical content save for one key piece. BIMI logos can be subject to such testing, and selectors are the way to do this.
If the goal is to A/B test two different logos, then the steps described above in the Alternative Logos section would be the way to do it. Obtain the Indicator File and Evidence Document for a second logo, publish the appropriate DNS record, and send campaigns that reference one logo or the other using the BIMI-Selector header as needed.
To perform A/B testing of whether or not BIMI is providing any value for your brand, you can take advantage of a special kind of BIMI DNS record called a “declination to publish”. Such a record looks like this:
“v=BIMI1; l=; a=;”If published at the default location, it announces that the brand is aware of BIMI, but doesn’t want to participate, so a strategy for A/B testing BIMI for a brand could be to do the following:
- Publish a “declination to publish” record in DNS at default._bimi.domainName
- Publish a regular BIMI record in DNS at testLogo._bimi.domainName
- Perform A/B testing, with only part of the campaign having a BIMI-Selector header that references “testLogo”.
Such a strategy would allow a brand to test the waters with BIMI before fully committing to its usage.
One Other Note – DKIM Signing the BIMI-Selector Header
The current BIMI specification recommends including the BIMI-Selector header in the DMARC-aligned DKIM-Signature header, and states that the header may be ignored if it’s not signed in this fashion. Therefore, in order to maximize the chances of a BIMI logo being displayed with a message, the AuthIndicators Working Group strongly endorses following this recommendation.
Conclusion
BIMI selectors are a way for domain and brand owners to use multiple logos for a given domain and/or perform A/B testing for BIMI with a minimum of DNS disruption. All that’s needed is a logo in SVG format, an Evidence Document, a DNS entry, and a header inserted in each email message, and you’re on your way.
Recent Comments