The BIMI selector explained

6 June 2026 · 12 min read

Almost every BIMI guide tells you to publish a record at default._bimi.example.com and stops there. That single word, default, is the selector, and most people never think about it again because for most domains they never need to. But the selector is not decoration. It is the mechanism that lets one domain serve more than one logo, and it is the one part of BIMI that an individual outbound message can override on the fly using a header. If you have ever wondered why the record lives at default._bimi rather than just _bimi, what the BIMI-Selector header is for, or how a company shows a festive logo in December and a normal one in January without touching DNS, this is the article.

This is specifically about the selector: how the lookup works, how the BIMI-Selector header changes which record a receiver fetches, and the handful of real situations where you would deliberately move away from default. It is not a general "what is BIMI" piece. If you need the prerequisites (DMARC at enforcement, a Tiny PS SVG, a Verified Mark Certificate) those are covered in Fix: BIMI logo not showing in Gmail and the BIMI glossary entry. Here we go one level down, into the part of the DNS name that sits in front of _bimi.

What the selector actually is

BIMI publishes its policy as a DNS TXT record at a structured hostname. That hostname has three parts, read right to left:

default._bimi.example.com
   |       |        |
selector  fixed   domain
          label

• example.com is your domain (or subdomain).
• _bimi is a fixed label that the BIMI specification reserves, the same way _dmarc is reserved for DMARC. It never changes.
• default is the selector. It names which BIMI record to use.

The selector exists for exactly one reason: a single domain can publish more than one BIMI record, each at a different selector label, and each pointing at a different logo and certificate. The receiver has to know which one to fetch for a given message. The selector is the answer to that question.

A minimal record at the default selector looks like this:

default._bimi.example.com.  IN  TXT  "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/vmc.pem"

If you only ever want one logo for your whole domain, default is all you need, and you can stop thinking about selectors entirely. The interesting behaviour starts when you want two.

How a receiver chooses a selector

When a mailbox provider decides whether to show a BIMI logo, it does not pick a selector at random. It follows a precise order:

1. Confirm the message passes DMARC with alignment and that the From domain's DMARC policy is at enforcement. No enforcement, no BIMI, and the selector never even gets looked up. (Why this gate exists is in the DMARC policy glossary entry.)
2. Look at the message headers for a BIMI-Selector header. If one is present and valid, take the selector value from it.
3. If there is no BIMI-Selector header, use the literal selector default.
4. Construct the lookup hostname as <selector>._bimi.<from-domain> and fetch the TXT record there.

So the selector is chosen per message, by the message itself. The default is default, but any individual email can ask for a different one by stamping a header on the way out. That is the whole design: DNS holds several records, and each message points at the one it wants.

This is worth sitting with, because it reframes what BIMI is. It is not "one logo per domain". It is "one logo per message, selected by a header, defaulting to a domain-wide logo when the header is absent". The domain-wide logo is just the common case where every message implicitly asks for the same selector.

The BIMI-Selector header

The BIMI-Selector header is a header your sending system adds to an outbound message to override which BIMI record receivers should use for that message. Its format is small and rigid:

BIMI-Selector: v=BIMI1; s=marketing

• v=BIMI1 is the version tag, required, and must come first.
• s= carries the selector name. In this example, marketing.

When a receiver sees that header on a message that otherwise qualifies for BIMI, it looks up marketing._bimi.example.com instead of default._bimi.example.com. If a record exists there, that record's logo and certificate are used. If no record exists at the named selector, behaviour depends on the receiver, but you should assume the safe outcome is no logo at all rather than a silent fallback to default. Never stamp a selector header that does not have a matching DNS record behind it.

A few rules govern the header that catch people out:

• The selector name is a DNS label. It must be valid as the left-most label of a hostname: letters, digits and hyphens, no spaces, no underscores in the value itself, reasonable length. summer-2026 is fine; Summer 2026 is not.
• It is case-insensitive in practice, but match it exactly. DNS labels are case-insensitive, so Marketing and marketing resolve the same record. Keep your header value and your DNS label identical to avoid confusion, and prefer lower case.
• The header must survive to the receiver. BIMI-Selector is added by the sender and read by the receiving mailbox provider. It is not part of the DKIM signature requirement, but if your signing or a downstream relay strips or rewrites custom headers, the override is lost and the receiver falls back to default. If you rely on a non-default selector, confirm the header actually arrives by inspecting a received message's raw source.
• One selector per message. A message asks for exactly one logo. There is no list.

If you never add this header, every message implicitly uses default, which is why the default selector is the only one most domains ever publish.

When you would actually use a non-default selector

Here is the honest part: the large majority of domains should publish a single record at default._bimi and never touch a custom selector. Extra selectors are extra DNS records, and if you use Verified Mark Certificates, potentially extra certificates, which is real cost and real maintenance. Do not add selectors for the sake of it. That said, there are genuine, concrete reasons to use them.

Seasonal or campaign logos

This is the textbook case. A retailer wants a festive version of its logo through December, or a special mark for a product launch or a sponsorship. Rather than rewriting the default record (and waiting on DNS TTLs each time, and risking a mistake on your primary logo), you publish a second record:

default._bimi.example.com.   IN  TXT  "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/vmc.pem"
holiday._bimi.example.com.   IN  TXT  "v=BIMI1; l=https://example.com/bimi/logo-holiday.svg; a=https://example.com/bimi/vmc-holiday.pem"

Then your marketing platform stamps BIMI-Selector: v=BIMI1; s=holiday on the seasonal campaign and nothing on transactional mail. The festive logo shows for the campaign; your standard logo shows everywhere else. When the season ends you simply stop sending the header. The default logo was never at risk because you never edited it.

The catch with this pattern, and it is a big one if you use VMCs: the certificate referenced in each record must contain a logo that matches the SVG that record serves. A seasonal logo that is materially different from your trademarked mark may not be certifiable as a Verified Mark Certificate at all, because a VMC attests to a registered trademark. A holiday variant with a snowflake added is not your registered trademark. In practice, seasonal selectors are most workable where the receiver accepts a Common Mark Certificate (see the CMC glossary entry) or where the variation is small enough to still read as the registered mark. Plan the certificate question before the DNS question.

Different brands or product lines on one domain

If a single organisational domain sends mail for visibly different brands, a non-default selector lets each brand carry its own logo while sharing the domain's DMARC and authentication setup. Each brand's sending stream stamps its own selector, and each selector points at that brand's logo and certificate. This only makes sense when the brands genuinely share the From domain; if they send from separate domains or subdomains, you would use separate default records on each, not selectors.

Subdomain sending streams

Selectors and subdomains are independent axes, and people conflate them. The lookup hostname is <selector>._bimi.<from-domain>, and the from-domain part includes any subdomain. So mail sent from news.example.com looks up default._bimi.news.example.com, not default._bimi.example.com. If you want a distinct logo for a subdomain's mail, the cleaner approach is usually to publish a default BIMI record under that subdomain, not to use a custom selector on the parent. Use selectors when you want multiple logos within the same from-domain; use subdomain records when the sending identity is already a different from-domain. Note the subdomain also needs to be at DMARC enforcement in its own right, which the subdomain policy (sp) glossary entry explains.

A staging or test selector

Some teams publish a throwaway selector to test a new logo or a renewed certificate against a real receiver before promoting it to default. You stamp the test selector on mail to your own test inboxes, confirm it renders, then either copy the validated assets into default or repoint default. This keeps experimentation away from your production logo. It is a niche use, but a tidy one.

A worked example end to end

Suppose example.com is a retailer, fully at p=reject, with a VMC for its primary logo, and it wants a holiday mark for its December newsletter only. The complete picture looks like this.

DNS holds two BIMI records:

default._bimi.example.com.   IN  TXT  "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/vmc.pem"
holiday._bimi.example.com.   IN  TXT  "v=BIMI1; l=https://example.com/bimi/logo-holiday.svg; a=https://example.com/bimi/cmc-holiday.pem"

The DMARC record at _dmarc.example.com is unchanged and enforced; BIMI rides on top of it and the selector does not affect DMARC at all:

"v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s"

A normal transactional email (an order confirmation) carries no BIMI-Selector header. The receiver looks up default._bimi.example.com, validates the standard logo and VMC, and shows the primary mark.

The December newsletter carries:

BIMI-Selector: v=BIMI1; s=holiday

The receiver looks up holiday._bimi.example.com, validates the holiday logo against its certificate, and shows the festive mark, but only for that message. When January arrives, the newsletter platform simply stops adding the header, and every message goes back to default with zero DNS changes. The holiday record can sit there harmlessly until next year.

The thing to notice: the only difference between the two outcomes is one header on the message. DNS held both options the whole time. That is the selector doing its job.

How the selector relates to the rest of BIMI

It helps to keep the selector in its lane, because it is easy to over-attribute problems to it.

• The selector chooses the record. The record chooses the logo and certificate. The selector itself contains no logo information. It is just a label that picks which TXT record to read. The l= (logo URL) and a= (certificate URL) tags live inside the record, not in the selector.
• The selector does not change DMARC. DMARC is looked up at _dmarc.<domain> regardless of which BIMI selector a message uses. You cannot weaken or strengthen DMARC per selector. Every selector inherits the same enforcement requirement. A message that fails DMARC shows no logo no matter how perfect its selector and record are.
• The selector is not the DKIM selector. This trips up newcomers constantly. DKIM also has a thing called a selector (the s= in a DKIM-Signature, the label in selector._domainkey.example.com). It is a completely separate concept that happens to share the word. The DKIM selector picks a signing key; the BIMI selector picks a logo record. They do not interact. If you have read about DKIM selectors, mentally file the BIMI selector as a parallel idea in a different protocol, not the same thing.
• The s= in the header is not the s= in DKIM either. Same warning, different header. BIMI-Selector: v=BIMI1; s=holiday and DKIM-Signature: ...; s=selector1; ... both use s=, and they mean unrelated things.

Common mistakes with selectors

A short field guide to the ways selectors go wrong, drawn from how these failures actually present.

• Publishing at _bimi.example.com with no selector label. The record must sit at default._bimi, not at _bimi. A bare _bimi record is never found, because receivers always prepend a selector (default if none is specified). This is one of the single most common reasons a brand-new BIMI setup shows nothing.
• Stamping a BIMI-Selector header with no matching record. If outbound mail says s=marketing but marketing._bimi.example.com does not exist, the receiver looks up a record that is not there and shows no logo. The fix is either to publish the record or to stop sending the header.
• Assuming a missing selector falls back to default. Do not rely on this. The reliable behaviour is: present a header, you get that exact selector; absent a header, you get default. A present header pointing at a missing record is a failure, not a silent fallback.
• The header gets stripped in transit. If your ESP, a gateway, or a relay removes custom headers, the override never reaches the receiver and everything quietly reverts to default. Always verify on a received message that the header survived, by reading the raw source. The header-from glossary entry is a reminder that the domain part of the lookup comes from the visible From header, which also must align.
• Certificate and logo mismatch on a non-default selector. Each selector's record points at its own a= certificate, and the logo embedded in that certificate must match the SVG at that record's l= URL. Copying the default certificate onto a holiday record with a different SVG breaks the match and the logo fails to render. Each selector is validated independently.
• Forgetting the subdomain is part of the hostname. As above, default._bimi.news.example.com and default._bimi.example.com are different records. Publishing only at the apex does nothing for mail whose From domain is the subdomain.

How to inspect and validate a selector

You can check exactly what a receiver would find. To see the record at a given selector, query the TXT record at the full hostname:

dig +short TXT default._bimi.example.com
"v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/vmc.pem"

dig +short TXT holiday._bimi.example.com
"v=BIMI1; l=https://example.com/bimi/logo-holiday.svg; a=https://example.com/bimi/cmc-holiday.pem"

If dig returns nothing for a selector you expected to exist, the record is missing or published at the wrong hostname, and that is your problem regardless of how good the logo is.

To validate the whole chain (record syntax, the SVG against the Tiny PS profile, and the certificate) without guessing, run the hostname through the BIMI checker, which resolves the record and inspects the referenced assets. To validate the certificate side specifically (chain, expiry, and that the embedded logo matches the served SVG) use the BIMI VMC checker. When you are designing a new record before it goes live, model the tags with the BIMI generator, and preview how the mark will look in an inbox with the BIMI simulator.

For a non-default selector, point those tools at the full selector hostname (holiday._bimi.example.com), not just the domain, so you are validating the exact record the header will request. And confirm the underlying DMARC posture first with the DMARC checker, because a perfect selector on a domain still at p=none shows no logo anywhere.

The practical takeaway

The BIMI selector is the label in front of _bimi that tells a receiver which logo record to fetch. For nearly every domain the answer is default, and the right setup is a single record at default._bimi.<domain> with a valid logo and certificate. The selector only earns its keep when you genuinely need more than one logo on the same From domain: a seasonal or campaign mark, distinct brands sharing a domain, or a test record you promote later. In those cases you publish an additional record at a named selector, and you stamp BIMI-Selector: v=BIMI1; s=<name> on the specific messages that should use it. No header means default; a header means that exact selector, and a header with no matching record means no logo, so never advertise a selector you have not published.

Keep three things straight and you will not get caught out. The selector picks the record, the record picks the logo and certificate, and DMARC enforcement underneath is non-negotiable for any selector. The BIMI selector is not the DKIM selector, even though both use the word and both use s=. And every non-default selector needs its own certificate-to-logo match, which is where the cost and the maintenance really live, especially with Verified Mark Certificates that attest to a registered trademark.

If you want the logo without owning any of this plumbing, that is what the done-for-you BIMI product and the wider DMARC service are for: we get you safely to p=reject first (the real prerequisite), then handle the record, the selector, the SVG and the certificate, and watch the DNS so a later edit does not quietly knock the logo out. Start by running your domain through the BIMI checker to see exactly which record, at which selector, a receiver finds today.