When you hear the term “selectors” and you work in the email industry your mind likely drifts to thoughts about DKIM and how different records can be separated by the use of a selector for different types of messages. One selector for corporate, one for support emails, one for marketing… you get the point. 

What are DKIM Selectors?

The selector used by DKIM is a DKIM-Signature header that indicates where the public key part of the DKIM keypair is hosted in DNS. The receiving server uses the DKIM selector to retrieve the public key as part of the authentication tests conducted on the inbound message.

It might surprise you to hear that BIMI also incorporates the idea of a selector for publishing an assertion record in a similar manner to DKIM. This could be utilized to have alternative logos between your corporate email, or different brands using the same email domain. Should you only have the need for one logo you can publish your BIMI record under the ‘default’ selector. 

Do different Mailbox providers treat selectors differently? 

The implementation decisions surrounding BIMI, or any type of authentication solution will always be in the hands of the Mailbox providers. As of this writing, most of the participating mailbox providers support selectors, or are planning to support selectors as they become more popular in use. However, most organizations are only publishing a single BIMI record today, and will not require additional records. 

What if my ESP doesn’t support selectors? 

If your service providers do not yet support BIMI selectors then you can configure alternative subdomains for use with each provider and publish a subdomain level BIMI policy with the logo you wish to have displayed for the message. The BIMI record would be published in a similar manner to the organization domain but with the subdomain included. 

Do subdomains inherit the BIMI record from the organization domain? 

Yes, the BIMI protocol is written in such a way that the publication of a record at the organization domain should apply to the subdomains that do not explicitly declare their own BIMI policy. This means that many organizations will only need to publish one record for their entire organization. This is similar to the design of DMARC where a subdomain will inherit the organization domain’s policies if it does not have one explicitly declared.