BIMI Draft -11 en date du 9 octobre 2025 : ce qui change et comment s'y préparer

⚡TL;DR

TL;DR - 🗞️ Le draft BIMI -11 (publié le 9 octobre 2025) introduit officiellement les Local-Part Selectors (lps=) pour piloter le sélecteur BIMI à partir de l'adresse expéditrice, met à jour la grammaire ABNF et la procédure de discovery, confirme que **l= pointe un logo SVG/SVGZ en HTTPS, et rappelle les pré-requis DMARC (pas de p=none, pct=100 requis si p=quarantine).

🧩 BIMI en 1 minute

BIMI (Brand Indicators for Message Identification) permet à un domaine d'indiquer dans le DNS quel logo afficher à côté d'un e-mail authentifié. Les récepteurs valident la politique BIMI, puis le MUA décide s'il affiche le logo selon sa politique locale.

🗞️ Nouveautés de la révision -11 (9 octobre 2025)

• lps= (Local-Part Selectors) : un nouveau tag optionnel dans le BIMI Assertion Record pour autoriser un lookup basé sur le local-part de l'adresse expéditrice ; pratique quand on ne peut pas poser l'en-tête BIMI-Selector côté MTA sortant.
• ABNF actualisée : le BIMI Assertion Record inclut désormais explicitement le bloc local-part-selector, et l'ordre des composants est rendu permutable (hors v=).
• Discovery enrichie : quand lps= est présent, le récepteur normalise le local-part, tente une requête avec ce sélecteur dérivé, puis retombe sur le record d'origine si non trouvé.
• Formats d'images : seuls SVG et SVGZ sont acceptés à la date de publication ; un registre IANA "BIMI formats" héberge la liste des formats supportés.
• Rappels en-têtes : BIMI-Selector devrait être signé DKIM (aligné DMARC) quand il est utilisé ; BIMI-Location/BIMI-Indicator/BIMI-Logo-Preference ne doivent pas être signés et doivent être supprimés s'ils proviennent de l'extérieur.

🔧 lps= : piloter un sélecteur depuis le local-part

L'objectif : afficher des logos différents selon l'adresse d'envoi sans devoir injecter BIMI-Selector. Le record par défaut peut ainsi activer lps= et rediriger la lookup vers <localpart>._bimi.<domaine>.

Algorithme de normalisation (-11) :

1. Retirer la plus-adresse (subaddressing, +...).
2. Remplacer _ et . par -, compacter les occurrences multiples, supprimer les - en début/fin.
3. Accepter uniquement [A-Za-z0-9-], longueur ≤ 63.
4. Insensibilité à la casse côté sélecteur.

Exemples :

# Activer lps= mais décliner BIMI par défaut
default._bimi.exemple.fr. IN TXT "v=BIMI1; l=; a=; lps=brand-indicators-"

# Deux sélecteurs pilotés par local-part
brand-one-noreply._bimi.exemple.fr. IN TXT "v=BIMI1; l=https://cdn.exemple.fr/logo-one.svg"
brand-two-noreply._bimi.exemple.fr. IN TXT "v=BIMI1; l=https://cdn.exemple.fr/logo-two.svg; a=https://mva.exemple/vmc.pem"

🧪 Discovery, ABNF et structure du record

Le BIMI Assertion Record reste un TXT sous <sélecteur>._bimi.<domaine>. La grammaire ABNF (-11) autorise désormais le bloc local-part-selector et rappelle que l'ordre (hors v=) est libre.

Points clés :

• Fallback : si lps= est présent, tenter d'abord <localpart>._bimi.<domaine> (puis retomber).
• Déclinaison explicite : v=BIMI1; l=; a=; refuse BIMI pour ce sélecteur.
• IANA : un registre des formats encadre l= (SVG/SVGZ à ce jour).

🖼️ Logos : formats et validation

• l= doit être un URI HTTPS.
• Formats acceptés : SVG et SVGZ (gzip).
• Les récepteurs valident la taille, le profil SVG et la sûreté avant d'afficher.
• Si une evidence a= est présente (ex. VMC/CMC), le récepteur peut comparer le SVG servi par l= avec celui extrait de l'evidence.

🔐 Exigences d'authentification et politique

• DMARC : le message doit passer DMARC (ou équivalent local).
• Politique : pas de p=none (au niveau du domaine auteur et du domaine organisationnel).
• Si p=quarantine, pct doit être 100.
• Le récepteur peut utiliser des méthodes additionnelles (ex. ARC de confiance) pour juger "comme pass" dans certains cas.

✉️ En-têtes BIMI côté réception

• BIMI-Selector : si présent, devrait être signé DKIM (aligné DMARC). Sinon, ignorer côté récepteur.
• BIMI-Location, BIMI-Indicator, BIMI-Logo-Preference : ne jamais signer, supprimer s'ils proviennent de l'extérieur.

Exemple d'Authentication-Results enrichi :

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

🗓️ Chronologie utile

• 2025-10-09 (-11) : ajout lps=, discovery/ABNF mis à jour.
• 2025-06-16 (-10) : consolidation en-têtes, avp= (préférence avatar), hash facultatif.
• 2025-05-01 (-09) : itérations discovery/evidence.
• 2024-11-04 (-08/-07) : CMC aux côtés de VMC.

ℹ️ Statut : Internet-Draft (work in progress) ; chaque MBP/MUA garde la main sur sa politique d'affichage.

✅ Check-list de mise en oeuvre

• DNS : dessiner une stratégie de sélecteurs (par défaut, variantes produit, lps= au besoin).
• Logos : fournir un SVG/SVGZ propre (profil/poids) et versionner les URLs.
• Evidence : publier a= (VMC/CMC) si utilisé, et tenir la chaîne à jour.
• MTAs sortants : ne pas poser BIMI-Location/BIMI-Indicator/BIMI-Logo-Preference ; signez BIMI-Selector si vous l'utilisez.
• Récepteurs : implémenter la normalisation LPS, la suppression des en-têtes entrants et, si souhaité, policy.indicator-hash dans Authentication-Results.

🧭 Conclusion

BIMI -11 ne bouleverse pas le protocole, mais débloque un cas opérationnel fréquent (pilotage par local-part) et clarifie la discovery, les formats et les en-têtes. Les domaines qui souhaitent orchestrer finement l'affichage de leurs logos gagnent en souplesse - à condition d'avoir une posture DMARC forte et des SVG irréprochables.

Document informatif basé sur un Internet-Draft susceptible d'évoluer ; reportez-vous au texte IETF pour les détails normatifs.