The short version

The lps tag lets a supporting receiver use the part of a sending address before @ to find a BIMI record. It can give different addresses different logos without adding a selector header to each message. Receiver support still determines whether it works.

When would you use it?

Imagine a business sending offers and customer-service replies from the same domain. It wants a different approved logo for each stream, while staff messages do not request a BIMI logo. The BIMI Group’s July 2026 guidance describes lps as an option for this kind of address-based branding.

Start by writing down the intended result for each sending address. If every stream should show the same mark, a single default setup may already meet the need.

An illustrative DNS setup

These fictional TXT records show two address-specific configurations. Replace the example domain and asset URLs with approved values before implementation.

default._bimi.example.com
v=BIMI1; l=; a=; lps=offers,help;

offers._bimi.example.com
v=BIMI1; l=https://example.com/offers.svg; a=https://example.com/offers.pem;

help._bimi.example.com
v=BIMI1; l=https://example.com/help.svg; a=https://example.com/help.pem;

For offers@example.com, a supporting receiver can discover the offers record; help@example.com selects the help record. The empty default l= declines a BIMI logo for other addresses. It does not control contact photos or other imagery supplied by the inbox.

Decide that default deliberately: copying this example over an existing corporate-logo record would change its behaviour.

Prefixes are not an exact address list

Under revision 15 of the BIMI draft, lps=help also matches helpdesk. That address triggers a lookup for helpdesk._bimi.example.com, not the help record. A missing selected record returns processing to the original record.

An empty lps= enables matching for every local-part. Normalisation removes a plus suffix and converts periods or underscores to hyphens: offers.weekly+autumn becomes offers-weekly. Eligible selectors contain letters, digits or hyphens and are at most 63 characters. DNS selector matching is case-insensitive. Review address collisions before choosing names.

How does this differ from a BIMI-Selector header?

A BIMI-Selector header lets a sending system name a selector for a message. The lps approach derives the selection from the sending address through DNS configuration. It is useful when the sending service cannot easily add that header.

If your design needs a changing logo for campaigns sent from the same address, discuss explicit selectors with your email-platform operator. The BIMI Group’s selector guide explains that approach and its requirements.

Each logo still needs the right evidence

Selectors do not make one certificate cover several different logos. The BIMI Group explains that an evidence document represents one logo, even when it covers multiple domains. Confirm the certificate and domain scope for each proposed mark with the issuer.

The normal BIMI prerequisites still apply: authenticated mail with DMARC enforcement, suitable SVG artwork, accessible HTTPS assets and any certificate required by the receiving provider. Changing the lookup cannot repair a failing authentication result.

Test the receiving behaviour before rollout

The specification is an Internet-Draft, dated 31 October 2026, and remains work in progress. General BIMI support does not establish support for lps. The BIMI Group advises checking compatibility with the receiving providers you need.

Use a small acceptance checklist:

  1. Ask the target providers about their current local-part selector support and any restrictions.
  2. Retain the existing DNS values and agree the intended default behaviour.
  3. Check each record, asset and certificate before sending.
  4. Send controlled messages from both configured addresses, an unmatched staff address and a prefix-matching address such as helpdesk@example.com.
  5. Record authentication results, the observed logo, the receiving service and the date. Investigate mismatches before expanding the rollout.

For each test, write the expected result first. A screenshot alone cannot show which record was selected. Keep received message headers and DNS observations alongside it, using the BIMI launch test plan to organise the evidence.

The complete guide

Understand the BIMI DNS record

Read the record, understand its tags, and avoid common publishing mistakes.

Read the guide

Sources & further reading

Sources checked on . Requirements can change; check the original guidance when implementing. Planning checklists and examples are BIMI World’s editorial suggestions.

Explore all Articles