Informes forenses DMARC (RUF) y privacidad: lo que hay que saber

Implicaciones RGPD

Para quien decide recibir y explotar RUF, estos son los puntos de cumplimiento a considerar:

Base legal. Las cabeceras de correo contienen datos personales (direcciones de correo, metadatos de mensajes). El tratamiento de estos datos requiere una base legal en el sentido del RGPD —típicamente el interés legítimo (seguridad del sistema de información), a documentar en el registro RGPD—.

Minimización de datos. Los RUF deben usarse únicamente para el diagnóstico de seguridad, no para otros usos. Su conservación se limita a lo necesario (unos días a unas semanas bastan para un diagnóstico).

Transmisión a terceros. Cuando los RUF se transmiten a una plataforma DMARC de terceros, esa plataforma se convierte en encargada del tratamiento en el sentido del RGPD —hay que asegurarse de que existe un DPA (Data Processing Agreement) en vigor y de que la plataforma respeta las exigencias de seguridad aplicables—.

Registro RGPD. Cuando se tratan RUF, este tratamiento debe añadirse al registro RGPD (art. 30): finalidad (seguridad del correo), categoría de datos (cabeceras, direcciones de correo), duración de conservación, base legal.

Cifrado y aislamiento. Los RUF no deben acabar en un buzón compartido o accesible a personas sin necesidad de consultarlos. Deben aislarse en un buzón dedicado con acceso limitado.

La cuestión de la utilidad real

Dadas las limitaciones actuales (pocos proveedores de correo que envían RUF) y las restricciones del RGPD, cabe preguntarse: ¿valen los RUF el esfuerzo? Para la gran mayoría de los despliegues, la respuesta es no. Los informes agregados (RUA) dan todo lo necesario para identificar y corregir las fuentes: IP, resultados de autenticación, volumen. Los RUF aportan un detalle sobre un mensaje individual que a menudo será inexplotable (puede que el proveedor de correo en cuestión no los envíe).

Los casos en los que los RUF conservan una utilidad real: cuando hay que diagnosticar un tipo concreto de mensaje que falla y existe confirmación de que el proveedor de correo afectado envía RUF; o en un contexto en el que se controla la infraestructura de correo de extremo a extremo y la organización puede enviarse RUF a sí misma.

Cómo configurar (o no configurar) ruf=

Cuando se opta por no usar los RUF —la recomendación para la mayoría de los casos—, basta con omitir ruf= y fo= del registro. El registro DMARC funcionará perfectamente con solo rua=:

_dmarc.ejemplo.es.  IN TXT
  "v=DMARC1; p=reject; rua=mailto:dmarc@ejemplo.es"

Cuando se opta por usar los RUF, se añade:

ruf=mailto:ruf@ejemplo.es; fo=1

fo=1 genera un RUF en cuanto una comprobación falla —es el valor más informativo pero también el más voluminoso—. fo=0 (por defecto) solo genera un RUF si todas las comprobaciones fallan —menos volumen, menos información—.

Un último reflejo de higiene: auditar lo existente. Muchos dominios arrastran un ruf= puesto hace años, apuntando a un buzón que ya nadie lee —o incluso a la dirección de un antiguo empleado o de una herramienta de terceros dada de baja hace tiempo—. Es lo peor de los dos mundos: no se saca ningún valor de diagnóstico, pero unos datos personales siguen acumulándose en un buzón sin dueño, sin duración de conservación controlada, a veces fuera de todo control. A la luz del RGPD, es un tratamiento huérfano —recogido sin finalidad activa ni responsable identificado—. Conviene comprobar, pues, lo que el registro DMARC declara realmente hoy: si la dirección ruf= ya no corresponde a un destinatario activo y legítimo, hay que retirar la etiqueta —es la corrección más rápida de toda esta guía—.

Preguntas frecuentes

¿Google envía todavía RUF? No, Google dejó de enviar informes forenses. La mayoría de los RUF que llegan provienen de actores menos conocidos.

¿Son peligrosos los RUF para la privacidad? Potencialmente, según su contenido. Pueden revelar direcciones de correo, asuntos de mensajes y rutas de envío. Deben tratarse con tanto cuidado como cualquier otro dato sensible.

¿Debo poner fo= en mi registro? Únicamente si se configura ruf=. Sin ruf=, la etiqueta fo= no tiene ningún efecto. Y a falta de ruf=, no hay nada que configurar.

¿Puede una herramienta DMARC de terceros recibir mis RUF? Sí, configurando ruf=mailto:direccion@herramienta-externa.es. Conviene comprobar que la herramienta ha firmado un DPA (acuerdo de tratamiento de datos) y que sus condiciones de tratamiento se corresponden con las exigencias RGPD aplicables.

¿Cómo saber si recibo RUF? Basta con mirar el buzón ruf=: los RUF llegan con un asunto distinto de los RUA, a menudo como archivos de texto MIME (no XML como los RUA, sino message/feedback-report).

¿Están los RUF cubiertos por una duración de conservación RGPD específica? No —no hay una duración legalmente impuesta para los RUF como tales—. En la práctica, la minimización de datos (principio del RGPD) sugiere guardarlos solo el tiempo del diagnóstico, es decir, de unos días a unas semanas. Más allá, deben borrarse o anonimizarse. Es aún más importante cuando se almacenan en un buzón de correo compartido.

¿Puedo desactivar los RUF si ya los he configurado? Sí. Basta con retirar ruf= y fo= del registro DMARC —los proveedores de correo que leen el registro con regularidad dejarán de enviar RUF—. Se aplica la propagación DNS, pero en 24-48 h ya no llegan nuevos.

¿Dan los RUF acceso a los mensajes de los destinatarios o de los remitentes? Únicamente de los remitentes (los mensajes que fallaron al pasar DMARC desde el dominio o pretendiendo venir de él). Un RUF nunca contiene el contenido de un mensaje entrante dirigido a uno de los usuarios del dominio —trata sobre los mensajes que usaron su From: de forma no conforme, legítimamente o no—. Es una distinción importante para evaluar el riesgo real para la privacidad: el riesgo recae sobre los remitentes del propio dominio (los usuarios que envían por rutas mal configuradas), no sobre los destinatarios externos.

La situación concreta en 2025-2026

La realidad del mercado ha zanjado en gran medida la cuestión de los RUF. Desde que Google dejó de enviarlos en 2023, la cobertura de los RUF se ha desplomado: los grandes proveedores de correo que representan lo esencial del tráfico de correo mundial ya no los envían. Lo que llega al configurar ruf= hoy proviene principalmente de pequeños proveedores o de servidores autoalojados, a menudo una minoría del tráfico total.

Esta realidad operativa hace que los RUF sean poco explotables para la gran mayoría de los despliegues: no hay RUF sobre los mensajes que fallan en Gmail (los destinatarios más numerosos), lo que limita el valor de diagnóstico. En cambio, cuando una organización envía principalmente hacia servidores internos (correo de empresa a otros servidores de empresa), o cuando se hacen pruebas en un entorno controlado, los RUF pueden todavía tener su utilidad.

RUF en DMARCbis (RFC 9990)

DMARCbis —la nueva versión de DMARC definida por las RFC 9989/9990/9991— trata los informes forenses en la RFC 9990, distinta de la RFC 9989 que define el protocolo en sí. La RFC 9990 reconoce explícitamente los problemas de privacidad ligados a los RUF y no refuerza su uso —al contrario, precisa que las implementaciones PUEDEN optar por no emitirlos—. Es un reconocimiento oficial del estado actual del mercado. Al migrar a DMARCbis (véase migrar a este nuevo estándar), la estrategia RUF puede quedar inalterada o prescindir de ellos por completo.

Thomas se encarga de los informes

Lleguen RUA, RUF o ambos, Thomas, el CISO virtual, se ocupa de la lectura, el diagnóstico y el plan de acción. No hay ningún XML que abrir, ni correos que clasificar, ni estadísticas que calcular —Thomas señala lo que importa y qué hacer—.

Analizar un dominio gratis o crear una cuenta para una gestión DMARC completa y sin fricción.