ri= en DMARC: la frecuencia de los informes y lo que cambia

ri=86400   → informes diarios (por defecto, recomendado)
ri=3600    → informes cada hora (si el proveedor lo admite)
ri=604800  → informes semanales

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

Por qué 86400 (24 h) es el valor a recordar

Para la práctica totalidad de los contextos, ri=86400 es el valor a usar, o simplemente omitir ri=, que viene a ser lo mismo (el valor por defecto es 86400). He aquí por qué:

• Es la cadencia que los proveedores aplican realmente.
• Un informe diario da un volumen de información manejable: deja ver las tendencias del día y detectar una nueva fuente o un pico anómalo en 24 h como máximo.
• Un informe más frecuente no aporta más información útil, solo más ruido si algunos actores lo respetaran.
• Un informe semanal (ri=604800) retrasa demasiado la detección de un problema.

Para un dominio crítico donde un incidente de seguridad en las primeras 24 horas podría tener un impacto mayor, lo eficaz es vigilar la actividad en tiempo real a través de una herramienta DMARC, en lugar de intentar modificar ri=.

El retardo entre el envío y la recepción de los informes

Un punto a menudo mal entendido: el informe que llega a las 8 de la mañana cubre el periodo del día anterior, no del día en curso. Siempre hay un desfase entre el momento en que se evaluaron los mensajes y el momento en que el informe llega. En la práctica:

• El periodo de informe cubre generalmente de 00h00 a 23h59 UTC.
• El informe se genera y se envía en las primeras horas siguientes (a menudo entre las 3 h y las 9 h UTC).
• Llega de unos minutos a unas horas después según el enrutamiento del correo.

En concreto: lo que pasó ayer lo cuenta el informe de la mañana siguiente. Para los incidentes del mismo día, hay que esperar al informe del día siguiente. Por eso una plataforma DMARC con una vista continua es más útil que una vigilancia manual de los informes.

Un buzón dedicado para recibir los informes

Punto práctico a menudo descuidado: el buzón que recibe todo esto. Con una cadencia diaria y varios proveedores que envían cada uno su fichero, la dirección rua= acumula rápidamente varios adjuntos comprimidos al día, XML en .zip o .gz, ilegible a simple vista. rua= no debe apuntar a un buzón personal: los informes ahogarían los mensajes reales, y un filtro un poco celoso acabaría clasificándolos como no deseados, o incluso borrándolos. Mejor crear una dirección dedicada a este uso, sin una cuota demasiado ajustada. Con una plataforma DMARC, es ella la que expone la dirección de recogida y la cuestión desaparece. Cuando los informes se tratan a mano, hace falta una regla de clasificación automática y una purga regular: un buzón lleno rechaza los informes entrantes, y la visibilidad se pierde sin que nadie se dé cuenta.

¿Y si no llega ningún informe?

Si no llega ningún informe tras unos días, hay que comprobar en este orden:

1. ¿Está publicado el registro DMARC? (dig TXT _dmarc.ejemplo.es debe devolver el registro).
2. ¿Es correcta la dirección rua=? Una errata, un buzón inexistente o un dominio incorrecto bastan para perderlo todo.
3. Si rua= apunta a un dominio externo (por ejemplo una plataforma DMARC), ese dominio debe tener un registro DNS de autorización (_dmarc.dominio-externo.es TXT "v=DMARC1").
4. ¿Envía correo el dominio? Un dominio que no envía nada no genera informes: normal.
5. ¿No están los informes en spam? La carpeta de spam de la dirección destinataria merece una mirada.

ri= en DMARCbis (RFC 9989)

En la nueva versión de DMARC (DMARCbis), el parámetro ri= sigue presente y conserva el mismo sentido. Los cambios mayores de DMARCbis afectan a otras etiquetas (pct suprimida, np y t añadidas), no a ri=. En una migración a DMARCbis (ver migrar a este nuevo estándar), el valor ri= sigue siendo válido sin modificación.

Preguntas frecuentes

¿Debo incluir ri= en mi registro? No, es opcional. El valor por defecto es 86400, que es el valor correcto para la mayoría de los casos. Por explicitud, se añade ri=86400; si no, se omite.

¿Se pueden pedir informes cada hora? Técnicamente sí (ri=3600), pero la práctica totalidad de los proveedores lo ignoran y envían de todos modos a diario. No hay que contar con una frecuencia inferior a 24 h.

¿Se aplica ri= también a los RUF? No. ri= concierne a los informes agregados (RUA). Los informes forenses (RUF) se disparan por evento (un mensaje que falla), no por intervalo.

¿Y si los informes llegan de varios proveedores a horas diferentes? Es normal: cada proveedor genera y envía su informe a su propia hora. El informe de Gmail puede llegar a las 6 h y el de Microsoft a las 14 h, ambos para el mismo periodo. Las herramientas DMARC los agregan automáticamente.

¿Puede un informe cubrir un periodo distinto de 24 h? Sí, especialmente al arrancar: si el registro DMARC se publica a las 15 h, el primer informe puede cubrir solo las 9 horas restantes del día. Los informes siguientes vuelven a las 24 h.

¿Cómo cubren los informes varios husos horarios? Los informes usan marcas de tiempo Unix (UTC) para los date_range. Es el proveedor quien decide el periodo cubierto, generalmente de 00h00 a 23h59 UTC. Cuando la actividad se concentra en un huso diferente (UTC+2, UTC-8…), los informes pueden cortar una jornada laboral en dos periodos de informe. Es un detalle que cuenta al analizar un incidente en un día concreto.

¿Tienen los informes DMARC una fecha de caducidad? No, no expiran, pero su valor disminuye con el tiempo. Un informe de seis meses solo es útil para comparar la evolución de una configuración, no para el diagnóstico de la situación actual. Los últimos 30 días bastan para el diagnóstico corriente; el histórico largo sirve para las tendencias.

Lo que debería vigilarse realmente (y con qué frecuencia)

La verdadera pregunta no es «¿con qué frecuencia llegan los informes?» sino «¿con qué frecuencia se leen?». Y ahí, la buena respuesta depende de la fase de despliegue DMARC.

En fase de observación (política p=none): lectura semanal. No hay ningún riesgo de interrupción, los cambios son lentos (identificar y corregir las fuentes lleva tiempo), y una revisión semanal basta para seguir los progresos. En fase de transición (p=quarantine): lectura diaria durante las primeras semanas, o alertas configuradas. Es ahí donde se puede bloquear involuntariamente un flujo legítimo, y donde detectarlo rápido importa. Una vez estabilizada la cuarentena desde hace unas semanas, se vuelve a un ritmo semanal. En fase estable (p=reject): una revisión mensual suele bastar, complementada con alertas automáticas para las anomalías (nueva IP desconocida, pico de fallos repentino). La monitorización pasa a ser mantenimiento, no investigación.

El ri= no cambia nada de esta lógica: los informes llegan a diario en todos los casos. Es la cadencia de lectura y de análisis lo que cuenta, no la de recepción.

Informes y auditoría de seguridad

Para las organizaciones sometidas a auditorías (ISO 27001, NIS2, sector bancario…), los informes DMARC constituyen una prueba de monitorización. Conservar un histórico de los informes, aunque sea parcial, permite demostrar en una auditoría que la política DMARC se vigila y que las anomalías se detectan y se tratan. Es el mismo razonamiento que para los logs de cortafuegos: su valor no está en la lectura diaria, sino en la capacidad de demostrar que hay vigilancia y que hay reacción. Una plataforma DMARC que conserva el histórico de los informes y registra las alertas cumple este papel sin obligar a archivar cientos de XML. Cuando esta dimensión de auditoría se impone, conviene comprobar que la herramienta elegida ofrezca un histórico largo (al menos 90 días) y exportaciones para las necesidades de cumplimiento.

Thomas vigila la frecuencia

El verdadero valor no está en la frecuencia de los informes, sino en lo que se hace con ellos. Thomas, el CISO virtual, vigila los informes en lugar del equipo, alerta cuando aparece algo inusual —una nueva IP, un pico de fallos, una fuente que deja de pasar— y dice qué hacer, no solo qué mirar.

Análisis gratuito del dominio o crear una cuenta para una vigilancia DMARC sin interrupciones.