Qué dice realmente un informe DMARC RUA

Cada mañana llegan a tu buzón uno o varios XML de Google, Microsoft o Yahoo. Si los abres, ves un muro de etiquetas incomprensibles. Si no los abres, ignoras el único dato empírico que determina si tu dominio está protegido o sangrando suplantaciones de identidad.

Acumular reportes en una carpeta automatizada no aporta ningún valor si no sabes extraer los datos críticos de su interior. La seguridad de tu infraestructura de correo depende de la precisión con la que analices estos registros diarios. En este documento aprenderás a leer informe DMARC, a decodificar la estricta sintaxis de esos archivos y a identificar exactamente qué direcciones IP están fallando por configuraciones deficientes y cuáles representan a atacantes activos.

Qué es exactamente un informe RUA y quién te lo manda

Un informe DMARC RUA (Reporting URI for Aggregate reports) es un archivo estructurado en formato XML, habitualmente comprimido en .zip o .gz, generado y enviado por los servidores de recepción de correo electrónico. Cuando un proveedor de servicios de internet (ISP) como Google, Microsoft o Yahoo recibe correos que afirman provenir de tu dominio, sus Mail Transfer Agents (MTA) evalúan la autenticación criptográfica (DKIM), la autorización de envío (SPF) y la correspondencia de dominios. Diariamente, estos receptores agregan los resultados de todas esas evaluaciones y te envían un volcado de datos.

Recibes este informe RUA porque has publicado explícitamente la etiqueta rua=mailto:tu-email@tudominio.com dentro de tu registro TXT en el DNS. Esta etiqueta actúa como una directiva de envío. Si dejas de recibir estos correos, el diagnóstico es binario: o bien eliminaste la etiqueta RUA de tu zona DNS, o el buzón de destino está rechazando los adjuntos, o la sintaxis de tu política carece de validez. Qué es RUA a nivel de protocolo está definido con rigor en la RFC 7489 de dmarc.org, la especificación base del estándar.

Las normativas de autenticación implementadas por Google y Microsoft obligan a disponer de DMARC para garantizar la entrega. Esto convierte la lectura de estos envíos en un requerimiento operativo ineludible. Si envías correos transaccionales o masivos y omites el análisis de este informe aggregate DMARC, tu tasa de entregabilidad decaerá sin que tengas datos objetivos para diagnosticar el origen del rechazo.

La estructura de un RUA en tres bloques

Interpretar XML DMARC requiere entender que el documento no es una lista plana, sino un árbol de nodos jerárquicos. Todo informe DMARC RUA válido se divide invariablemente en tres bloques fundamentales. Aislar cada bloque es el primer paso para analizar DMARC correctamente.

El bloque report_metadata: el remitente del informe

Este nodo inicial, <report_metadata>, establece las coordenadas del documento. Contiene el nombre de la organización emisora (<org_name>, por ejemplo, google.com), un identificador único del reporte (<report_id>) y el rango de tiempo evaluado expresado en formato Unix Epoch (<date_range>). Este bloque define quién audita tus envíos y qué franja temporal abarca la muestra, un dato crítico cuando correlacionas fallos con despliegues de software internos.

El bloque policy_published: tu política en el momento del análisis

El nodo <policy_published> actúa como un espejo de tu configuración DNS. Muestra exactamente qué política (p=none, quarantine o reject) detectó el receptor cuando procesó los correos. También detalla tu política de subdominios (sp=) y el porcentaje de aplicación (pct=). Si modificas tu registro DNS hoy, los informes tardarán entre 24 y 48 horas en reflejar el cambio en este bloque debido a los tiempos de propagación y al ciclo de agregación diario de los ISPs.

El bloque record: dónde está la información que importa

El nodo <record> se repite múltiples veces dentro del XML. Cada instancia de <record> representa un conjunto de correos electrónicos que comparten exactamente la misma dirección IP de origen y los mismos resultados de autenticación. Este es el núcleo operativo del informe, donde se cuantifican los aciertos y los fallos.


<feedback>
  <report_metadata>...</report_metadata>
  <policy_published>...</policy_published>
  <record>
    <row>...</row>
    <identifiers>...</identifiers>
    <auth_results>...</auth_results>
  </record>
</feedback>

Si quieres ver esto sobre un RUA real, puedes pegar tu propio XML en el analizador de Smartxpression — corre íntegramente en tu navegador, no se transfiere ningún dato a servidores externos.

Anatomía de un registro <record>

El bloque <record> es donde la mayoría de los administradores de sistemas cometen errores de interpretación. Cada uno de estos nodos se subdivide en tres ramas críticas: <row>, <identifiers> y <auth_results>. Desglosar estas ramas es vital para configurar DMARC paso a paso sin interrumpir flujos de correo legítimos.

El bloque row: la IP, el conteo y la decisión

Dentro de <row>, encuentras tres etiquetas. <source_ip> expone la dirección IPv4 o IPv6 desde la cual se emitió el correo. <count> indica el volumen exacto de mensajes enviados desde esa IP bajo las mismas condiciones. Finalmente, <policy_evaluated> detalla la decisión tomada por el receptor: si aplicó tu política (disposition: none, quarantine o reject) y el veredicto final de DMARC para SPF y DKIM (pass o fail).

Existe una diferencia técnica crítica aquí: policy_evaluated muestra el resultado de DMARC (que requiere alineación), mientras que auth_results mostrará los resultados aislados de los protocolos subyacentes.

El bloque identifiers: From visible vs envelope-from

El nodo <identifiers> contiene una única etiqueta indispensable: <header_from>. Este es el dominio que el destinatario final ve en el campo "De:" de su cliente de correo (el RFC 5322 From). Todo el protocolo DMARC orbita en torno a proteger este dominio específico. Si el <header_from> es tudominio.com, DMARC exige que las firmas DKIM o el dominio del Return-Path (SPF) coincidan de forma exacta o parcial con tudominio.com.

El bloque auth_results: qué pasó realmente con SPF y DKIM

El nodo <auth_results> expone el crudo diagnóstico técnico. Aquí verás el dominio evaluado por SPF (el dominio del Return-Path o envelope-from) y su resultado (pass, fail, softfail, neutral). También verás el dominio que firmó el mensaje con DKIM (d=) y su resultado (pass, fail, temperror). Es imperativo cruzar los datos de este bloque con el <header_from> para determinar por qué un mensaje falló la evaluación global.

La clave: alineación

No basta con que SPF o DKIM pasen sus respectivas validaciones aisladas (auth_results). Para que DMARC apruebe un correo (policy_evaluated), el dominio validado por SPF o el dominio de la firma DKIM debe coincidir con el dominio visible en el header From. Esta coincidencia se denomina alineación. Si tienes un SPF pass pero el dominio del Return-Path pertenece a tu proveedor de email marketing y no a tu dominio, DMARC registrará un fallo por falta de alineación.

Cuatro categorías para clasificar lo que ves

Al leer informe DMARC te enfrentarás a miles de IPs. Tratar de investigarlas una a una es inviable. Para operar con eficacia, debes aplicar una taxonomía estricta a cada registro <record>. Todo hallazgo se clasifica en una de las siguientes cuatro categorías.

Posible ataque

Identificas un ataque cuando la <source_ip> pertenece a un ASN desconocido o a un país donde no tienes operaciones, el <count> es bajo o moderado, y tanto SPF como DKIM muestran un fallo total o una desalineación completa en <auth_results>. El remitente está forjando tu dominio en el <header_from>. Acción requerida: ninguna intervención técnica en tu DNS. Estos registros confirman que DMARC está cumpliendo su función de visibilidad. Tu objetivo será eventualmente aplicar una política de rechazo para bloquearlos.

Vulnerabilidad activa

Una fuente es vulnerable cuando la IP pertenece a una herramienta legítima de tu ecosistema (un CRM, una plataforma de facturación, un servicio de mailing), el <count> es alto, pero falla sistemáticamente en DMARC. Verás que en <auth_results>, SPF o DKIM pueden estar pasando la verificación técnica, pero fallan en policy_evaluated debido a la falta de alineación. Acción requerida: acceder al panel de configuración de esa herramienta externa y habilitar un dominio de envío personalizado (custom Return-Path) o configurar las claves CNAME para la firma DKIM delegada.

Misconfiguración

Esta categoría engloba los fallos internos de tu propia infraestructura. Se detecta cuando la IP corresponde a tu propio servidor de correo corporativo (Microsoft 365, Google Workspace, o tu servidor on-premise), pero ves fallos en DKIM (quizás porque rotaste las claves y olvidaste actualizar el DNS) o errores de sintaxis en el registro SPF (como superar el límite de 10 búsquedas DNS). Acción requerida: corrección inmediata de los registros TXT en tu zona DNS o reconfiguración del agente de firma en tu MTA.

OK: lo que sí está bien

Estos son los registros donde <policy_evaluated> muestra pass tanto para SPF como para DKIM (o al menos para uno de los dos, que es suficiente para DMARC). La IP pertenece a una fuente autorizada y la alineación es correcta. Acción requerida: documentar la IP y el servicio asociado como "sancionado" dentro de tu inventario de activos.

Esta clasificación está implementada automáticamente en el analizador DMARC de Smartxpression: pegas tu XML y ves cada fila etiquetada con su categoría y la acción recomendada. Si gestionas correo de varios clientes, te ahorra horas de análisis manual.

Un ejemplo práctico: del XML al diagnóstico en 5 minutos

Para materializar la teoría, analizaremos la estructura interna de un RUA anonimizado. Observa el siguiente bloque de código.


<record>
  <row>
    <source_ip>198.51.100.42</source_ip>
    <count>1540</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>empresa.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>mailingservice.net</domain>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounces.mailingservice.net</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Paso 1: Evaluar policy_evaluated. Observamos un fallo total en la evaluación DMARC (<dkim>fail</dkim> y <spf>fail</spf>). La política aplicada fue none, lo que significa que el mensaje se entregó, pero habría sido bloqueado bajo una política estricta.

Paso 2: Revisar identifiers. El dominio que el usuario final ve es empresa.com. DMARC exige que la autenticación se alinee con este dominio.

Paso 3: Diagnosticar con auth_results. Para DKIM, la firma es criptográficamente válida (pass), pero el dominio que firma es mailingservice.net. No coincide con empresa.com. Fallo por desalineación. Para SPF, la IP está autorizada en el registro SPF de bounces.mailingservice.net (pass), pero este dominio no coincide con empresa.com. Segundo fallo por desalineación.

Conclusión y Categorización. Cruzando el alto volumen (count: 1540) con la naturaleza del dominio firmante (mailingservice.net), determinamos que esto no es un ataque. Es una Vulnerabilidad activa. El remitente legítimo está utilizando una plataforma de marketing sin haber configurado un dominio personalizado. La orden de prioridades exige contactar a los administradores de esa plataforma para generar registros CNAME que alineen el DKIM con empresa.com.

Qué hacer después de leer tu primer RUA

La extracción de datos carece de propósito si no desencadena cambios en la infraestructura. Una vez decodificado tu primer informe, debes ejecutar tres acciones inmediatas.

Primero, corrige las fuentes clasificadas como "Vulnerabilidad activa". Debes exigir a cada proveedor de software de tu organización que proporcione instrucciones para configurar firmas DKIM alineadas. Segundo, documenta las IPs categorizadas como "Posible ataque" pero no intervengas tu DNS para bloquearlas; la política de rechazo se encargará de ello automáticamente cuando la actives.

Tercero, planifica la transición de políticas. La regla de oro dicta mantener p=none hasta que el 100% de tus flujos legítimos (OK) superen DMARC. Solo entonces, debes escalar a p=quarantine (iniciando con un pct=10 e incrementándolo progresivamente) y, tras un mes de monitorización sin incidencias, asentar la infraestructura en p=reject. El análisis continuo es imperativo; implementar DMARC en español, o en cualquier región, no es un ajuste estático, sino un proceso de monitorización mensual permanente frente a la incorporación de nuevos proveedores de software.

Si prefieres delegar la auditoría completa a alguien que ya ha leído cientos de RUAs, en Smartxpression hacemos auditorías DMARC para consultores IT y agencias por 290€ por dominio, entregadas en 48h con PDF white-label listo para tu cliente. Más info →

Errores comunes al leer un RUA por primera vez

La curva de aprendizaje al analizar DMARC propicia interpretaciones defectuosas que resultan en la interrupción del tráfico de correo legítimo. Los errores más recurrentes son:

En conclusión

La lectura de un informe DMARC RUA se reduce a extraer hechos comprobables del formato XML, separar los flujos legítimos desalineados de las anomalías externas, y aplicar correcciones específicas en los portales de tus proveedores. Hemos analizado la anatomía técnica del registro, expuesto la metodología de categorización y demostrado el diagnóstico mediante la inspección directa del código.

Si quieres profundizar en las especificaciones técnicas más allá de este artículo, hemos publicado una guía PDF de 24 páginas detallando el ciclo de vida de DMARC: despliegue, monitorización, casos operativos reales y errores de sintaxis comunes. Es gratis: pídela aquí →

En el próximo artículo de esta serie técnica disecaremos la estructura de las cabeceras de email — porque cuando un RUA te muestra una IP anómala, el paso consecuente es auditar el código fuente de un mensaje concreto emitido por ese servidor. [Próximamente].