Comience con un mensaje y una afirmación intencionada
Un dominio puede tener varios BIMI afirmaciones sin que cada mensaje las utilice todas. El diseño previsto utiliza distintos selector nombres para identificar diferentes afirmaciones. Un conflicto es una situación diferente: registros de candidatos duplicados en un nombre de propietario, encabezados de selector en conflicto o una plataforma de envío que elige un selector distinto al que espera el operador. Diagnostique estos casos por separado antes de eliminar registros que puedan admitir otro flujo de correo legítimo.
Este artículo utiliza la guía de selección de BIMI Group y las especificaciones de autenticación y DNS conservadas. No afirma que cada receptor implemente todos los comportamientos de draft. No se realizó ninguna consulta DNS en vivo ni verificación de mensajes. La cadena de evidencia requerida comienza con un mensaje real, continúa a través de su selector y respuesta DNS público y termina con un resultado de verificación confiable; una captura de pantalla del editor DNS por sí sola no puede proporcionar esa cadena.
Distinguir selectores de registros duplicados
La guía de BIMI Group describe los nombres de las aserciones del selector de formulario. _bimi.domain , por defecto como selector convencional cuando no se selecciona ninguna alternativa. Describe un encabezado BIMI-Selector que lleva la versión BIMI y el nombre del selector, combinado con el dominio De visible para seleccionar la aserción. Las afirmaciones separadas bajo diferentes selectores son el mecanismo para múltiples logotipos; agregar varias afirmaciones en competencia sobre el mismo nombre no es el mismo diseño. Guiado del selector BIMI
Para un inventario, indique el nombre de cada propietario, flujo previsto, activo y equipo responsable. Distinga default._bimi.example.com de seasonal._bimi.example.com y de registros con nombres similares bajo un subdominio de envío. Estos nombres de ejemplo son ilustrativos, no registros que se consultaron. No combine sus significados en un único resultado de "dominio tiene BIMI ", porque el nombre seleccionado del mensaje es el punto de partida relevante.
Lea datos TXT como registros DNS , no como líneas de editor
Un registro de recursos DNS TXT puede contener una o más cadenas de caracteres. Esa estructura a nivel de cable significa que varias piezas citadas en una pantalla no son necesariamente registros múltiples. Por el contrario, dos registros separados pueden parecer una entrada agrupada en la interfaz de un proveedor. Inspeccione los límites reales de los registros devueltos antes de decidir que el dominio tiene aserciones duplicadas. Formato RFC 1035 TXT
La propuesta de solución segura es una afirmación BIMI intencionada e inequívoca en el nombre del propietario seleccionado, con logotipos alternativos asignados a distintos selectores. Este artículo no afirma una elección de receptor universal entre afirmaciones duplicadas ni proporciona un algoritmo normativo de registro duplicado a partir de un borrador de texto no disponible. Trate a los candidatos en competencia como una configuración retenida y verifique el comportamiento documentado del receptor objetivo antes de confiar en cualquier orden de selección observado.
Rastree el selector a través de la canalización de envío
Obtener una copia autorizada del mensaje recibido, conservando los encabezados. Registre el dominio Desde visible y todas las ocurrencias del Selector BIMI. Compare el estado de recepción con la configuración de la plataforma de envío y cualquier intermediario que pueda agregar o cambiar encabezados. Una aplicación puede solicitar un selector estacional mientras un servicio saliente inyecta una preferencia predeterminada diferente. Sin el mensaje real, el equipo DNS puede estar investigando un nombre que no se le pidió usar a ningún receptor.
BIMI Group recomienda incluir BIMI-Selector en el DMARC alineado firma DKIM y advierte que se puede ignorar un encabezado de selector sin firmar. Conserve la lista de encabezados firmados de la firma relevante y la evidencia de verificación. No asuma que una firma aprobada cubrió automáticamente este encabezado en particular. Una firma puede autenticar otras partes de un mensaje dejando la preferencia del selector fuera de su protección. Guía de firma BIMI
Si aparecen varios encabezados de selector, identifique dónde se agregaron y resuelva la configuración de envío en lugar de adivinar cuál respetará el receptor. Conserve el mensaje original antes de proponer una corrección. No edite un encabezado recibido y luego presente ese mensaje editado como evidencia del resultado de la verificación original. Cualquier prueba controlada posterior debe ser una observación nueva y autorizada con su propia identidad y marca de tiempo.
Establecer un límite de verificación confiable
Authentication-Results es útil sólo cuando el consumidor sabe qué sistema confiable lo produjo. Un encabezado arbitrario puede contener una afirmación que no es de confianza. RFC 8601 describe este límite de confianza; utilice evidencia del origen del receptor u otro verificador explícitamente confiable en lugar de aceptar un resultado pegado sin procedencia. Mantener la decisión BIMI , DMARC resultado y DKIM cobertura distinguible en la investigación. Límites de confianza RFC 8601
Registre el tiempo de observación DNS y el contexto de resolución junto con el tiempo del mensaje. Una búsqueda DNS posterior puede mostrar un estado reparado que no era visible cuando se evaluó el mensaje. Por el contrario, un error actual no prueba que un mensaje anterior haya recibido la misma respuesta. Trate la evidencia recopilada como una cadena con un límite de tiempo y evite inventar el estado histórico DNS a partir del contenido del editor actual.
Hoja de trabajo original de conflicto de selectores
Utilice esta hoja de trabajo por secuencia afectada. Los campos son solicitudes de evidencia propuestas, no verificaciones completadas. Preservar el contenido confidencial de los mensajes solo cuando sea necesario y esté autorizado; La redacción centrada en el encabezado a menudo puede conservar las relaciones relevantes.
- Identidad del mensaje: hora de recepción, visible desde el dominio y ubicación de evidencia autorizada.
- Estado del selector: ausencia, ocurrencia de encabezado único o múltiple, con valores retenidos exactos.
- Cobertura de firma: identidad DKIM alineada, lista de encabezados firmados y resultado de validación confiable.
- Destino DNS : nombre del propietario seleccionado, respuesta pública, límites de registro y tiempo de observación.
- Propiedad de la afirmación: transmisión prevista, activo, dependencia del certificado y cambio de propietario DNS .
- Conflicto: afirmaciones duplicadas, selector no coincidente, preferencia sin firmar o comportamiento del receptor no resuelto.
- Corrección propuesta: registro exacto afectado o configuración de envío, aprobación y plan de reversión.
- Cierre: nuevo mensaje controlado, observación DNS correspondiente y resultado del receptor confiable.
La hoja de trabajo debe distinguir los hechos de las hipótesis. “Se devolvieron dos registros con este nombre” es un hecho sólo cuando se ha conservado una respuesta real. “Es posible que un intermediario haya agregado otro encabezado” es una hipótesis hasta que la ruta del mensaje la admita. Mantener esa distinción visible ayuda a evitar cambios amplios DNS basados en una explicación plausible pero no probada.
Ejemplo ficticio: dos equipos comparten el nombre predeterminado
La ficticia Amber Ferry tiene un equipo de correo corporativo y una agencia de campaña. Ambos proponen publicar una aserción BIMI con el nombre del propietario predeterminado, mientras que la plataforma de la agencia está configurada para solicitar un selector estacional. La revisión de planificación inventada revela dos problemas independientes: intenciones predeterminadas en competencia y un nombre seleccionado que puede no tener la afirmación deseada. Eliminar un registro predeterminado por sí solo no establecería que el correo estacional siga la ruta correcta.
La solución propuesta es acordar la propiedad, mantener una afirmación prevista por nombre seleccionado y verificar el encabezado del selector y la cobertura de firma de la agencia en una nueva prueba autorizada. Las transmisiones existentes deben verificarse antes de retirar cualquier registro. No se inspeccionaron registros ni mensajes DNS de Amber Ferry y no se ejecutó ninguna corrección o prueba; el ejemplo muestra cómo separar los conflictos en lugar de pretender una reparación exitosa.
Cerrar sólo la cadena que se observó.
Una observación exitosa de un selector no valida todos los demás selectores, subdominios o plataformas de envío. Registre exactamente qué flujo y receptor se verificaron y conserve las incógnitas restantes. BIMI Group también señala que la evidencia del certificado está vinculada a un logotipo, por lo que un segundo selector que apunte a diferentes ilustraciones puede introducir una dependencia separada entre la evidencia y el documento en lugar de simplemente una tarea de denominación DNS . Guía de múltiples logotipos
El catálogo requiere una cadena de evidencia de mensaje a selector con DNS público y verificación confiable. No existe ninguno para un despliegue real en este manuscrito. 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. Este borrador es un flujo de trabajo de diagnóstico, no una prueba de que se haya probado el manejo duplicado o la selección del receptor.