Cómo leer un informe DMARC RUA (y qué revela)

<?xml version="1.0" ?>
<feedback>
  <report_metadata>
    <org_name>Google Inc.</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>3456789012345678901</report_id>
    <date_range>
      <begin>1719273600</begin>
      <end>1719359999</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>ejemplo.es</domain>
    <p>reject</p>
    <sp>reject</sp>
    <adkim>r</adkim>
    <aspf>r</aspf>
  </policy_published>
  <record>
    <row>
      <source_ip>40.107.1.25</source_ip>
      <count>347</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>ejemplo.es</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>ejemplo.es</domain>
        <result>pass</result>
        <selector>selector1</selector>
      </dkim>
      <spf>
        <domain>ejemplo.es</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Leer un informe en la práctica: el flujo de lectura

Cuando llega un informe, se lee en este orden:

1. org_name — quién lo envía (Gmail, Outlook, Yahoo…).
2. date_range — de qué periodo (¿ayer? ¿hace dos días?).
3. policy_published/p — ¿está bien visible la política publicada?
4. Para cada <record>:
   • source_ip: ¿es una IP reconocible?
   • count: ¿cuántos mensajes?
   • policy_evaluated/dkim y spf: ¿pasa o falla?
   • Si falla: ¿por qué? El detalle está en auth_results.

En unos minutos con este flujo, se sabe si las fuentes legítimas pasan y si hay IP sospechosas enviando en nombre del dominio.

Por qué una herramienta de análisis marca la diferencia

Un informe de Gmail solo contiene a veces decenas de bloques <record>. Multiplicado por los informes de Microsoft, Yahoo, Apple y los demás, la lectura manual se vuelve rápidamente agotadora. Las herramientas de análisis DMARC agregan estos informes, los enriquecen con la identidad de las IP (alojadores, plataformas conocidas) y presentan una vista consolidada. Nuestro analizador hace exactamente eso: lee los informes, identifica las fuentes y presenta el estado de cada una — sin necesidad de abrir un solo fichero XML.

Preguntas frecuentes

Mis informes llegan en .gz o .zip. ¿Cómo abrirlos? Se descomprime el fichero (gunzip en Mac/Linux, 7-Zip o WinRAR en Windows) para obtener el .xml, y se abre en un editor de texto o un navegador. Mejor aún: una herramienta de análisis que lo haga automáticamente.

¿Por qué llegan varios informes al día? No, en general uno por remitente al día (periodo de 24h por defecto). Si llegan varios del mismo actor, puede haber un troceado si el volumen es muy elevado.

Veo disposition=quarantine pero mi política es p=reject. ¿Por qué? El policy_evaluated/disposition refleja lo que el ISP ha efectivamente aplicado, no la política declarada. Algunos actores tienen overrides (listas blancas, acuerdos bilaterales) que suavizan la aplicación. No es un error de configuración.

No llega ningún informe. ¿Qué pasa? Hay que verificar que el registro DMARC está bien publicado y contiene rua=mailto:direccion@ejemplo.es. Conviene verificar también que la dirección de recepción es accesible y que los emails no acaban en spam. Si la dirección rua= está en un dominio externo, el dominio externo debe tener un registro _dmarc de autorización.

¿Cada email enviado genera un informe? No. Los informes son agregados: un bloque por combinación IP/resultados sobre el periodo. 1000 emails desde la misma IP con los mismos resultados = 1 <record> con count=1000.

¿Qué hacer ante una IP no reconocida? El primer paso es resolverla en DNS inverso (nslookup IP o dig -x IP) y mirar a qué servicio pertenece. Si es un alojador cloud conocido, quizá es una antigua VM o un servicio olvidado. Si es un rango desconocido sin DNS inverso claro, es una señal de alerta — quizá falsificación. En todos los casos, no hay que marcarla como «legítima» sin haber identificado su fuente con certeza.

¿Los informes incluyen los mensajes rechazados por mi propio filtro de spam? No. Los informes RUA se refieren a los mensajes que han alcanzado el servidor destinatario y han sido evaluados por DMARC. Los mensajes rechazados antes de la evaluación DMARC (conexión TCP bloqueada, rechazo SMTP) no aparecen en ellos.

¿Los informes reflejan todos mis emails o solo algunos? Solo los mensajes que llegan a los destinatarios cuyo ISP envía informes DMARC. Si el envío va hacia un dominio que no ha implementado el reporting, esos mensajes no aparecen — incluso con una política activa. Es por eso que los datos de los grandes ISP (Gmail, Outlook, Yahoo) son los más representativos: cubren lo esencial del tráfico mundial.

Lo que un informe revela sobre la postura real

Un informe RUA no es solo una lista de resultados — es una instantánea de la postura de autenticación. Leyendo atentamente cada bloque <record>, se reconstruye una imagen precisa de la situación: qué fuentes funcionan, cuáles están rotas, y cuáles no se habían identificado. Este último punto es a menudo el más revelador: los informes DMARC descubren regularmente fuentes de envío que las organizaciones han olvidado — una antigua aplicación, un proveedor cuyo servicio ya no se usa pero cuya configuración DNS no se ha limpiado, una herramienta SaaS que envía notificaciones en nombre del dominio sin que nadie lo sepa.

Para sacar el máximo de un informe, conviene ir más allá de la lectura fuente por fuente y buscar los patrones: ¿están los fallos concentrados en unas pocas IP o dispersos? ¿Fallan las mismas IP en los informes de varios ISP o solo en uno? ¿Aumenta el volumen de fallos con el tiempo? Estas preguntas transforman un diagnóstico puntual en una comprensión sistémica de la postura.

Las señales de alarma que hay que vigilar

Algunas configuraciones en un informe deben atraer la atención inmediata. Un count elevado sobre una IP desconocida: alguien envía muchos mensajes fingiendo ser el dominio legítimo desde una IP no identificada. Si la política es p=none, esos mensajes llegan a destino — con la imagen del dominio. Fallos repentinos sobre una IP conocida: una configuración ha cambiado en algún sitio (rotación de clave DKIM mal ejecutada, modificación de configuración SPF, cambio de proveedor). Un policy_published/p diferente de la política declarada: el registro no está bien publicado, o ha habido una modificación no deseada. Estas tres señales merecen una investigación inmediata, independientemente del resto del informe.

Una cuarta señal merece el mismo reflejo: un header_from que muestra un subdominio sin uso. Los informes no cubren solo el dominio principal — cuando un mensaje se reclama de un subdominio, el bloque <record> correspondiente lo muestra en header_from, y es la etiqueta <sp> de la política la que se aplica entonces. Un remitente legítimo puede alojarse ahí (una plataforma configurada en un subdominio dedicado), pero un usurpador también: los subdominios están a menudo menos vigilados que la raíz, y es exactamente lo que los hace atractivos. Conviene adoptar el hábito de barrer los valores de header_from de cada informe, no solo las IP — un subdominio inesperado es un descubrimiento igual que una dirección desconocida.

Thomas descodifica los informes

Abrir y descodificar XML a mano es factible — pero tedioso y potencialmente engañoso sin saber dónde mirar. Thomas, el CISO virtual, lee los informes de forma continua, indica qué fuentes pasan y cuáles merecen atención, y presenta un diagnóstico claro sin XML bruto.

Analizar un dominio gratis o crear una cuenta para informes DMARC legibles de un vistazo.