Separar el protocolo de la elegibilidad del receptor
BIMI la elegibilidad no se establece al encontrar la palabra DMARC en un registro DNS . El operador debe determinar la política de autenticación aplicable, si el mensaje real pasa las comprobaciones requeridas y qué requiere actualmente el receptor previsto antes de mostrar un logotipo. Esas son preguntas relacionadas pero distintas. Una especificación de protocolo actual y la página de ayuda operativa de un proveedor también pueden diferir en terminología o tiempo de migración, por lo que la evidencia necesita fechas y alcance explícito.
Este artículo compara las fuentes primarias retenidas. La página de configuración de Google se actualizó el 26 de octubre; La página BIMI de Yahoo se recuperó sin una fecha de revisión visible equivalente. RFC 9989 proporciona el contexto actual del protocolo DMARC . El artículo no prueba a un inquilino ni infiere que un proveedor haya implementado todos los aspectos del RFC más nuevo. BIMI sigue siendo un borrador y la visualización del receptor no es una garantía de protocolo universal.
Registre las condiciones reales publicadas por Google
La página de configuración BIMI de Google dice que los mensajes deben ser autenticados por DMARC y enumera p=quarantine o p=reject, con pct=100. También requiere un VMC o CMC por su flujo de trabajo documentado respaldado por certificados y no admite la implementación independiente de SVG únicamente en Gmail . Registre esas declaraciones como guía de elegibilidad publicada por Google, no como una definición completa de DMARC o prueba del resultado de un mensaje en particular. Requisitos de configuración de Google
Sus requisitos de SVG e instrucciones de alojamiento forman puertas adicionales. Una política DMARC adecuada no hace que una imagen no válida sea adecuada, no obtiene un certificado ni hace que el PEM sea accesible públicamente. Por el contrario, un certificado válido no repara la autenticación alineada de un remitente fallido. Utilice una lista de verificación con filas separadas para que un equipo no pueda marcar accidentalmente todo el proyecto como listo después de completar solo la fila de la política DNS.
Sacar a la luz la discrepancia del PCT en lugar de ocultarla
RFC 9989 deja obsoletas las especificaciones DMARC anteriores y elimina la etiqueta pct. Su apéndice explica el mecanismo de porcentaje histórico e introduce la etiqueta de prueba t con valores y y n. Este es un cambio de protocolo significativo, mientras que la página BIMI de Google conservada todavía menciona explícitamente pct=100. Ambas observaciones deben preservarse en lugar de reescribir silenciosamente cualquiera de las fuentes para que parezcan idénticas. RFC 9989 , Apéndice A.6
La respuesta operativa es confirmar la aplicabilidad actual del receptor antes de cambiar una política de producción sobre la base de ese desajuste. No afirmes que Google ignora, requiere información o traduce internamente una etiqueta en particular, a menos que la evidencia actual establezca ese comportamiento. No trate a t como un sustituto de elegibilidad BIMI universalmente probado para pct simplemente porque el RFC explica su relación histórica. La implementación y la documentación del proveedor pueden evolucionar según diferentes cronogramas.
Por lo tanto, un registro de aplicabilidad de la fuente debe incluir la versión del RFC, la fecha de la página del proveedor, la condición exacta en disputa y la pregunta no resuelta. Solicite al revisor responsable que lo resuelva con evidencia actual del proveedor o una observación autorizada y con el alcance adecuado. Este artículo no realiza esa confirmación. El conflicto es un motivo para abrir una puerta, no un motivo para debilitar la aplicación de la ley o improvisar un reclamo de compatibilidad.
Compare las condiciones establecidas de Yahoo de forma independiente
La propia pagina BIMI de Yahoo requiere una cuarentena o rechazar la politica DMARC , una registro BIMI apuntando a un SVG válido, correo masivo y suficiente reputación y participación para la dirección de envío. Dice que los VMC no son necesarios actualmente, aunque un VMC suministrado informa la elegibilidad general. Su página respeta los registros BIMI de subdominio y prefiere la configuración de dominio organizacional. Estas son declaraciones específicas de Yahoo, no evidencia de que Gmail comparta el mismo certificado o política de visualización. Requisitos BIMI Yahoo
No interprete la ausencia de una condición de pct por parte de Yahoo en esa página como prueba de todos los posibles comportamientos de manejo de etiquetas. Registre lo que la fuente realmente dice y lo que deja sin especificar. Del mismo modo, sus condiciones de reputación y correo masivo significan que un solo mensaje de prueba personal puede no representar a la población documentada que muestra el logotipo. No invente un umbral de envío numérico cuando la fuente revisada no proporcione uno.
Conecte la política a la autenticación de mensajes real
DMARC evalúa alineación entre el dominio visible Desde y un paso SPF o DKIM identidad bajo sus reglas. Una preferencia de cumplimiento publicada no obliga a todos los remitentes legítimos a aprobar. Inventario de los servicios de envío e identificación de qué identidades autentifican antes de proponer un tratamiento más estricto. Los cambios en la política pueden afectar los flujos de trabajo legítimos, por lo que una fecha límite para el logotipo no debe pasar por alto el proceso de preparación y aprobación del equipo de correo. Autenticación y alineación RFC 9989
Para una observación controlada posterior, conserve el mensaje recibido real y los resultados de autenticación confiables. No acepte un pase reclamado de un encabezado arbitrario sin identificar el sistema productor y el límite de confianza. Mantenga el descubrimiento de políticas, la autenticación de mensajes y la visualización del logotipo como resultados separados; un mensaje puede pasar la autenticación sin cumplir las condiciones de visualización adicionales del receptor. Límite de confianza RFC 8601
Hoja de trabajo original de elegibilidad del receptor
Cree una fila por receptor y flujo de correo. Los siguientes campos propuestos evitan que un estado genérico " BIMI ready" oculte diferencias importantes. No se ha evaluado ninguna implementación real con esta hoja de trabajo.
- Fuente: página del receptor, fecha de recuperación, fecha de revisión visible y versión de referencia del protocolo.
- Política de dominio: registro exacto aplicable y cualquier cuestión organizativa o de subdominio.
- Falta de coincidencia en la documentación: etiqueta o condición en disputa, evidencia y propietario de aplicabilidad no resuelta.
- Evidencia del mensaje: visible desde, identidades autenticadas, alineación y fuente de resultados confiable.
- Activo: versión SVG aprobada, dimensiones del receptor y hallazgos estructurales.
- Certificado: categoría requerida, estado del emisor y dependencia de PEM alojado.
- Recuperación y visualización: evidencia de punto final público, cliente receptor, tiempo de observación y límites.
- Decisión: elegible, no elegible o desconocido para esta transmisión, con las condiciones restantes.
Mantenga las decisiones de seguimiento y cumplimiento separadas de la experimentación con la visualización. Si un remitente existente no logra alinearse, resuelva la configuración del remitente y el impacto comercial en lugar de cambiar un archivo de logotipo repetidamente. Si se pasa la autenticación pero no aparece ningún logotipo, investigue el certificado, el alojamiento, el soporte y la elegibilidad discrecional sin declarar DMARC se ha roto únicamente por el gráfico que falta.
Ejemplo ficticio: una lista de verificación esconde dos receptores
El ficticio Silver Orchard prepara una lista de verificación de lanzamiento que dice “Pase DMARC , certificado opcional”. Esa redacción fusiona la posición de certificado de Yahoo con el flujo de trabajo documentado diferente de Gmail . Un revisor también observa que una guía interna más antigua trata al pct como un requisito de protocolo universal sin cambios, mientras que RFC 9989 lo eliminó y la página actual de Google todavía incluye pct=100. El equipo tiene dos preguntas sobre documentación, no hay evidencia de que alguno de los receptores esté funcionando mal.
El siguiente paso propuesto es dividir la lista de verificación en filas de receptor con fecha de origen y escalar la pregunta sobre la aplicabilidad de la etiqueta antes de cambiar DNS de producción. Cada flujo necesitaría evidencia de mensajes reales y sus propias verificaciones de activos y certificados. No se probó ningún mensaje, registro DNS o receptor de Silver Orchard. El ejemplo ilustra cómo una lista de verificación genérica puede ocultar suposiciones no resueltas.
El catálogo requiere una matriz de elegibilidad específica del receptor y evidencia de autenticación DNS , logotipo, certificado y mensaje. Este manuscrito proporciona una matriz propuesta y diferencias documentadas, no la evidencia operativa. La evidencia original, la PYME humana, la aplicabilidad de la fuente, las rutas de producción, la accesibilidad visual y la autorización del propietario permanecen abiertas. No se implica ningún cambio de política, prueba en vivo o garantía de elegibilidad.