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.ton-domaine.fr.  IN TXT
  "v=DMARC1; p=quarantine; rua=mailto:dmarc@ton-domaine.fr; 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: ves las tendencias del día, detectas 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.

Si gestionas un dominio crítico donde un incidente de seguridad en las primeras 24 horas podría tener un impacto mayor, vigila la actividad en tiempo real a través de tu herramienta DMARC en lugar de intentar modificar ri=: es más eficaz.

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

Un punto a menudo mal entendido: el informe que recibes 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 te 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).
• Lo recibes de unos minutos a unas horas después según el enrutamiento del correo.

En concreto: si quieres saber lo que pasó ayer, el informe de la mañana siguiente te lo dirá. 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 tus 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. No apuntes rua= hacia tu buzón personal: los informes ahogarían tus mensajes reales, y un filtro un poco celoso acabaría clasificándolos como no deseados, o incluso borrándolos. Crea más bien una dirección dedicada a este uso, sin una cuota demasiado ajustada. Si pasas por una plataforma DMARC, es ella la que expone la dirección de recogida y la cuestión desaparece. Si tratas los informes a mano, prevé una regla de clasificación automática y una purga regular: un buzón lleno rechaza los informes entrantes, y pierdes tu visibilidad sin darte cuenta.

¿Y si no recibo ningún informe?

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

1. ¿Está publicado el registro DMARC? (dig TXT _dmarc.ton-domaine.fr debe devolver tu 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.domaine-externe.fr 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? Comprueba la carpeta de spam de la dirección destinataria.

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=. Si migras a DMARCbis (ver migrar a este nuevo estándar), tu 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. Si quieres ser explícito, añade ri=86400; si no, omítelo.

¿Puedo 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 cuentes 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.

¿Qué pasa si recibo informes de varios proveedores a horas diferentes? Es normal: cada proveedor genera y envía su informe a su propia hora. Puedes recibir el informe de Gmail 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 publicas tu registro DMARC 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. Si tu 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 cuando analizas 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. Concéntrate en los últimos 30 días para tu diagnóstico corriente, y guarda el histórico largo para las tendencias.

Lo que deberías vigilar realmente (y con qué frecuencia)

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

En fase de observación (política p=none): lee tus informes semanalmente. No corres ningún riesgo de interrupción, los cambios son lentos (identificar y corregir tus fuentes lleva tiempo), y una revisión semanal basta para seguir los progresos. En fase de transición (p=quarantine): lee los informes a diario durante las primeras semanas, o configura alertas. Es ahí donde puedes bloquear involuntariamente un flujo legítimo; quieres detectarlo rápido. Una vez estabilizado en cuarentena desde hace unas semanas, 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, te 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 vigilas y que reaccionas. Una plataforma DMARC que conserva el histórico de los informes y registra las alertas cumple este papel sin que tengas que archivar cientos de XML. Si esta dimensión de auditoría se te impone, comprueba que la herramienta que elijas ofrezca un histórico largo (al menos 90 días) y exportaciones para las necesidades de cumplimiento.

Deja que Thomas vigile la frecuencia por ti

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

Analiza tu dominio gratis o crea una cuenta para una vigilancia DMARC sin interrupciones.