Cómo leer un informe agregado de DMARC: guía campo por campo

Tu registro DMARC tiene una etiqueta rua=, y cada día, los proveedores de correo te envían un archivo XML. Esto es lo que realmente contiene y cómo leerlo sin dolores de cabeza.

Ten esta tabla a mano. Todo lo de abajo repasa por qué importa cada fila y cómo leerla en un archivo real.

Los informes agregados de DMARC son la única parte de DMARC diseñada específicamente para que la lea un humano, y aún así están escritos en XML. He ahí el dilema. Red Sift OnDMARC traduce esto en paneles para que nunca tengas que tocar XML crudo, pero entender lo que esos paneles resumen hace que todas tus decisiones sobre tu política DMARC sean más rápidas y defendibles. Esta guía recorre un informe real, campo por campo, y te enseña cómo distinguir una rotación de tu proveedor de correo de un intento real de suplantación.

Esto no es una repetición de qué es un informe agregado ni por qué tu buzón rua= puede estar vacío. Si necesitas esa base primero, nuestra guía de fundamentos del informe agregado de DMARC lo explica. Esta guía parte del momento en que el archivo llega a tu bandeja de entrada y te muestra qué hacer con él.

Al terminar, serás capaz de:

• Abrir un informe e identificar cada sección sin hoja de referencia
• Distinguir entre el resultado pass/fail de DMARC y el resultado en crudo de SPF/DKIM
• Leer la columna de disposición y saber exactamente qué sucedió con ese correo
• Detectar los cuatro patrones más comunes en informes reales, incluyendo reenvío, rotación de ESP y suplantación flagrante
• Entender qué cambió en el formato del informe con la actualización DMARC 2026

Cada informe agregado de DMARC es un único documento XML con un elemento raíz llamado feedback. Dentro, tres bloques contienen toda la información que necesitas [1].

• report_meta identifica quién te envió el informe y cuándo. Incluye el nombre de la organización que reporta, un email de contacto, un ID único y un date_range que muestra la ventana de reporte en segundos desde el inicio de la época Unix. La mayoría de los receptores reportan sobre una ventana móvil de 24 horas.
• policy_published es la lectura del receptor sobre tu registro DMARC en el momento en que evaluó tu correo. Esto importa más de lo que parece. Si cambiaste la política de p=none a p=quarantine a media jornada, distintos informes de ese día podrían mostrar distintos valores aquí, porque la propagación y el caché DNS significa que no todos los receptores vieron el cambio al mismo tiempo [1].
• record es donde vive la información real. Hay un bloque record por cada combinación de IP, resultado evaluado e identificadores de autenticación, así que la misma IP puede aparecer legítimamente en varios records incluso si la disposición es la misma. Un solo informe puede contener desde uno hasta miles de estos, según tu volumen de correo. Cada record se descompone en tres partes: row (IP, conteo y veredicto), identifiers (los dominios que realmente comprobó DMARC), y auth_results (resultados SPF y DKIM en crudo antes de la lógica de alineación de DMARC).

Una vez que reconozcas estos tres bloques a simple vista, leer cualquier informe será solo cuestión de encontrar el correcto, no de descifrar el archivo completo desde cero.

Así se ve un solo record ya descomprimido, según la estructura definida en RFC 9990 [1]. La mayoría de los receptores comprime el archivo (Gmail envía .zip, otros envían .xml.gz), así que el primer paso siempre es descomprimir antes de leer.

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>16215678901234567890</report_id>
    <date_range>
      <begin>1754784000</begin>
      <end>1754870399</end>
    </date_range>
  </report_metadata>

  <policy_published>
    <domain>redsift.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>quarantine</p>
    <sp>none</sp>
  </policy_published>

  <record>
    <row>
      <source_ip>203.0.113.42</source_ip>
      <count>842</count>
      <policy_evaluated>
        <disposition>pass</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>redsift.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>redsift.com</domain>
        <result>pass</result>
        <selector>google</selector>
      </dkim>
      <spf>
        <domain>redsift.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Esto es lo que realmente te dice cada línea:

• org_name y date_range: Google generó este informe cubriendo una ventana de 24 horas. Todo lo demás refleja correo enviado en esa ventana, no el que se envía hoy.
• policy_published: Google leyó el registro DMARC de redsift.com con alineación relajada (r) tanto en DKIM como SPF, y política de cuarentena. Es la política realmente aplicada, no necesariamente la vigente ahora mismo en DNS si ha cambiado desde entonces.
• source_ip: 842 mensajes provinieron de esa IP en esa ventana. Es un conteo agrupado, no 842 líneas individuales de registro.
• disposition: pass significa que el mensaje pasó la evaluación DMARC bajo esta política aplicada. Disposition refleja el resultado/acción DMARC reportado aquí, no hay garantía de cómo el proveedor de buzón gestionó realmente ese mensaje.
• dkim y spf en policy_evaluated: Ambos muestran pass, por lo que el mensaje estuvo alineado según DMARC, no solo según el chequeo de protocolo.
• auth_results: Este es el veredicto previo a DMARC. DKIM pasó usando el selector google y SPF también aprobó. En este caso, el resultado en crudo y el resultado alineado con DMARC coinciden. No siempre será así.

Ese último punto es el que suele pasar desapercibido en la primera lectura de un informe — y merece su propio apartado. Pero primero, una nota sobre el bloque identifiers, ya que determina qué dominio recibe el crédito o culpa del resto de la información.

El elemento identifiers solo lleva hasta tres campos y es fácil pasarlo por alto, porque ninguno muestra pass ni fail. Precisamente por eso es importante. Este bloque indica qué dominios comprobó DMARC realmente, y el resto de los veredictos del registro se comparan contra esos valores.

• header_form es el dominio en el remitente visible, el que el destinatario ve en su bandeja de entrada. Es obligatorio en todo registro y es el pilar de toda la lógica de alineación DMARC. Toda comprobación de alineación en policy_evaluated en realidad pregunta: ¿el dominio que pasó SPF/DKIM coincide con este?
• envelope_form es el dominio del comando SMTP MAIL FROM, a veces llamado devolución o return-path. El destinatario nunca lo ve directamente, pero es contra lo que valida SPF. Cuando una plataforma de marketing envía en tu nombre, a menudo muestra el dominio de su infraestructura y no el tuyo, que es precisamente por lo que falla la alineación SPF si no configuras un return-path personalizado.
• envelope_to es opcional y muestra el dominio destinatario, útil sobre todo si buscas saber si el flujo fallido va a un proveedor concreto o está distribuido entre varios.

Aquí está el punto fundamental: si header_from muestra redsift.com pero envelope_from muestra bounce.some-esp.com, SPF se comprueba contra el dominio del ESP, no el tuyo. La comprobación SPF puede pasar sin problemas en ese dominio y aun así fallar en la alineación DMARC, porque la alineación compara envelope_from con header_from, y esos dos no coinciden a menos que el ESP envíe a través de un subdominio delegado tuyo. Esta relación explica más "por qué falló esto" que casi cualquier otro aspecto del informe.

Cada registro incluye veredictos separados en DKIM y SPF, y responden cosas distintas.

• auth_results responde: "¿El chequeo en crudo de SPF o DKIM fue exitoso?" Es el resultado a nivel de protocolo, validado contra cualquier dominio que figure en la firma o el registro SPF.
• policy_evaluated responde: "¿Ese resultado cuenta para DMARC?" Es el resultado tras comprobar la alineación, y es el que determina la disposición.

La diferencia es la alineación. DMARC no solo pregunta si pasó SPF o DKIM. Pregunta si el dominio que pasó SPF o DKIM coincide con el que aparece en tu remitente visible, ya sea exactamente (strict alignment, adkim=s o aspf=s) o a nivel organizativo (relaxed alignment, el valor por defecto de la mayoría) [2]. Un mensaje puede pasar SPF con bounce.thirdpartyesp.com y aun así fallar DMARC porque bounce.thirdpartyesp.com no se alinea con redsift.com en el encabezado From.

Por eso a veces verás que auth_results da pass pero policy_evaluated da fail en el mismo registro. Esa diferencia suele ser la clave cuando el correo legítimo acaba en cuarentena aunque "todo pase en el panel del proveedor". El proveedor muestra el resultado SPF o DKIM en crudo. DMARC exige además alineación.

El campo disposition indica lo que realmente ocurrió con el correo, y puede tomar cuatro valores [1]:

Un detalle suele confundir a todos en algún momento: si tu política es p=none, la mayoría de los registros mostrarán disposition: none, incluso cuando DKIM y SPF hayan fallado. Normalmente esto es lo esperado, aunque el receptor aún puede aplicar política local u otra anulación, que es para lo que sirve el elemento reason (abajo). Con p=none, solo pides a los receptores que informen sobre lo que ocurriría, no que refuercen nada. El informe hace su función. Nada fue bloqueado porque aún no has pedido bloquear nada.

Si ves una disposición que no cuadra con tu política publicada, revisa si dentro de policy_evaluated aparece un elemento reason. RFC 9990 define cinco tipos de anulaciones que puede reportar un receptor: local_policy, mailing_list, trusted_forwarder, policy_test_mode y other [1]. Un motivo mailing_list en un registro fallido indica que el receptor atribuyó la anulación al procesamiento de listas. Es común que eso sea un servidor de listas reenviando el mensaje de modo que rompe la alineación SPF y modifica o elimina la firma DKIM, pero el valor reason no garantiza esa secuencia exacta. Sea como sea, es el comportamiento esperado al reenviar y no algo que debas tratar como amenaza.

Leer un registro en aislamiento solo lleva hasta cierto punto. El valor de los informes agregados está en leer muchos registros de un mismo remitente durante varios días. Hay cuatro patrones recurrentes, y distinguirlos te ahorra tanto ignorar un problema real como perseguir uno que no existe.

1. Un remitente legítimo aún no autorizado. Aparece una nueva source_ip, auth_results muestra SPF y DKIM fallando y el conteo se repite día a día. Normalmente es una plataforma de marketing, CRM o herramienta de soporte que alguien contrató sin avisar a TI. La solución es añadirlos a SPF y configurar la firma DKIM, no bloquearlos.

2. Rotación de IP en ESP o proveedor cloud. Llevas meses con un remitente autorizado y de repente aparecen lotes de nuevas IPs fallando SPF, mientras DKIM sigue pasando. Los grandes remitentes rotan su infraestructura regularmente. Como la firma DKIM viaja con el mensaje sin importar la IP, si DKIM sigue alineado y SPF se rompe es una señal clara de rotación, no de suplantación. Consulta con tu ESP si hubo cambios.

3. Listas de correo y reenviadores. SPF y DKIM fallan, el elemento reason muestra mailing_list o el conteo es bajo y repartido en muchas IP de origen, pero el header_from sigue tu dominio. Esto suele ser un colega reenviando o una lista redistribuyendo el mensaje. Es el coste previsto por reenviar con DMARC, y RFC 9989 lo contempla expresamente como flujo indirecto [2].

4. Suplantación real. SPF y DKIM fallan, la IP de origen no guarda relación con ningún proveedor o infraestructura conocida, no hay override reason y el volumen es un pico ocasional o un goteo que no puedes relacionar internamente. Es el patrón que sí debes atajar: asegurarte que tu política es suficientemente fuerte para poner en cuarentena o rechazar, y si el volumen es alto, tratarlo como campaña de phishing contra tu dominio.

Hacer estos chequeos manualmente a diario en miles de registros no escala cuando tienes muchas fuentes, que es precisamente por lo que existen plataformas como Red Sift OnDMARC: para detectar automáticamente esos cuatro patrones sin pedirte leer XML cada mañana.

En mayo de 2026, la IETF reemplazó la especificación original de DMARC, RFC 7489, con tres nuevos documentos “Standards Track”: RFC 9989 cubre el protocolo central, RFC 9990 la reportabilidad agregada y RFC 9991 los reports de fallo [1, 2]. Si ya has leído informes agregados antes, el formato sigue valiendo. Las herramientas existentes suelen seguir funcionando, porque RFC 9990 exige tolerar datos extra [1], pero no garantiza que todos los parsers estrictos acepten el archivo, ya que el namespace y el esquema cambian respecto a RFC 7489, y cambios semánticos como la disposición pass pueden no aceptarse en un parser antiguo.

Algunas novedades a tener en cuenta para la próxima vez que abras un informe:

• discover_method puede aparecer dentro de policy_published, mostrando psl (el método clásico de la Public Suffix List) o treewalk (nuevo método DNS para hallar tu dominio organizativo) [1].
• Ahora los selectores son obligatorios, no opcionales, cada vez que una firma DKIM aparece en auth_results. Antes, algunos receptores omitían el campo selector.
• Puede aparecer un campo generator en report_metadata, nombrando el software que creó el informe, útil si necesitas depurar archivos mal formados.

Nada de esto cambia tu lectura diaria. Parsers y paneles existentes suelen funcionar porque RFC 9990 pide tolerar campos no soportados [1]; no es garantía del parseo XML estándar, sino una regla explícita de extensibilidad del RFC. Conviene saberlo si revisas tu propio parser o evalúas un proveedor. También recuerda que DMARC aún es un estándar activo, no algo congelado en 2015. El mayor cambio estructural es que la reportabilidad agregada tiene ya especificación propia, así que puede evolucionar sin esperar a que se actualice el protocolo general. Explicamos todo el cambio, incluyendo lo que supone para tu registro DNS, en nuestro análisis de la actualización RFC 9989.

Un dominio mediano puede recibir informes diarios de 15 a 30 proveedores diferentes, cada uno con su archivo, compresión y peculiaridades sobre campos opcionales. Nada de eso está pensado para personas, sino para que lo procese una máquina y resuma los datos donde alguien pueda actuar.

Los requisitos de remitentes masivos de Google, en vigor desde febrero de 2024, exigen que cualquier dominio que envía 5.000 o más mensajes diarios a Gmail tenga autenticación SPF, DKIM y una política DMARC al menos p=none [3]. Esa sola condición empujó a muchas organizaciones a usar DMARC, y la mayoría se encontró con la misma pared: los informes son correctos y completos pero imposibles de leer manualmente con volumen.

Ahí es donde entra Red Sift OnDMARC. Ingiere informes automáticamente, agrupa registros por fuente de envío en vez de archivo, señala remitentes nuevos o no autorizados cuando surgen y te da una vista simple del ratio de éxito por fuente para que sepas cuándo pasar de p=none a p=quarantine a p=reject. Si vas dando los primeros pasos, nuestra guía de despliegue de DMARC recorre todo el proceso desde el primer registro hasta el refuerzo total.

Leer un informe, no una tendencia. Un informe diario te dice qué pasó en 24 horas. La infraestructura cambia, varía el volumen y surgen fallos puntuales. Mira la misma fuente mínimo una semana antes de sacar conclusiones.

Confundir auth_results con el veredicto DMARC. Pueden diferir. Si todo “pasa en el proveedor” pero DMARC falla, casi siempre es cuestión de alineación.

Suponer que disposition:none equivale a que nada falló. Con p=none solo significa que nada se bloqueó, no que todo pasó. Revisa dkim y spf dentro de policy_evaluated directamente.

Ignorar el campo count. Un registro con un fallo de una IP sin identificar es ruido. El mismo fallo reiterado por cientos de mensajes diarios durante dos semanas es un remitente que debes autorizar o bloquear.

Tratar cada fallo como un ataque. La mayoría de los fallos en una bandeja típica se deben a reenvíos, listas o proveedores que necesitan tu SPF, no suplantaciones. Solo hay que alarmarse si el patrón no tiene explicación interna ni hay override reason.

Saltar el bloque identifiers. Como no muestra pass/fail es fácil ir directamente a policy_evaluated. Pero si no comparas header_from y envelope_from, solo adivinas por qué falló alineación.

Un informe agregado DMARC son tres bloques XML y un puñado de campos repetidos para cada fuente de envío. Cuando ya sabes identificar report_metadata, policy_published y record a simple vista, y sabes buscar el resultado DMARC en policy_evaluated y no en auth_results, el archivo deja de intimidar. Lo difícil es hacerlo cada día en docenas de receptores y miles de registros sin perder el hilo.

Eso sí conviene automatizar. Red Sift OnDMARC analiza cada informe en cuanto llega, detecta remitentes nuevos o no autorizados automáticamente y te muestra ratio de éxito por fuente, haciendo el paso a una política más estricta mucho más sencillo.

[1] RFC 9990 - Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting

[2] RFC 9989 - Domain-Based Message Authentication, Reporting, and Conformance (DMARC)

[3] Preguntas frecuentes sobre el envío de correo - Ayuda de Gmail