Cómo leer los informes DMARC antes de aplicar la política

Una vez que publicas un registro DMARC con una dirección rua=, los proveedores de buzones empiezan a enviarte informes diarios sobre cada servidor que usa tu dominio, y aprender a leer los informes DMARC es la diferencia entre pasar de forma segura a la aplicación de la política y enviar por accidente tus propias facturas a la carpeta de spam. La trampa es que estos informes llegan como XML denso que ningún humano estaba destinado a revisar. Esta guía explica exactamente qué contiene un informe agregado, cómo interpretarlo para encontrar correo legítimo que está fallando y dónde vale la pena un analizador de informes.

La respuesta corta#

Los informes agregados de DMARC (los que dispara la etiqueta rua=) son archivos XML que un receptor te envía aproximadamente una vez al día. Cada uno agrupa el correo que vio afirmando proceder de tu dominio por IP de envío, y para cada fuente te dice: cuántos mensajes, si SPF y DKIM pasaron y se alinearon, y qué hizo el receptor al respecto. Los lees para construir un inventario completo de quién envía en tu nombre y para confirmar que cada flujo legítimo se autentica en alineación antes de endurecer tu política de p=none a quarantine y reject. El XML en bruto es doloroso, así que casi todo el mundo lo carga en un analizador de informes DMARC que lo convierte en una tabla legible.

¿Ya tienes un informe en mano? Pégalo o súbelo al analizador de informes DMARC gratuito para seguir esta guía con tus propios datos: lo analiza todo en tu navegador, no se sube nada.

Qué desencadena un informe agregado#

El disparador es una única etiqueta en tu registro DMARC. Cuando publicas rua= en _dmarc.yourdomain.com, estás pidiendo a cada receptor participante que te envíe por correo comentarios agregados:

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

A partir de entonces, los grandes receptores —Google, Yahoo, Microsoft, Comcast y muchos otros— agrupan todo lo que vieron de tu dominio en una ventana de 24 horas y envían un único informe XML por dominio. El informe suele llegar como un adjunto comprimido (.xml.gz o .zip) con un nombre de archivo que codifica el emisor del informe, tu dominio y el rango de fechas. Puedes apuntar rua a varias direcciones, e incluso puedes recopilar informes de un dominio que no controlas usando un destino externo, aunque eso requiere un registro de autorización adicional en el dominio receptor. Si aún no has publicado un registro, empieza por el tutorial ordenado de configuración de DMARC: los informes solo empiezan una vez que el registro está activo.

Cómo leer un informe agregado de DMARC, fila por fila#

Cada informe agregado sigue el mismo esquema XML, definido en el RFC 7489. Tiene tres partes: quién envió el informe, qué política tenías publicada en ese momento y luego uno o más bloques <record>, uno por fuente de envío. Aquí tienes un ejemplo recortado de un único registro:

<record>
  <row>
    <source_ip>203.0.113.42</source_ip>
    <count>128</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>example.com</domain>
      <selector>s1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>example.com</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Lo más importante que hay que entender es que un informe te da el resultado de la autenticación en dos lugares distintos, y significan cosas diferentes:

El bloque auth_results informa de si SPF y DKIM pasaron en absoluto. El bloque policy_evaluated informa de si pasaron en alineación, que es lo único que le importa a DMARC. Esos dos pueden discrepar, y esa brecha es donde ocurre la mayor parte de tu trabajo de investigación.

Cómo detectar una fuente legítima que está fallando#

Este es el patrón que buscas, y por qué importa. Imagina un registro donde la source_ip pertenece claramente a una plataforma de marketing que usas, el header_from es tu dominio y auth_results muestra spf: pass, pero el dominio SPF que aparece es el propio dominio de rebote de la plataforma, no el tuyo, y policy_evaluated/spf marca fail. Ese mensaje se autenticó para alguien, pero no para ti de una forma que se alinee. Bajo p=none la disposition sigue siendo none, así que nada se rompió, todavía. En el momento en que pasas a quarantine o reject, cada mensaje de ese count empieza a ir a spam o a rebotar.

Así que la lectura es siempre la misma comparación de tres pasos:

• Identifica la fuente. Asocia cada source_ip a un servicio real. Un DNS inverso rápido o el etiquetado integrado del analizador suele nombrarla. Tu objetivo es una lista completa: los informes revelan de forma rutinaria una herramienta de facturación olvidada o una vieja plataforma de campañas que sigue enviando en tu nombre.
• Comprueba la alineación, no solo la autenticación. Fíjate en policy_evaluated, no en auth_results. Una fuente puede pasar SPF o DKIM y aun así fallar DMARC porque el dominio para el que se autenticó no coincide con tu "From".
• Decide: corregir o dejar que falle. Si la fuente es legítima, corrige su alineación: añádela a SPF o, mejor, configura la firma DKIM en tu dominio para que el dominio firmante coincida. Si es un suplantador, el fallo es exactamente lo que quieres, y es prueba de que tu futuro p=reject hará su trabajo.

Normalmente vale la pena priorizar la alineación de DKIM sobre la de SPF, porque una firma DKIM viaja con el mensaje y sobrevive al reenvío, mientras que la alineación de SPF se rompe en el momento en que el correo se reenvía. La mecánica de la alineación —relajada frente a estricta, dominio organizativo frente a coincidencia exacta— se cubre en el explicativo de SPF, DKIM y DMARC si necesitas ir más despacio con el concepto.

RUA frente a RUF: dos informes muy distintos#

DMARC define dos etiquetas de informe, y no son intercambiables:

• rua — informes agregados. Los resúmenes XML diarios descritos arriba. Contienen recuentos y resultados agrupados por fuente, sin contenido del mensaje, y son en los que confías para todo el despliegue. Todo receptor serio los envía.
• ruf — informes forenses (de fallo). Informes por mensaje generados en el momento en que un mensaje individual falla. Históricamente podían incluir cabeceras y a veces partes del mensaje, lo que significa que pueden contener datos personales.

Como los informes forenses pueden exponer información del destinatario, la mayoría de los grandes proveedores dejaron de enviarlos hace años por motivos de privacidad, y muchos remitentes nunca publican ruf en absoluto. Un registro que solicita ambos tiene este aspecto:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:agg@example.com; ruf=mailto:forensic@example.com"

En la práctica obtendrás un flujo constante de informes agregados rua y pocos o ningún informe forense ruf. Planifica tu monitorización en torno a los datos agregados; trata cualquier informe forense que recibas como una bonificación ocasional, y solo habilita ruf si tienes una base legal y un lugar donde almacenar lo que pueden ser datos personales.

Por qué quieres un analizador, no un buzón en bruto#

Puedes abrir el XML a mano, y para un único dominio con dos o tres remitentes eso es soportable durante un tiempo. Deja de escalar rápido. Un dominio con mucho tráfico genera docenas de informes al día de distintos receptores, cada uno enumerando muchas IP de origen, y la señal interesante —un remitente legítimo que falla en silencio la alineación— queda enterrada entre etiquetas con marcas de tiempo Unix y direcciones IP sin etiquetar.

Un analizador de informes DMARC o panel de monitorización ingiere los informes en una dirección dedicada, descomprime y analiza el XML, resuelve las IP a nombres de servicio reconocibles y vuelca todo en una tabla que realmente puedes leer: las fuentes por un lado, los volúmenes de aprobado y fallo por el otro, tendencias a lo largo del tiempo. Los buenos señalan las fuentes nuevas o que empiezan a fallar para que notes un cambio sin releer cada archivo. Tanto si usas un servicio alojado como un analizador autoalojado, la tarea es la misma: convertir un montón de XML en "esto es quién envía en tu nombre, y esto es quién todavía no está alineado". Esa claridad es lo que hace que los informes sean accionables en lugar de simplemente archivados.

Cómo encaja esto en el despliegue seguro#

Leer los informes no es una tarea separada de configurar DMARC: es la mitad del despliegue, y saltárselo es como la gente entierra su propio correo. La secuencia:

1. Publica p=none con rua. Nada cambia en cómo se gestiona tu correo; simplemente se activan los informes.
2. Lee los informes agregados durante un ciclo de envío completo. Un par de semanas como mínimo, más si tienes flujos de baja frecuencia como los extractos mensuales. Construye el inventario completo de fuentes.
3. Corrige cada fuente legítima que falle la alineación. Aquí es donde se va el tiempo de verdad, y a donde te señalan los informes.
4. Pasa a quarantine y luego a reject. Solo una vez que los informes muestren que cada flujo genuino pasa en alineación. p=reject es el ajuste que realmente detiene la suplantación y satisface las reglas para remitentes masivos de los requisitos para remitentes de Google y Yahoo.

Los informes siguen ganándose su lugar después de que llegues a reject también: son la forma en que detectas una nueva herramienta SaaS añadida que empieza a enviar en tu nombre, o una campaña de suplantación que se intensifica contra tu marca. Vigilarlos junto con tus quejas de bucles de retroalimentación y tu reputación de remitente general te da un sistema de alerta temprana en lugar de una tarea de configuración de una sola vez.

Un límite honesto: pasar DMARC en alineación demuestra quién eres, no que seas un buen remitente. Un dominio perfectamente alineado que envíe a direcciones muertas o a trampas de spam aun así acaba en spam: la autenticación es la entrada, y la calidad de la lista y la interacción deciden la ubicación. Ese panorama más amplio es el tema de la guía de entregabilidad, y es la razón más común por la que el correo legítimo aún va a spam incluso con informes limpios.

Preguntas frecuentes#

¿Qué contienen realmente los informes agregados de DMARC?#

Un informe agregado (rua) es un archivo XML que agrupa el correo que un receptor vio procedente de tu dominio por dirección IP de envío. Para cada fuente indica el número de mensajes, los resultados en bruto de SPF y DKIM y contra qué dominios se ejecutaron, el veredicto alineado de DMARC y la disposición que el receptor aplicó según tu política publicada. Nunca incluye asuntos, cuerpos de mensajes ni direcciones de destinatarios, solo recuentos agregados y resultados de autenticación, que es lo que lo mantiene respetuoso con la privacidad.

¿Cuál es la diferencia entre los informes RUA y RUF?#

rua solicita informes agregados diarios: recuentos resumidos y resultados de aprobado/fallo agrupados por fuente, sin contenido del mensaje. ruf solicita informes forenses o de fallo, generados por cada mensaje que falla e históricamente capaces de incluir cabeceras y datos del mensaje. Como los informes forenses pueden contener datos personales, la mayoría de los grandes receptores ya no los envían, así que deberías basar tu monitorización en los informes agregados y tratar cualquier dato forense como un extra ocasional.

¿Por qué una fuente muestra SPF aprobado pero DMARC fallido en mi informe?#

Porque DMARC exige alineación, no solo autenticación. Un mensaje puede pasar SPF para el propio dominio del servicio de envío mientras tu dominio figura en el "From" visible: SPF pasa, pero los dominios no coinciden, así que DMARC falla. Lee el resultado de policy_evaluated en lugar de los auth_results en bruto: el primero refleja la alineación. Corregirlo suele significar añadir la fuente a tu registro SPF o, de forma más robusta, habilitar la firma DKIM en tu propio dominio para que el dominio firmante coincida.

¿Necesito un analizador de DMARC o puedo leer los informes yo mismo?#

Para un dominio con un par de remitentes puedes leer el XML en bruto durante un tiempo. Deja de ser práctico rápidamente, porque un dominio con mucho tráfico recibe docenas de informes al día llenos de IP y marcas de tiempo sin etiquetar. Un analizador o panel de monitorización descomprime y analiza los informes, nombra las fuentes y vuelca los datos en una tabla legible con tendencias, que es lo que convierte los informes en decisiones en lugar de una carpeta sin leer.

Los informes agregados te dicen quién envía en tu nombre; no te dicen si la lista detrás de ese correo está limpia. Pasa tus direcciones por el verificador de correo gratuito para eliminar dominios muertos, erratas y trampas de spam antes de que reboten, porque un dominio perfectamente alineado aún necesita una lista sana para ganarse la bandeja de entrada.