BIMI Draft -11 dated 9 October 2025: what's changing and how to prepare

By CaptainDNS
Published on November 13, 2025

  • #Email
  • #BIMI
  • #DMARC
  • #DKIM
  • #DNS
  • #VMC
  • #CMC
  • #Security
TL;DR

TL;DR - 🗞️ BIMI draft -11 (published 9 October 2025) formally introduces Local-Part Selectors (lps=) to drive the selector from the sender address, refreshes the ABNF grammar and discovery flow, confirms that **l= must serve an SVG/SVGZ logo over HTTPS, and reiterates the DMARC prerequisites (no p=none, pct=100 required when p=quarantine).

🧩 BIMI in 1 minute

BIMI (Brand Indicators for Message Identification) lets a domain declare in DNS which logo should appear next to an authenticated email. Receivers validate the BIMI policy and the MUA ultimately decides whether to display the logo according to its local policy.

BIMI flow at a glance

🗞️ What's new in revision -11 (9 October 2025)

  • lps= (Local-Part Selectors): a new optional tag in the BIMI assertion record that allows a lookup based on the sender local-part—handy when you cannot set the BIMI-Selector header on the outbound MTA.
  • Updated ABNF: the assertion record now explicitly references the local-part-selector block and the order of components (except v=) is interchangeable.
  • Enriched discovery: when lps= is present, the receiver normalizes the local-part, attempts a query with the derived selector, then falls back to the original record if needed.
  • Image formats: as of this draft only SVG and SVGZ are allowed, with a dedicated IANA "BIMI formats" registry tracking supported media.
  • Header reminders: BIMI-Selector should be DKIM-signed (and DMARC aligned) when used; BIMI-Location / BIMI-Indicator / BIMI-Logo-Preference must not be signed and must be stripped if injected from outside.

🔧 lps=: driving the selector from the local-part

Goal: show different logos depending on the sender address without injecting BIMI-Selector. The default record can enable lps= and redirect the lookup to <localpart>._bimi.<domain>.

From address to selector (lps=)

Normalization algorithm (-11):

  1. Remove the plus addressing part (+...).
  2. Replace _ and . with -, collapse duplicates, trim leading/trailing -.
  3. Allow only [A-Za-z0-9-], length ≤ 63.
  4. Selector comparison is case-insensitive.

Examples:

# Enable lps= but decline BIMI by default
default._bimi.example.org. IN TXT "v=BIMI1; l=; a=; lps=brand-indicators-"

# Two selectors derived from the local-part
brand-one-noreply._bimi.example.org. IN TXT "v=BIMI1; l=https://cdn.example.org/logo-one.svg"
brand-two-noreply._bimi.example.org. IN TXT "v=BIMI1; l=https://cdn.example.org/logo-two.svg; a=https://mva.example/vmc.pem"

🧪 Discovery, ABNF and record structure

The BIMI assertion record remains a TXT under <selector>._bimi.<domain>. The ABNF grammar (-11) now permits the local-part-selector block and reiterates that the order (except for v=) is free-form.

Anatomy of a BIMI record

Key points:

  • Fallback: when lps= exists, try <localpart>._bimi.<domain> first, then revert to the original selector.
  • Explicit decline: v=BIMI1; l=; a=; refuses BIMI for that selector.
  • IANA: a formats registry governs what l= may return (SVG/SVGZ today).

🖼️ Logos: formats and validation

  • l= must be an HTTPS URI.
  • Permitted formats: SVG and SVGZ (gzip).
  • Receivers validate size, SVG profile and safety before rendering.
  • If evidence a= exists (e.g. VMC/CMC), the receiver may compare the SVG served by l= with the one embedded inside the evidence.

🔐 Authentication and policy requirements

  • DMARC: the message must pass DMARC (or an equivalent local policy).
  • Policy: no p=none (both on the author domain and its organizational domain).
  • If p=quarantine, pct must be 100.
  • Receivers may use additional methods (e.g. trusted ARC) to treat some cases as "pass".

✉️ BIMI headers at the receiver

BIMI headers

  • BIMI-Selector: if present, should be DKIM-signed (DMARC aligned). Otherwise the receiver should ignore it.
  • BIMI-Location, BIMI-Indicator, BIMI-Logo-Preference: never sign them and strip them if they arrive from outside.

Example Authentication-Results entry:

Authentication-Results: mx.example.org; dmarc=pass header.from=example.org;
  bimi=pass header.d=example.org header.selector=brand-one-noreply;
  policy.indicator-uri=https://cdn.example.org/logo-one.svg;
  policy.indicator-hash=1a2b3c4d

🗓️ Timeline to keep in mind

  • 2025-10-09 (-11): adds lps=, refreshes discovery/ABNF.
  • 2025-06-16 (-10): header consolidation, avp= (avatar preference), optional hash.
  • 2025-05-01 (-09): discovery/evidence iterations.
  • 2024-11-04 (-08/-07): CMC added alongside VMC.

ℹ️ Status: Internet-Draft (work in progress); each MBP/MUA keeps full control over its rendering policy.

✅ Implementation checklist

  • DNS: define a selector strategy (default, product variants, lps= when needed).
  • Logos: provide a clean SVG/SVGZ (profile/weight) and version the URLs.
  • Evidence: publish a= (VMC/CMC) when available and keep the chain up to date.
  • Outbound MTAs: do not add BIMI-Location / BIMI-Indicator / BIMI-Logo-Preference; sign BIMI-Selector if you set it.
  • Receivers: implement LPS normalization, strip incoming headers, and optionally add policy.indicator-hash inside Authentication-Results.

🧭 Takeaways

BIMI -11 doesn't overhaul the protocol but unblocks a frequent scenario (selector driven by the local-part) and clarifies discovery, formats and headers. Domains that want fine-grained control over logo rendering gain flexibility—provided they enforce a strong DMARC posture and pristine SVG assets.

Informational article based on an Internet-Draft that may evolve; refer to the IETF text for normative details.

Similar articles