Dos partes establecen la relación de subordinación.
Publicar un destino de informes en un dominio DMARC La política expresa la solicitud del propietario del dominio. No exige unilateralmente que un destino no relacionado acepte los informes resultantes. Verificación de destino externa protege a los destinatarios de ser seleccionados como objetivos de informes no dispuestos. El lado receptor publica el permiso a través de DNS , mientras que el lado informador verifica ese permiso antes de usar el destino externo.
RFC 9990 aplica su procedimiento de verificación cuando el Dominio organizacional La comparación muestra un destino externo para los informes agregados. No reemplace esa regla con una prueba simplista de que las cadenas en la dirección de origen y la dirección del informe difieren. Se deben conservar el dominio de políticas descubierto, el host de destino y el contexto del dominio organizacional para que la decisión de realizar la verificación sea reproducible. RFC 9990 , sección 4
Construya el nombre del propietario en el orden correcto
Extraiga el host de destino del URI de informes. Anteponer _reporte. _dmarc , luego anteponga el nombre de dominio del cual se recuperó la política, convirtiendo ese dominio en una etiqueta A si es necesario. El propietario DNS resultante tiene el formato dominio-política._informe. _dmarc.destination-host. Se consulta por Registros TXT. Si el nombre construido excede los límites DNS , no se puede realizar una determinación de autorización positiva.
Esta construcción utiliza el dominio real del que se recuperó la política. No lo reduzca a un padre conocido simplemente porque ese padre se parece a la marca de la organización. Del mismo modo, la parte local de una dirección de correo no se inserta en el nombre del propietario DNS . Conserve el URI original y el host de destino analizado para que los revisores puedan ver cómo el nombre construido se deriva de las entradas. RFC 9990 , sección 4
Validar la respuesta en lugar de reconocer una cadena familiar
Los registros devueltos se analizan como listas de valores de etiquetas. La etiqueta obligatoria v=DMARC1 debe aparecer primero y el punto y coma al final es opcional. Los registros que no pasan la prueba de análisis especificada se descartan. Al menos un registro calificado restante establece el acuerdo de presentación de informes externos según el procedimiento. Una respuesta vacía, un valor TXT no relacionado o un récord con una ubicación de versión incorrecta no establece el permiso.
El valor de la versión DMARC distingue entre mayúsculas y minúsculas: DMARC1 es el valor requerido, no una aproximación en minúsculas ni una versión de protocolo recién inventada. Las reglas de comparación de nombres DNS no deben confundirse con el requisito de mayúsculas y minúsculas del valor de la versión. Una revisión debe preservar los bytes de respuesta exactos y los límites de los registros en lugar de normalizar los detalles antes de la validación. RFC 9990 , sección 4; RFC 9989 , sección 4.7 y 4.8
Respetar el comportamiento de anulación y falla
Un registro de autorización puede proporcionar una anulación del destino de informes según el procedimiento. El URI principal debe utilizar el mismo host de destino extraído al principio. Esta restricción evita que una respuesta de autorización redirija el proceso a una cadena de destinatarios no relacionados. Si la confirmación contiene una anulación con un host diferente, el generador de informes no debe generar un informe ni para el URI original ni para la anulación.
Si la verificación no confirma la autorización, se debe ignorar el URI externo. Un error temporal DNS tiene su propio tratamiento: el receptor puede optar por fallar temporalmente la entrega para que la prueba de verificación pueda repetirse más tarde. Conserve ese permiso como MAYO, no como una garantía de reintento universal o una descripción de una implementación probada. Una verificación DNS exitosa aún no prueba que el buzón de destino exista, acepte el tamaño del informe o alimente el panel de control del cliente previsto. RFC 9990 , sección 4
Distinguir solicitudes de informes agregados y de fallas
Para informes agregados, el procedimiento está asociado a rua. Los informes de fallos se especifican por separado en RFC 9991. Para destinos de informes de fallas externos, ese documento requiere el mismo procedimiento de verificación externa con ruf sustituido dondequiera que aparezca rua. No trate los informes de errores como habilitados automáticamente solo porque los informes agregados están fluyendo, ni copie el manejo del destino agregado sin reconocer el tipo de informe separado.
Informes de fallas plantean preocupaciones adicionales sobre la exposición de los datos porque su contenido puede ser más detallado que los resúmenes agregados. Un registro de autorización DNS correcto no sustituye la decisión de una organización sobre qué datos se pueden compartir, con quién y con qué propósito. Este manuscrito no proporciona permiso para solicitar, transmitir o cargar informes reales. Cualquier configuración real debe cumplir con las aprobaciones operativas, de destinatario y de privacidad aplicables. RFC 9991 , secciones 5 y 7
Hoja de trabajo de construcción y aceptación ficticia.
Supongamos que se recuperó una política ficticia de blue.example.com y solicita informes agregados en mailto:reports@red.example.net. El propietario de la autorización construida es blue.example.com._report._dmarc.red.example.net . Una respuesta TXT hipotética cuyo valor completo es v=DMARC1; satisface el requisito de la primera versión ilustrada. No se ejecutó ninguna consulta DNS y este ejemplo no afirma que los nombres tengan registros publicados.
La hoja de trabajo debe conservar el resultado de la búsqueda de políticas, el dominio de políticas descubierto, el URI de informes original, el host de destino, la comparación del dominio organizacional, el propietario construido, el tipo de consulta, la marca de tiempo, los registros exactos devueltos y el resultado del análisis. Agregue un campo separado para cualquier anulación y confirme su restricción de host. Un revisor debería poder reconstruir el nombre sin depender de una captura de pantalla del proveedor o de la visualización abreviada de un editor DNS .
Utilice una segunda sección de aceptación para la recopilación: cuenta prevista, buzón de destino, tipo de informe autorizado y propietario de la canalización. Esos campos describen un flujo de trabajo de verificación planificado, no evidencia de ingesta completa. Mantenga el resultado de la relación DNS distinto de la recepción, el análisis, la atribución de inquilinos y la presentación del panel. Una verificación de permisos puede tener éxito mientras otra parte de la ruta de recopilación permanece sin resolver.
Retenciones de publicación e implementación
El catálogo requiere la construcción de la búsqueda de autorización exacta de los dominios de origen y de destino y la verificación de su respuesta. Este borrador proporciona únicamente una construcción ficticia. La respuesta real, la transcripción de la consulta original y la implementación del dominio de recepción permanecen abiertas. No se publicó ningún registro DNS , no se accedió a ningún buzón y no se transmitió ningún informe.
Antes de publicarlo como un recorrido operativo, obtenga evidencia autorizada de la relación de producción exacta y haga que un revisor calificado confirme el contexto de descubrimiento de políticas, el análisis de versiones y el manejo de anulaciones. Conserve la fecha de origen y distinga los requisitos de estándares de la incorporación de cuentas específicas del proveedor. Las seis puertas de divulgación permanecen abiertas, incluida la evidencia original, la revisión humana, la aplicabilidad de las fuentes, las rutas de producción, la accesibilidad visual y la autorización del propietario.
Un cambio posterior en el dominio de destino o de descubrimiento de políticas puede cambiar el propietario de la autorización requerida. Trátelo como una nueva relación de alcance para verificar en lugar de asumir que una verificación positiva anterior cubre todas las direcciones de informes futuras. El resultado útil es una cadena de permisos auditable, no simplemente un valor TXT copiado.