BIMI-Draft -11 vom 9. Oktober 2025: Änderungen und Vorbereitung

⚡TL;DR

TL;DR - 🗞️ Der BIMI-Draft -11 (veröffentlicht am 9. Oktober 2025) führt offiziell die Local-Part Selectors (lps=) ein, um den BIMI-Selector aus der Absenderadresse abzuleiten, aktualisiert die ABNF-Grammatik und den Discovery-Flow, bestätigt dass **l= ein SVG/SVGZ über HTTPS liefern muss und erinnert an die DMARC-Vorgaben (kein p=none, bei p=quarantine ist pct=100 Pflicht).

🧩 BIMI in 1 Minute

BIMI (Brand Indicators for Message Identification) ermöglicht es einem Domaininhaber, im DNS festzulegen, welches Logo neben einer authentifizierten E-Mail angezeigt werden soll. Empfänger prüfen die BIMI-Policy, und das MUA entscheidet anhand seiner lokalen Richtlinie, ob das Logo gerendert wird.

🗞️ Neuerungen der Revision -11 (9. Oktober 2025)

• lps= (Local-Part Selectors): neue optionale Kennung im BIMI Assertion Record, die eine Abfrage basierend auf dem lokalen Teil der Absenderadresse erlaubt – praktisch, wenn der Header BIMI-Selector nicht gesetzt werden kann.
• Aktualisierte ABNF: der Eintrag erwähnt nun explizit den Block local-part-selector; die Reihenfolge der Komponenten (außer v=) ist flexibel.
• Erweiterte Discovery: ist lps= vorhanden, normalisiert der Empfänger den Local-Part, versucht eine Abfrage mit dem abgeleiteten Selector und fällt zurück auf den Originaleintrag, falls nichts gefunden wird.
• Bildformate: Stand heute sind nur SVG und SVGZ erlaubt; ein IANA-Register „BIMI formats" führt die zulässigen Formate.
• Header-Hinweise: BIMI-Selector sollte DKIM-signiert (DMARC-konform) sein; BIMI-Location / BIMI-Indicator / BIMI-Logo-Preference dürfen nicht signiert werden und müssen entfernt werden, wenn sie extern eingespeist werden.

🔧 lps=: Selector aus dem Local-Part ableiten

Ziel: je nach Absenderadresse unterschiedliche Logos anzeigen, ohne BIMI-Selector einzufügen. Der Standard-Record kann lps= aktivieren und die Abfrage auf <localpart>._bimi.<domain> umlenken.

Normalisierung (-11):

1. Entfernen des Plus-Anteils (+...).
2. _ und . durch - ersetzen, Mehrfachzeichen zusammenfassen, führende/abschließende - trimmen.
3. Nur Zeichen [A-Za-z0-9-] erlauben, Länge ≤ 63.
4. Vergleich des Selectors ist nicht case-sensitiv.

Beispiele:

# lps= aktivieren, BIMI standardmäßig ablehnen
default._bimi.example.org. IN TXT "v=BIMI1; l=; a=; lps=brand-indicators-"

# Zwei Selector-Varianten aus dem 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 und Aufbau des Records

Der BIMI Assertion Record bleibt ein TXT unter <selector>._bimi.<domain>. Die ABNF-Grammatik (-11) erlaubt nun den Block local-part-selector und stellt klar, dass die Reihenfolge (außer v=) frei ist.

Wesentlich:

• Fallback: bei lps= zuerst <localpart>._bimi.<domain> testen, danach zum Ausgangsselector zurückkehren.
• Explizite Ablehnung: v=BIMI1; l=; a=; lehnt BIMI für diesen Selector ab.
• IANA: ein Formate-Register definiert, was l= liefern darf (derzeit SVG/SVGZ).

🖼️ Logos: Formate und Validierung

• l= muss eine HTTPS-URI sein.
• Zulässige Formate: SVG und SVGZ (gzip).
• Empfänger prüfen Größe, SVG-Profil und Sicherheit, bevor das Logo angezeigt wird.
• Mit vorhandener Evidence a= (z. B. VMC/CMC) kann das geladene SVG mit dem Zertifikat-Inhalt verglichen werden.

🔐 Anforderungen an Authentifizierung und Policy

• DMARC: die Nachricht muss DMARC bestehen (oder eine lokale Gleichwertigkeit).
• Policy: kein p=none (weder auf der Absender- noch auf der Organisationsdomain).
• Bei p=quarantine muss pct=100 sein.
• Empfänger dürfen zusätzliche Verfahren (z. B. vertrauenswürdiges ARC) nutzen, um Fälle als „pass" zu bewerten.

✉️ BIMI-Header auf Empfängerseite

• BIMI-Selector: falls vorhanden DKIM-signieren (DMARC-konform). Andernfalls sollte der Empfänger ihn ignorieren.
• BIMI-Location, BIMI-Indicator, BIMI-Logo-Preference: nie signieren und entfernen, wenn sie extern eingehen.

Beispiel Authentication-Results:

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

🗓️ Zeitstrahl

• 2025-10-09 (-11): lps= ergänzt, Discovery/ABNF überarbeitet.
• 2025-06-16 (-10): Header-Konsolidierung, avp= (Avatarpräferenz), optionaler Hash.
• 2025-05-01 (-09): Discovery/Evidence-Iterationen.
• 2024-11-04 (-08/-07): CMC kommt zu VMC hinzu.

ℹ️ Status: Internet-Draft (work in progress); jedes MBP/MUA entscheidet weiterhin selbst über die Darstellung.

✅ Checkliste für die Umsetzung

• DNS: eine Selector-Strategie definieren (Default, Produktvarianten, lps= bei Bedarf).
• Logos: saubere SVG/SVGZ (Profil/Größe) bereitstellen und die URLs versionieren.
• Evidence: a= (VMC/CMC) publizieren und die Kette pflegen.
• Ausgehende MTAs: BIMI-Location / BIMI-Indicator / BIMI-Logo-Preference nicht setzen; BIMI-Selector signieren, falls verwendet.
• Empfänger: LPS-Normalisierung implementieren, eingehende Header verwerfen und optional policy.indicator-hash in Authentication-Results ergänzen.

🧭 Fazit

BIMI -11 revolutioniert nichts, aber öffnet einen typischen Anwendungsfall (Selector über den Local-Part) und schafft Klarheit bei Discovery, Formaten und Headern. Domains, die die Logo-Anzeige fein steuern wollen, gewinnen Flexibilität – vorausgesetzt, sie halten eine starke DMARC-Position und einwandfreie SVGs vor.

Informationsartikel basierend auf einem sich entwickelnden Internet-Draft; maßgeblich bleibt der IETF-Text.