Cómo leer informes DMARC: guía campo a campo del XML agregado
Los informes agregados DMARC parecen hostiles pero solo tienen tres secciones. Esta guía recorre un informe RFC 9990 real campo por campo, muestra los siete patrones de fila que verás de verdad y explica qué hacer con cada uno.
Ejecuta la misma comprobación ahora — gratis
Introduce tu dominio y obtén una auditoría de 9 puntos — DNS, SPF/DKIM/DMARC, SSL, cabeceras de seguridad, exposición en dark web — en 60 segundos.
Sin registro · <60s · Procesamiento GDPR/UE
Para leer un informe DMARC, abre el adjunto XML comprimido, mira policy_published para confirmar qué política aplicaron los receptores y después recorre cada bloque record: source_ip y count te dicen quién envió cuánto, policy_evaluated da el veredicto DMARC y auth_results muestra los resultados brutos de SPF y DKIM que hay debajo. Una fila que supera SPF o DKIM pero falla en DMARC tiene un problema de alineación. Una fila que falla en todo es o un remitente olvidado o alguien suplantando tu dominio. Esta guía recorre un informe real campo por campo, muestra los siete patrones que verás con más frecuencia y explica qué hacer con cada uno.
Qué es realmente un informe DMARC
Cada receptor de correo compatible con DMARC (Google, Microsoft 365, Yahoo, Mail.ru, Fastmail, Zoho y muchos más) cuenta los mensajes que ve afirmando venir de tu dominio en la cabecera From. Una vez por día UTC empaqueta esos recuentos en un archivo XML, lo comprime y lo envía por correo a la dirección de la etiqueta rua= de tu registro DMARC. Son los informes agregados, a veces llamados informes RUA. No contienen contenido de mensajes, solo recuentos por IP remitente con los resultados de autenticación de cada una.
Según RFC 9990, publicado por el IETF en mayo de 2026 como especificación Standards Track para los informes agregados, el periodo de informe es normalmente un único día UTC que empieza a las 0000 UTC, el XML debe ir comprimido con gzip en circunstancias normales y cada informe cubre exactamente un dominio de política. Los informes llegan tanto si tu política es p=none como p=quarantine o p=reject. Son el único canal de retroalimentación que ofrece DMARC, y leerlos es la diferencia entre aplicar la política con seguridad y bloquear tus propias facturas.
De los 1,8 millones de dominios principales, 937 931 (52,1 %) publican DMARC, más de 553 000 recogen informes agregados y 411 935 aplican la política. Solo alrededor del 9 % hace ambas cosas. Fuente: EasyDMARC, 2026 DMARC Adoption Report, 30 de marzo de 2026.
La brecha de ese gráfico es el problema que resuelve este artículo. El estudio de EasyDMARC de marzo de 2026 sobre los 1,8 millones de dominios principales encontró que solo un 9 % combina una política de aplicación con informes. Un escaneo independiente de DMARCguard sobre 5 499 028 dominios Tranco, del 27 de febrero de 2026, encontró que 776 918 de los 1 670 975 dominios con DMARC (46,5 %) no tienen etiqueta rua=. La mayoría de los propietarios que sí reciben informes nunca los abren, porque el XML en bruto parece hostil. No lo es. Solo hay tres secciones.
Paso 1: abrir el adjunto
Un correo de informe legítimo tiene un asunto como Report Domain: example.com Submitter: google.com Report-ID: 1234567890 y un único adjunto. La sección 3.5.2 del RFC 9990 fija el formato del nombre de archivo como receptor!dominio-de-política!marca-inicio!marca-fin.xml.gz, por ejemplo google.com!example.com!1757462400!1757548799.xml.gz. Los dos números son marcas de tiempo Unix del inicio y el fin de la ventana del informe, así que sabes qué día cubre antes de abrir nada.
Descomprímelo en la línea de comandos:
gunzip google.com!example.com!1757462400!1757548799.xml.gz
Algunos remitentes, entre ellos Microsoft, usan zip en lugar de gzip. En ese caso usa unzip sobre el archivo. Para formatear el resultado y que sea legible:
xmllint --format google.com!example.com!1757462400!1757548799.xml
Cualquier editor de texto también sirve. Lo que verás es un único elemento feedback que contiene report_metadata, policy_published y uno o más bloques record.
Paso 2: leer las tres secciones
Aquí tienes un informe recortado a un solo registro, con la estructura del apéndice B del RFC 9990:
<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0">
<version>1.0</version>
<report_metadata>
<org_name>google.com</org_name>
<email>noreply-dmarc-support@google.com</email>
<report_id>1757548799.example.com</report_id>
<date_range>
<begin>1757462400</begin>
<end>1757548799</end>
</date_range>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>quarantine</p>
<sp>none</sp>
</policy_published>
<record>
<row>
<source_ip>192.0.2.123</source_ip>
<count>123</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<envelope_from>example.com</envelope_from>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>example.com</domain>
<result>pass</result>
<selector>abc123</selector>
</dkim>
<spf>
<domain>example.com</domain>
<result>fail</result>
</spf>
</auth_results>
</record>
</feedback>
Los informes antiguos usan el espacio de nombres http://dmarc.org/dmarc-xml/0.1 del RFC 7489. Los campos son los mismos, así que se leen igual.
| Elemento | Qué te dice | Cómo usarlo |
|---|---|---|
report_metadata / org_name | Qué receptor generó el informe | Agrupa los hallazgos por receptor; Google y Microsoft juntos suelen cubrir la mayor parte de tu volumen |
date_range | Marcas de tiempo Unix de la ventana cubierta | Relaciona los picos con campañas o incidentes de ese día |
policy_published | Tu registro DMARC tal como lo leyó el receptor | Si p no coincide con lo que publicaste, el DNS no había propagado o tienes dos registros |
source_ip | La IP que entregó el mensaje al receptor | Haz una búsqueda inversa; este es tu inventario de remitentes |
count | Mensajes desde esa IP con resultados idénticos | Los recuentos grandes son tus flujos reales; los pequeños son ruido o sondeos |
policy_evaluated / dkim y spf | Resultados alineados de DKIM y SPF | Este es el veredicto DMARC, tras la alineación, no la comprobación bruta |
disposition | Qué hizo el receptor: none, quarantine, reject, o pass en informes RFC 9990 | Te dice qué pasó realmente con el correo |
reason | Por qué un receptor anuló tu política | mailing_list, trusted_forwarder, local_policy, policy_test_mode u other |
header_from | El dominio de la cabecera From visible | El dominio que DMARC protege en esta fila |
envelope_from | El dominio RFC5321.MailFrom que comprobó SPF | Si difiere de header_from, SPF no puede alinearse |
auth_results / dkim | Resultado bruto de DKIM, dominio firmante y selector | Un pass aquí con un fail en policy_evaluated significa que el dominio d= no es el tuyo |
auth_results / spf | Resultado bruto de SPF y dominio comprobado | Un pass aquí con un fail arriba significa que el dominio de sobre no está alineado |
La distinción que confunde a casi todo el mundo: auth_results es la comprobación bruta y policy_evaluated es la comprobación después de la alineación. DMARC solo cuenta SPF o DKIM como superados si el dominio autenticado coincide con tu dominio header_from. Una plataforma de marketing que firma con su propio dominio mostrará DKIM pass en auth_results y DKIM fail en policy_evaluated. No es una firma rota. Es una firma no alineada.
Paso 3: clasificar cada fila
Una vez que los campos tienen sentido, leer un informe es reconocer patrones. Estos siete cubren casi todas las filas con las que te encontrarás.
| # | Qué muestra la fila | Causa más probable | Qué hacer |
|---|---|---|---|
| 1 | SPF alineado pass, DKIM alineado pass, recuento alto | Tu propio servidor de correo o un servicio bien configurado | Nada. Este es el estado objetivo |
| 2 | SPF alineado pass, DKIM fail o ausente | Un servicio autorizado en SPF que no firma con tu dominio | Activa DKIM en ese servicio y publica su selector CNAME o TXT |
| 3 | SPF fail, DKIM alineado pass, envelope_from es otro dominio | Reenvío, lista de correo o plataforma con su propio dominio de rebote | Normal. DMARC sigue pasando. No añadas el reenviador a SPF |
| 4 | DKIM bruto pass con dominio firmante ajeno, DKIM alineado fail | Remitente externo que firma con su clave por defecto | Pide al proveedor un dominio de firma personalizado (un CNAME bajo el tuyo) |
| 5 | SPF bruto pass para envelope_from, SPF alineado fail | El proveedor usa su propio dominio de return-path | Configura un return-path o dominio de rebote propio en el proveedor, o apóyate en DKIM |
| 6 | Todo falla, source_ip pertenece a un rango de nube u hosting que no reconoces, recuento de cientos o miles | Suplantación o campaña de phishing usando tu dominio | Déjalo fallar. Avanza hacia p=reject para que los receptores lo descarten |
| 7 | Todo falla, recuento bajo, reason indica mailing_list o trusted_forwarder | El receptor eximió el mensaje de tu política | Informativo. Nada que corregir por tu parte |
Para una fila que no puedas ubicar, haz una búsqueda inversa de la IP con dig -x 192.0.2.123 +short o host 192.0.2.123 y después comprueba el include SPF del proveedor que sospeches. Un registro PTR que termina en outbound.protection.outlook.com, google.com, amazonses.com, sendgrid.net o mailgun.org suele apuntar directamente al servicio responsable.
Leer informes en volumen
Un dominio con pocos remitentes produce un puñado de archivos al día, y la lectura manual funciona. Por encima de eso, usa un analizador. Un analizador típico ingiere el buzón rua=, descomprime cada archivo y agrupa las filas por origen, de modo que ves "Microsoft 365: 12 400 mensajes, 100 % alineados" en lugar de cuarenta archivos XML. Existen opciones gratuitas, y el propio escaneo de FortifyNet te dirá si existe siquiera una etiqueta rua= y si está bien escrita.
Dos hábitos importan más que la herramienta. Primero, vigila policy_published después de cada cambio de DNS: los receptores cachean los registros DMARC, así que un informe que cubra el día en que cambiaste p= puede mostrar la política antigua, y la sección 3.3 del RFC 9990 permite explícitamente una mezcla. Segundo, sigue leyendo después de llegar a p=reject. Las nuevas herramientas SaaS, las claves DKIM rotadas y los registros SPF editados aparecen como una nueva fila de patrón 2, 4 o 5 al día siguiente, mucho antes de que tus clientes noten los rebotes.
Qué cambió el RFC 9990 para quien lee informes
El estándar de mayo de 2026, que sustituye las partes de informes del RFC 7489 de 2015, importa si analizas los informes por tu cuenta o evalúas a un proveedor.
| Campo o regla | RFC 7489 (2015) | RFC 9990 (2026) |
|---|---|---|
| Espacio de nombres XML | http://dmarc.org/dmarc-xml/0.1 | urn:ietf:params:xml:ns:dmarc-2.0 |
selector DKIM | Opcional | Obligatorio siempre que se informe un resultado DKIM |
Valores de disposition | none, quarantine, reject | Añade pass |
| Motivos de anulación | forwarded, sampled_out, trusted_forwarder, mailing_list, local_policy, other | local_policy, mailing_list, other, policy_test_mode, trusted_forwarder |
discovery_method | No existe | Opcional: psl o treewalk |
generator | No existe | Nombre y versión opcionales del software de informes |
envelope_from | Opcional | Opcional, puede estar vacío en rebotes con remitente nulo |
| Elementos desconocidos | Sin definir | Deben ignorarse, no tratarse como errores |
Todos los grandes receptores siguen enviando informes con el formato antiguo en septiembre de 2026, y lo harán durante mucho tiempo. Lee ambos formatos de la misma manera y nunca descartes un informe porque tenga un campo que no reconoces.
Preguntas frecuentes
¿Por qué recibo informes DMARC de correos que nunca envié? Porque los envía otra persona. Los informes agregados cubren cada mensaje que afirmó venir de tu dominio en la cabecera From, incluidos los falsificados. Una fila con recuento alto, IP desconocida y fallos en SPF y DKIM es exactamente la suplantación que DMARC está diseñado para detectar.
¿Cuántos informes debo esperar al día? Uno por receptor que informa, por día y por dominio, así que normalmente entre 3 y 15 archivos para una pequeña empresa. El RFC 9990 fija el periodo en un único día UTC. Los receptores muy grandes pueden dividir un día en varios archivos.
¿Qué significa disposition none si tengo p=quarantine?
O el mensaje superó DMARC, por lo que no se aplicó ninguna política, o el receptor anuló tu política y el elemento reason indica por qué. Revisa policy_evaluated: si ambos resultados alineados son pass, none es la disposición correcta.
¿Los informes DMARC contienen contenido de correos o datos personales? Los informes agregados contienen IP remitentes, recuentos y resultados de autenticación, nada del cuerpo ni de las cabeceras más allá del dominio From. Los informes de fallo (RUF, definidos en el RFC 9991) pueden contener cabeceras y los grandes proveedores rara vez los envían.
¿Puedo dejar de recibir informes?
Elimina la etiqueta rua= y los receptores dejan de enviarlos en un día. Al hacerlo pierdes toda la visibilidad sobre suplantación y errores de configuración, así que apuntar rua= a un analizador es la mejor opción.
Comprueba si tus informes llegan siquiera
Antes de dedicar una tarde al XML, conviene saber si tu registro DMARC pide informes, si la dirección rua= está autorizada y si SPF y DKIM están configurados en los remitentes que ya conoces. El escaneo gratuito de FortifyNet lee tus registros DMARC, SPF y DKIM y señala lo que falta en unos 60 segundos, sin registro. Ejecuta un escaneo gratuito en FortifyNet.
Guías relacionadas: Monitorización DMARC: cómo llegar a p=reject con seguridad · Cómo configurar DMARC paso a paso · ¿Qué es DKIM? · SPF Record Checker
Frequently Asked Questions
Verifica tu dominio ahora
Ejecuta una auditoría gratuita y comprueba si tu dominio tiene los problemas descritos.
