Separate a described mechanism from proven support
A multi-logo feature can be documented by the BIMI working group without being available in every receiving mailbox. The useful planning question is not simply whether a tag exists, but whether the intended receiver implements the relevant behavior and whether the sender can prove the outcome for its actual messages. Keep specification status, provider support, observed display and business impact as four separate evidence categories.
The BIMI Group published its lps explanation on 23 July 2026; this review retained that page on 8 November 2026. It calls the feature relatively new and explicitly says receiver support is still emerging. This article summarizes that group-described mechanism, not a universally deployed standard. Full current draft text was unavailable for verification, so exact normative edge cases and receiver implementation remain bounded evidence gaps. No live provider support or display test has been performed.
Understand the local-part idea at a high level
The group explains lps as Local-part as Selector. The local-part is the portion of a sender address before the at sign. In its described workflow, a receiver first examines the default BIMI assertion and may perform an additional lookup using the sender's local-part when the lps condition applies. This moves a choice into DNS rather than requiring the sender's platform to insert a custom selector header. BIMI Group lps explanation
The article describes comma-separated prefixes and an empty lps value that allows every sender to trigger the additional lookup. It also describes normalization examples, including removal of plus addressing and conversion of periods or underscores to dashes. Treat these as the working group's documented explanation, not a complete parser specification. Before implementation, resolve exact normalization, matching and fallback behavior against the applicable draft and receiver evidence rather than extrapolating from a few examples.
Compare lps with a message selector
BIMI Group's separate selector guide describes a BIMI-Selector header that identifies an alternative assertion under selector._bimi.domain. It recommends protecting that header with the DMARC-aligned DKIM signature and warns that an unsigned preference may be ignored. This is a different control point from the lps approach, which is described as deriving the choice from the address and DNS. BIMI selector guidance
The choice between these approaches depends on the sending platform and target receivers. A platform that cannot add a suitable header may find the DNS-based idea attractive, but that does not establish receiver support. Conversely, support for conventional BIMI selectors does not prove support for lps. Keep both capabilities as separate rows in the provider matrix, with source evidence or an explicit unknown value.
Design the default behavior first
The lps article says providers that do not implement the tag ignore it and evaluate the standard BIMI record. That means the default assertion remains a deliberate compatibility choice. A plan that publishes a default logo but expects lps to restrict branding to selected addresses must consider what unsupported receivers would do with the default. The group illustrates an empty default logo alongside selected local-part lookups, but that example is not proof of behavior at a named receiver. BIMI Group fallback discussion
Do not treat logo suppression as a security boundary. An absent brand indicator is not a delivery prohibition, identity authorization system or guarantee that no other avatar appears. A receiver may have contact images or other presentation mechanisms outside BIMI. The proposed design should state the desired branding behavior while leaving message authentication and access control to their actual mechanisms.
Plan the asset and rights dependencies for every logo
Multiple selector names do not eliminate the requirements attached to each image. BIMI Group's selector guide describes evidence documents as tied to one logo, even when a document can cover multiple domains. A plan for different brand artwork therefore needs an issuer and rights review for each intended logo rather than assuming one certificate automatically covers a campaign collection. Confirm current issuer packaging and category rules for the real application. Multiple-logo evidence dependencies
Keep the asset, certificate material, DNS assertion and owner connected in the change record. If a support address changes or a product is retired, review the corresponding assertion and hosted resources. Avoid automatically generating selectors for every mailbox without understanding naming collisions, address changes and ownership. Normalization can make seemingly different addresses map similarly; exact collision behavior remains a question for the applicable implementation and controlled tests.
Original support and display test matrix
The following is a proposed matrix, not a test result. Each cell should distinguish documented support, observed behavior and unresolved interpretation. Obtain authorization before sending test messages or changing DNS, and use controlled accounts and non-sensitive content.
- Receiver and client: service, web or mobile surface, version if available and observation date.
- Mechanism: ordinary default assertion, BIMI-Selector header or lps-based selection.
- Input case: approved matching prefix, nonmatching address, plus address or normalization case.
- Default behavior: intended fallback and expected behavior when lps is unsupported.
- Authentication: actual message identities, aligned result and trusted verifier evidence.
- Asset chain: selected assertion, public answer, approved logo and certificate dependency.
- Observation: actual displayed image, no image or indeterminate result, with retained context.
- Limitations: caching, account contact images, unknown implementation and incomplete coverage.
Begin with the simplest cases before edge cases. A default assertion and one explicitly selected address can establish whether the basic intended path is observable in the authorized environment. Only then expand the matrix to normalization, fallback and client differences. A single screenshot should not be used to infer all address mappings or all receiver surfaces.
Keep outcome measurement separate from display testing
A logo appearing is a display observation, not proof of increased opens, clicks or trust. If the business wants a controlled outcome claim, define the metric, comparison groups, sample period and limitations in advance. Avoid mixing changes to content, audience or sending reputation with a logo experiment and attributing the entire difference to BIMI. This is proposed experimental discipline, not a claim that a controlled study has been conducted.
Any reported outcome should distinguish delivery, rendering and engagement. Missing render evidence weakens a claim that the audience actually saw the treatment. Client caching and privacy-related measurement behavior can also complicate interpretation. Preserve these limitations and obtain appropriate review before making a marketing claim. No percentage uplift, causal effect or return-on-investment estimate is supported by this manuscript.
Fictional example: a shared domain with two customer-facing addresses
Fictional Juniper Desk wants different artwork for newsletter and support messages while leaving employee mail without a BIMI logo. The proposed design uses lps because its platform cannot easily insert a custom header. The review first asks whether the intended receivers support lps and what they would do with the default assertion if they do not. Those questions must be answered before the team relies on address-level branding.
The planned test matrix would include the two approved addresses, a nonmatching employee address and selected normalization cases, with separate rows for each receiver and client. It would also require rights and certificate review for each logo. Juniper Desk is fictional: no records were published, no mail sent and no display or engagement measured.
The catalogue requires a receiver-display test matrix and, if claimed, controlled outcome measurement with limitations. This article provides a proposed matrix only. Original evidence, human SME, source applicability, production routes, visual accessibility and owner release remain open. The lps discussion is suitable for scoped planning, not an assertion of implemented support or measured benefit.