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_ipycount: quién envió, y cuánto. Las fuentes de alto volumen son las más importantes de configurar correctamente.- Los resultados
dkimyspfenpolicy_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í mostrarspf: failaquí porque el dominio no se alineaba con tuFrom:. 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:
- 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.
- 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.
- Corregir la alineación de las legítimas. Añade el
include:que falta a SPF, implementa una firma DKIM con und=alineado, hasta que cada fuente real muestre unpass. - Ver disminuir los fallos. Cuando las únicas fuentes en
failque quedan son desconocidas —suplantadores— estás listo para endurecer. - Subir la política. Pasa a
quarantine, despuésreject, 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/spfenpolicy_evaluatedreflejan la alineación. Una fuente puede muy bien superar un SPF en bruto y aun así mostrarspf: failaquí porque su sobre no se alinea con tuFrom:. 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. Enp=none, ladispositionsigue siendononeincluso cuandodkimyspffallan: es normal, todavía no aplicas nada. No leas undisposition: nonecomo «todo va bien»: sondkim/spflos 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 vespct, 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 — gratisGuías relacionadas
- Cómo leer un informe DMARC RUA (y qué te dice)
Un informe DMARC RUA es un fichero XML comprimido. Esta guía desmenuza la estructura, explica cada etiqueta útil y muestra cómo transformar ese XML en un plan de acción.
- Informes DMARC: RUA vs RUF, ¿qué diferencia?
DMARC genera dos tipos de informes: los RUA (agregados, estadísticos) y los RUF (forenses, mensaje por mensaje). Qué contienen, quién los envía y cuál necesitas de verdad.
- Macros SPF y el mecanismo exists: ir más allá del límite de 10 búsquedas
Las macros SPF con el mecanismo exists autorizan un número ilimitado de IP en una sola resolución DNS: la única técnica que realmente sortea el límite de 10. Cómo funciona y sus contrapartidas reales.
Sobre el autor
Thomas — Thomas 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.
