Understanding the new lps= tag in BIMI

The BIMI specification continues to evolve, and one of the most notable changes in draft version 11 is the introduction of the new lps= tag, also known as the local-part selector.

What is the lps= tag?

In prior versions of BIMI, published brand indicators and their DNS assertion records relied on the concept of a selector (via the BIMI-Selector header or using a default selector record). However, the new lps= tag in the DNS TXT assertion record allows a brand owner to declare different brand indicators based on the local-part of the message’s From: address (i.e., the part before the @).

In other words: by using lps=, you can publish multiple “sub-selectors” depending on sender address (e.g., noreply@, support@, marketing@) without relying solely on the selector header mechanism.

For example:
v=BIMI1; l=…; a=…; lps = noreply, support, marketing

This means that when the part of the sender’s address before the “@” matches one of the prefixes listed in the lps tag, the receiver will look up a BIMI record that matches that name and use it instead of the default one.

Additionally, the lps= tag also gives domain owners the flexibility to exclude specific messages from displaying a BIMI logo altogether. This is useful when certain local-parts (for example, automated system messages) should not show any brand indicator. This capability makes lps= valuable not only for managing multiple logos but also for selectively suppressing BIMI display where appropriate.

How it works (step-by-step)

1. When an email is received, the mail server (MTA) first checks authentication using SPF, DKIM, and DMARC.
2. The MTA looks up the BIMI assertion record in DNS (e.g., default._bimi.example.com) for the domain in the From: header.
3. If the record contains an lps= tag, the MTA extracts the message’s local-part (portion before @) and checks if it matches one of the prefixes listed in lps=.
4. If a match occurs, the MTA then performs another DNS lookup using a normalized local-part as the selector (i.e., <localPart>._bimi.<domain>). If that record is found and valid, it is used instead of the original. The local-part normalization follows the process defined in the RFC draft.
5. If there is no match, or the local-part lookup fails, the MTA uses the original assertion record (the fallback).
6. If the selected record yields a valid l= tag (logo location) and passes any optional a= (evidence) checks, the brand indicator may be displayed.

This logic gives senders granular control while still aligning with the simpler selector model for “one-brand per domain”.

What senders should do: checklist

If you’re responsible for BIMI deployment, consider the following:

• Ensure you have an enforced DMARC policy (reject or quarantine).
• Consider whether different local-parts in your domain should show different logos or use different selectors (e.g., valid sender addresses vs. system notifications).
• If yes, update your assertion record to include lps= listing the desired local-part selectors (prefixes) separated by commas.
  Example: lps=newsletter,support-,alerts
• Publish individual BIMI assertion records under each local-part selector (e.g., newsletter._bimi.example.com, support-eu._bimi.example.com, etc). Those records themselves must have the v=BIMI1 version tag and valid l=, a= etc.
• Validate that each local-part selector record exists, is correctly formatted, and matches your logo and optional BIMI Evidence Document.

Conclusion

The lps= tag in the BIMI draft marks a meaningful evolution: bringing more granular control to brand indicator deployment by local-part. For brands that send from many distinct local-parts (newsletters, alerts, transactional, support, etc.), it unlocks the opportunity to customize branding and indicator logic per sender. That said, it also adds new complexity in DNS management, selector syntax and monitoring.

If you’re using BIMI (or considering it), now is the time to review your sending flows, map your local-parts, and ensure your DNS assertion records are aligned with the new lps= logic. At URIports we’re ready to help monitor and validate the full selector chain so that you stay ahead of misconfigurations and ensure your BIMI deployment truly delivers brand impact and trust.

At URIports, we also provide a free BIMI Validator that checks your record’s syntax, validity, and whether your SVG logo complies with the BIMI Standard. It’s a quick and reliable way to confirm your setup before publishing or troubleshooting issues.