Cómo leer un informe DMARC sin ahogarte en XML

Qué es en realidad un informe DMARC

Publica un registro DMARC con una dirección en rua= y los proveedores de correo empezarán a enviarte informes agregados: un archivo XML por proveedor y día, con cada IP que envió correo diciendo ser tu dominio, cuántos mensajes envió cada una y si SPF y DKIM pasaron y estaban alineados.

Dos cosas que conviene saber antes de abrir el primero:

• Los informes agregados no contienen contenido de los mensajes. Ni asuntos, ni destinatarios, ni cuerpos. Son recuentos agrupados por IP de envío. Por eso es seguro recogerlos y por eso no pueden decirte qué mensaje falló.
• No son lo mismo que los informes forenses. Una dirección en ruf= pide muestras de fallos por mensaje, que sí incluyen cabeceras y a veces algo más. La mayoría de proveedores ya no los envía, por privacidad, así que en la práctica la visibilidad de DMARC son los informes agregados.

Lo que te dan es lo único que no puedes conseguir de otro modo: una lista de todo lo que en el mundo envía correo como tu dominio, incluidos los sistemas de tu propia empresa que nadie recuerda haber configurado. Ese inventario es el objetivo entero, y es lo que hace posible pasar a aplicar una política sin romper nada.

Cómo empezar a recibirlos

Un registro mínimo que solo recoge datos y no cambia nada en la entrega:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Va en _dmarc.example.com como registro TXT. p=none significa «no apliques ninguna política, solo cuéntame»: es el punto de partida correcto y no puede perjudicar tu entrega. Comprueba que el registro está publicado y se lee bien con una herramienta de consulta DNS antes de esperar informes que no llegarán nunca.

Dos notas prácticas. Los informes llegan a diario y en volumen, así que mándalos a un buzón dedicado y no al tuyo. Y si quieres recibirlos en una dirección de otro dominio, ese dominio tiene que autorizarlo con su propio registro DNS: la falta de esa autorización es el motivo más común de que los informes no aparezcan jamás.

Leer el XML: tres bloques

Todos los informes agregados tienen la misma forma. En cuanto la ves una vez deja de intimidar.

Bloque 1: quién envió el informe

<report_metadata> nombra a la organización que informa y da un identificador y un rango de fechas. El rango es lo que hay que mirar: los informes suelen cubrir 24 horas y llegan con uno o dos días de retraso, así que la IP que estás viendo envió en el pasado.

Bloque 2: la política que vieron

<policy_published> es tu propio registro DMARC tal y como lo leyó ese proveedor: p (tu política), sp (la de subdominios), pct (el porcentaje que pediste aplicar) y los modos de alineación. Este bloque sirve de comprobación: si no coincide con lo que crees haber publicado, tu registro tiene un problema de sintaxis o aún no se ha propagado.

Bloque 3: las filas que importan

Después, una serie de elementos <record>. Cada uno es un grupo de mensajes de una IP con un mismo resultado, no un correo suelto. Cada uno lleva un <row> con la IP de origen y un recuento, un <policy_evaluated> con el resultado DMARC y lo que hizo el proveedor, y un <auth_results> con los resultados de SPF y DKIM por debajo.

Leer una fila en la práctica

Hazlo en este orden y la fila se explica sola:

1. ¿Quién es la IP? Búscala. Un nombre de una plataforma de correo conocida significa que es un servicio tuyo; una red desconocida es la que hay que investigar.
2. ¿Cuántos mensajes? Dos mensajes son ruido. Veinte mil son un sistema.
3. ¿Qué dice <policy_evaluated><disposition>? none, quarantine o reject: lo que hizo el proveedor.
4. ¿Pasaron SPF y DKIM, y estaban alineados? Esa pareja es todo el diagnóstico, y es la sección siguiente.

Las cuatro combinaciones y qué significa cada una

DMARC pasa si uno de los dos, SPF o DKIM, pasa y está alineado con el dominio From: visible. De ahí salen cuatro casos:

• SPF pasa y DKIM pasa. Tu remitente bien configurado. Nada que hacer.
• SPF pasa, DKIM falla. Normalmente un servicio que envía desde una IP autorizada sin firmar. Activa la firma DKIM: SPF por sí solo es frágil, porque se rompe en cuanto el mensaje se reenvía.
• SPF falla, DKIM pasa. Casi siempre correo reenviado legítimo: la IP del reenviador no está en tu registro SPF, pero la firma sobrevivió. DMARC pasa solo con DKIM, que es justo el diseño funcionando.
• Fallan los dos. O un remitente tuyo que nunca se configuró, o alguien suplantándote. Distinguirlos es la sección siguiente.

Cuidado con una trampa del XML: un resultado puede poner pass en <auth_results> y aun así fallar DMARC, porque el dominio autenticado no estaba alineado con el dominio From:. Una plataforma que firma con su propio dominio produce exactamente eso. Si eso confunde, por qué un pass de SPF no es un pass de DMARC explica la alineación a fondo.

Distinguir tus remitentes de una suplantación

Los primeros informes de casi todo el mundo parecen alarmantes y casi nada es un ataque. Reparte las IPs que fallan en tres montones:

• Tuyas, mal configuradas. Un CRM, un sistema de facturación, una herramienta de tickets, una plataforma de marketing, un servidor de aplicaciones. Pistas: la IP resuelve a un proveedor reconocible, el volumen es estable día tras día y los mensajes se están entregando. Solución: autorízalo bien, preferiblemente con DKIM.
• Reenviadores. Poco volumen, IPs dispersas, universidades y pequeños servidores de correo, SPF fallando mientras DKIM pasa. No es un problema y no se arregla desde tu lado.
• Suplantación real. Redes desconocidas, a menudo a ráfagas, con frecuencia ajenas a tu negocio, fallando ambas comprobaciones. La parte tranquilizadora: con una política aplicada ese correo ya se está rechazando, que es justo el objetivo.

El orden importa. Identifica todo el primer montón antes de endurecer la política, porque aplicarla convierte a un remitente tuyo mal configurado en correo que no llega.

Por qué los reenvíos parecen ataques

Esto confunde a todo el mundo una vez. Una lista de correo o un alias retransmiten tu mensaje desde su propio servidor, así que tu registro SPF se comprueba contra una IP que nunca autorizaste y falla, correctamente. El informe muestra una IP desconocida fallando SPF mientras envía como tú, que se lee exactamente igual que un abuso.

Dos señales los separan. El correo reenviado normalmente sigue pasando DKIM, porque la firma viaja con el mensaje, así que DMARC acaba pasando. Y el volumen es pequeño y está repartido entre muchas IPs sin relación, en vez de concentrado. Las listas de correo son la excepción que puede romper las dos cosas: algunas reescriben el asunto o añaden un pie, lo que invalida la firma DKIM y deja un mensaje legítimo fallando todo.

Usar los informes para llegar a aplicar la política

Los informes existen para que este paso sea seguro. Una secuencia que funciona:

• Quédate en p=none hasta que los informes sean aburridos: normalmente unas semanas. Estás esperando a que todo remitente legítimo que encuentres esté autorizado y no aparezca nada nuevo.
• Arregla los remitentes según los encuentres, con preferencia por DKIM. Un remitente con DKIM sobrevive al reenvío; uno que solo tiene SPF, no.
• Pasa a p=quarantine, opcionalmente con pct= para ir subiendo. El correo que falla va a spam en vez de desaparecer, así que un error es reversible.
• Después p=reject, cuando la cuarentena lleve tiempo tranquila. Es el momento en que el correo que suplanta tu dominio se rechaza de verdad.
• Sigue leyendo los informes después. Un proveedor nuevo contratado dentro de seis meses aparecerá como una IP que falla, y quieres verlo antes de que alguien te diga que sus facturas rebotan.

No pongas p=reject el primer día. Lo único que hace segura la aplicación es el inventario que dan los informes, y ese inventario tarda semanas en estar completo. La guía de SPF, DKIM y DMARC cubre los registros en sí.

Errores comunes

• Saltar a p=reject sin leer informes. El sistema olvidado suele ser el que factura a tus clientes.
• Leer cada fila como un mensaje. Una fila es un grupo de mensajes de una IP con un mismo resultado.
• Tratar cada IP que falla como un atacante. La mayoría de los fallos iniciales son servicios tuyos y reenvíos normales.
• Dar por hecho que un pass en auth_results significa que DMARC pasó. Sin alineación con el dominio From:, no.
• Mandar los informes a un buzón humano. Llegan a diario desde decenas de proveedores. Usa una dirección dedicada.
• Olvidar la política de subdominios. Sin sp=, los subdominios heredan p, que puede no ser lo que quieres durante el despliegue.
• Arreglar solo SPF. SPF se rompe con los reenvíos; DKIM es lo que lleva DMARC a través de ellos.
• Apagar los informes al llegar a reject. Es justo cuando empiezan a ser un sistema de alerta temprana.

En resumen

Un informe agregado de DMARC es una lista XML diaria de cada IP que envía como tu dominio, con recuentos y resultados de SPF y DKIM, sin contenido de los mensajes. Lee cada fila en cuatro pasos: identifica la IP, mira el volumen, lee la disposición y comprueba si SPF o DKIM pasaron y estaban alineados. Cuenta con que la mayoría de los fallos iniciales sean servicios tuyos sin configurar y reenvíos normales, no suplantación; arregla los remitentes con DKIM siempre que puedas; y pasa de p=none a cuarentena y luego a reject solo cuando los informes se hayan quedado tranquilos. Comprueba que tu registro _dmarc está publicado y se lee con la herramienta gratuita de consulta DNS, y si un resultado de SPF en un informe parece contradictorio, la guía de diagnóstico de SPF lo explica.

Herramientas y guías relacionadas:

• Búsqueda de DNS: Consulta registros A, AAAA, MX, TXT, NS y más, con valores y TTL, además de DNS inverso.
• Por qué tu registro SPF falla una y otra vez (y cómo arreglarlo): Cómo leer tu registro SPF

Preguntas frecuentes