DMARC aggregate reports XML: parser + guía 2026

Los DMARC aggregate reports (RUA) son la herramienta más poderosa que tiene un equipo de email para entender qué pasa con la autenticación del dominio. Llegan a diario desde Gmail, Microsoft, Yahoo y otros ~50 proveedores major en formato XML comprimido. Contienen información detallada sobre cada IP que envió correos usando el dominio: cuántos pasaron SPF, cuántos pasaron DKIM, cuántos alinearon con el From, qué política se aplicó.

El problema operativo: el XML es notoriamente difícil de leer manualmente. Una sola jornada de reports de Gmail puede contener cientos de líneas. Equipos sin herramientas dedicadas terminan ignorando los reports o, peor, tomando decisiones equivocadas (típicamente: subir DMARC a p=reject sin parsing previo, bloqueando mail legítimo).

Este post explica la estructura RFC 7489 de un report RUA, qué buscar específicamente, y incluye un parser interactivo donde puede pegar el XML de un report real y ver análisis visual inmediato. Sin tener que subir el archivo a ningún servicio externo.

Estructura RFC 7489 de un report RUA

Un report DMARC aggregate sigue el schema definido en RFC 7489 Section 7.2. Tres secciones obligatorias:

1. report_metadata

Identifica quién envía el report y para qué período.

<report_metadata>
  <org_name>google.com</org_name>
  <email>[email protected]</email>
  <report_id>1234567890123456789</report_id>
  <date_range>
    <begin>1715126400</begin>
    <end>1715212800</end>
  </date_range>
</report_metadata>

Campos clave:

• org_name: la organización que envió el report (Google, Microsoft Outlook, Yahoo, etc.)
• report_id: identificador único del report
• date_range: período cubierto, en formato epoch Unix (1715126400 = mayo 8 2026 00:00 UTC)

2. policy_published

Refleja la política DMARC que el receptor vio en su DNS al momento del análisis.

<policy_published>
  <domain>marca.com</domain>
  <adkim>r</adkim>
  <aspf>r</aspf>
  <p>none</p>
  <sp>none</sp>
  <pct>100</pct>
</policy_published>

Campos clave:

• domain: el dominio sobre el cual se reporta
• adkim / aspf: modo de alignment DKIM y SPF (r = relaxed, s = strict)
• p: política aplicada al dominio (none, quarantine, reject)
• sp: política para subdominios (puede ser distinta a p)
• pct: porcentaje del tráfico al que se aplica la política

3. records (uno o varios)

El corazón del report. Cada record representa tráfico de una IP fuente específica.

<record>
  <row>
    <source_ip>209.85.220.41</source_ip>
    <count>1247</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>marca.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>marca.com</domain>
      <result>pass</result>
      <selector>s1</selector>
    </dkim>
    <spf>
      <domain>marca.com</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Campos clave:

• source_ip: IP que envió los correos
• count: cantidad de mensajes desde esa IP en este período
• policy_evaluated: resultado DMARC final (pass, fail) y disposición aplicada
• header_from: dominio en el header From
• auth_results.dkim/spf: detalles individuales de SPF y DKIM

Parser interactivo: pegue su XML para ver análisis

Pegue el contenido de un report DMARC aggregate (después de descomprimir el .gz si aplica) y vea el análisis visualmente. El procesamiento es 100% en su navegador.

Cómo interpretar lo que el parser muestra

El parser categoriza cada source IP en uno de cuatro estados de diagnóstico. Cada uno requiere acción distinta:

Estado 1: DMARC pass, SPF y DKIM ambos pass

Es lo esperado. El IP está autorizado, autentica correctamente, y el dominio firmado coincide con el From. Acción: ninguna, mantener configuración.

Estado 2: DKIM pass, SPF fail

Patrón típico de forwarders. Cuando un usuario reenvía un correo, la dirección IP que envía cambia (a la del servidor de reenvío), pero la firma DKIM se mantiene. SPF falla porque la IP nueva no está autorizada por el SPF record del dominio original. DMARC pasa de todos modos porque DKIM alinea.

Es benigno. La mayoría de operaciones tienen 2-5% de tráfico en este estado por forwarders naturales. Acción: ninguna, salvo si el volumen es desproporcionado (más del 20%) lo cual indica algún servicio intermedio mal configurado.

Estado 3: SPF pass, DKIM fail

Patrón típico de servicios que envían en nombre del dominio sin configuración DKIM. Por ejemplo: un sistema CRM que envía notificaciones pero el equipo solo configuró SPF (agregando la IP del CRM al record) sin haber configurado DKIM con el proveedor.

Acción: identificar qué servicio es (por el spfDomain o reverse DNS de la IP), configurar DKIM apropiado, verificar alignment.

Estado 4: SPF y DKIM ambos fallan

Es el más serio. Tres causas posibles:

4a) Spoofing/phishing: alguien externo está enviando correos haciéndose pasar por el dominio. Volumen típico: bajo (decenas-centenas), distribuido en muchas IPs distintas. Acción: si la política DMARC es p=none, considerar subir a p=quarantine para mitigar.

4b) Servicio legítimo no autenticado: la marca contrató un servicio (típicamente legacy o no técnico) que envía emails pero no está configurado con SPF ni DKIM. Volumen típico: alto, concentrado en pocas IPs. Acción: identificar el servicio, decidir si autenticar o reemplazar.

4c) Migración en curso mal coordinada: el servicio fue cambiado pero la configuración DNS no se actualizó simultáneamente. Volumen típico: alto, súbito (no aparece en reports anteriores). Acción: corregir DNS inmediatamente.

Tabla: códigos típicos por fuente

Flujo del análisis: de DMARC report a decisión de policy

El proceso no es de un día. El camino completo desde primer report a p=reject típicamente toma 60-90 días: 14 días de observación a p=none, 30 días progresivos a p=quarantine con pct creciendo, y otros 30 días en p=reject con pct creciendo.

Cómo configurar reporting RUA correctamente

Para empezar a recibir reports, hay que configurar el tag rua en el record DMARC. La sintaxis básica:

v=DMARC1; p=none; rua=mailto:[email protected]

Detalles operativos importantes que muchos equipos omiten:

Usar dirección dedicada, no personal. Crear [email protected] o [email protected] específico para esto. NO usar info@, soporte@, o el correo personal del admin. Los reports se acumulan rápido (decenas por día) y mezclados con correo operativo se pierden.

Considerar dominio externo de hosting. Si la operación recibe muchos correos en marca.com y los reports llegarían junto con todo, considerar un dominio externo. Pero requiere DNS adicional: el dominio externo debe publicar un TXT autorizando recibir reports del dominio principal: marca.com._report._dmarc.dominioexterno.com con valor v=DMARC1.

Configurar intervalo con ri. Por defecto los reports llegan cada 24 horas. Para operaciones que quieren más granularidad puede configurarse el tag ri con un valor en segundos. Ejemplo: ri=3600 para reports cada hora. Aviso: muchos receptores ignoran el tag ri y mandan 24h igual.

Múltiples destinos. Se puede especificar más de una dirección separando con coma:

rua=mailto:[email protected],mailto:[email protected]

Útil para tener copia en herramienta de análisis externa (DMARC Report, EasyDMARC, etc.) sin perder copia local.

Tag ruf para forensic reports. Adicional al rua, existe ruf para forensic reports (copia completa de correos que fallan). Muchos receptores ya no envían ruf por razones de privacidad. En 2026, depender de ruf para análisis es no recomendable; mejor confiar en rua exclusivamente.

Cómo decidir cuándo pasar a p=quarantine y p=reject

La política DMARC tiene tres modos: p=none (monitoreo sin acción), p=quarantine (mensajes fallidos van a spam), p=reject (mensajes fallidos rechazados). El error común es saltarse fases o mover sin datos.

Fase 1: p=none por al menos 30 días. Solo monitoreo. Genera reports pero no afecta entrega. Tiempo suficiente para identificar TODOS los servicios legítimos que envían en nombre del dominio. Si pasa a quarantine antes de identificarlos, los correos legítimos de esos servicios van a spam.

Fase 2: p=quarantine con pct gradual. Subir a quarantine pero solo aplicar al X% del tráfico fallido. Empezar con pct=10, observar 7 días, subir a pct=25 si todo OK, después pct=50, después pct=100. Permite detectar problemas con muestra reducida sin impacto operativo grande.

Fase 3: p=reject con pct gradual también. Misma lógica. pct=10 → pct=25 → pct=50 → pct=100. En total el proceso de p=none a p=reject 100% debería tomar 60-90 días con observación cuidadosa.

Algunas reglas operativas adicionales:

No subir política durante períodos críticos. No subir a p=reject la semana de Black Friday, la semana de mayor envío del año, o durante campañas críticas. Si algo sale mal, el impacto es mayor.

Mantener visibilidad post-enforcement. Una vez en p=reject, los reports siguen llegando. Hay que seguir monitoreándolos. Aparición súbita de nuevas fuentes legítimas (un servicio nuevo contratado por marketing sin avisar a IT) genera fail rate alto rápidamente. Si nadie está mirando, esos correos legítimos se rechazan y nadie sabe por qué.

Subdominios necesitan política propia. Si el dominio principal marca.com está en p=reject pero mail.marca.com no tiene política propia, hereda la del root pero con potencial alignment imperfecto. Configurar política sp=reject en el record del root también, o publicar record DMARC propio en cada subdominio activo.

Errores comunes que vemos en operaciones panameñas

Después de analizar DMARC reports de docenas de operaciones panameñas, los errores recurrentes:

Error 1: Configurar rua pero nunca leer los reports. Es lo más común. Hace 18 meses alguien siguió un tutorial, configuró rua=mailto:[email protected], y los reports vienen acumulándose en esa casilla sin que nadie los abra. Resultado: cero valor del esfuerzo de configuración.

Error 2: Pasar directo de p=none a p=reject. Sin pasar por quarantine y sin usar pct gradual. Resultado típico: correos legítimos de servicios no identificados son rechazados de un día para el otro. Tickets de soporte, notificaciones de pago, OTPs que dejan de llegar.

Error 3: Configurar pct como porcentaje aspiracional. Algunos equipos ponen pct=50 desde el inicio pensando “estamos al 50% de quien sabe qué”. pct es porcentaje del tráfico FALLIDO al que se aplica la política. No es un porcentaje de readiness. Configurar pct=50 significa que 50% del tráfico que falla DMARC va a quarantine y 50% pasa libre. Operativamente confuso, no protege bien.

Error 4: Confundir SPF pass con DMARC pass. Un correo puede pasar SPF (la IP está autorizada) pero fallar DMARC si el dominio que pasó SPF no es el mismo del header From. Es el concepto de alignment. Equipos que solo miran el resultado SPF en headers de correos individuales no entienden el resultado DMARC real.

Error 5: Ignorar reports de subdominios. Solo monitorear marca.com y olvidar mail.marca.com, app.marca.com, news.marca.com. Cada uno genera reports separados si los receptores los detectan como dominios distintos. Subdominios sin política propia pueden ser usados para spoofing fácil.

Error 6: Subir a p=reject y no monitorear los rejection. Una vez en p=reject, además de los reports RUA, hay que monitorear los rejection rates desde Postmaster Tools v2 (Gmail) y SNDS (Microsoft). Si el rejection rate sube, indica que la política está bloqueando correos legítimos no identificados.

Tools de análisis automatizado vs análisis manual

Para volúmenes operativos, parsear XML manualmente no escala. Las opciones:

Self-hosted/open source: parsedmarc (Python), OpenDMARC tools. Gratis, requiere infraestructura propia (servidor para ingesta + base de datos). Tiempo de setup: 4-8 horas para un ingeniero competente. Mantenimiento: 1-2 horas/mes. Recomendado para operaciones con equipo técnico fuerte y compliance que requiere “no enviar data fuera”.

Managed SaaS gratuitos limitados: EasyDMARC tier gratis, DMARC Analyzer free tier. Útiles para volumen bajo (1-3 dominios, pocos miles de mensajes/día). Limitaciones: retención corta de datos, sin alertas avanzadas.

Managed SaaS comerciales: PowerDMARC, Valimail, DMARC Report, dmarcian. USD 100-500/mes para operaciones medianas. Valor agregado: identificación automática de servicios por IP, tendencias históricas, alertas, soporte en remediación. Recomendado para operaciones sin equipo dedicado a esto.

Híbrido: usar parser open-source para ingesta + dashboard custom interno. Mejor relación costo-control para operaciones grandes con equipo técnico. Costo: solo infra + tiempo de desarrollo interno.

Para operaciones panameñas medianas (1-5 dominios, <10M mensajes/mes), la recomendación más común es Managed SaaS comercial. El costo de USD 200-300/mes vs el costo de no analizar (riesgo de spoofing, errores de configuración detectados tarde) tiene relación clara.

Cómo identificar spoofing real vs falsos positivos

No todo “DMARC fail” es spoofing. Distinguir requiere análisis cuidadoso.

Indicios de spoofing real:

• IPs de geografías inusuales (Europa del Este, Asia) sin razón de negocio
• Picos súbitos sin correlación con campañas propias
• Concentración en fines de semana o noches cuando la operación normal está dormida
• Header From a [email protected] o variantes con typos ([email protected])
• Volumen creciente sostenido (atacante refinando técnica)

Indicios de falso positivo (servicio legítimo no autenticado):

• IPs que reverse-resuelven a SaaS conocidos (Salesforce, HubSpot, Mailchimp, etc.)
• Volumen consistente con calendario de operación normal
• Concentrado en horarios de oficina latinoamericanos
• Header From a direcciones de operación normal (info@, soporte@, etc.)
• Aparece consistentemente en reports cada día con volumen similar

Indicios de forwarder benigno:

• IPs residenciales (Comcast, Cox, ISPs locales panameños)
• Volumen bajo (1-50 mensajes por IP)
• DKIM típicamente pasa, solo SPF falla
• Distribución amplia en muchas IPs distintas

La regla operativa: ante DMARC fail con DKIM pass = probable forwarder benigno, ignorar salvo volumen muy alto. DMARC fail con ambos SPF+DKIM fail = investigar fuente.

Tres patrones panameños recurrentes

Patrón 1: el CRM olvidado

E-commerce panameño descubre en sus DMARC reports que aproximadamente 8.000 correos/mes fallan SPF+DKIM desde una IP que reverse-resuelve a un proveedor SaaS de CRM contratado hace 3 años. El equipo actual no sabía que el CRM seguía enviando correos en nombre del dominio. Resolver: o autenticar el CRM correctamente, o desactivar el envío desde ese servicio.

Patrón 2: el subdominio en penumbra

Marca corporativa que opera marca.com con DMARC estricto descubre que mail.legacy.marca.com (subdominio olvidado de proyecto cerrado en 2022) sigue siendo origen de algunos correos automáticos legacy. Como el subdominio no tiene política DMARC propia, hereda la política del root pero con alignment imperfecto. Resolver: documentar subdominio formalmente, autenticarlo correctamente o cerrarlo.

Patrón 3: el spoofer persistente

Fintech panameña detecta en reports recurrentes que IPs de Europa del Este envían correos con From: marca.com aunque las IPs no están autorizadas. Volumen bajo (50-200 correos/día) pero consistente. Patrón clásico de phishing dirigido a clientes de la fintech. Resolver: subir a p=quarantine rápidamente, monitorear si el atacante cambia tácticas, considerar BIMI para mejorar identificación legítima.

Integración con SIEM/SOC para operaciones avanzadas

Para empresas con equipo de seguridad (SOC) o plataforma SIEM (Splunk, Elastic, Datadog), los DMARC reports pueden integrarse al flujo de monitoreo general. Esto permite correlacionar eventos de email con otros indicadores de compromiso.

Ingesta a SIEM: parsedmarc (Python) puede exportar datos a Elasticsearch, Splunk HTTP Event Collector, o Datadog API directamente. Para SOC que ya tiene dashboard de threat intelligence, agregar fuente DMARC es valor incremental claro.

Correlación con threat intel: cuando un spoofer aparece en DMARC reports con IP específica, ejecutar lookup contra threat intelligence feeds (AlienVault OTX, AbuseIPDB, etc.) para confirmar si la IP está ya identificada como maliciosa por otros indicadores. Si lo está, escalar a investigación de campaña de phishing más amplia.

Alertas automatizadas: configurar SIEM para alertar cuando: nueva ASN aparece como source con volumen significativo, geografía inusual genera volumen, fail rate sube súbitamente más del 50% día a día. Estas son señales que mejor capturar automatizadas que esperar al review semanal.

Retención larga: reports DMARC tienen valor histórico. Algunas plataformas SIEM permiten retener 12-24 meses. Útil para investigar incidentes meses después de que ocurrieron (típico en respuesta a incidentes de phishing reportados por clientes después del hecho).

Para operaciones panameñas con compliance fuerte (banca, fintech, salud), integrar DMARC reports al SOC es práctica creciente. Auditorías 2026 cada vez más preguntan “¿cómo monitorean spoofing de su dominio?” y la respuesta “tenemos DMARC con monitoreo en SIEM” es más fuerte que “tenemos DMARC publicado”.

Recursos verificados

Documentación oficial verificada a mayo 2026:

• RFC 7489 (DMARC): datatracker.ietf.org/doc/html/rfc7489
• DMARC Report aggregate guide: dmarcreport.com/blog/dmarc-aggregate-reports-complete-guide
• Valimail RUA explained: valimail.com/blog/dmarc-rua-value
• EasyDMARC reports guide: easydmarc.com/blog/understanding-dmarc-reports
• PowerDMARC analyzer: powerdmarc.com/dmarc-aggregate-report
• Open-source parser (parsedmarc Python): github.com/domainaware/parsedmarc

En CMP ofrecemos setup DMARC con monitoreo continuo de reports que incluye parsing automatizado de RUA, alertas por fuentes sospechosas, y plan progresivo desde p=none hasta p=reject con validación en cada etapa.