Borrador BIMI -11 del 9 de octubre de 2025: qué cambia y cómo prepararse

⚡TL;DR

TL;DR - 🗞️ El borrador BIMI -11 (publicado el 9 de octubre de 2025) introduce oficialmente los Local-Part Selectors (lps=) para dirigir el selector BIMI desde la dirección remitente, actualiza la gramática ABNF y el recorrido de discovery, confirma que **l= debe alojar un logo SVG/SVGZ en HTTPS y recuerda los requisitos DMARC (nada de p=none, pct=100 obligatorio si p=quarantine).

🧩 BIMI en 1 minuto

BIMI (Brand Indicators for Message Identification) permite que un dominio declare en DNS qué logo debe mostrarse junto a un correo autenticado. Los receptores validan la política BIMI y el MUA decide si renderiza el logo según su política local.

🗞️ Novedades de la revisión -11 (9 de octubre de 2025)

• lps= (Local-Part Selectors): nueva etiqueta opcional en el BIMI Assertion Record que autoriza una consulta basada en el local-part de la dirección remitente; útil cuando no puedes añadir el encabezado BIMI-Selector en el MTA saliente.
• ABNF actualizada: el BIMI Assertion Record ahora referencia explícitamente el bloque local-part-selector y el orden de los componentes (salvo v=) pasa a ser intercambiable.
• Discovery ampliado: si existe lps=, el receptor normaliza el local-part, intenta una consulta con el selector derivado y vuelve al registro original si no lo encuentra.
• Formatos de imagen: a la fecha solo se aceptan SVG y SVGZ y un registro IANA "BIMI formats" lleva la lista de formatos soportados.
• Recordatorio de encabezados: BIMI-Selector debería firmarse con DKIM (alineado DMARC) cuando se usa; BIMI-Location / BIMI-Indicator / BIMI-Logo-Preference no deben firmarse y hay que eliminarlos si llegan desde fuera.

🔧 lps=: dirigir el selector desde el local-part

Objetivo: mostrar logos distintos según la dirección de envío sin inyectar BIMI-Selector. El registro por defecto puede activar lps= y redirigir la consulta hacia <localpart>._bimi.<domain>.

Algoritmo de normalización (-11):

1. Quitar la parte de plus addressing (+...).
2. Sustituir _ y . por -, compactar duplicados y recortar los - iniciales/finales.
3. Solo permitir [A-Za-z0-9-], longitud ≤ 63.
4. El selector es insensible a mayúsculas/minúsculas.

Ejemplos:

# Activar lps= pero rechazar BIMI por defecto
default._bimi.example.org. IN TXT "v=BIMI1; l=; a=; lps=brand-indicators-"

# Dos selectores derivados del local-part
brand-one-noreply._bimi.example.org. IN TXT "v=BIMI1; l=https://cdn.example.org/logo-one.svg"
brand-two-noreply._bimi.example.org. IN TXT "v=BIMI1; l=https://cdn.example.org/logo-two.svg; a=https://mva.example/vmc.pem"

🧪 Discovery, ABNF y estructura del registro

El BIMI Assertion Record sigue siendo un TXT bajo <selector>._bimi.<domain>. La gramática ABNF (-11) ahora permite el bloque local-part-selector y recuerda que el orden (salvo v=) es libre.

Puntos clave:

• Fallback: si existe lps=, intenta primero <localpart>._bimi.<domain> y después vuelve al selector original.
• Rechazo explícito: v=BIMI1; l=; a=; deniega BIMI para ese selector.
• IANA: un registro de formatos gobierna lo que puede devolver l= (hoy, SVG/SVGZ).

🖼️ Logos: formatos y validación

• l= debe ser un URI HTTPS.
• Formatos permitidos: SVG y SVGZ (gzip).
• Los receptores validan tamaño, perfil SVG y seguridad antes de mostrarlo.
• Si existe una evidence a= (ej. VMC/CMC), el receptor puede comparar el SVG servido en l= con el embebido en la evidencia.

🔐 Requisitos de autenticación y política

• DMARC: el mensaje debe aprobar DMARC (o un equivalente local).
• Política: nada de p=none (en el dominio autor y en el organizacional).
• Si p=quarantine, pct tiene que ser 100.
• Los receptores pueden usar métodos adicionales (ej. ARC de confianza) para considerar algunos casos como "pass".

✉️ Encabezados BIMI en recepción

• BIMI-Selector: si existe, debería firmarse con DKIM (alineado con DMARC). En caso contrario, el receptor debe ignorarlo.
• BIMI-Location, BIMI-Indicator, BIMI-Logo-Preference: no los firmes nunca y elimínalos si llegan del exterior.

Ejemplo de Authentication-Results:

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

🗓️ Cronología útil

• 2025-10-09 (-11): añade lps=, refresca discovery/ABNF.
• 2025-06-16 (-10): consolidación de encabezados, avp= (preferencia de avatar), hash opcional.
• 2025-05-01 (-09): iteraciones discovery/evidence.
• 2024-11-04 (-08/-07): CMC se suma a VMC.

ℹ️ Estado: Internet-Draft (work in progress); cada MBP/MUA mantiene el control total de su política de renderizado.

✅ Lista de verificación de implementación

• DNS: diseña una estrategia de selectores (por defecto, variantes de producto, lps= cuando aplique).
• Logos: entrega un SVG/SVGZ limpio (perfil/peso) y versiona las URL.
• Evidence: publica a= (VMC/CMC) cuando exista y mantén la cadena al día.
• MTAs salientes: no añadas BIMI-Location / BIMI-Indicator / BIMI-Logo-Preference; firma BIMI-Selector si lo usas.
• Receptores: implementa la normalización LPS, elimina los encabezados entrantes y, si quieres, añade policy.indicator-hash en Authentication-Results.

🧭 Conclusión

BIMI -11 no revoluciona el protocolo, pero desbloquea un caso frecuente (selector guiado por el local-part) y aclara discovery, formatos y encabezados. Los dominios que buscan controlar con precisión la visualización de sus logos ganan flexibilidad, siempre que mantengan una postura DMARC sólida y SVG impecables.

Artículo informativo basado en un Internet-Draft que puede evolucionar; consulta el texto del IETF para los detalles normativos.