Hébergement BIMI : où et comment héberger votre logo SVG et votre certificat

Q: Puis-je héberger mon logo BIMI sur GitHub Pages ?

Oui pour le logo SVG : GitHub Pages sert les fichiers .svg avec le content-type image/svg+xml automatiquement. En revanche, GitHub Pages ne convient pas pour héberger un certificat PEM (content-type incorrect) et n'offre ni SLA de disponibilité ni surveillance. C'est une option acceptable pour du BIMI auto-déclaré (sans certificat), mais pas pour un déploiement complet avec VMC/CMC.

Par CaptainDNS
Publié le 31 mars 2026

TL;DR

L'hébergement du logo est le maillon le plus fragile de la chaîne BIMI : HTTPS obligatoire, TLS 1.2+, content-type image/svg+xml, zéro redirection, fichier inférieur à 32 Ko
53 % des enregistrements BIMI contiennent au moins une erreur : le mauvais hébergement du logo est l'une des causes les plus fréquentes
5 options comparées : serveur auto-géré, CDN (S3, R2), GitHub Pages, service dédié (CaptainDNS), plateforme intégrée (PowerDMARC, Valimail)
CaptainDNS héberge gratuitement logo SVG et certificat VMC/CMC, avec TLS automatique, statistiques d'accès et alerte d'expiration du certificat

Quand on parle de BIMI, les discussions techniques se concentrent presque toujours sur trois sujets : monter DMARC en enforcement, convertir le logo au format SVG Tiny-PS, obtenir un certificat VMC ou CMC. Ces étapes sont documentées, outillées, couvertes par des dizaines de guides. Mais il existe un quatrième sujet, rarement abordé, qui provoque pourtant autant d'échecs que les trois autres réunis : l'hébergement du fichier SVG.

Le principe est simple en apparence. L'enregistrement DNS BIMI contient une URL (l=) qui pointe vers votre logo. Les fournisseurs de messagerie (Gmail, Yahoo Mail, Apple Mail) récupèrent le fichier à cette URL pour l'afficher dans la boîte de réception. Si le serveur ne répond pas, si le certificat TLS est expiré, si le content-type est incorrect, si une redirection se glisse dans la chaîne : le logo n'apparaît pas. Aucun message d'erreur. Aucun retour. Le fournisseur passe simplement au message suivant sans logo.

Les chiffres confirment l'ampleur du problème. Selon une analyse URIports de 2025 portant sur le top 1 million de domaines, 53,6 % des enregistrements BIMI contiennent au moins une erreur. Parmi ces erreurs, les défaillances d'hébergement (serveur inaccessible, certificat TLS invalide, content-type incorrect, redirections) figurent parmi les causes les plus fréquentes. Ce n'est pas un problème de niche : c'est un problème structurel.

Ce guide couvre trois questions. D'abord, les exigences techniques exactes que votre serveur d'hébergement doit respecter. Ensuite, les cinq options d'hébergement disponibles, avec leurs forces et leurs limites. Enfin, un tutoriel pas-à-pas pour héberger votre logo et votre certificat gratuitement avec CaptainDNS, en moins de trois minutes.

Que vous soyez administrateur système, responsable technique ou consultant email, ce guide vous donne les clés pour choisir la bonne solution d'hébergement et éviter les erreurs qui cassent silencieusement votre déploiement BIMI.

Pourquoi l'hébergement du logo BIMI est-il critique ?

Pour comprendre pourquoi l'hébergement est si critique, il faut comprendre comment les fournisseurs de messagerie récupèrent le logo. Le processus suit une chaîne précise :

Un email arrive chez le fournisseur (Gmail, Yahoo, Apple Mail)
Le fournisseur vérifie l'authentification : SPF, DKIM, DMARC
Si DMARC passe en mode enforcement, le fournisseur cherche un enregistrement BIMI sur default._bimi.captaindns.com
Le fournisseur extrait l'URL du tag l= dans le record BIMI
Le fournisseur envoie une requête HTTPS GET vers cette URL
Si la réponse est HTTP 200 avec Content-Type: image/svg+xml et un fichier SVG valide : le logo est affiché
Si quoi que ce soit échoue dans cette chaîne : aucun logo, aucune notification

Le point crucial est l'étape 5. Le fournisseur de messagerie n'est pas un navigateur web. C'est un agent automatisé qui applique des règles strictes et ne tolère aucune déviation.

Les exigences techniques de l'hébergement BIMI

Voici les exigences que votre serveur d'hébergement doit respecter pour que les fournisseurs de messagerie puissent récupérer le logo :

Exigence	Détail	Conséquence si non respectée
HTTPS obligatoire	TLS 1.2 minimum, certificat valide (pas auto-signé)	Logo rejeté silencieusement
Content-Type exact	`image/svg+xml` (pas `text/plain`, `application/octet-stream`)	Logo rejeté
Réponse HTTP 200	Pas de redirection 301/302	Logo rejeté (les clients mail ne suivent pas les redirections)
Taille fichier	Inférieure à 32 Ko	Logo rejeté
Disponibilité 24/7	Pas de maintenance prolongée, pas de rate limiting	Logo absent pendant l'indisponibilité
Pas de géo-blocage	Le serveur de messagerie peut être n'importe où	Logo absent pour certains fournisseurs

Pourquoi ces exigences sont-elles plus strictes que l'hébergement web classique ?

Sur le web classique, un navigateur suit les redirections, affiche une page d'erreur, relance la requête si elle échoue. Un fournisseur de messagerie qui récupère un logo BIMI ne fait rien de tout cela.

Pas de suivi de redirections. Si votre serveur répond 301 ou 302 (même pour un simple HTTP vers HTTPS), le fournisseur considère que le fichier est inaccessible. C'est le piège le plus courant pour les équipes qui configurent leur serveur web avec une redirection HTTP vers HTTPS par défaut. L'URL dans le record BIMI doit pointer directement vers la destination finale.

Pas de retry automatique. Si votre serveur est indisponible au moment où Gmail tente de récupérer le logo, le logo ne s'affiche pas pour cet email. Certains fournisseurs comme Gmail utilisent un cache et peuvent réessayer ultérieurement, mais ce comportement n'est ni garanti ni documenté.

Pas de négociation de content-type. Le fournisseur attend image/svg+xml. S'il reçoit text/plain (défaut de nombreux serveurs pour les fichiers .svg) ou application/octet-stream, il rejette le fichier. Il n'essaie pas de détecter le format en analysant le contenu.

Pas de tolérance aux erreurs TLS. Un certificat auto-signé, un certificat expiré, une chaîne de certificats incomplète : tout cela provoque un rejet immédiat. Les fournisseurs de messagerie ne proposent pas de "continuer malgré l'erreur" comme un navigateur web.

Un comportement de cache variable. Certains fournisseurs comme Gmail mettent le logo en cache après la première récupération réussie. Ce cache masque les problèmes d'hébergement temporaires : le logo continue de s'afficher même si le serveur est tombé. Mais ce cache a une durée de vie limitée et non documentée. Quand il expire, le fournisseur retente de récupérer le logo. Si le serveur est toujours indisponible à ce moment-là, le logo disparaît. Le cache crée un faux sentiment de sécurité : tout semble fonctionner alors que l'infrastructure sous-jacente est défaillante.

Pour les exigences du fichier SVG lui-même (format Tiny-PS, dimensions, contenu), consultez notre guide de création de logo BIMI.

Les cinq options d'hébergement comparées

Il n'existe pas de solution unique pour héberger un logo BIMI. Le choix dépend de votre infrastructure existante, de vos compétences techniques et de vos besoins en surveillance. Voici les cinq options les plus courantes, avec leurs avantages, leurs limites et leur cas d'usage idéal.

Serveur web auto-géré (nginx, apache)

L'approche la plus directe : héberger le fichier SVG sur votre propre serveur web. Si vous disposez déjà d'un serveur nginx ou apache exposé sur Internet, il suffit en théorie de déposer le fichier SVG dans un répertoire accessible.

Configuration nginx typique :

location /bimi/logo.svg {
    root /var/www/bimi;
    types {
        image/svg+xml svg;
    }
    add_header Content-Type "image/svg+xml";
    add_header Cache-Control "public, max-age=86400";
}

Configuration apache :

<Directory /var/www/bimi>
    AddType image/svg+xml .svg
</Directory>

Avantages :

Contrôle total sur la configuration
Pas de dépendance à un service tiers
Aucun coût supplémentaire si le serveur existe déjà

Limites :

Gestion manuelle du certificat TLS (renouvellement, chaîne de certificats)
Responsabilité de la disponibilité 24/7
Risque d'interruption lors des maintenances serveur
Configuration content-type à faire manuellement
Pas de surveillance intégrée (il faut mettre en place un monitoring externe)

Cas d'usage idéal : équipes avec une infrastructure existante, une équipe ops en place et une habitude de gestion de serveurs web. Si vous gérez déjà des dizaines de sites web, ajouter un fichier SVG est trivial. Si votre seul serveur est un VPS que personne ne surveille, c'est un risque.

Piège fréquent : la redirection HTTP vers HTTPS. La plupart des configurations nginx et apache incluent un bloc server qui redirige le port 80 vers le port 443. Si votre URL BIMI est en HTTPS, pas de problème. Mais si quelqu'un copie l'URL HTTP par erreur dans le record DNS, la redirection 301 provoquera un rejet silencieux par le fournisseur de messagerie.

CDN générique avec stockage cloud

Les services de stockage cloud avec CDN sont une option populaire. Le fichier est hébergé dans un bucket (AWS S3, Cloudflare R2, Google Cloud Storage) et servi via un CDN (Cloudflare, AWS CloudFront, Cloud CDN).

Déploiement AWS S3 + CloudFront :

# Upload du fichier avec le bon content-type
aws s3 cp logo.svg s3://mon-bucket-bimi/logo.svg \
  --content-type "image/svg+xml" \
  --cache-control "public, max-age=86400"

# Vérification
curl -I https://d1234abcd.cloudfront.net/logo.svg

Déploiement Cloudflare R2 :

# Upload via wrangler
npx wrangler r2 object put mon-bucket-bimi/logo.svg \
  --file=logo.svg \
  --content-type="image/svg+xml"

Avantages :

Disponibilité très élevée (SLA 99,9 % et plus)
TLS géré automatiquement par le CDN
Distribution géographique (réduction de la latence)
Coût très faible (quelques centimes par mois pour un seul fichier)

Limites :

Le content-type doit être défini explicitement lors de l'upload (si vous oubliez, le bucket sert application/octet-stream)
Le CDN peut ajouter des redirections si le domaine personnalisé n'est pas correctement configuré
Pas de validation SVG : vous pouvez uploader un fichier invalide sans le savoir
Pas d'alerte d'expiration pour les certificats VMC/CMC hébergés dans le même bucket
Configuration initiale non triviale (IAM, bucket policy, distribution CDN)

Cas d'usage idéal : équipes qui utilisent déjà AWS, Cloudflare ou GCP pour d'autres ressources. L'infrastructure est déjà en place, les compétences sont là, et le coût marginal est quasi nul.

Piège fréquent : le content-type par défaut. Si vous uploadez un fichier .svg dans un bucket S3 sans spécifier le content-type, S3 le sert avec application/octet-stream. Le fichier est téléchargé au lieu d'être interprété comme une image. Les fournisseurs de messagerie le rejettent.

Un autre piège courant avec les CDN est la configuration du domaine personnalisé. Si vous associez un nom de domaine à votre distribution CloudFront ou à votre bucket R2, vous devez vous assurer que la résolution DNS pointe directement vers le CDN sans redirection intermédiaire. Une mauvaise configuration du CNAME ou de la zone DNS peut introduire une redirection 301 invisible qui casse la récupération du logo par les fournisseurs de messagerie.

GitHub Pages

GitHub Pages est une option gratuite qui fonctionne pour les cas simples. Créez un dépôt, déposez le fichier SVG, activez GitHub Pages : le fichier est servi en HTTPS avec le content-type correct.

Déploiement :

# Créer un dépôt dédié
mkdir bimi-assets && cd bimi-assets
git init
cp ~/logo.svg ./logo.svg
git add logo.svg
git commit -m "add BIMI logo"
git remote add origin git@github.com:captaindns/bimi-assets.git
git push -u origin main

Activez GitHub Pages dans les paramètres du dépôt (source : branche main). L'URL sera : https://captaindns.github.io/bimi-assets/logo.svg

Avantages :

Gratuit
TLS automatique (Let's Encrypt via GitHub)
Content-type correct pour les fichiers .svg (géré automatiquement)
Mise à jour simple (git push)

Limites :

Aucun SLA de disponibilité (GitHub Pages est conçu pour des sites statiques, pas pour du hosting critique)
Hébergement de certificats PEM problématique : GitHub Pages sert les fichiers .pem avec un content-type incorrect (text/plain)
Pas de statistiques d'accès (vous ne savez pas si les fournisseurs récupèrent le logo)
Pas d'alerte d'expiration de certificat
Dépendance à GitHub (changements de politique, interruptions de service)
Pas de domaine personnalisé par défaut (URL github.io)

Cas d'usage idéal : projets personnels, tests, déploiement BIMI auto-déclaré (sans certificat VMC/CMC). Si vous voulez tester BIMI sur Yahoo Mail avant d'investir dans un certificat, GitHub Pages est un bon point de départ.

Piège fréquent : le certificat VMC/CMC. Si vous tentez d'héberger un fichier .pem sur GitHub Pages, le content-type sera text/plain. Les fournisseurs de messagerie peuvent rejeter le certificat. Pour un déploiement BIMI complet (avec certificat), GitHub Pages ne convient pas.

Il faut aussi garder à l'esprit que GitHub Pages a des limites de bande passante (100 Go/mois) et de taille de site (1 Go). Pour un seul fichier SVG, ces limites ne seront jamais atteintes, mais elles soulignent que le service n'est pas conçu pour du hosting de production critique. En cas de pic de trafic (un FAI qui met en cache le logo et le re-télécharge fréquemment), GitHub Pages pourrait temporairement limiter l'accès.

Service d'hébergement BIMI dédié (CaptainDNS)

Un service conçu spécifiquement pour héberger les assets BIMI. CaptainDNS prend en charge l'ensemble de la chaîne : upload, validation, hébergement, génération du record DNS, surveillance.

Fonctionnement :

Vous créez un profil BIMI pour votre domaine
Vous vérifiez la propriété du domaine (record TXT)
Vous uploadez votre logo SVG (validé automatiquement au format Tiny-PS)
Vous uploadez votre certificat VMC/CMC (optionnel)
CaptainDNS génère l'enregistrement DNS BIMI complet
Vous copiez le record dans votre zone DNS

Les fichiers sont servis depuis assets.captaindns.com avec TLS automatique (Let's Encrypt), le content-type correct et sans aucune redirection.

Avantages :

Configuration zéro : pas de serveur à gérer, pas de content-type à configurer
Validation SVG Tiny-PS à l'upload : si le fichier n'est pas conforme, il est rejeté avec un message d'erreur explicite
Hébergement du certificat VMC/CMC avec extraction automatique des métadonnées (émetteur, dates de validité, type)
Alerte d'expiration du certificat (30 jours avant l'échéance)
Statistiques d'accès : nombre de requêtes reçues et horodatage de la dernière requête
Génération automatique de l'enregistrement DNS BIMI
Gratuit pour les 5 premiers domaines

Limites :

Dépendance à un service tiers (comme toute solution hébergée)
Domaine d'hébergement fixe (assets.captaindns.com, pas de domaine personnalisé pour l'URL)

Cas d'usage idéal : toute organisation qui veut un hébergement BIMI fiable sans se soucier de la configuration technique. Particulièrement adapté aux PME sans équipe ops dédiée.

Plateforme DMARC intégrée

Les plateformes de surveillance DMARC comme PowerDMARC, Valimail ou Red Sift proposent souvent l'hébergement BIMI comme fonctionnalité incluse dans leur offre. Le logo et le certificat sont uploadés dans le tableau de bord de la plateforme, qui se charge de l'hébergement et de la génération du record DNS.

Avantages :

Intégration native avec la surveillance DMARC (vision unifiée de l'authentification email)
Hébergement géré (TLS, content-type, disponibilité)
Support et accompagnement inclus dans l'abonnement

Limites :

Coût élevé : ces plateformes facturent entre 50 et 500 $/mois (voire plus) pour la suite DMARC complète. L'hébergement BIMI n'est qu'une fonctionnalité parmi d'autres
Vendor lock-in : si vous changez de plateforme, l'URL du logo change et vous devez mettre à jour votre record DNS
Fonctionnalités BIMI variables : certaines plateformes n'offrent pas de validation SVG à l'upload ni d'alerte d'expiration de certificat

Cas d'usage idéal : grandes entreprises qui utilisent déjà une plateforme DMARC pour la surveillance de leur authentification email. Dans ce cas, l'hébergement BIMI est un bonus inclus dans l'abonnement existant.

Tableau comparatif des cinq options

Critère	Serveur auto-géré	CDN (S3/R2)	GitHub Pages	CaptainDNS	Plateforme intégrée
Coût	Variable	0-5 $/mois	Gratuit	Gratuit	50-500+ $/mois
Configuration	Manuelle	Moyenne	Simple	Aucune	Aucune
Content-Type automatique	Non	Configuration requise	Oui (SVG)	Oui	Oui
TLS géré	Manuel	Automatique	Automatique	Automatique	Automatique
Génération record DNS	Non	Non	Non	Oui	Oui
Hébergement certificat	Oui	Oui	Non (PEM)	Oui	Oui
Alerte expiration certificat	Non	Non	Non	Oui	Variable
Statistiques d'accès	Logs serveur	CloudWatch/R2 Analytics	Non	Oui	Variable
Validation SVG à l'upload	Non	Non	Non	Oui (SVG Tiny-PS)	Variable

Le choix dépend de votre situation. Si vous avez une équipe ops et une infrastructure cloud en place, un CDN est une excellente option. Si vous cherchez la solution la plus simple et la plus fiable sans rien configurer, CaptainDNS est conçu pour ça. Si vous utilisez déjà une plateforme DMARC, vérifiez si l'hébergement BIMI est inclus dans votre abonnement.

Un critère souvent oublié dans ce choix est la pérennité de l'URL. L'URL du logo est gravée dans votre record BIMI DNS. Si vous changez de solution d'hébergement, vous devez aussi mettre à jour le record DNS, ce qui implique un délai de propagation pendant lequel certains fournisseurs récupèrent l'ancienne URL (devenue inaccessible) et d'autres la nouvelle. Pour minimiser ce risque, privilégiez une solution que vous n'aurez pas besoin de changer dans les prochaines années.

Les cinq erreurs d'hébergement qui cassent votre BIMI

Même avec la bonne option d'hébergement, des erreurs de configuration peuvent empêcher l'affichage du logo. Voici les cinq erreurs les plus fréquentes, avec pour chacune le symptôme, la commande de diagnostic et la solution.

Erreur 1 : HTTP au lieu de HTTPS

Symptôme : le logo n'apparaît chez aucun fournisseur de messagerie, malgré un record BIMI valide et un fichier SVG conforme.

Cause : l'URL dans le tag l= du record BIMI utilise http:// au lieu de https://. Ou bien le record contient https:// mais le serveur ne répond que sur le port 80 (HTTP) et redirige vers HTTPS. La spécification BIMI exige une URL HTTPS qui répond directement en 200, sans aucune redirection.

Diagnostic :

# Vérifier le record BIMI
dig default._bimi.captaindns.com TXT +short

# Tester la réponse HTTPS directe
curl -I https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg

Vérifiez que :

L'URL dans le record commence par https://
La réponse curl renvoie un code HTTP/2 200 (pas 301, 302, 307)

Solution : assurez-vous que l'URL dans le record BIMI pointe directement vers l'endpoint HTTPS. Ne comptez pas sur une redirection HTTP vers HTTPS : les fournisseurs de messagerie ne la suivent pas. Si votre serveur ne supporte que HTTP, il faut configurer TLS avant de déployer BIMI.

Cette erreur est particulièrement insidieuse car elle est invisible lors des tests manuels. Si vous tapez l'URL HTTP dans un navigateur, celui-ci suit la redirection et affiche le fichier normalement. Tout semble fonctionner. Mais les agents automatisés des fournisseurs de messagerie s'arrêtent au premier code de réponse : s'il n'est pas 200, le fichier est considéré comme inaccessible.

Erreur 2 : content-type incorrect

Symptôme : le fichier SVG est accessible en HTTPS, le code HTTP est 200, mais le logo n'apparaît pas.

Cause : le serveur renvoie un content-type incorrect. Les cas les plus fréquents :

text/plain : défaut de nombreux serveurs quand le type MIME n'est pas configuré pour l'extension .svg
application/octet-stream : défaut de certains services de stockage cloud (S3 sans configuration explicite)
text/html : si le serveur renvoie une page d'erreur HTML au lieu du fichier SVG

Diagnostic :

curl -I https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg

Cherchez la ligne Content-Type dans la réponse. Elle doit contenir exactement image/svg+xml :

HTTP/2 200
content-type: image/svg+xml

Solution selon votre serveur :

nginx : ajoutez dans votre bloc server ou location :

types {
    image/svg+xml svg;
}

apache : ajoutez dans votre .htaccess ou configuration globale :

AddType image/svg+xml .svg

S3 : spécifiez le content-type lors de l'upload :

aws s3 cp logo.svg s3://bucket/logo.svg --content-type "image/svg+xml"

R2 : spécifiez le content-type dans la commande wrangler :

npx wrangler r2 object put bucket/logo.svg --file=logo.svg --content-type="image/svg+xml"

Erreur 3 : redirections HTTP

Symptôme : curl renvoie un code 200 quand vous testez dans un navigateur, mais les fournisseurs de messagerie ne récupèrent pas le logo.

Cause : il y a une ou plusieurs redirections dans la chaîne. Les navigateurs les suivent automatiquement et vous montrent le résultat final, ce qui masque le problème. Les fournisseurs de messagerie BIMI ne suivent pas les redirections.

Les redirections les plus courantes :

HTTP vers HTTPS (301 de http:// vers https://)
www vers non-www (301 de www.captaindns.com vers captaindns.com)
Ancienne URL vers nouvelle URL (301 après réorganisation du serveur)
Trailing slash (301 de /bimi/logo.svg/ vers /bimi/logo.svg)

Diagnostic :

# Suivre la chaîne de redirections
curl -IL https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg

Si vous voyez plusieurs réponses HTTP (301, 302, 307) avant le 200 final, c'est le problème. La première réponse doit être un 200 direct.

Solution : mettez à jour l'URL dans votre record BIMI pour pointer vers la destination finale, celle qui renvoie directement un 200. Si votre serveur redirige http:// vers https://, utilisez l'URL https:// dans le record. Si votre serveur redirige www vers le domaine nu, utilisez le domaine nu dans le record.

Erreur 4 : serveur indisponible

Symptôme : le logo apparaît par intermittence, ou bien il apparaissait avant et a disparu.

Cause : le serveur d'hébergement est temporairement inaccessible. Les causes possibles :

Maintenance planifiée du serveur
Dépassement de quota ou rate limiting
Restriction géographique (le serveur bloque certaines IP)
Saturation du serveur (trop de requêtes simultanées)
Serveur virtuel éteint (VPS non surveillé)

Diagnostic :

# Vérifier la disponibilité depuis votre machine
curl -o /dev/null -s -w "%{http_code}" https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg

# Tester depuis une IP différente (optionnel, via un service en ligne)

Si le code HTTP n'est pas 200, le serveur est inaccessible.

Solution : mettez en place un monitoring externe qui vérifie la disponibilité de l'URL du logo toutes les 5 minutes. Des services comme UptimeRobot, Pingdom ou BetterStack peuvent alerter en cas d'indisponibilité. CaptainDNS fournit un compteur de requêtes et l'horodatage de la dernière requête servie : si le compteur ne bouge plus alors que vous envoyez des emails, c'est un indicateur de problème.

Pour un serveur auto-géré, évitez les maintenances longues sans serveur de secours. Pour un CDN ou un service dédié, le risque d'indisponibilité est beaucoup plus faible grâce à la redondance intégrée.

Erreur 5 : certificat TLS du serveur expiré

Symptôme : le logo fonctionnait et a soudainement disparu chez tous les fournisseurs.

Cause : le certificat TLS du serveur d'hébergement a expiré. Il ne s'agit pas du certificat VMC/CMC (qui est un fichier hébergé), mais du certificat HTTPS du serveur lui-même. Les fournisseurs de messagerie refusent de se connecter à un serveur dont le certificat TLS est invalide.

Cette erreur est distincte de l'expiration du certificat VMC/CMC. Ici, c'est le serveur lui-même qui est rejeté, pas le certificat BIMI.

Diagnostic :

# Vérifier la validité du certificat TLS du serveur
curl -vI https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg 2>&1 | grep "expire date"

# Ou avec openssl
echo | openssl s_client -connect assets.captaindns.com:443 2>/dev/null | openssl x509 -noout -dates

Solution : activez le renouvellement automatique du certificat TLS. Let's Encrypt propose des certificats gratuits avec renouvellement automatique via Certbot ou des alternatives comme acme.sh. Les CDN et services managés (Cloudflare, CaptainDNS) gèrent le renouvellement TLS automatiquement.

Si vous utilisez un serveur auto-géré, configurez un cron job pour le renouvellement :

# Renouvellement automatique avec Certbot
0 0 * * * certbot renew --quiet

Pour un diagnostic complet de toutes les erreurs BIMI, consultez notre guide logo BIMI qui ne s'affiche pas : 5 erreurs à corriger. Vous pouvez aussi utiliser l'outil de vérification BIMI de CaptainDNS pour valider automatiquement l'ensemble de la chaîne.

Héberger le certificat VMC ou CMC

L'hébergement du logo SVG n'est que la moitié du problème. Si vous disposez d'un certificat VMC (Verified Mark Certificate) ou CMC (Common Mark Certificate), il doit lui aussi être hébergé en HTTPS et accessible aux fournisseurs de messagerie.

Le certificat est référencé dans le tag a= du record BIMI :

default._bimi.captaindns.com. 3600 IN TXT "v=BIMI1; l=https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg; a=https://assets.captaindns.com/bimi/cert/captaindns.com/vmc.pem"

Les exigences d'hébergement du certificat

Les exigences sont similaires à celles du logo, avec quelques spécificités :

HTTPS obligatoire. Comme pour le logo, le certificat doit être servi en HTTPS avec un certificat TLS valide sur le serveur. Pas de redirection, pas d'erreur TLS.

Content-type pour les fichiers PEM. Le content-type attendu pour un certificat PEM est application/x-pem-file ou application/pkix-cert. Certains serveurs servent les fichiers .pem avec text/plain, ce qui peut fonctionner chez certains fournisseurs mais n'est pas conforme à la recommandation.

Réponse HTTP 200 directe. Comme pour le logo, aucune redirection n'est tolérée.

Le problème de l'expiration du certificat

Les certificats VMC et CMC ont une durée de validité limitée, généralement un an. Quand le certificat expire :

Gmail cesse d'afficher le logo (le certificat est obligatoire pour Gmail)
Le record BIMI reste valide, mais le champ a= pointe vers un certificat expiré
Aucune notification automatique de la part de Gmail ou Yahoo

C'est un problème insidieux. Contrairement à un certificat TLS de serveur web (qui provoque des erreurs visibles dans le navigateur), l'expiration d'un certificat VMC/CMC passe inaperçue. Le logo disparaît silencieusement de Gmail, et personne ne s'en rend compte avant qu'un collègue ou un client ne le signale.

Le renouvellement d'un certificat VMC ou CMC n'est pas instantané : il faut contacter l'autorité de certification, fournir les preuves nécessaires (marque déposée pour un VMC, preuve d'usage pour un CMC), attendre la validation. Le processus peut prendre de quelques jours à plusieurs semaines. Si vous attendez l'expiration pour lancer le renouvellement, votre logo sera absent de Gmail pendant toute cette période. C'est pourquoi une alerte 30 jours avant l'échéance est essentielle.

Logo et certificat sur des serveurs différents

Le record BIMI contient deux champs séparés : l= pour le logo et a= pour le certificat. Chacun peut pointer vers un serveur différent. C'est une flexibilité utile si vous voulez héberger le logo sur un CDN rapide et le certificat sur un service dédié qui gère les alertes d'expiration.

Exemple de record avec des serveurs différents :

default._bimi.captaindns.com. 3600 IN TXT "v=BIMI1; l=https://cdn.captaindns.com/bimi/logo.svg; a=https://assets.captaindns.com/bimi/cert/captaindns.com/vmc.pem"

La solution CaptainDNS pour les certificats

CaptainDNS prend en charge l'hébergement du certificat VMC/CMC avec plusieurs fonctionnalités spécifiques :

Extraction automatique des métadonnées : à l'upload, CaptainDNS analyse le certificat PEM et extrait l'émetteur, les dates de validité et le type (VMC ou CMC)
Alerte d'expiration : 30 jours avant l'échéance du certificat, CaptainDNS envoie une alerte pour vous rappeler de le renouveler
Statistiques d'accès : comme pour le logo, CaptainDNS compte les requêtes reçues et enregistre l'horodatage de la dernière requête
Content-type correct : le certificat est servi avec le content-type approprié, sans configuration de votre part

Pour un guide complet sur les différences entre VMC et CMC et leur compatibilité avec les fournisseurs de messagerie, consultez notre article sur la compatibilité VMC, CMC et DNS.

Héberger votre logo BIMI en 3 minutes avec CaptainDNS

Ce tutoriel détaille les six étapes pour héberger votre logo SVG et votre certificat VMC/CMC avec CaptainDNS. Le processus complet prend moins de trois minutes (hors propagation DNS).

Étape 1 : créer un profil BIMI

Connectez-vous à votre compte CaptainDNS (ou créez-en un gratuitement). Accédez à la section BIMI Hosting depuis le tableau de bord. Cliquez sur Nouveau profil BIMI et entrez votre domaine (par exemple captaindns.com).

Le sélecteur par défaut (default) convient dans la grande majorité des cas. Un sélecteur personnalisé n'est utile que si vous avez besoin de logos différents pour des sous-marques ou des départements qui envoient des emails depuis le même domaine.

Étape 2 : vérifier la propriété du domaine

CaptainDNS vous demande de prouver que vous contrôlez le domaine. Ajoutez un enregistrement TXT dans votre zone DNS avec la valeur fournie par CaptainDNS :

_captaindns-verify.captaindns.com. 3600 IN TXT "captaindns-verification=abc123xyz"

La vérification est automatique. CaptainDNS interroge votre DNS à intervalles réguliers et valide dès que le record est détecté. La propagation DNS peut prendre de quelques minutes à quelques heures selon votre registrar.

Étape 3 : uploader votre logo SVG

Une fois le domaine vérifié, uploadez votre fichier SVG Tiny-PS. CaptainDNS valide le fichier automatiquement à l'upload :

Vérification du format SVG Tiny-PS (attributs version="1.2" et baseProfile="tiny-ps")
Vérification du viewBox carré
Détection des éléments interdits (<script>, <style>, <image>, <animate>)
Vérification de la taille du fichier (inférieure à 32 Ko)

Si le fichier n'est pas conforme, CaptainDNS affiche un message d'erreur explicite avec la liste des problèmes détectés. Dans ce cas, utilisez le convertisseur SVG Tiny-PS pour corriger automatiquement votre fichier, puis réuploadez la version convertie.

Si le fichier est conforme, CaptainDNS l'héberge immédiatement à une URL stable :

https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg

Étape 4 : uploader votre certificat (optionnel)

Si vous disposez d'un certificat VMC ou CMC, uploadez le fichier PEM. CaptainDNS extrait automatiquement les métadonnées :

Émetteur : DigiCert, Entrust, etc.
Dates de validité : début et fin de la période de validité
Type : VMC (Verified Mark Certificate) ou CMC (Common Mark Certificate)

L'alerte d'expiration est activée automatiquement : CaptainDNS vous prévient 30 jours avant l'échéance pour que vous puissiez renouveler le certificat sans interruption d'affichage.

Le certificat est hébergé à une URL stable :

https://assets.captaindns.com/bimi/cert/captaindns.com/vmc.pem

Étape 5 : copier et publier le record DNS

CaptainDNS génère automatiquement l'enregistrement DNS BIMI complet, prêt à être copié dans votre zone DNS.

Avec certificat :

default._bimi.captaindns.com. 3600 IN TXT "v=BIMI1; l=https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg; a=https://assets.captaindns.com/bimi/cert/captaindns.com/vmc.pem"

Sans certificat (auto-déclaré) :

default._bimi.captaindns.com. 3600 IN TXT "v=BIMI1; l=https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg; a=;"

Copiez le record et ajoutez-le dans votre zone DNS chez votre registrar ou hébergeur DNS. Le type d'enregistrement est TXT, le nom est default._bimi.captaindns.com (remplacez par votre domaine).

Attention à la syntaxe lors de la copie : certains panneaux de gestion DNS ajoutent automatiquement le domaine en suffixe. Dans ce cas, entrez uniquement default._bimi comme nom d'hôte, sans le domaine. Vérifiez avec dig après la création pour confirmer que le record est correctement résolu.

Étape 6 : vérifier le déploiement

Après la propagation DNS (quelques minutes à quelques heures), vérifiez que tout fonctionne. CaptainDNS propose un outil de vérification intégré qui contrôle l'ensemble de la chaîne :

Résolution DNS du record BIMI
Accessibilité HTTPS du logo SVG
Validation du content-type
Vérification du format SVG Tiny-PS
Accessibilité HTTPS du certificat (si présent)
Validité du certificat VMC/CMC (si présent)

Vous pouvez aussi vérifier manuellement avec dig et curl :

# Vérifier le record DNS
dig default._bimi.captaindns.com TXT +short

# Vérifier l'accès au logo
curl -I https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg

# Vérifier l'accès au certificat
curl -I https://assets.captaindns.com/bimi/cert/captaindns.com/vmc.pem

Fonctionnalités incluses dans l'hébergement CaptainDNS

En résumé, l'hébergement BIMI CaptainDNS inclut :

Jusqu'à 5 domaines gratuits : aucun coût pour les petites organisations
Statistiques d'accès : nombre de requêtes servies et horodatage de la dernière requête, pour vérifier que les fournisseurs récupèrent bien votre logo
Alertes d'expiration du certificat : notification 30 jours avant l'échéance du VMC/CMC
TLS automatique : certificat Let's Encrypt géré automatiquement, sans intervention
Validation SVG Tiny-PS à l'upload : rejet immédiat des fichiers non conformes avec un message d'erreur explicite
Génération du record DNS : l'enregistrement BIMI complet est généré automatiquement, prêt à copier

Checklist d'hébergement BIMI

Avant de considérer votre hébergement comme opérationnel, vérifiez ces huit points :

✅ URL en HTTPS (pas HTTP)
✅ Certificat TLS valide et non expiré sur le serveur d'hébergement
✅ TLS 1.2 ou version supérieure
✅ Réponse HTTP 200 directe (aucune redirection 301/302)
✅ Content-Type image/svg+xml pour le logo
✅ Taille du fichier SVG inférieure à 32 Ko
✅ Serveur accessible 24/7 sans restriction géographique
✅ Si certificat VMC/CMC : hébergé en HTTPS avec Content-Type approprié et date d'expiration surveillée

Vous pouvez vérifier les points 1 à 6 en une seule commande curl :

curl -IL -o /dev/null -s -w "HTTP: %{http_code}\nContent-Type: %{content_type}\nSize: %{size_download} bytes\nTLS: %{ssl_version}\n" https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg

Résultat attendu :

HTTP: 200
Content-Type: image/svg+xml
Size: 8432 bytes
TLS: TLSv1.3

Si l'un de ces points échoue, le logo ne s'affichera pas. Corrigez dans l'ordre : les problèmes HTTPS et TLS d'abord (sans connexion sécurisée, rien ne fonctionne), puis le content-type, puis la taille du fichier.

Pensez aussi à exécuter cette vérification depuis un serveur externe (pas uniquement depuis votre réseau local). Un serveur qui fonctionne parfaitement depuis votre bureau peut être bloqué par un pare-feu ou un WAF pour les requêtes provenant d'IP situées dans d'autres pays. Les fournisseurs de messagerie récupèrent le logo depuis leurs propres data centers, répartis dans le monde entier.

Plan d'action

Trois étapes pour sécuriser l'hébergement de votre logo BIMI :

Auditer votre hébergement actuel : utilisez la checklist ci-dessus et la commande curl pour vérifier que votre serveur répond aux huit exigences. Si vous avez déjà un record BIMI publié, testez-le avec l'outil BIMI Record Check de CaptainDNS
Migrer vers un hébergement fiable : si votre hébergement actuel ne satisfait pas toutes les exigences, migrez vers CaptainDNS pour du zero-config, ou vers un CDN si vous avez l'infrastructure en place. Dans tous les cas, éliminez les redirections et vérifiez le content-type
Mettre en place la surveillance : configurez une alerte d'expiration pour votre certificat VMC/CMC (CaptainDNS le fait automatiquement) et un monitoring de disponibilité pour l'URL du logo (UptimeRobot, BetterStack, ou les statistiques d'accès CaptainDNS)

FAQ

Où héberger mon logo BIMI ?

Cinq options : serveur auto-géré (nginx, apache), CDN (S3, Cloudflare R2), GitHub Pages, service dédié comme CaptainDNS, ou plateforme DMARC intégrée (PowerDMARC, Valimail). Le plus simple est un service dédié qui gère automatiquement HTTPS, content-type et génération du record DNS. CaptainDNS propose cet hébergement gratuitement pour les 5 premiers domaines.

Le logo BIMI doit-il obligatoirement être en HTTPS ?

Oui. HTTP est rejeté par tous les fournisseurs de messagerie. Le certificat TLS du serveur doit être valide (pas auto-signé) et en version 1.2 minimum. Un certificat expiré ou une chaîne de certificats incomplète provoque également un rejet silencieux du logo.

Quelle est la taille maximale d'un fichier SVG BIMI ?

La spécification recommande un maximum de 32 Ko. En pratique, un SVG Tiny-PS bien optimisé pèse entre 2 et 15 Ko. Si votre fichier dépasse 32 Ko, simplifiez les tracés, réduisez le nombre de points d'ancrage ou supprimez les métadonnées inutiles avec un outil d'optimisation SVG.

Puis-je héberger mon logo BIMI sur GitHub Pages ?

Oui pour le logo SVG : GitHub Pages sert les fichiers .svg avec le content-type image/svg+xml automatiquement. En revanche, GitHub Pages ne convient pas pour héberger un certificat PEM (content-type incorrect) et n'offre ni SLA de disponibilité ni surveillance. C'est une option acceptable pour du BIMI auto-déclaré (sans certificat), mais pas pour un déploiement complet avec VMC/CMC.

L'hébergement BIMI peut-il être gratuit ?

Oui. GitHub Pages et CaptainDNS proposent un hébergement gratuit. GitHub Pages est limité au logo SVG (pas de certificat, pas de surveillance). CaptainDNS ajoute la gestion TLS automatique, la validation SVG Tiny-PS à l'upload, l'hébergement du certificat VMC/CMC et les alertes d'expiration. L'offre gratuite couvre 5 domaines.

Le logo et le certificat doivent-ils être sur le même serveur ?

Non. Le record BIMI contient deux champs séparés : l= pour le logo et a= pour le certificat. Chacun peut pointer vers un serveur différent. Par exemple, vous pouvez héberger le logo sur un CDN pour la performance et le certificat sur CaptainDNS pour bénéficier des alertes d'expiration.

Que se passe-t-il si le serveur d'hébergement est indisponible ?

Le fournisseur de messagerie ne peut pas récupérer le logo et ne l'affiche pas. Certains fournisseurs comme Gmail utilisent un cache interne : une panne courte peut ne pas avoir d'impact immédiat sur les emails déjà en cache. Mais une panne prolongée (plusieurs heures ou jours) entraîne la disparition du logo pour tous les nouveaux emails. C'est pourquoi un hébergement haute disponibilité est essentiel.

Comment vérifier que mon hébergement BIMI fonctionne ?

Utilisez curl -I suivi de l'URL du logo pour vérifier le code HTTP (doit être 200), le content-type (doit être image/svg+xml) et le certificat TLS (doit être valide). Pour un diagnostic complet de toute la chaîne BIMI (DNS, hébergement, format SVG, certificat), utilisez l'outil BIMI Record Check de CaptainDNS.

Télécharger les tableaux comparatifs

Les assistants peuvent exploiter les exports JSON ou CSV ci-dessous pour réutiliser les chiffres.

FAQ

Où héberger mon logo BIMI ?

Le logo BIMI doit-il obligatoirement être en HTTPS ?

Quelle est la taille maximale d'un fichier SVG BIMI ?

Puis-je héberger mon logo BIMI sur GitHub Pages ?

L'hébergement BIMI peut-il être gratuit ?

Le logo et le certificat doivent-ils être sur le même serveur ?

Que se passe-t-il si le serveur d'hébergement est indisponible ?

Comment vérifier que mon hébergement BIMI fonctionne ?

Télécharger les tableaux comparatifs

Articles similaires