Cómo leer los informes agregados DMARC (RUA)

<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>

<policy_published>
  <domain>ejemplo.es</domain>
  <p>none</p><adkim>r</adkim><aspf>r</aspf><pct>100</pct>
</policy_published>

<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>ejemplo.es</header_from></identifiers>
</record>

Los campos que lo deciden todo

Para cada fuente, tres cosas concentran lo esencial:

• 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 su From:.
• disposition: lo que el destinatario hizo realmente (none, quarantine, reject), según la política actual del dominio.

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. La combinación de numerosos informes a lo largo de unas semanas es lo que revela el cuadro completo de quién envía por el dominio.
2. Identificar cada fuente legítima. Esa IP de alto volumen que supera DKIM es sin duda la plataforma de correo de la casa. La que falla ambos puede ser el CRM, la facturación, o una herramienta que un equipo instaló sin avisar a informática. Cada una debe recibir un nombre.
3. Corregir la alineación de las legítimas. Se añade el include: que falta a SPF, se 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— el terreno está listo para endurecer.
5. Subir la política. Se pasa a quarantine, después a reject, comprobando que los informes siguen limpios. La secuencia completa está en alcanzar p=reject.

La lectura, un hábito más que un proyecto

El flujo de arriba solo rinde si alguien lo desarrolla de verdad. La lectura de los informes merece el trato de un ritual recurrente con un responsable designado, no el de una auditoría puntual: una breve revisión semanal mientras el dominio esté 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, un inventario vivo de las fuentes se mantiene al día: 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, el CISO virtual: ingiere los informes agregados, transforma las IP en bruto y los PTR en nombres de servicios reconocibles («el Mailchimp de la casa», «una subcuenta SendGrid sin configurar»), evalúa la preparación del dominio sobre una ventana deslizante, e indica exactamente qué fuentes corregir antes de cada etapa hacia p=reject.

Lo que los informes agregados no dicen

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 nombre del dominio 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: lo que se mira siempre es ayer, no el instante presente. Modificar un registro no produce una respuesta en tiempo real; hay que dejar 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. Rastrear un email individual es imposible solo con los datos agregados.
• Solo los destinatarios participantes. La mayoría de los grandes proveedores envían informes, pero no todos. Los informes recibidos representan la amplia mayoría del correo, no literalmente la totalidad.
• IP en bruto, no nombres. El informe dice 198.51.100.7, no «el Zendesk de la casa». Hacer corresponder las direcciones con los servicios incumbe al propietario del dominio, 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. Se leen como tendencias sobre semanas, no como telemetría instantánea, asociados 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 su From:. Esos campos se leen siempre 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 el correo recibido) más que un ataque. El volumen y la regularidad se miran 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 se aplica nada. Un disposition: none no significa «todo va bien»: son dkim/spf los que 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 descritos aquí. El espíritu no cambia —mismos bloques fuente / volumen / resultados— pero dos detalles aparecerán progresivamente en los informes:

• El bloque <policy_published> ya no mostrará <pct> (etiqueta suprimida) y podrá incluir <np>, la política de los subdominios inexistentes. Un pct que siga apareciendo delata simplemente a 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, la forma de leer un informe no se mueve. Conviene tener en cuenta solamente que, durante la transición, los informes pueden mezclar formato antiguo y nuevo según el proveedor.

Hacer llegar los informes

Hacen falta 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 la 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 los informes diarios se convierten en un panel legible en lugar de una carpeta de adjuntos.

El primer paso es verificar la configuración actual con nuestro analizador DMARC gratuito: muestra si existe una dirección rua= y cómo se alinean las fuentes hoy. Después, crear una cuenta permite recopilar y leer los informes de forma continua, con Thomas que traduce cada fuente e indica el camino hacia la aplicación de la política.

Para los fundamentos, el punto de entrada es qué es DMARC, seguido de cómo funcionan juntos SPF, DKIM y DMARC.