BIMI : comment fonctionnent les Brand Indicators for Message Identification

Ce qui change l’affichage BIMI

L’éligibilité BIMI n’est pas l’affichage du logo. Le récepteur décide de l’affichage : un expéditeur peut publier un enregistrement syntaxiquement valide sans voir de logo dans une boîte donnée.

La réponse varie selon ces conditions :

• Politique DMARC : les consignes BIMI exigent une politique DMARC quarantine ou reject. Une politique de surveillance p=none ne remplit pas cette condition. Même si la RFC 9989 a retiré l’ancienne balise pct de DMARC, les consignes BIMI actuelles n’acceptent toujours pas une valeur publiée inférieure à 100.
• Alignement DMARC : le message livré doit réussir DMARC. Un enregistrement BIMI valide ne compense pas un échec d’alignement SPF ou DKIM.
• Format du logo : l’URL du logo doit mener à un fichier conforme au profil BIMI SVG Tiny Portable/Secure. Un SVG classique peut contenir des éléments que le profil BIMI interdit.
• Politique de certificat : certains récepteurs exigent un Verified Mark Certificate ou un autre certificat accepté avant d’afficher un logo. Consultez la documentation BIMI actuelle du fournisseur avant d’acheter ou de publier un certificat.
• Prise en charge du fournisseur : un fournisseur qui n’implémente pas BIMI n’affichera pas l’indicateur, quelle que soit la configuration DNS de l’expéditeur.
• Politique locale du récepteur : un fournisseur compatible peut appliquer d’autres contrôles de confiance et anti-abus. BIMI ne les contourne pas.

Pour réunir application, conversion SVG, enregistrement hébergé et vérification dans un seul parcours guidé, voir la fonction BIMI gérée de Palisade. Le récepteur garde la décision finale d’affichage.

Ne passez pas un domaine en p=quarantine ou p=reject uniquement pour obtenir un logo. Identifiez d’abord les sources d’envoi légitimes et confirmez l’authentification alignée des flux importants.

L’enjeu se mesure : les données d’adoption BIMI de Palisade sur 100 000 domaines montrent combien de domaines prêts pour l’application n’ont pas encore publié de BIMI, avec un entonnoir réutilisable et des chiffres téléchargeables.

Qui prend en charge BIMI ?

Les grands fournisseurs ont adopté la norme : Gmail, Yahoo et Apple intègrent BIMI. Gmail et Apple Mail exigent un certificat de marque, alors que Yahoo affiche les logos d’enregistrements auto-déclarés, et Google a étendu la prise en charge BIMI de Gmail en mai 2023 pour ajouter une coche vérifiée à côté des expéditeurs participants. Publier un enregistrement valide montre le logo aux utilisateurs de ces services, sous réserve de la décision d’affichage de chaque fournisseur.

L’argument d’engagement repose sur cette visibilité. Une étude grand public de 2021 de Red Sift et Entrust a mesuré des taux d’ouverture jusqu’à 39 % plus élevés quand le logo de la marque s’affichait. C’est une indication, pas une garantie : le récepteur décide toujours si un logo apparaît, et les résultats varient selon l’audience et le fournisseur.

Exemple d’enregistrement BIMI

Un enregistrement BIMI est en général publié en TXT sous le sélecteur et le libellé _bimi. Le BIMI Group documente default comme sélecteur habituel, mais un récepteur peut utiliser le sélecteur de l’en-tête BIMI-Selector du message s’il existe.

Host: default._bimi.yourdomain.com
Type: TXT
Value: v=BIMI1; l=https://assets.yourdomain.com/logo.svg; a=https://assets.yourdomain.com/mark.pem

Ceci n’est qu’un exemple. Ne publiez pas ces URL d’exemple. Votre organisation doit héberger son propre logo approuvé et utiliser l’emplacement du certificat émis pour sa propre marque, si un récepteur visé l’exige.

Dans cet exemple :

• v=BIMI1 signale un enregistrement BIMI.
• l= indique l’emplacement HTTPS du logo SVG conforme BIMI.
• a= indique l’emplacement HTTPS d’un certificat de marque.

Un résultat DNS public peut montrer si l’enregistrement est visible. Il ne peut pas prouver qu’un message de production précis a réussi DMARC, que le récepteur a récupéré le logo ni qu’il a choisi de l’afficher.

Pourquoi BIMI dépend de DKIM, pas seulement de SPF

Gmail ajoute une coche bleue vérifiée par-dessus BIMI pour signaler que l’identité d’une marque est confirmée. La chronologie est souvent mal rapportée : les avatars de logo BIMI ont été généralisés dans Gmail en juillet 2021, mais la coche bleue est arrivée en mai 2023.

Quelques semaines après ce lancement, le chercheur en sécurité Chris Plummer a montré un message usurpé qui portait le logo d’UPS et la coche bleue de Google, et qui était une arnaque. La cause tenait à la façon dont BIMI s’appuyait sur SPF. DMARC réussit si l’un ou l’autre contrôle, SPF aligné ou DKIM aligné, réussit. Comme UPS autorisait une plateforme d’envoi tierce partagée dans son enregistrement SPF, un attaquant qui passait par cette même plateforme obtenait un succès SPF aligné, qui satisfaisait DMARC, qui qualifiait le message pour BIMI et la coche. On parle parfois de « SPF upgrade attack » : un message qui aurait dû paraître non fiable a été promu au rang de fiable.

En juin 2023, Google a dit à la presse qu’il cesserait de tenir un succès SPF aligné pour suffisant et exigerait DKIM pour qualifier un expéditeur pour BIMI et la coche. Une signature DKIM est un hachage cryptographique lié au message et signé avec la clé privée du domaine : un expéditeur ne peut donc pas hériter de la confiance en relayant ses e-mails via une infrastructure que la cible liste dans son SPF. Google n’a jamais reporté ce changement dans sa documentation BIMI publiée : le guide de configuration BIMI actuel de Google indique toujours qu’un domaine doit configurer SPF ou DKIM avant DMARC, et il lie la coche elle-même à un Verified Mark Certificate.

Pour un domaine d’envoi, cette ambiguïté ne change rien en pratique. Les consignes d’expéditeur de Google exigent SPF et DKIM de quiconque envoie plus de 5 000 messages par jour à des comptes Gmail, et la coche exige en plus un VMC ou un CMC. Vérifiez que le domaine signe avec un DKIM aligné et détient un certificat de marque avant de juger la coche accessible. Pour le parcours complet (certificat et prix), voir comment obtenir la coche bleue vérifiée de Gmail.

À vérifier ensuite

Partez de vos preuves :

• Si vous n’avez qu’un nom de domaine, utilisez le test BIMI pour inspecter l’enregistrement BIMI public et ses URL de logo ou de certificat.
• Si vous préparez un logo, vérifiez que le fichier final hébergé respecte le profil SVG BIMI. Gardez la source de design séparée du fichier BIMI publié.
• Si vous avez un message de test livré, inspectez ses résultats d’authentification. La RFC 8601 définit le champ d’en-tête Authentication-Results qui rapporte les évaluations d’authentification. Confirmez que le vrai chemin d’envoi obtient un succès SPF ou DKIM aligné avant d’accuser BIMI.
• Si un fournisseur n’affiche pas le logo, comparez ses exigences BIMI documentées au chemin exact du message, à l’enregistrement DNS, au logo et aux preuves de certificat. Ne déduisez pas sa décision du seul DNS.

Testez d’abord l’enregistrement BIMI

Une recherche BIMI est la bonne première étape quand vous avez un domaine d’envoi et devez confirmer ce que l’enregistrement DNS public publie.

Lancer le test BIMI

Une recherche publique ne peut prouver que l’expéditeur de production réussit DMARC, que chaque récepteur prend en charge BIMI ni qu’un fournisseur affichera le logo.

Reliez la préparation BIMI aux preuves d’envoi réelles

Un enregistrement correct aujourd’hui ne repère pas chaque source d’envoi qui pourrait échouer plus tard à l’alignement, ni si un changement de politique touche une autre application ou un sous-domaine. Palisade est un logiciel DMARC qui analyse les rapports agrégés DMARC, identifie les sources d’envoi et les problèmes d’authentification ou d’alignement, et crée des tickets de correction priorisés. Il peut proposer l’étape de politique suivante si les preuves le justifient ; un humain les examine et applique le changement DNS.

Commencez avec Palisade

Palisade ne change pas seul la politique DMARC et ne garantit ni le logo ni le placement en boîte de réception.