Resumen
- RFC 9991 especifica informes DMARC de fallo para un mensaje concreto o un grupo de fallos semejantes; suelen llegar antes y con más material diagnóstico que un informe agregado.
rufyfoformulan la solicitud del propietario del dominio. El receptor conserva la decisión sobre qué tipo de informe, si alguno, enviar conforme a su política, el fallo observado y los riesgos de privacidad.- Daniel Kade propone un recibo de divulgación limitada que registra finalidad, categorías, reducción, agrupación, límite, transporte, acceso y borrado sin guardar mensajes, direcciones, credenciales ni cargas hostiles.
Un ejemplo perfecto puede ser una filtración perfecta
Un equipo ve que la tasa de alineación cae tras cambiar un servicio de envío. Pide un caso individual. La cabecera recibida muestra de inmediato qué salto alteró el mensaje. También revela el buzón final, un nombre interno y un reenvío que la organización de origen desconocía.
El dato ha resuelto el incidente técnico y ha creado otro problema de custodia.
El informe de fallo es valioso porque conserva detalles que el agregado elimina. Esa misma precisión cambia la naturaleza de la prueba: ya no son solo contadores atribuidos a un receptor, sino fragmentos de una comunicación real y de su recorrido. El propietario del dominio puede no haber enviado el mensaje; alguien pudo usar su identidad sin permiso, o un mensaje legítimo pudo fallar por accidente.
RFC 9991 no adjudica automáticamente ese contenido al solicitante. Coordina cómo se pide y cómo se describe. Quien recibió el mensaje sigue decidiendo si lo copia fuera de su frontera.
Solicitar, generar y consumir son actos distintos
El propietario publica destinos ruf y opciones fo en su registro DMARC. El receptor observa el resultado de autenticación y aplica su propia política para decidir qué informes transmite, si transmite alguno. El consumidor recibe después un objeto que debe aislar, interpretar y eliminar a tiempo.
La cadena contiene tres autoridades. Un DNS válido demuestra lo que pidió el dominio, no el consentimiento de una persona mencionada en el correo. Una respuesta de autorización del destino externo demuestra disposición a recibir, no necesidad de cada campo. Un consumidor capaz de procesar un mensaje no demuestra que el receptor estuviera obligado a entregarlo.
El texto del estándar preserva expresamente la elección del receptor. La condición solicitada, el fallo y la política local concurren en la decisión. Esa arquitectura importa: la interoperabilidad no exige que un actor pierda su responsabilidad sobre datos que custodia.
La velocidad tampoco elimina el control. Los informes pueden generarse casi inmediatamente para acelerar el diagnóstico. Cuanto menor es la demora, más necesario es que la política, la reducción y la ruta segura estén decididas de antemano.
Un campo de alineación no explica la historia
RFC 9991 actualiza ARF con datos DMARC. Identity-Alignment enumera los mecanismos que no autenticaron una identidad alineada, o contiene none si las pruebas intentadas sí lo hicieron. Otros campos describen DKIM, SPF y el resultado del receptor.
Son afirmaciones delimitadas. No distinguen por sí solas entre transformación intermedia, error de configuración, problema temporal o remitente no autorizado. No prueban intención humana, contenido dañino, entrega final ni derecho de acceso. Incluso none no convierte el mensaje en seguro.
ARF separa una explicación humana, una sección legible por máquinas y cabeceras o contenido original. La organización ayuda a procesar; no iguala el valor probatorio. La explicación puede equivocarse, los campos derivados reflejan una observación y el original aporta material que puede confirmar o refutar una hipótesis a costa de ampliar la exposición.
El consumidor debe formular la proposición exacta que necesita. Si basta saber qué mecanismo falló, no hay razón automática para recibir un cuerpo completo.
La autorización del destino no decide la proporcionalidad
Un registro puede pedir que los informes vayan a otro dominio. RFC 9991 utiliza el procedimiento de RFC 9990 por el que ese destino publica autorización. Así se evita que un propietario obligue unilateralmente a un tercero a recibir grandes volúmenes, datos sensibles o material abusivo.
La prueba cierra un abuso concreto. No certifica base jurídica, contrato, finalidad, plazo, personal autorizado ni subcontratistas posteriores. El propio RFC advierte que una dirección aparentemente interna puede reenviar, por lo que la ubicación final no queda garantizada por el primer salto.
Conviene registrar por separado la elegibilidad del destino y la decisión sobre el contenido. «Acepta informes» no significa «puede recibir cualquier copia que el generador tenga disponible».
Minimizar sin construir una identidad sombra
RFC 9991 recomienda limitar finalidad y duración, controlar cuidadosamente las URI, usar transporte seguro y redactar cuerpos o cabeceras. Reconoce que muchos proveedores grandes restringen o desactivan estos informes por su coste de privacidad.
RFC 6590 describe una transformación consistente y resistente a colisiones. Permite comprobar que dos valores ocultos eran iguales sin revelar el original. La correlación ayuda a agrupar, pero también crea persistencia: un token estable puede seguir a una persona o dirección entre casos.
La gobernanza debe fijar el ámbito de la clave, versión, periodo y propósito. No conviene reutilizar el mismo pseudónimo en clientes o investigaciones no relacionadas. Si no hace falta correlacionar, una categoría o identificador efímero expone menos.
Reducir demasiado tampoco es neutral. Un informe inútil sigue ocupando sistemas sensibles. La política debe responder qué dato mínimo resuelve la pregunta concreta y quién asumirá que no basta. La minimización es una decisión probada, no una casilla universal.
El límite de tasa convierte el flujo en una muestra
Un atacante puede enviar miles de mensajes fingiendo pertenecer a un dominio víctima y hacer que receptores participantes dirijan informes a esa víctima o su delegado. Por eso el estándar exige límites de salida y permite agrupar incidentes parecidos o descartar excedentes. La finalidad es mostrar condiciones diferentes, no contar cada fallo.
La ausencia de informes tiene muchas causas: ninguna condición, receptor no participante, política de privacidad, agrupación, descarte, fallo de transporte o ventana cerrada. Un pico puede reflejar un ataque, pero también un cambio de política o la recuperación de una cola.
El consumidor necesita conocer ventana, regla de agrupación y límite antes de inferir volumen. El generador puede conservar contadores por motivo y periodo sin guardar una copia por mensaje. Así se explica la muestra sin recrear el riesgo que la reducción pretendía evitar.
El contenedor de pruebas también contiene amenazas
Los informes pueden reproducir spam, enlaces de phishing, adjuntos maliciosos y estructuras pensadas para agotar analizadores. RFC 9991 recomienda aislamiento, entornos de pruebas, segmentación y acceso de personal formado. Enviarlos al buzón o buscador normal amplía la superficie.
Que el flujo del informe pase DMARC alineado mejora la atribución del transporte. No vuelve inocuo el contenido ni verifica todas las afirmaciones. Identidad del generador, seguridad de la carga, permiso del analista y retención son controles independientes.
Una automatización responsable puede terminar en negativa: eliminar adjuntos, neutralizar URI, rechazar MIME extraño, limitar recursos y mantener el caso fuera de índices generales. Parsear bien no equivale a custodiar bien.
El recibo de divulgación limitada
Propongo un recibo compacto para la política y para cada excepción. Es una recomendación editorial, no un nuevo requisito de RFC 9991.
El recibo enlaza dominio, consulta DNS, destinos ruf, condición fo, autorización externa, versión de política, finalidad y caducidad. Registra clase de fallo, agrupación, límite y categorías liberadas: campos derivados, subconjunto de cabeceras, token redactado o extracto acotado.
Añade método y alcance de redacción, resultado del transporte, rol consumidor, aislamiento, retención y borrado o sustitución. No incorpora cuerpo, partes locales, destinatarios, credenciales, URL activas ni adjuntos. Una huella solo se conserva si la finalidad y el riesgo la justifican.
El resultado no promete ausencia de daño. Permite reconstruir por qué unos datos concretos cruzaron una frontera concreta. La respuesta nunca debe reducirse a que alguien publicó ruf.
Fuentes
- Lu Heng — Soberanía de datos: realidades técnicas y prácticas
- Lu Heng — Por qué existe BTW Media
- Lu Heng — The Policy Mirror
- IANA — Parámetros de Messaging Abuse Reporting Format
- Ficha de RFC 9991
- RFC 5322 — Formato de mensajes de Internet
- RFC 5965 — Formato extensible de informes de correo
- RFC 6590 — Redacción de datos potencialmente sensibles
- RFC 6591 — Informes de fallos de autenticación
- RFC 6650 — Creación y uso de informes ARF
- RFC 7489 — DMARC
- RFC 9989 — DMARC
- RFC 9990 — Informes agregados DMARC
- RFC 9991 — Informes de fallo DMARC
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance