Resumen

  • RFC 9990 define un informe XML en el que un Mail Receiver comunica observaciones agregadas sobre mensajes vistos, la política publicada, resultados de autenticación y recuentos para un periodo.
  • La verificación DNS de un destino rua externo confirma que ese Report Consumer acepta recibir informes; no acredita que los datos sean completos o verdaderos ni habilita por sí misma una sanción.

El destinatario externo suele ser el punto que se sobredimensiona. Un equipo de seguridad contrata un servicio de análisis, publica una dirección de informe y observa que la comprobación DNS ya está resuelta. Desde ahí resulta tentador convertir cada fila entrante en una orden: bloquear una IP, elevar un incidente o declarar que un proveedor incumple. El propio diseño del protocolo rechaza esa compresión.

RFC 9990 permite que los Domain Owners soliciten informes agregados a los receptores. Para un destino ubicado fuera del dominio organizacional, el receptor debe realizar el procedimiento de verificación externa. Si la relación no se confirma con el registro DNS requerido, debe ignorar la URI. La medida limita un abuso claro: sin ella, alguien podría publicar una política que señale a una víctima y provocar que muchos receptores le envíen informes no deseados.

La respuesta positiva contesta una pregunta concreta: ¿está este consumidor dispuesto a recibir informes para esta relación de dominio? No responde quién podrá acceder al panel, durante cuánto tiempo se guardarán los datos, si el procesador los combinará con otras fuentes, qué subcontratista los verá o qué acción se permitirá derivar de ellos. La autorización de ruta no es una licencia de uso de datos ni una delegación de la política del receptor.

El XML registra una vista de recepción

La estructura exigida conserva esa limitación. Hay metadatos del generador, una policy_published y uno o más record. La política es la configuración observada por el sistema receptor. Cada registro afirma que determinadas direcciones IP fueron vistas entregando mensajes para el Author Domain a ese sistema. Una fila puede resultar muy informativa: quizá muestre un origen de envío no inventariado, una firma que dejó de funcionar o tráfico que merece una comparación urgente. No es una muestra universal de todos los receptores ni una prueba de quién escribió el mensaje o con qué intención.

La fecha tampoco ofrece una historia total. La gama begin/end define el periodo del informe, no el primer y último mensaje observados. Habitualmente cubre un día UTC y no debería solaparse con otros periodos. La ausencia de un origen en una ventana no demuestra que nunca enviara; la presencia de un conteo no demuestra que el resto de Internet viera lo mismo.

Los resultados SPF y DKIM se incluyen, pero RFC 9990 los describe como no interpretados respecto de DMARC. Un motivo de anulación de política es igualmente un dato sobre por qué un receptor anuló una decisión, no una certificación de identidad humana, intención o culpabilidad. Cuando un tablero cambia ese material por etiquetas como “fraude confirmado” o “proveedor hostil”, agrega una decisión nueva que debe tener responsable, evidencia adicional y posibilidad de revisión.

La práctica prudente es contrastar la fila con el inventario de remitentes autorizados, cambios de DNS y claves, registros propios de salida, rutas de reenvío, historial de proveedor y resultados repetidos de receptores independientes. Conserve el artefacto original, su hash y los campos derivados por separado. Así una recomendación de un tablero puede ser discutida como lo que es: una inferencia local, no una sentencia alojada dentro del RFC.

Un informe alineado todavía puede ser falso o peligroso

RFC 9990 transporta el agregado como archivo XML por correo, normalmente comprimido con GZIP. El flujo que lleva feedback debe conformar DMARC y lograr un pase alineado para reducir el riesgo de que el consumidor procese informes fraudulentos. Los identificadores y nombres de archivo ayudan a detectar reenvíos o duplicados.

Esas capas no resuelven la verdad del contenido. El RFC advierte que los datos agregados pueden ser falsificados para influir en decisiones de política o de arquitectura de plataforma. También advierte que un informe malformado puede agotar el descompresor o el analizador XML con una bomba ZIP o XML. Una entrega aparentemente correcta, a una dirección autorizada, no convierte las afirmaciones internas en hechos completos y seguros.

Por eso la primera acción de un consumidor no es modificar su política, sino limitar su superficie de entrada. Aplique presupuestos de tamaño antes y después de descomprimir, límite de profundidad y complejidad XML, validación de esquema y separación entre archivo bruto y datos extraídos. Si el formato no coincide, RFC 9990 permite que el evaluador descarte o aparte el informe para coordinar con el generador. Haberlo analizado no equivale a aceptarlo como evidencia; haberlo aceptado tampoco equivale a justificar una decisión de alto impacto.

Las restricciones de privacidad añaden una razón independiente para no simplificar. El RFC indica que los informes agregados no contienen contenido de mensajes, direcciones individuales ni IP de individuos. Pero los destinatarios pueden hacer análisis de tráfico y un Mail Receiver puede tener políticas o condiciones que limiten el envío a terceros. Un reporte de dominio sigue siendo una vista operacional valiosa. Conviene definir quién la puede mirar y para qué antes de que la herramienta la normalice como telemetría sin dueño.

La política empieza después del informe

RFC 9989 señala que, según la cadencia de correo, un Domain Owner puede requerir muchos meses de informes agregados antes de tener certeza de que autentica todo su correo correctamente. La elección de p depende de sus propias necesidades. El texto no prescribe que una cantidad determinada obligue a pasar a cuarentena o rechazo. Declara un espacio de juicio local y de efectos locales.

Interpretación editorial: una capa común acotada

Esa división es la que conviene conservar. El Mail Receiver observa. El Report Consumer acepta una relación de entrega. El evaluador valida y decide qué guardar. El operador que soportará las consecuencias decide la política. Esta es una lectura editorial: una gramática común y un control contra reflexión bastan para interoperar; no hace falta que el formato designe una autoridad central sobre los correos de otros. Hay que ubicar el hecho en la ejecución: qué receptor observó, qué versión del validador aceptó, quién ordenó el cambio y qué resultado produjo.