Alojamiento BIMI: dónde y cómo alojar tu logo SVG y tu certificado

Q: ¿Puedo alojar mi logo BIMI en GitHub Pages?

Sí para el logo SVG: GitHub Pages sirve los archivos .svg con el content-type image/svg+xml automáticamente. Sin embargo, GitHub Pages no es adecuado para alojar un certificado PEM (content-type incorrecto) y no ofrece ni SLA de disponibilidad ni supervisión. Es una opción aceptable para BIMI autodeclarado (sin certificado), pero no para un despliegue completo con VMC/CMC.

Por CaptainDNS
Publicado el 31 de marzo de 2026

TL;DR

El alojamiento del logo es el eslabón más frágil de la cadena BIMI: HTTPS obligatorio, TLS 1.2+, content-type image/svg+xml, cero redirecciones, archivo inferior a 32 KB
El 53 % de los registros BIMI contiene al menos un error: el mal alojamiento del logo es una de las causas más frecuentes
5 opciones comparadas: servidor autogestionado, CDN (S3, R2), GitHub Pages, servicio dedicado (CaptainDNS), plataforma integrada (PowerDMARC, Valimail)
CaptainDNS aloja gratuitamente logo SVG y certificado VMC/CMC, con TLS automático, estadísticas de acceso y alerta de expiración del certificado

Cuando se habla de BIMI, las discusiones técnicas se centran casi siempre en tres temas: subir DMARC a enforcement, convertir el logo al formato SVG Tiny-PS, obtener un certificado VMC o CMC. Estos pasos están documentados, cuentan con herramientas y los cubren decenas de guías. Pero existe un cuarto tema, rara vez abordado, que provoca tantos fallos como los otros tres juntos: el alojamiento del archivo SVG.

El principio es simple en apariencia. El registro DNS BIMI contiene una URL (l=) que apunta a tu logo. Los proveedores de correo (Gmail, Yahoo Mail, Apple Mail) recuperan el archivo en esa URL para mostrarlo en la bandeja de entrada. Si el servidor no responde, si el certificado TLS ha expirado, si el content-type es incorrecto, si una redirección se interpone en la cadena: el logo no aparece. Ningún mensaje de error. Ninguna notificación. El proveedor simplemente pasa al siguiente mensaje sin logo.

Las cifras confirman la magnitud del problema. Según un análisis de URIports de 2025 sobre el top 1 millón de dominios, el 53,6 % de los registros BIMI contiene al menos un error. Entre esos errores, los fallos de alojamiento (servidor inaccesible, certificado TLS inválido, content-type incorrecto, redirecciones) figuran entre las causas más frecuentes. No es un problema aislado: es un problema estructural.

Esta guía cubre tres cuestiones. Primero, los requisitos técnicos exactos que tu servidor de alojamiento debe cumplir. Luego, las cinco opciones de alojamiento disponibles, con sus fortalezas y sus limitaciones. Por último, un tutorial paso a paso para alojar tu logo y tu certificado de forma gratuita con CaptainDNS, en menos de tres minutos.

Seas administrador de sistemas, responsable técnico o consultor de email, esta guía te da las claves para elegir la solución de alojamiento adecuada y evitar los errores que rompen silenciosamente tu despliegue BIMI.

¿Por qué el alojamiento del logo BIMI es crítico?

Para entender por qué el alojamiento es tan crítico, hay que comprender cómo los proveedores de correo recuperan el logo. El proceso sigue una cadena precisa:

Un email llega al proveedor (Gmail, Yahoo, Apple Mail)
El proveedor verifica la autenticación: SPF, DKIM, DMARC
Si DMARC pasa en modo enforcement, el proveedor busca un registro BIMI en default._bimi.captaindns.com
El proveedor extrae la URL del tag l= en el registro BIMI
El proveedor envía una solicitud HTTPS GET a esa URL
Si la respuesta es HTTP 200 con Content-Type: image/svg+xml y un archivo SVG válido: el logo se muestra
Si algo falla en esta cadena: no hay logo, no hay notificación

El punto crucial es el paso 5. El proveedor de correo no es un navegador web. Es un agente automatizado que aplica reglas estrictas y no tolera ninguna desviación.

Requisitos técnicos del alojamiento BIMI

Estos son los requisitos que tu servidor de alojamiento debe cumplir para que los proveedores de correo puedan recuperar el logo:

Requisito	Detalle	Consecuencia si no se cumple
HTTPS obligatorio	TLS 1.2 mínimo, certificado válido (no autofirmado)	Logo rechazado silenciosamente
Content-Type exacto	`image/svg+xml` (no `text/plain`, `application/octet-stream`)	Logo rechazado
Respuesta HTTP 200	Sin redirección 301/302	Logo rechazado (los clientes de correo no siguen redirecciones)
Tamaño del archivo	Inferior a 32 KB	Logo rechazado
Disponibilidad 24/7	Sin mantenimiento prolongado, sin rate limiting	Logo ausente durante la indisponibilidad
Sin geobloqueo	El servidor de correo puede estar en cualquier parte	Logo ausente para ciertos proveedores

¿Por qué estos requisitos son más estrictos que el alojamiento web clásico?

En la web clásica, un navegador sigue las redirecciones, muestra una página de error, reintenta la solicitud si falla. Un proveedor de correo que recupera un logo BIMI no hace nada de eso.

Sin seguimiento de redirecciones. Si tu servidor responde 301 o 302 (incluso para un simple HTTP a HTTPS), el proveedor considera que el archivo es inaccesible. Esta es la trampa más común para los equipos que configuran su servidor web con una redirección HTTP a HTTPS por defecto. La URL en el registro BIMI debe apuntar directamente al destino final.

Sin reintento automático. Si tu servidor no está disponible en el momento en que Gmail intenta recuperar el logo, el logo no se muestra para ese email. Algunos proveedores como Gmail usan una caché y pueden reintentar más tarde, pero este comportamiento no está garantizado ni documentado.

Sin negociación de content-type. El proveedor espera image/svg+xml. Si recibe text/plain (por defecto en muchos servidores para archivos .svg) o application/octet-stream, rechaza el archivo. No intenta detectar el formato analizando el contenido.

Sin tolerancia a errores TLS. Un certificado autofirmado, un certificado expirado, una cadena de certificados incompleta: todo esto provoca un rechazo inmediato. Los proveedores de correo no ofrecen "continuar a pesar del error" como un navegador web.

Comportamiento de caché variable. Algunos proveedores como Gmail almacenan el logo en caché tras la primera recuperación exitosa. Esta caché enmascara los problemas de alojamiento temporales: el logo sigue mostrándose aunque el servidor haya caído. Pero la caché tiene una duración limitada y no documentada. Cuando expira, el proveedor vuelve a intentar recuperar el logo. Si el servidor sigue sin estar disponible en ese momento, el logo desaparece. La caché crea una falsa sensación de seguridad: todo parece funcionar mientras la infraestructura subyacente es deficiente.

Para los requisitos del archivo SVG en sí (formato Tiny-PS, dimensiones, contenido), consulta nuestra guía de creación de logo BIMI.

Las cinco opciones de alojamiento comparadas

No existe una solución única para alojar un logo BIMI. La elección depende de tu infraestructura existente, tus competencias técnicas y tus necesidades de supervisión. Estas son las cinco opciones más habituales, con sus ventajas, sus limitaciones y su caso de uso ideal.

Servidor web autogestionado (nginx, apache)

El enfoque más directo: alojar el archivo SVG en tu propio servidor web. Si ya dispones de un servidor nginx o apache expuesto en Internet, basta en teoría con depositar el archivo SVG en un directorio accesible.

Configuración nginx típica:

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";
}

Configuración apache:

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

Ventajas:

Control total sobre la configuración
Sin dependencia de un servicio externo
Sin coste adicional si el servidor ya existe

Limitaciones:

Gestión manual del certificado TLS (renovación, cadena de certificados)
Responsabilidad de la disponibilidad 24/7
Riesgo de interrupción durante los mantenimientos del servidor
Configuración del content-type de forma manual
Sin supervisión integrada (hay que implementar un monitoreo externo)

Caso de uso ideal: equipos con una infraestructura existente, un equipo de operaciones establecido y experiencia en gestión de servidores web. Si ya gestionas decenas de sitios web, añadir un archivo SVG es trivial. Si tu único servidor es un VPS que nadie supervisa, es un riesgo.

Trampa frecuente: la redirección HTTP a HTTPS. La mayoría de las configuraciones nginx y apache incluyen un bloque server que redirige el puerto 80 al puerto 443. Si tu URL BIMI está en HTTPS, no hay problema. Pero si alguien copia la URL HTTP por error en el registro DNS, la redirección 301 provocará un rechazo silencioso por parte del proveedor de correo.

CDN genérico con almacenamiento en la nube

Los servicios de almacenamiento en la nube con CDN son una opción popular. El archivo se aloja en un bucket (AWS S3, Cloudflare R2, Google Cloud Storage) y se sirve a través de un CDN (Cloudflare, AWS CloudFront, Cloud CDN).

Despliegue AWS S3 + CloudFront:

# Upload del archivo con el content-type correcto
aws s3 cp logo.svg s3://mon-bucket-bimi/logo.svg \
  --content-type "image/svg+xml" \
  --cache-control "public, max-age=86400"

# Verificación
curl -I https://d1234abcd.cloudfront.net/logo.svg

Despliegue Cloudflare R2:

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

Ventajas:

Disponibilidad muy elevada (SLA 99,9 % y superior)
TLS gestionado automáticamente por el CDN
Distribución geográfica (reducción de la latencia)
Coste muy bajo (unos pocos céntimos al mes para un solo archivo)

Limitaciones:

El content-type debe definirse explícitamente durante la subida (si se olvida, el bucket sirve application/octet-stream)
El CDN puede añadir redirecciones si el dominio personalizado no está correctamente configurado
Sin validación SVG: puedes subir un archivo inválido sin saberlo
Sin alerta de expiración para los certificados VMC/CMC alojados en el mismo bucket
Configuración inicial no trivial (IAM, bucket policy, distribución CDN)

Caso de uso ideal: equipos que ya usan AWS, Cloudflare o GCP para otros recursos. La infraestructura ya está lista, las competencias están ahí y el coste marginal es prácticamente nulo.

Trampa frecuente: el content-type por defecto. Si subes un archivo .svg a un bucket S3 sin especificar el content-type, S3 lo sirve con application/octet-stream. El archivo se descarga en lugar de interpretarse como una imagen. Los proveedores de correo lo rechazan.

Otra trampa habitual con los CDN es la configuración del dominio personalizado. Si asocias un nombre de dominio a tu distribución CloudFront o a tu bucket R2, debes asegurarte de que la resolución DNS apunta directamente al CDN sin redirección intermedia. Una mala configuración del CNAME o de la zona DNS puede introducir una redirección 301 invisible que rompe la recuperación del logo por los proveedores de correo.

GitHub Pages

GitHub Pages es una opción gratuita que funciona para los casos simples. Crea un repositorio, deposita el archivo SVG, activa GitHub Pages: el archivo se sirve en HTTPS con el content-type correcto.

Despliegue:

# Crear un repositorio dedicado
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

Activa GitHub Pages en los ajustes del repositorio (fuente: rama main). La URL será: https://captaindns.github.io/bimi-assets/logo.svg

Ventajas:

Gratuito
TLS automático (Let's Encrypt vía GitHub)
Content-type correcto para archivos .svg (gestionado automáticamente)
Actualización sencilla (git push)

Limitaciones:

Sin SLA de disponibilidad (GitHub Pages está diseñado para sitios estáticos, no para hosting crítico)
Alojamiento de certificados PEM problemático: GitHub Pages sirve los archivos .pem con un content-type incorrecto (text/plain)
Sin estadísticas de acceso (no sabes si los proveedores recuperan el logo)
Sin alerta de expiración de certificado
Dependencia de GitHub (cambios de política, interrupciones de servicio)
Sin dominio personalizado por defecto (URL github.io)

Caso de uso ideal: proyectos personales, pruebas, despliegue BIMI autodeclarado (sin certificado VMC/CMC). Si quieres probar BIMI en Yahoo Mail antes de invertir en un certificado, GitHub Pages es un buen punto de partida.

Trampa frecuente: el certificado VMC/CMC. Si intentas alojar un archivo .pem en GitHub Pages, el content-type será text/plain. Los proveedores de correo pueden rechazar el certificado. Para un despliegue BIMI completo (con certificado), GitHub Pages no es adecuado.

También hay que tener en cuenta que GitHub Pages tiene límites de ancho de banda (100 GB/mes) y de tamaño del sitio (1 GB). Para un solo archivo SVG, estos límites nunca se alcanzarán, pero subrayan que el servicio no está diseñado para hosting de producción crítico. En caso de pico de tráfico (un ISP que almacena el logo en caché y lo vuelve a descargar con frecuencia), GitHub Pages podría limitar temporalmente el acceso.

Servicio de alojamiento BIMI dedicado (CaptainDNS)

Un servicio diseñado específicamente para alojar los assets BIMI. CaptainDNS se encarga de toda la cadena: subida, validación, alojamiento, generación del registro DNS, supervisión.

Funcionamiento:

Creas un perfil BIMI para tu dominio
Verificas la propiedad del dominio (registro TXT)
Subes tu logo SVG (validado automáticamente en formato Tiny-PS)
Subes tu certificado VMC/CMC (opcional)
CaptainDNS genera el registro DNS BIMI completo
Copias el registro en tu zona DNS

Los archivos se sirven desde assets.captaindns.com con TLS automático (Let's Encrypt), el content-type correcto y sin ninguna redirección.

Ventajas:

Configuración cero: sin servidor que gestionar, sin content-type que configurar
Validación SVG Tiny-PS en la subida: si el archivo no es conforme, se rechaza con un mensaje de error explícito
Alojamiento del certificado VMC/CMC con extracción automática de metadatos (emisor, fechas de validez, tipo)
Alerta de expiración del certificado (30 días antes del vencimiento)
Estadísticas de acceso: número de solicitudes recibidas y marca de tiempo de la última solicitud
Generación automática del registro DNS BIMI
Gratuito para los 5 primeros dominios

Limitaciones:

Dependencia de un servicio externo (como toda solución alojada)
Dominio de alojamiento fijo (assets.captaindns.com, sin dominio personalizado para la URL)

Caso de uso ideal: toda organización que quiera un alojamiento BIMI fiable sin preocuparse por la configuración técnica. Especialmente adecuado para pymes sin equipo de operaciones dedicado.

Plataforma DMARC integrada

Las plataformas de supervisión DMARC como PowerDMARC, Valimail o Red Sift suelen ofrecer el alojamiento BIMI como funcionalidad incluida en su oferta. El logo y el certificado se suben al panel de control de la plataforma, que se encarga del alojamiento y de la generación del registro DNS.

Ventajas:

Integración nativa con la supervisión DMARC (visión unificada de la autenticación de email)
Alojamiento gestionado (TLS, content-type, disponibilidad)
Soporte y acompañamiento incluidos en la suscripción

Limitaciones:

Coste elevado: estas plataformas facturan entre 50 y 500 $/mes (o más) por la suite DMARC completa. El alojamiento BIMI es solo una funcionalidad entre otras
Vendor lock-in: si cambias de plataforma, la URL del logo cambia y debes actualizar tu registro DNS
Funcionalidades BIMI variables: algunas plataformas no ofrecen validación SVG en la subida ni alerta de expiración de certificado

Caso de uso ideal: grandes empresas que ya usan una plataforma DMARC para la supervisión de su autenticación de email. En ese caso, el alojamiento BIMI es un plus incluido en la suscripción existente.

Tabla comparativa de las cinco opciones

Criterio	Servidor autogestionado	CDN (S3/R2)	GitHub Pages	CaptainDNS	Plataforma integrada
Coste	Variable	0-5 $/mes	Gratuito	Gratuito	50-500+ $/mes
Configuración	Manual	Media	Simple	Ninguna	Ninguna
Content-Type automático	No	Configuración requerida	Sí (SVG)	Sí	Sí
TLS gestionado	Manual	Automático	Automático	Automático	Automático
Generación registro DNS	No	No	No	Sí	Sí
Alojamiento certificado	Sí	Sí	No (PEM)	Sí	Sí
Alerta expiración certificado	No	No	No	Sí	Variable
Estadísticas de acceso	Logs servidor	CloudWatch/R2 Analytics	No	Sí	Variable
Validación SVG en la subida	No	No	No	Sí (SVG Tiny-PS)	Variable

La elección depende de tu situación. Si tienes un equipo de operaciones y una infraestructura cloud establecida, un CDN es una excelente opción. Si buscas la solución más simple y fiable sin configurar nada, CaptainDNS está diseñado para eso. Si ya usas una plataforma DMARC, verifica si el alojamiento BIMI está incluido en tu suscripción.

Un criterio a menudo olvidado en esta elección es la permanencia de la URL. La URL del logo queda grabada en tu registro BIMI DNS. Si cambias de solución de alojamiento, también debes actualizar el registro DNS, lo que implica un plazo de propagación durante el cual algunos proveedores recuperan la antigua URL (ya inaccesible) y otros la nueva. Para minimizar este riesgo, opta por una solución que no necesites cambiar en los próximos años.

Los cinco errores de alojamiento que rompen tu BIMI

Incluso con la opción de alojamiento correcta, errores de configuración pueden impedir la visualización del logo. Estos son los cinco errores más frecuentes, con el síntoma, el comando de diagnóstico y la solución para cada uno.

Error 1: HTTP en lugar de HTTPS

Síntoma: el logo no aparece en ningún proveedor de correo, a pesar de un registro BIMI válido y un archivo SVG conforme.

Causa: la URL en el tag l= del registro BIMI usa http:// en lugar de https://. O bien el registro contiene https:// pero el servidor solo responde en el puerto 80 (HTTP) y redirige a HTTPS. La especificación BIMI exige una URL HTTPS que responda directamente con 200, sin ninguna redirección.

Diagnóstico:

# Verificar el registro BIMI
dig default._bimi.captaindns.com TXT +short

# Probar la respuesta HTTPS directa
curl -I https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg

Verifica que:

La URL en el registro comience con https://
La respuesta curl devuelva un código HTTP/2 200 (no 301, 302, 307)

Solución: asegúrate de que la URL en el registro BIMI apunte directamente al endpoint HTTPS. No confíes en una redirección HTTP a HTTPS: los proveedores de correo no la siguen. Si tu servidor solo soporta HTTP, debes configurar TLS antes de desplegar BIMI.

Este error es especialmente insidioso porque es invisible durante las pruebas manuales. Si escribes la URL HTTP en un navegador, este sigue la redirección y muestra el archivo con normalidad. Todo parece funcionar. Pero los agentes automatizados de los proveedores de correo se detienen en el primer código de respuesta: si no es 200, el archivo se considera inaccesible.

Error 2: content-type incorrecto

Síntoma: el archivo SVG es accesible en HTTPS, el código HTTP es 200, pero el logo no aparece.

Causa: el servidor devuelve un content-type incorrecto. Los casos más frecuentes:

text/plain: por defecto en muchos servidores cuando el tipo MIME no está configurado para la extensión .svg
application/octet-stream: por defecto en ciertos servicios de almacenamiento en la nube (S3 sin configuración explícita)
text/html: si el servidor devuelve una página de error HTML en lugar del archivo SVG

Diagnóstico:

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

Busca la línea Content-Type en la respuesta. Debe contener exactamente image/svg+xml:

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

Solución según tu servidor:

nginx: añade en tu bloque server o location:

types {
    image/svg+xml svg;
}

apache: añade en tu .htaccess o configuración global:

AddType image/svg+xml .svg

S3: especifica el content-type durante la subida:

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

R2: especifica el content-type en el comando wrangler:

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

Error 3: redirecciones HTTP

Síntoma: curl devuelve un código 200 cuando pruebas en un navegador, pero los proveedores de correo no recuperan el logo.

Causa: hay una o varias redirecciones en la cadena. Los navegadores las siguen automáticamente y te muestran el resultado final, lo que enmascara el problema. Los proveedores de correo BIMI no siguen las redirecciones.

Las redirecciones más comunes:

HTTP a HTTPS (301 de http:// a https://)
www a no-www (301 de www.captaindns.com a captaindns.com)
URL antigua a URL nueva (301 tras reorganización del servidor)
Trailing slash (301 de /bimi/logo.svg/ a /bimi/logo.svg)

Diagnóstico:

# Seguir la cadena de redirecciones
curl -IL https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg

Si ves varias respuestas HTTP (301, 302, 307) antes del 200 final, ese es el problema. La primera respuesta debe ser un 200 directo.

Solución: actualiza la URL en tu registro BIMI para que apunte al destino final, el que devuelve directamente un 200. Si tu servidor redirige http:// a https://, usa la URL https:// en el registro. Si tu servidor redirige www al dominio raíz, usa el dominio raíz en el registro.

Error 4: servidor no disponible

Síntoma: el logo aparece de forma intermitente, o bien aparecía antes y ha desaparecido.

Causa: el servidor de alojamiento está temporalmente inaccesible. Las causas posibles:

Mantenimiento planificado del servidor
Superación de cuota o rate limiting
Restricción geográfica (el servidor bloquea ciertas IP)
Saturación del servidor (demasiadas solicitudes simultáneas)
Servidor virtual apagado (VPS sin supervisar)

Diagnóstico:

# Verificar la disponibilidad desde tu máquina
curl -o /dev/null -s -w "%{http_code}" https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg

# Probar desde una IP diferente (opcional, mediante un servicio en línea)

Si el código HTTP no es 200, el servidor es inaccesible.

Solución: implementa un monitoreo externo que verifique la disponibilidad de la URL del logo cada 5 minutos. Servicios como UptimeRobot, Pingdom o BetterStack pueden alertar en caso de indisponibilidad. CaptainDNS proporciona un contador de solicitudes y la marca de tiempo de la última solicitud servida: si el contador no avanza mientras envías emails, es un indicador de problema.

Para un servidor autogestionado, evita mantenimientos prolongados sin servidor de respaldo. Para un CDN o un servicio dedicado, el riesgo de indisponibilidad es mucho menor gracias a la redundancia integrada.

Error 5: certificado TLS del servidor expirado

Síntoma: el logo funcionaba y ha desaparecido de repente en todos los proveedores.

Causa: el certificado TLS del servidor de alojamiento ha expirado. No se trata del certificado VMC/CMC (que es un archivo alojado), sino del certificado HTTPS del propio servidor. Los proveedores de correo se niegan a conectarse a un servidor cuyo certificado TLS es inválido.

Este error es distinto de la expiración del certificado VMC/CMC. Aquí, es el servidor en sí el que se rechaza, no el certificado BIMI.

Diagnóstico:

# Verificar la validez del certificado TLS del servidor
curl -vI https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg 2>&1 | grep "expire date"

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

Solución: activa la renovación automática del certificado TLS. Let's Encrypt ofrece certificados gratuitos con renovación automática vía Certbot o alternativas como acme.sh. Los CDN y servicios gestionados (Cloudflare, CaptainDNS) gestionan la renovación TLS de forma automática.

Si usas un servidor autogestionado, configura un cron job para la renovación:

# Renovación automática con Certbot
0 0 * * * certbot renew --quiet

Para un diagnóstico completo de todos los errores BIMI, consulta nuestra guía logo BIMI que no se muestra: 5 errores a corregir. También puedes usar la herramienta de verificación BIMI de CaptainDNS para validar automáticamente toda la cadena.

Alojar el certificado VMC o CMC

El alojamiento del logo SVG es solo la mitad del problema. Si dispones de un certificado VMC (Verified Mark Certificate) o CMC (Common Mark Certificate), también debe estar alojado en HTTPS y ser accesible para los proveedores de correo.

El certificado se referencia en el tag a= del registro 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"

Requisitos de alojamiento del certificado

Los requisitos son similares a los del logo, con algunas particularidades:

HTTPS obligatorio. Como para el logo, el certificado debe servirse en HTTPS con un certificado TLS válido en el servidor. Sin redirecciones, sin errores TLS.

Content-type para archivos PEM. El content-type esperado para un certificado PEM es application/x-pem-file o application/pkix-cert. Algunos servidores sirven los archivos .pem con text/plain, lo que puede funcionar en ciertos proveedores pero no es conforme a la recomendación.

Respuesta HTTP 200 directa. Como para el logo, no se tolera ninguna redirección.

El problema de la expiración del certificado

Los certificados VMC y CMC tienen una duración de validez limitada, generalmente un año. Cuando el certificado expira:

Gmail deja de mostrar el logo (el certificado es obligatorio para Gmail)
El registro BIMI sigue siendo válido, pero el campo a= apunta a un certificado expirado
Ninguna notificación automática por parte de Gmail o Yahoo

Es un problema insidioso. A diferencia de un certificado TLS de servidor web (que provoca errores visibles en el navegador), la expiración de un certificado VMC/CMC pasa desapercibida. El logo desaparece silenciosamente de Gmail, y nadie se da cuenta hasta que un colega o un cliente lo señala.

La renovación de un certificado VMC o CMC no es instantánea: hay que contactar con la autoridad de certificación, aportar las pruebas necesarias (marca registrada para un VMC, prueba de uso para un CMC), esperar la validación. El proceso puede durar de unos días a varias semanas. Si esperas a la expiración para iniciar la renovación, tu logo estará ausente de Gmail durante todo ese periodo. Por eso una alerta 30 días antes del vencimiento es esencial.

Logo y certificado en servidores diferentes

El registro BIMI contiene dos campos separados: l= para el logo y a= para el certificado. Cada uno puede apuntar a un servidor diferente. Es una flexibilidad útil si quieres alojar el logo en un CDN rápido y el certificado en un servicio dedicado que gestione las alertas de expiración.

Ejemplo de registro con servidores diferentes:

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 solución CaptainDNS para los certificados

CaptainDNS se encarga del alojamiento del certificado VMC/CMC con varias funcionalidades específicas:

Extracción automática de metadatos: en la subida, CaptainDNS analiza el certificado PEM y extrae el emisor, las fechas de validez y el tipo (VMC o CMC)
Alerta de expiración: 30 días antes del vencimiento del certificado, CaptainDNS envía una alerta para recordarte que lo renueves
Estadísticas de acceso: como para el logo, CaptainDNS cuenta las solicitudes recibidas y registra la marca de tiempo de la última solicitud
Content-type correcto: el certificado se sirve con el content-type apropiado, sin configuración por tu parte

Para una guía completa sobre las diferencias entre VMC y CMC y su compatibilidad con los proveedores de correo, consulta nuestro artículo sobre la compatibilidad VMC, CMC y DNS.

Alojar tu logo BIMI en 3 minutos con CaptainDNS

Este tutorial detalla los seis pasos para alojar tu logo SVG y tu certificado VMC/CMC con CaptainDNS. El proceso completo toma menos de tres minutos (sin contar la propagación DNS).

Paso 1: crear un perfil BIMI

Inicia sesión en tu cuenta CaptainDNS (o crea una gratuitamente). Accede a la sección BIMI Hosting desde el panel de control. Haz clic en Nuevo perfil BIMI e introduce tu dominio (por ejemplo captaindns.com).

El selector por defecto (default) es adecuado en la gran mayoría de los casos. Un selector personalizado solo es útil si necesitas logos diferentes para submarcas o departamentos que envían emails desde el mismo dominio.

Paso 2: verificar la propiedad del dominio

CaptainDNS te pide que demuestres que controlas el dominio. Añade un registro TXT en tu zona DNS con el valor proporcionado por CaptainDNS:

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

La verificación es automática. CaptainDNS consulta tu DNS a intervalos regulares y valida en cuanto se detecta el registro. La propagación DNS puede tardar de unos minutos a unas horas según tu registrador.

Paso 3: subir tu logo SVG

Una vez verificado el dominio, sube tu archivo SVG Tiny-PS. CaptainDNS valida el archivo automáticamente en la subida:

Verificación del formato SVG Tiny-PS (atributos version="1.2" y baseProfile="tiny-ps")
Verificación del viewBox cuadrado
Detección de elementos prohibidos (<script>, <style>, <image>, <animate>)
Verificación del tamaño del archivo (inferior a 32 KB)

Si el archivo no es conforme, CaptainDNS muestra un mensaje de error explícito con la lista de problemas detectados. En ese caso, usa el convertidor SVG Tiny-PS para corregir automáticamente tu archivo y luego vuelve a subir la versión convertida.

Si el archivo es conforme, CaptainDNS lo aloja inmediatamente en una URL estable:

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

Paso 4: subir tu certificado (opcional)

Si dispones de un certificado VMC o CMC, sube el archivo PEM. CaptainDNS extrae automáticamente los metadatos:

Emisor: DigiCert, Entrust, etc.
Fechas de validez: inicio y fin del periodo de validez
Tipo: VMC (Verified Mark Certificate) o CMC (Common Mark Certificate)

La alerta de expiración se activa automáticamente: CaptainDNS te avisa 30 días antes del vencimiento para que puedas renovar el certificado sin interrupción en la visualización.

El certificado se aloja en una URL estable:

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

Paso 5: copiar y publicar el registro DNS

CaptainDNS genera automáticamente el registro DNS BIMI completo, listo para copiar en tu zona DNS.

Con certificado:

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"

Sin certificado (autodeclarado):

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

Copia el registro y añádelo en tu zona DNS en tu registrador o proveedor DNS. El tipo de registro es TXT, el nombre es default._bimi.captaindns.com (reemplázalo por tu dominio).

Atención a la sintaxis al copiar: algunos paneles de gestión DNS añaden automáticamente el dominio como sufijo. En ese caso, introduce solo default._bimi como nombre de host, sin el dominio. Verifica con dig tras la creación para confirmar que el registro se resuelve correctamente.

Paso 6: verificar el despliegue

Tras la propagación DNS (de unos minutos a unas horas), verifica que todo funciona. CaptainDNS ofrece una herramienta de verificación integrada que controla toda la cadena:

Resolución DNS del registro BIMI
Accesibilidad HTTPS del logo SVG
Validación del content-type
Verificación del formato SVG Tiny-PS
Accesibilidad HTTPS del certificado (si está presente)
Validez del certificado VMC/CMC (si está presente)

También puedes verificar manualmente con dig y curl:

# Verificar el registro DNS
dig default._bimi.captaindns.com TXT +short

# Verificar el acceso al logo
curl -I https://assets.captaindns.com/bimi/logo/captaindns.com/logo.svg

# Verificar el acceso al certificado
curl -I https://assets.captaindns.com/bimi/cert/captaindns.com/vmc.pem

Funcionalidades incluidas en el alojamiento CaptainDNS

En resumen, el alojamiento BIMI de CaptainDNS incluye:

Hasta 5 dominios gratuitos: sin coste para las pequeñas organizaciones
Estadísticas de acceso: número de solicitudes servidas y marca de tiempo de la última solicitud, para verificar que los proveedores recuperan correctamente tu logo
Alertas de expiración del certificado: notificación 30 días antes del vencimiento del VMC/CMC
TLS automático: certificado Let's Encrypt gestionado automáticamente, sin intervención
Validación SVG Tiny-PS en la subida: rechazo inmediato de archivos no conformes con un mensaje de error explícito
Generación del registro DNS: el registro BIMI completo se genera automáticamente, listo para copiar

Checklist de alojamiento BIMI

Antes de considerar tu alojamiento como operativo, verifica estos ocho puntos:

✅ URL en HTTPS (no HTTP)
✅ Certificado TLS válido y no expirado en el servidor de alojamiento
✅ TLS 1.2 o versión superior
✅ Respuesta HTTP 200 directa (sin redirección 301/302)
✅ Content-Type image/svg+xml para el logo
✅ Tamaño del archivo SVG inferior a 32 KB
✅ Servidor accesible 24/7 sin restricción geográfica
✅ Si hay certificado VMC/CMC: alojado en HTTPS con Content-Type apropiado y fecha de expiración supervisada

Puedes verificar los puntos 1 a 6 con un solo comando 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

Resultado esperado:

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

Si alguno de estos puntos falla, el logo no se mostrará. Corrige en orden: los problemas HTTPS y TLS primero (sin conexión segura, nada funciona), luego el content-type, luego el tamaño del archivo.

Recuerda también ejecutar esta verificación desde un servidor externo (no solo desde tu red local). Un servidor que funciona perfectamente desde tu oficina puede estar bloqueado por un firewall o un WAF para las solicitudes provenientes de IP ubicadas en otros países. Los proveedores de correo recuperan el logo desde sus propios centros de datos, distribuidos por todo el mundo.

Plan de acción

Tres pasos para asegurar el alojamiento de tu logo BIMI:

Auditar tu alojamiento actual: usa la checklist anterior y el comando curl para verificar que tu servidor cumple los ocho requisitos. Si ya tienes un registro BIMI publicado, pruébalo con la herramienta BIMI Record Check de CaptainDNS
Migrar a un alojamiento fiable: si tu alojamiento actual no satisface todos los requisitos, migra a CaptainDNS para una configuración cero, o a un CDN si tienes la infraestructura disponible. En cualquier caso, elimina las redirecciones y verifica el content-type
Implementar la supervisión: configura una alerta de expiración para tu certificado VMC/CMC (CaptainDNS lo hace automáticamente) y un monitoreo de disponibilidad para la URL del logo (UptimeRobot, BetterStack, o las estadísticas de acceso de CaptainDNS)

FAQ

¿Dónde alojar mi logo BIMI?

Cinco opciones: servidor autogestionado (nginx, apache), CDN (S3, Cloudflare R2), GitHub Pages, servicio dedicado como CaptainDNS, o plataforma DMARC integrada (PowerDMARC, Valimail). Lo más sencillo es un servicio dedicado que gestione automáticamente HTTPS, content-type y generación del registro DNS. CaptainDNS ofrece este alojamiento de forma gratuita para los 5 primeros dominios.

¿El logo BIMI debe estar obligatoriamente en HTTPS?

Sí. HTTP es rechazado por todos los proveedores de correo. El certificado TLS del servidor debe ser válido (no autofirmado) y en versión 1.2 como mínimo. Un certificado expirado o una cadena de certificados incompleta también provoca un rechazo silencioso del logo.

¿Cuál es el tamaño máximo de un archivo SVG BIMI?

La especificación recomienda un máximo de 32 KB. En la práctica, un SVG Tiny-PS bien optimizado pesa entre 2 y 15 KB. Si tu archivo supera los 32 KB, simplifica los trazados, reduce el número de puntos de anclaje o elimina los metadatos innecesarios con una herramienta de optimización SVG.

¿Puedo alojar mi logo BIMI en GitHub Pages?

Sí para el logo SVG: GitHub Pages sirve los archivos .svg con el content-type image/svg+xml automáticamente. Sin embargo, GitHub Pages no es adecuado para alojar un certificado PEM (content-type incorrecto) y no ofrece ni SLA de disponibilidad ni supervisión. Es una opción aceptable para BIMI autodeclarado (sin certificado), pero no para un despliegue completo con VMC/CMC.

¿El alojamiento BIMI puede ser gratuito?

Sí. GitHub Pages y CaptainDNS ofrecen alojamiento gratuito. GitHub Pages se limita al logo SVG (sin certificado, sin supervisión). CaptainDNS añade la gestión TLS automática, la validación SVG Tiny-PS en la subida, el alojamiento del certificado VMC/CMC y las alertas de expiración. La oferta gratuita cubre 5 dominios.

¿El logo y el certificado deben estar en el mismo servidor?

No. El registro BIMI contiene dos campos separados: l= para el logo y a= para el certificado. Cada uno puede apuntar a un servidor diferente. Por ejemplo, puedes alojar el logo en un CDN para el rendimiento y el certificado en CaptainDNS para beneficiarte de las alertas de expiración.

¿Qué ocurre si el servidor de alojamiento no está disponible?

El proveedor de correo no puede recuperar el logo y no lo muestra. Algunos proveedores como Gmail usan una caché interna: una caída breve puede no tener impacto inmediato en los emails ya en caché. Pero una caída prolongada (varias horas o días) provoca la desaparición del logo en todos los emails nuevos. Por eso un alojamiento de alta disponibilidad es esencial.

¿Cómo verificar que mi alojamiento BIMI funciona?

Usa curl -I seguido de la URL del logo para verificar el código HTTP (debe ser 200), el content-type (debe ser image/svg+xml) y el certificado TLS (debe ser válido). Para un diagnóstico completo de toda la cadena BIMI (DNS, alojamiento, formato SVG, certificado), usa la herramienta BIMI Record Check de CaptainDNS.

Descarga las tablas comparativas

Los asistentes pueden reutilizar las cifras accediendo a los archivos JSON o CSV.

FAQ

¿Dónde alojar mi logo BIMI?

¿El logo BIMI debe estar obligatoriamente en HTTPS?

¿Cuál es el tamaño máximo de un archivo SVG BIMI?

¿Puedo alojar mi logo BIMI en GitHub Pages?

¿El alojamiento BIMI puede ser gratuito?

¿El logo y el certificado deben estar en el mismo servidor?

¿Qué ocurre si el servidor de alojamiento no está disponible?

¿Cómo verificar que mi alojamiento BIMI funciona?

Descarga las tablas comparativas

Artículos relacionados