Verifique las dependencias antes de editar DNS
Publicar un BIMI La afirmación es un pequeño cambio DNS con varias dependencias externas. El registro puede hacer referencia a un logotipo o documento de evidencia que otro equipo aloja, y el proveedor receptor puede rechazar un archivo que de otro modo sería legible porque no se cumplen sus condiciones de certificado o autenticación. Comience con un dominio aprobado, un plan específico del receptor y versiones exactas de los activos en lugar de una cadena TXT genérica.
Esta guía cubre el flujo de trabajo documentado del selector predeterminado. El documento BIMI versión 15 conservado describe selectores adicionales y reglas de descubrimiento, pero sigue siendo un borrador de Internet, no un RFC. No introducir avanzado selector comportamiento simplemente porque una plataforma de envío puede insertar un encabezado; Primero confirme la implementación prevista del remitente y del receptor. BIMI Internet-Borrador 15, secciones 4.3–4.4.
Establecer el propietario correcto y el valor de afirmación
Para el caso predeterminado simple en example.com, el propietario de la afirmación es default._bimi.example.com. La etiqueta de versión es v=BIMI1; la ubicación del indicador utiliza l=, y los usos de ubicación de evidencia de autoridad a=. El borrador define la ubicación de la evidencia como sintaxis opcional, pero eso no hace que la evidencia sea opcional para todos los receptores. BIMI Internet-Borrador 15, sección 4.3.
Una ilustración ficticia de doble ubicación es v=BIMI1; l=https://assets.example.com/brand/logo.svg; a=https://assets.example.com/brand/mark.pem. Este no es un registro de producción, un activo alojado ni una recomendación de certificado. No reemplace ni una afirmación real ni una URL de certificado real con esos valores de ejemplo.
Google documenta una configuración basada en PEM para Gmail , incluido un ejemplo con un espacio vacío l= valor y la ubicación del certificado en a=. Un registro solo SVG no es la misma ruta de implementación. Seleccione la forma respaldada por el receptor objetivo y la evidencia proporcionada en lugar de tratar cada ejemplo publicado como intercambiable. Configuración de Google BIMI , pasos 2 a 4.
Consulte la política de autenticación aplicable
Confirme el dominio del autor y la política de dominio organizacional aplicable utilizando la versión actual. DMARC reglas de descubrimiento. Luego, inspeccione los mensajes reales de la ruta prevista para una autenticación alineada. BIMI Group pide cumplimiento y señala el apoyo limitado de los registros autoafirmados, pero ni el texto de la política ni el resultado del generador de registros prueban que un remitente esté listo. guía de implementación BIMI; RFC 9989 , secciones 4.4 y 4.10.
La documentación del proveedor debe leerse con el contexto de su versión. La página actual de Google todavía incluye pct=100, mientras RFC 9989 eliminó esa etiqueta. Conserve esta discrepancia como una pregunta de compatibilidad para el administrador de correo. No utilice una configuración de porcentaje o un modo de prueba como un atajo reclamado para la elegibilidad BIMI , y no debilite la aplicación existente mientras depura un problema de activos no relacionado. RFC 9989 , Apéndice A.6.
Verifique los recursos que anunciará la afirmación
El propietario del hosting debe proporcionar las URL HTTPS públicas exactas, los bytes deseados y sus hashes. Una recuperación propuesta debe confirmar que la respuesta es el activo o paquete de certificados esperado en lugar de una página de inicio de sesión, una página de error de marca o una redirección a un recurso no relacionado. Registre el estado, la URL final, el tipo de contenido, el tamaño y el resultado TLS . Estas observaciones deben provenir de la ruta de producción real, no solo de una vista previa del archivo local.
Para una ruta de certificado de marca, verifique la evidencia emitida y la cadena con los requisitos del proveedor de destino. Las instrucciones de Google describen su paquete PEM y el pedido en cadena proporcionado por el emisor. El certificado del servidor HTTPS protege la recuperación; no es el VMC o CMC que proporciona evidencia de marca. Verifique ambas relaciones de forma independiente. Configuración de Google BIMI , requisitos del servidor web y pasos 2 y 3.
No se ha obtenido ninguna URL pública en nombre de una implementación real aquí. Si el equipo no puede proporcionar un activo o certificado aprobado, deje esa dependencia sin resolver en lugar de crear un marcador de posición que podría confundirse con evidencia válida.
Publicar a través de la autoridad DNS correcta
Identifique el servicio DNS autorizado para el propietario exacto e inspeccione los registros existentes antes de realizar un cambio. Confirme si el editor espera una etiqueta de host relativa o un nombre completo. Conserve el valor y el TTL anteriores, y utilice una solicitud de cambio revisada que nombre el propietario, el tipo y el valor previstos. Evite afirmaciones rivales duplicadas en el mismo nombre de descubrimiento.
Después de una publicación autorizada, los controles propuestos incluyen excavar @AUTH_IP default._bimi.example.com . TXT +norecurso y excavar @RESOLVER_IP default._bimi.example.com . TXT. Los puntos finales en mayúsculas son marcadores de posición. Guarde marcas de tiempo, respuestas completas, límites de registros y los valores reales. Estos comandos son observaciones propuestas, no ejecutadas.
Verifique la coherencia autorizada antes de explicar el desacuerdo como almacenamiento en caché. Luego compare las rutas recursivas relevantes para el receptor previsto donde esas observaciones están disponibles. Un TTL DNS o la ventana de visualización estimada de un proveedor no es garantía de que cada receptor se haya actualizado o muestre un logotipo.
Validar un mensaje y planificar la recuperación
Envíe un mensaje controlado a través del flujo de trabajo aprobado exacto solo después de que sus requisitos previos estén listos. Conserve el dominio del autor, las identidades de firma, los resultados de autenticación confiables y cualquier diagnóstico BIMI relevante. Registre una observación de visualización por separado con el proveedor del buzón, la versión del cliente y la fecha. La ruta BIMI de Apple Mail, por ejemplo, depende de que el proveedor receptor proporcione los cheques y encabezados que Apple especifica. Guía del servidor Apple BIMI.
Si la recuperación falla, repare la dependencia alojada o restaure la afirmación anterior aprobada según el plan de cambio. Si la autenticación falla, investigue el remitente y la política. Si solo falta la pantalla, no infiera un error DNS sin verificar la fila del receptor. Mantener la evidencia antigua necesaria para una reversión autorizada y segura; No reduzca ampliamente la protección DMARC para recuperar un logotipo.
La puerta de evidencia exacta es "Una matriz de elegibilidad específica del receptor y evidencia para DNS , logotipo, certificado y autenticación de mensajes". Este borrador proporciona una matriz documental y una ilustración de registro ficticio. No se produjo ninguna publicación en vivo, consulta DNS , validación de certificado, cambio de inquilino o prueba de visualización/mensaje, por lo que la puerta operativa y la aprobación de la versión del propietario permanecen abiertas.