Informes DMARC: RUA vs RUF, ¿qué diferencia?

Configurar RUA y RUF en el registro DMARC

Las dos direcciones se configuran en el registro _dmarc:

_dmarc.ejemplo.es.  IN TXT
  "v=DMARC1; p=quarantine; rua=mailto:dmarc@ejemplo.es;
   ruf=mailto:ruf@ejemplo.es; fo=1"

• rua=: la dirección donde se reciben los informes agregados. Se pueden poner varias, separadas por comas.
• ruf=: la dirección para los informes forenses. A menudo diferente, a veces ausente.
• fo=: controla cuándo se genera un RUF. fo=0 (por defecto) = solo si todas las verificaciones fallan. fo=1 = en cuanto una verificación falla. fo=d = únicamente si DKIM falla. fo=s = únicamente si SPF falla. En la práctica, fo=1 da el máximo detalle, pero también el máximo volumen.

Cuando no se quieren RUF (por elección de conformidad, o porque no se explotan), basta con omitir ruf= y fo=. El informe agregado (RUA) es el verdadero valor — el RUF es un complemento para diagnósticos específicos.

Lo que conviene hacer en la práctica

Para la gran mayoría de los despliegues, los RUA bastan ampliamente. Dan una visión completa de quién envía en nombre del dominio, con qué resultados, desde qué IP — exactamente lo que hace falta para progresar hacia p=reject. Analizarlos regularmente (o hacerlos analizar por una herramienta o por Thomas) revela qué fuentes corregir, en qué orden, y cuándo el dominio está listo para endurecer su política.

Los RUF son útiles para diagnosticar un problema muy específico: un tipo de mensaje particular que falla, una fuente desconocida que envía en nombre del dominio. Pero solo hay que abrirlos con conocimiento de su contenido potencialmente sensible, y sobre todo no transmitirlos a terceros sin verificar lo que contienen.

El buen reflejo al empezar: configurar un rua= hacia un buzón dedicado (o una plataforma DMARC), dejar que los informes lleguen unos días, y leerlos. El diagnóstico de quién envía en nombre del dominio está ahí casi entero. No hace falta RUF para dar este primer paso, ni para la mayoría de los que vienen después: la foto que dibujan los RUA basta para tomar cada decisión de endurecimiento con criterio, hasta llegar a p=reject.

Quién envía informes RUA

Los grandes actores envían RUA de manera fiable: Gmail, Outlook/Microsoft, Yahoo, Apple Mail, AOL, ProtonMail, y muchos otros. No es exhaustivo — solo los actores que han implementado el protocolo envían informes — pero en la práctica, los informes recibidos cubren la gran mayoría del tráfico de email mundial. Con un envío en volumen, los datos suficientes para diagnosticar llegan rápidamente.

Nota: los RUA solo cubren el tráfico hacia los buzones de los proveedores que los envían. El correo dirigido a servidores autoalojados o a pequeños proveedores no aparece en los informes.

Preguntas frecuentes

¿Hay que configurar ruf=? No. Los RUA bastan para la práctica totalidad de los casos. ruf= se configura solo ante una necesidad de diagnóstico forense preciso, y una vez evaluadas las implicaciones de privacidad.

¿Cuánto tiempo antes de recibir informes? De unas horas a 24h tras la publicación del registro DMARC. Los primeros informes llegan a menudo a la mañana siguiente. Cubren el periodo anterior.

¿Llegan los informes de todos los destinatarios? No. Solo de los actores que han implementado el protocolo. Gmail y Microsoft envían informes muy fiables; muchos pequeños servidores no envían ninguno.

¿Exponen los RUA datos personales? No: los informes agregados contienen estadísticas e IP, pero no el contenido de los mensajes ni las direcciones de los destinatarios. Los RUF, por su parte, sí pueden contenerlos — es por eso que hay que manejarlos con precaución.

¿Se pueden recibir los informes en una dirección externa? Sí, pero hace falta que el dominio de la dirección de recepción esté autorizado mediante un registro TXT en _dmarc.dominio-externo.es (para evitar que cualquiera pueda enviar sus informes a cualquier buzón). Si la dirección está en el propio dominio, es automático.

Cómo los informes ayudan a progresar hacia p=reject

El valor principal de los informes DMARC no es confirmar que el correo pasa — es mostrar cómo hacerlo pasar. Un informe RUA es en realidad un mapa de los flujos de envío: cada bloque <record> es una fuente, y el resultado de autenticación de esa fuente dice exactamente lo que hay que corregir. El proceso es iterativo por naturaleza.

Al principio, con p=none, los informes llegan sin que nada esté bloqueado. Es la fase de observación: se descubre qué IP envían en nombre del dominio, cuáles pasan, cuáles fallan, y cuáles ni siquiera se reconocían. Las fuentes legítimas se corrigen una por una — activando DKIM, alineando SPF, excluyendo las fuentes desconocidas — y se vigilan los informes para confirmar que cada corrección ha surtido efecto.

Una vez que los informes muestran que la gran mayoría de las fuentes legítimas pasan (típicamente >95%), se pasa a p=quarantine. La misma lógica se aplica: vigilar los informes, verificar que ninguna fuente legítima esté impactada, afinar. Luego se sube a p=reject. En cada etapa, los informes RUA son el instrumento de medida: dicen dónde está el dominio, no solo si pasa o si rompe.

La sutileza: un informe que muestra dmarc=fail sobre una IP no es forzosamente un problema. Si es una IP no reconocida, quizá es falsificación (alguien intenta usurpar el dominio) — y el p=reject se lo impedirá. Si es una IP identificada como una fuente legítima mal configurada, es algo que hay que corregir. Distinguir los dos es lo esencial del trabajo de interpretación que los informes hacen posible.

Identificar las fuentes en los informes

Un informe bruto da una IP. Un informe bien explotado dice a quién pertenece esa IP. Es esa conversión — IP → servicio de envío identificado — lo que transforma un informe en un plan de acción. Las herramientas DMARC hacen este trabajo automáticamente (ver las herramientas para analizar los informes), pero también se puede hacer manualmente para unas pocas IP clave mediante herramientas de resolución inversa.

Las IP recurrentes con dkim=pass, spf=pass, dmarc=pass son las fuentes bien configuradas — no hay que tocarlas. Las IP recurrentes con fallos sobre una fuente identificada son las prioridades de corrección. Las IP desconocidas con dmarc=fail son o bien falsificación (ninguna acción necesaria, p=reject hace su trabajo), o bien una fuente legítima olvidada (a corregir o a confirmar como apagada).

Thomas lee los informes

Recibir informes RUA es una cosa; explotarlos es otra. Thomas, el CISO virtual, lee los informes, dice qué fuentes pasan, cuáles fallan, por qué, y en qué orden corregirlas. Transforma un XML bruto en un plan de acción claro hacia p=reject.

Analizar un dominio gratis o crear una cuenta para informes DMARC descodificados automáticamente.