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

<?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>ton-domaine.fr</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>ton-domaine.fr</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>ton-domaine.fr</domain>
        <result>pass</result>
        <selector>selector1</selector>
      </dkim>
      <spf>
        <domain>ton-domaine.fr</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

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

Cuando llega un informe, léelo 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 — ¿es mi política bien visible?
4. Para cada <record>:
   • source_ip: ¿reconozco esta IP?
   • count: ¿cuántos mensajes?
   • policy_evaluated/dkim y spf: ¿pasa o falla?
   • Si falla: ¿por qué? Mira auth_results para el detalle.

En unos minutos con este flujo, sabes si tus fuentes legítimas pasan y si hay IP sospechosas enviando en tu nombre.

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 te presentan una vista consolidada. Nuestro analizador hace exactamente eso: lee tus informes, identifica tus fuentes y te presenta el estado de cada una — sin que tengas que abrir un solo fichero XML.

Preguntas frecuentes

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

¿Por qué recibo varios informes al día? No, en general uno por remitente al día (periodo de 24h por defecto). Si recibes 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 tu política declarada. Algunos actores tienen overrides (listas blancas, acuerdos bilaterales) que suavizan la aplicación. No es un error por tu parte.

No recibo ningún informe. ¿Qué pasa? Verifica que tu registro DMARC está bien publicado y contiene rua=mailto:direccion@ton-domaine.fr. Verifica 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 que envío 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 cuando veo una IP que no reconozco? Empieza por resolverla en DNS inverso (nslookup IP o dig -x IP) y mira 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 la marques 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 envías hacia un dominio que no ha implementado el reporting, esos mensajes no aparecen — incluso si tu política está 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 te dice sobre tu postura real

Un informe RUA no es solo una lista de resultados — es una instantánea de tu postura de autenticación. Leyendo atentamente cada bloque <record>, puedes reconstruir una imagen precisa de tu situación: qué fuentes funcionan, cuáles están rotas, y cuáles no habías 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 usas pero cuya configuración DNS no se ha limpiado, una herramienta SaaS que envía notificaciones en tu nombre sin que lo sepas.

Para sacar el máximo de un informe, ve más allá de la lectura fuente por fuente y busca 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 tu postura.

Las señales de alarma que hay que vigilar

Algunas configuraciones en un informe deben atraer tu atención inmediata. Un count elevado sobre una IP desconocida: alguien envía muchos mensajes fingiendo ser tú desde una IP que no reconoces. Si tu política es p=none, esos mensajes llegan a destino — con la imagen de tu dominio. Fallos repentinos sobre una IP que reconoces: 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 tu política: tu 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 que no usas. Los informes no cubren solo tu dominio principal — cuando un mensaje se reclama de un subdominio de tu dominio, el bloque <record> correspondiente lo muestra en header_from, y es la etiqueta <sp> de tu 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. Adopta 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.

Deja que Thomas descodifique tus informes

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

Analiza tu dominio gratis → o crea una cuenta para informes DMARC legibles de un vistazo.