← Blog

Cómo leer los informes agregados DMARC (RUA)

Por Thomas · CISO virtual · 2026-06-16

La primera vez que abres un informe agregado DMARC, parece ruido: un muro de XML lleno de direcciones IP y de banderas pass/fail. Sin embargo, esos informes son lo más útil que DMARC te ofrece. Son el mapa que lleva un dominio de la vigilancia a la aplicación de la política, la única forma fiable de descubrir a todos los que envían en tu nombre antes de endurecer la política. Esta guía explica qué hay dentro, cómo leerlo y cómo actuar.

Qué son los informes agregados

Cuando publicas un registro DMARC con una dirección rua= (mira qué es DMARC para lo básico), los proveedores destinatarios —Google, Microsoft, Yahoo y cientos de otros— te envían un resumen diario. Cada informe cubre una ventana de 24 h y responde a una pregunta: de todo el correo que dijo venir de tu dominio, ¿de dónde venía y se autenticó?

Son informes agregados (RUA): recuentos agrupados por fuente de envío, no copias de emails individuales. (Otro tipo, más raro, llamado forense o de fallo, RUF, puede incluir muestras censuradas, pero son los informes agregados los que se consultan a diario.) Llegan en XML, generalmente comprimidos en gzip o zip, adjuntos a un email.

Anatomía del XML

Cada informe tiene la misma forma. Tres partes cuentan:

1. Metadatos del informe: quién lo envió y la ventana temporal:

<report_metadata>
  <org_name>google.com</org_name>
  <report_id>14217...</report_id>
  <date_range><begin>1718...</begin><end>1718...</end></date_range>
</report_metadata>

2. Política publicada: el registro DMARC que el destinatario vio para ti ese día. Útil para confirmar que tu registro se propagó como estaba previsto:

<policy_published>
  <domain>ton-domaine.fr</domain>
  <p>none</p><adkim>r</adkim><aspf>r</aspf><pct>100</pct>
</policy_published>

3. Records: el corazón del informe. Un bloque por fuente de envío, con un recuento de volumen y los resultados de autenticación:

<record>
  <row>
    <source_ip>203.0.113.10</source_ip>
    <count>42</count>
    <policy_evaluated><disposition>none</disposition><dkim>pass</dkim><spf>fail</spf></policy_evaluated>
  </row>
  <identifiers><header_from>ton-domaine.fr</header_from></identifiers>
</record>

Lee este bloque como una frase: «Desde la IP 203.0.113.10, 42 mensajes dijeron venir de ton-domaine.fr; DKIM alineado y superado, SPF no.» Como DMARC solo necesita un único paso alineado, esos 42 mensajes superaron DMARC gracias a DKIM.

Los campos que lo deciden todo

Para cada fuente, concéntrate en tres cosas:

  • source_ip y count: quién envió, y cuánto. Las fuentes de alto volumen son las más importantes de configurar correctamente.
  • Los resultados dkim y spf en policy_evaluated: reflejan la alineación, no solo el paso del mecanismo aislado. Es la cifra que cuenta: una fuente puede superar SPF en bruto y aun así mostrar spf: fail aquí porque el dominio no se alineaba con tu From:.
  • disposition: lo que el destinatario hizo realmente (none, quarantine, reject), según tu política actual.

Una fuente donde dkim o spf muestra pass está autenticada y es segura de aplicar. Una fuente donde ambos fail es el conjunto problemático: o bien un remitente legítimo aún no alineado, o bien un suplantador.

Transformar los informes en acciones

El flujo es siempre el mismo, y ahí está todo el reto:

  1. Agregar sobre varios informes. Un solo día de un solo proveedor no es más que un fragmento. Combina numerosos informes a lo largo de unas semanas para ver el cuadro completo de quién envía por ti.
  2. Identificar cada fuente legítima. Esa IP de alto volumen que supera DKIM es sin duda tu plataforma de correo. La que falla ambos puede ser tu CRM, tu facturación, o una herramienta que un equipo instaló sin avisar a informática. Nombra cada una.
  3. Corregir la alineación de las legítimas. Añade el include: que falta a SPF, implementa una firma DKIM con un d= alineado, hasta que cada fuente real muestre un pass.
  4. Ver disminuir los fallos. Cuando las únicas fuentes en fail que quedan son desconocidas —suplantadores— estás listo para endurecer.
  5. Subir la política. Pasa a quarantine, después reject, comprobando que los informes siguen limpios. La secuencia completa está en alcanzar p=reject.

Haz de la lectura un hábito, no un proyecto

El flujo de arriba solo rinde si alguien lo desarrolla de verdad. Trata la lectura de los informes como un ritual recurrente con un responsable designado, no como una auditoría puntual: una breve revisión semanal mientras estés en p=none, un examen más atento en los días que siguen a cualquier cambio de DNS o de política, y un vistazo tras la llegada de cada nueva herramienta de envío. En paralelo, mantén un inventario vivo de tus fuentes: cada IP o servicio identificado, su propietario interno, su estado de alineación actual. Es ese inventario el que sobrevive a las marchas y a los cambios de proveedores: dentro de unos meses, nadie debería tener que redescubrir que tal rango de IP es «nuestra plataforma de facturación». Escrito una vez, verificado en cada revisión, transforma cada nuevo informe en una simple comparación en lugar de una investigación.

Por qué se abandona, y cómo evitarlo

Leer XML en bruto a mano no escala. Una empresa de tamaño medio puede recibir decenas de informes al día de numerosos proveedores, cada uno listando numerosas IP. Hacer corresponder un flujo de direcciones IP con «ah, es nuestro Zendesk» es tedioso y propenso a errores: es exactamente por eso por lo que tantos dominios recogen informes un tiempo y luego se detienen discretamente en p=none. Los informes nunca fueron el problema; darles sentido, sí.

La solución es dejar que un software haga la agregación y la traducción. Es para lo que está diseñado Thomas, tu CISO virtual: ingiere tus informes agregados, transforma las IP en bruto y los PTR en nombres de servicios reconocibles («tu Mailchimp», «una subcuenta SendGrid sin configurar»), evalúa tu preparación sobre una ventana deslizante, y te dice exactamente qué fuentes corregir antes de cada etapa hacia p=reject.

Lo que los informes agregados no te dirán

Los informes agregados son potentes, pero conocer sus límites evita sacar conclusiones falsas:

  • Ningún contenido de mensaje. Los informes agregados contienen recuentos y resultados de autenticación, nunca los asuntos, cuerpos o direcciones de los destinatarios. Dicen que una fuente emitió en tu nombre y cómo se autenticó, no qué decía el correo. (Un tipo de informe distinto y más raro —forense o de fallo, RUF— puede incluir muestras censuradas, pero muchos proveedores no envían ninguno, por razones de privacidad.)
  • Un retraso de aproximadamente un día. Los informes cubren una ventana de 24 h y llegan después: siempre estás mirando ayer, no el instante presente. No esperes una respuesta en tiempo real cuando modificas un registro; deja un día o dos. Este ritmo diario está inscrito en el estándar: por qué los informes llegan una vez al día explica sus mecanismos.
  • Por fuente, no por mensaje. Una línea agrega numerosos mensajes de una misma IP con el mismo resultado. No puedes rastrear un email individual solo con los datos agregados.
  • Solo los destinatarios participantes. La mayoría de los grandes proveedores envían informes, pero no todos. Tus informes representan la amplia mayoría de tu correo, no literalmente la totalidad.
  • IP en bruto, no nombres. El informe dice 198.51.100.7, no «tu Zendesk». Hacer corresponder las direcciones con los servicios te incumbe a ti, y es la parte más laboriosa del trabajo.

Nada de esto disminuye su valor; solo significa que los informes agregados son un mapa, no una cámara en directo. Léelos como tendencias sobre semanas, no como telemetría instantánea, y asócialos a una herramienta que transforme las IP en remitentes reconocibles.

Tres trampas de lectura frecuentes

Algunos reflejos evitan sacar malas conclusiones de un informe:

  • Confundir paso de mecanismo y alineación. Los campos dkim/spf en policy_evaluated reflejan la alineación. Una fuente puede muy bien superar un SPF en bruto y aun así mostrar spf: fail aquí porque su sobre no se alinea con tu From:. Lee siempre esos campos como «¿alineado?», no como «¿el mecanismo pasó técnicamente?».
  • Entrar en pánico ante IP desconocidas. Un pico de pequeñas fuentes dispersas suele ser reenvío (un destinatario que reexpide tu correo) más que un ataque. Mira el volumen y la regularidad antes de concluir que hay suplantación: un suplantador busca el volumen, un reenvío deja una larga cola de cuentas con un solo mensaje.
  • Olvidar lo que dice disposition. En p=none, la disposition sigue siendo none incluso cuando dkim y spf fallan: es normal, todavía no aplicas nada. No leas un disposition: none como «todo va bien»: son dkim/spf los que te dicen si una fuente está sana.

DMARCbis y los informes (RFC 9990)

DMARCbis (mayo de 2026) ha repartido la especificación en tres RFC: 9989 para el protocolo, y sobre todo 9990, ahora dedicada a los informes agregados que lees aquí. El espíritu no cambia —mismos bloques fuente / volumen / resultados— pero dos detalles aparecerán progresivamente en tus informes:

  • El bloque <policy_published> ya no mostrará <pct> (etiqueta suprimida) y podrá incluir <np>, la política de los subdominios inexistentes. Si aún ves pct, es simplemente un destinatario que todavía no está actualizado.
  • La determinación del dominio organizacional se apoya ahora en el DNS Tree Walk en lugar de la Public Suffix List, lo que hace la atribución más predecible.

En concreto, tu forma de leer un informe no se mueve. Ten en cuenta solamente que, durante la transición, tus informes pueden mezclar formato antiguo y nuevo según el proveedor.

Hacer llegar los informes

Necesitas dos cosas para empezar: un registro DMARC con una dirección rua=, y un sitio adonde enviar los informes. La sintaxis exacta de esa etiqueta —incluido el paso adicional cuando los informes salen hacia otro dominio— está detallada en configurar tu dirección rua. Lo más rápido es un buzón de recopilación DMARC gratuito que ingiere y parsea el XML automáticamente: una línea DNS, y tus informes diarios se convierten en un panel legible en lugar de una carpeta de adjuntos.

Empieza por verificar tu configuración actual con nuestro analizador DMARC gratuito: muestra si solo tienes una dirección rua= y cómo se alinean tus fuentes hoy. Después crea una cuenta para recopilar y leer tus informes de forma continua, con Thomas que traduce cada fuente e indica el camino hacia la aplicación de la política.

¿Nuevo en los fundamentos? Empieza por qué es DMARC y cómo funcionan juntos SPF, DKIM y DMARC.

¿Listo para aplicar DMARC?

Thomas, tu CISO virtual, identifica cada fuente de envío legítima, escribe los registros DNS exactos y lleva tu dominio de p=none a p=reject — sin romper tu correo.

Alcanzar p=reject — gratis

Guías relacionadas

Sobre el autor

ThomasThomas es el CISO virtual de DMARC.com: un copiloto especializado en la autenticación de correo que acompaña a las organizaciones de p=none hasta p=reject, sin romper su correo. Sus guías se basan en los datos reales del Observatorio DMARC y de los informes RUA analizados por la plataforma.