Registro BIMI explicado: logotipo en Gmail, requisitos y límites

BIMI (Brand Indicators for Message Identification) es un registro TXT que indica a los proveedores de buzones dónde encontrar su logotipo, para que puedan mostrarlo junto a los mensajes que han superado DMARC. El registro en sí es una sola línea. El trabajo está en los requisitos previos: DMARC en modo estricto (p=quarantine o p=reject), un logotipo en un perfil SVG restringido y, para los proveedores que más importan a la mayoría, un certificado de marca emitido por una autoridad de certificación. Incluso con todo eso en su sitio, que el logotipo aparezca o no es decisión del receptor.

Conviene tener claro algo desde el principio: BIMI no es un estándar RFC. Es una especificación del AuthIndicators Working Group (el BIMI Group), publicada como borradores Internet-Draft del IETF. Los proveedores lo implementan en distinto grado y sus requisitos cambian.

Cómo es el registro

$ dig +short TXT default._bimi.example.com
"v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/certificate.pem"

Etiqueta	Significado
`v=BIMI1`	Versión, debe ir en primer lugar
`l=`	URL HTTPS del logotipo (SVG)
`a=`	URL HTTPS del documento de evidencia: el certificado de marca en formato PEM

default es el selector. Un remitente puede publicar más selectores (por ejemplo newsletter._bimi.example.com) y elegir uno por mensaje con una cabecera BIMI-Selector. La mayoría de los dominios nunca necesita más que default.

Los subdominios heredan: para el correo de news.example.com, un receptor que no encuentra registro en default._bimi.news.example.com recurre al registro del dominio organizativo. Un subdominio puede publicar su propio registro para mostrar un logotipo distinto.

Requisito 1: DMARC en modo estricto

Aquí es donde de verdad empieza la mayoría de los proyectos BIMI, y donde se va la mayor parte del tiempo.

$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

La política del dominio organizativo debe ser p=quarantine o p=reject. p=none no cuenta.
sp=none (una política relajada para los subdominios) y un valor pct inferior a 100 pueden descalificar al dominio.
Cada mensaje individual debe superar DMARC: SPF o DKIM pasa, con el dominio autenticado alineado con el dominio del From.

La lógica es sencilla. Un logotipo es una señal de confianza, y un receptor solo lo asociará al correo de un dominio que ha declarado públicamente que rechaza las falsificaciones. Llegar ahí sin sobresaltos exige un inventario de todos los sistemas que envían en su nombre, DKIM alineado en cada uno y semanas de lectura de informes antes de endurecer la política; el orden de despliegue está en MX, SPF, DKIM y DMARC explicados. Puede ver en qué punto está hoy un dominio con la verificación DMARC de OrbitProbe, y el generador DMARC compone la sintaxis del registro.

Requisito 2: el logotipo como SVG Tiny PS

Los receptores no aceptan archivos SVG cualesquiera. El logotipo debe seguir el perfil SVG Tiny Portable/Secure (SVG Tiny PS), un perfil reducido definido para BIMI:

sin scripts
sin referencias externas (ni imágenes, fuentes ni hojas de estilo enlazadas): todo va incrustado en el único archivo
sin animación
proporción cuadrada
se recomienda un fondo sólido, porque los proveedores recortan la imagen en círculo o en cuadrado redondeado y la muestran sobre temas claros y oscuros
servido por HTTPS

El elemento raíz declara el perfil, y se espera un <title>:

<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny-ps" viewBox="0 0 100 100">
  <title>Example Ltd</title>
  …
</svg>

Una exportación directa desde una herramienta de diseño casi nunca cumple: arrastra metadatos del editor, un baseProfile incorrecto y con frecuencia un mapa de bits incrustado. Cuente con una limpieza manual o con un paso de conversión específico, y mantenga el logotipo centrado y con margen alrededor para que el recorte circular no lo corte.

$ curl -I https://example.com/bimi/logo.svg
HTTP/2 200
content-type: image/svg+xml

Una respuesta 200, el tipo de contenido image/svg+xml y ninguna redirección a una página de inicio de sesión o de consentimiento: compruebe esas tres cosas.

Requisito 3: un certificado de marca

La etiqueta a= apunta a un certificado que vincula el logotipo con su organización. Lo emite una autoridad de certificación tras validar su identidad y su derecho al logotipo, y el logotipo va incrustado en el certificado. Solo un número reducido de CA los emite. Existen dos tipos:

	VMC (Verified Mark Certificate)	CMC (Common Mark Certificate)
Marca registrada	Obligatoria	No obligatoria
Base para el logotipo	El registro de la marca	Por ejemplo, un uso previo demostrado del logotipo
Validación de identidad por la CA	Sí	Sí

No son certificados TLS. No se instalan en su servidor web y no tienen nada que ver con el certificado HTTPS que sirve los archivos.

Compatibilidad de los proveedores, a septiembre de 2026

La compatibilidad varía entre proveedores de buzones y ha cambiado más de una vez. Según lo conocido en el momento de escribir esto:

Gmail exige un VMC o un CMC. Google anunció la compatibilidad con CMC en 2024; su marca de verificación azul está vinculada a un VMC.
Apple Mail exige un VMC.
Algunos proveedores pueden mostrar un logotipo sin ningún certificado, a su propio criterio (un registro "autoafirmado" con solo la etiqueta l=).
Algunos grandes proveedores no admiten BIMI en absoluto.

Antes de pagar un certificado, lea la documentación actual de los proveedores de buzones que usan realmente sus destinatarios. Si la mayor parte de su audiencia está en un proveedor que ignora BIMI, ningún registro pondrá allí su logotipo.

Lo que BIMI no hace

Mostrarlo es siempre decisión del receptor. Un registro válido, un certificado válido y un DMARC superado le hacen elegible. Los proveedores también miran la reputación del dominio y de la fuente de envío, y pueden negarse sin decirle por qué.
No mejora la entregabilidad por sí mismo. BIMI no saca el correo de la carpeta de spam. Lo que ayuda es el trabajo de DMARC que hizo para cumplir los requisitos; el logotipo se muestra en correo que ya iba a entregarse. Si su correo acaba en spam, empiece por la lista de comprobación DNS para correo que llega a spam.
No es una garantía contra el phishing. Un dominio parecido al suyo puede pasar por el mismo proceso con su propio logotipo, y los destinatarios cuyo cliente de correo no muestra BIMI no ven nada en ningún caso. La ausencia de logotipo no demuestra nada.
Los logotipos se guardan en caché. Los receptores descargan el SVG y el certificado según su propio calendario. Un logotipo nuevo o modificado puede tardar días en aparecer, y uno retirado puede seguir viéndose durante un tiempo.

El camino, en orden

Alinee SPF y DKIM para cada servicio que envía como su dominio. El DKIM alineado es lo más importante, porque sobrevive al reenvío.
Publique DMARC con p=none y una dirección rua, y lea los informes.
Pase a p=quarantine y después a p=reject, con pct=100 y sin sp=none.
Prepare el logotipo SVG Tiny PS y alójelo por HTTPS en una URL estable.
Obtenga el certificado (VMC si tiene una marca registrada y quiere la compatibilidad más amplia, CMC en caso contrario) exactamente para ese archivo de logotipo.
Publique el registro BIMI en default._bimi.
Envíe correo real a buzones de los proveedores que le interesan, y espere.

Los pasos 1 a 3 suelen llevar meses en una organización con muchos sistemas de envío. Los pasos 4 a 6 llevan días, más el tiempo de validación de la CA.

Lista de comprobación

_dmarc en el dominio organizativo: p=quarantine o p=reject, sin pct por debajo de 100, sin sp=none
Cada servicio de envío supera DMARC con alineación (compruebe los informes, no un único mensaje de prueba)
El logotipo es SVG Tiny PS: cuadrado, autocontenido, sin scripts, sin animación, baseProfile="tiny-ps"
La URL del logotipo y la del certificado responden 200 por HTTPS, sin redirecciones a otro contenido
El logotipo del certificado es el mismo al que apunta la etiqueta l=
Un registro TXT en default._bimi, que empieza por v=BIMI1
Fecha de caducidad del certificado anotada en el calendario: los certificados de marca caducan como cualquier otro

Puede consultar el registro BIMI publicado de un dominio con el comprobador de BIMI.

Errores frecuentes

Publicar un registro BIMI mientras DMARC sigue en p=none y esperar un logotipo que no puede llegar.
Poner p=reject en el dominio principal y dejar en el registro un sp=none o un pct=50 de una fase anterior del despliegue.
Subir sin cambios el SVG exportado por el diseñador.
Colocar el registro en _bimi.example.com en lugar de en default._bimi.example.com.
Alojar el logotipo detrás de una redirección, un muro de cookies o una regla de CDN que bloquea a los clientes que no son navegadores.
Cambiar el archivo del logotipo después de emitido el certificado. El certificado contiene un logotipo concreto; un archivo distinto en l= ya no coincide.
Comprar primero el certificado y empezar después el proyecto DMARC.
Esperar el logotipo en todas las bandejas de entrada. La compatibilidad de los proveedores es parcial y mostrarlo es discrecional.
Tratar BIMI como un control de seguridad. La seguridad viene del modo estricto de DMARC; BIMI es la recompensa visible por ello.

Compruébelo con OrbitProbe

Como todo en BIMI depende de DMARC, empiece por ahí. La verificación DMARC de OrbitProbe consulta el registro en _dmarc de un dominio, muestra qué política publica (none, quarantine, reject) y señala un registro ausente, duplicado o inválido. Ejecútela primero para el dominio organizativo y después para cada subdominio desde el que envíe. Una comprobación DNS muestra la política publicada en ese momento. No puede decirle si los mensajes individuales pasan con alineación (eso está en sus informes agregados DMARC), y ninguna consulta puede predecir si un proveedor de buzones decidirá mostrar el logotipo.