Cómo interpretar los informes DMARC: una guía completa sobre RUA y RUF

Has publicado un registro DMARC, has configurado «rua=» con tu dirección de correo electrónico y ahora los informes llegan a tu bandeja de entrada en forma de archivos XML comprimidos. Son difíciles de leer, proceden de empresas de las que nunca has oído hablar y no queda claro qué se supone que debes hacer con ellos, si es que hay que hacer algo.

Esta guía te ayuda a solucionarlo. Explica qué contienen los informes DMARC, cómo leer el XML campo por campo, qué significan realmente RUA y RUF y, lo más importante, qué medidas debes tomar cuando un remitente supera la comprobación, no la supera o aparece de forma inesperada. Si tienes tu primer informe entre manos en este momento, empieza por el principio y ve leyendo hacia abajo.

Este blog da por hecho que ya tienes un registro configurado. Si no es así, publica primero un registro DMARC y, a continuación, vuelve aquí para interpretar los informes que genera.

¿Qué son los informes DMARC?

Los informes DMARC son resúmenes diarios que envían los servidores de correo receptores a la dirección indicada en tu etiqueta «rua=». En cada uno de ellos se enumeran todas las direcciones IP que han enviado un correo electrónico afirmando proceder de tu dominio durante un periodo de informe, y se indica si SPF y DKIM han superado o no las comprobaciones para cada origen. Son la herramienta principal para supervisar el estado de autenticación del correo electrónico de su dominio. Son su única fuente real de información sobre quién está enviando correo en su nombre, ya sea de forma legítima o no.

¿Quién envía los informes DMARC?

Todos los servidores de correo que reciban mensajes de tu dominio enviarán un informe si tienes configurado «rua=». Esto incluye, obviamente, a Google, Microsoft y Yahoo. También incluye a proveedores de servicios de correo electrónico (ESP) más pequeños, pasarelas de correo corporativas, sistemas universitarios y proveedores internacionales que, por casualidad, utilicen tus destinatarios. 

Recibir mensajes de organizaciones que no reconoces es normal y previsible. Puede significar simplemente que un servidor en algún lugar ha procesado un mensaje que parecía proceder de tu dominio. Sin embargo, ten en cuenta que un gran volumen de correo en esos informes procedente de una IP que no controlas sigue justificando una investigación, ya que se trata de una señal de suplantación de identidad.

El número de informes que recibes al día depende del número de servidores de correo distintos que hayan recibido tu correo electrónico. Si solo envías mensajes a unos pocos destinatarios, es posible que recibas dos o tres informes al día. Los remitentes que envían grandes volúmenes de mensajes pueden recibir cientos. Ninguno de estos datos indica por sí solo que haya un problema. El volumen de informes refleja la dispersión de tus destinatarios, no el estado de tu dominio.

¿Cuándo llegan los informes?

La mayoría de los proveedores envían un informe agregado cada 24 horas, y los informes suelen llegar entre 24 y 48 horas después de la actividad de correo electrónico que describen. Se recibe un informe independiente de cada organización que proporciona datos (Google y Microsoft envían los suyos propios, de forma independiente), por lo que el correo de un solo día dirigido a destinatarios diversos genera varios informes que abarcan el mismo periodo.

Los informes llegan como archivos adjuntos comprimidos en formato .zip o .gz procedentes de remitentes automáticos. Algunos clientes de correo electrónico los marcan como sospechosos, así que, si esperas recibir informes y no ves ninguno, comprueba tu carpeta de spam o correo no deseado antes de dar por hecho que algo no funciona bien.

Tipos de informes DMARC: RUA frente a RUF

Hay dos tipos de informes DMARC. En el caso de casi todos los dominios, solo tendrás que tener en cuenta el primero.

Informes agregados (RUA): La norma

Informes agregados de DMARC son un resumen de las últimas 24 horas de todo el tráfico de correo electrónico procedente de su dominio que ha procesado un servidor de correo determinado. Se reciben en formato XML comprimido y muestran las direcciones IP de envío, los volúmenes de mensajes, si SPF ha superado o no la verificación, si DKIM ha superado o no la verificación y la disposición de DMARC (la acción que ha tomado el destinatario). Es fundamental destacar que no contienen ningún contenido de correo electrónico ni información de carácter personal, sino únicamente metadatos de autenticación, lo que hace que su recepción y almacenamiento sean seguros en cualquier región. Este es el informe en el que se centra esta guía. 

Informes de errores (RUF): Errores por mensaje

Informes de fallos de DMARC (anteriormente denominados «informes forenses») son notificaciones casi en tiempo real que indican que un mensaje concreto no ha superado la autenticación. La norma RFC 9991 (mayo de 2026) normalizó formalmente este tipo de informe. Dado que un informe de fallo puede incluir encabezados del mensaje y, en ocasiones, el contenido del cuerpo (datos que pueden contener información de carácter personal), los principales proveedores, entre ellos Google, Microsoft y Yahoo, no los envían en absoluto. Activa ruf= solo si dispones de un procesador dedicado para los datos y, en cualquier caso, no esperes recibir informes de los grandes proveedores de correo electrónico. 

RUA contra RUF 

Qué incluye un informe DMARC: campo por campo

Un informe agregado de DMARC es un archivo XML dividido en tres secciones principales: metadatos del informe (quién lo envió y cuándo), política publicada (tu registro DMARC tal y como lo vio el destinatario) y registros, una fila por cada origen de envío. Si entiendes estos tres bloques, el resto son solo detalles.

Section 1: Report Metadata (<report_metadata>)

En este apartado se indica quién ha enviado el informe y el periodo al que se refiere.

• org_name: la organización que presenta el informe (p. ej., google.com).
• Correo electrónico: la dirección de contacto del remitente del informe.
• report_id: un identificador único para este informe concreto.
• date_range (inicio + fin): el intervalo del informe, expresado en marcas de tiempo de época, que deberás convertir a una fecha legible para el ser humano.

Qué hay que comprobar aquí: comprueba que el informe abarque el periodo que esperas.

Section 2: Policy Published (<policy_published>)

Esto muestra tu registro DMARC tal y como lo evaluó el destinatario en el momento del procesamiento.

• dominio: el dominio al que se aplica la política.
• adkim / aspf: Modos de alineación de DKIM y SPF (flexible o estricto).
• p: tu política (ninguna, cuarentena o rechazo).
• sp: tu política de subdominios, si está configurada.
• pct: un campo de porcentaje heredado. Ten en cuenta que pct se eliminó en virtud de la RFC 9989 (mayo de 2026); es posible que aún lo veas en informes antiguos, pero en los nuevos registros debe omitirse.

Qué debes comprobar aquí: verifica que la política publicada se corresponda con lo que pretendías. Si no es así, es posible que tu DNS no se haya propagado por completo.

Section 3: Records (<record>): The Important Part

Each <record> represents all the emails from one source IP during the reporting period. This is where you spend most of your time.

• source_ip: la dirección IP del remitente. Consulta este dato para identificar quién envió el correo.
• recuento: cuántos mensajes procedían de esa IP.
• policy_evaluated/disposition: la acción realizada (ninguna, cuarentena o rechazo).
• policy_evaluated/dkim y policy_evaluated/spf: el resultado de «aprobado» o «suspendido», conforme a DMARC, para cada uno de ellos.
• identificadores/header_from: el dominio «De:» visible, que es el que protege DMARC.
• auth_results/spf: el dominio SPF y el resultado.
• auth_results/dkim: el dominio, el selector y el resultado de DKIM.

Qué hay que comprobar aquí: ¿ todas las direcciones IP que reconoces superan la verificación DMARC? ¿Hay alguna dirección IP que no reconozcas?

Ejemplo de informe XML de DMARC

A continuación se muestra un informe agregado realista y anonimizado en el que se presentan tres fuentes de envío: un remitente legítimo que cumple los requisitos, un remitente legítimo que no los cumple y una dirección IP desconocida. Cada campo incluye un comentario en lenguaje sencillo. 

<?xml version="1.0" encoding="UTF-8"?>
<feedback>

  <!-- ===== SECTION 1: WHO SENT THIS REPORT AND WHEN ===== -->
  <report_metadata>
    <org_name>google.com</org_name>             <!-- The provider that generated this report -->
    <email>[email protected]</email>  <!-- Where the report came from -->
    <report_id>1234567890123456789</report_id>  <!-- Unique ID for this report -->
    <date_range>
      <begin>1718928000</begin>                 <!-- Start of window (epoch) = 2024-06-21 00:00 UTC -->
      <end>1719014400</end>                      <!-- End of window (epoch)   = 2024-06-22 00:00 UTC -->
    </date_range>
  </report_metadata>

  <!-- ===== SECTION 2: YOUR POLICY AS THE RECEIVER SAW IT ===== -->
  <policy_published>
    <domain>example.com</domain>                <!-- The domain this report is about -->
    <adkim>r</adkim>                             <!-- DKIM alignment: r = relaxed -->
    <aspf>r</aspf>                               <!-- SPF alignment:  r = relaxed -->
    <p>none</p>                                  <!-- Your policy: monitoring only -->
    <sp>none</sp>                                <!-- Subdomain policy -->
  </policy_published>

  <!-- ===== SECTION 3: ONE RECORD PER SENDING SOURCE ===== -->

  <!-- RECORD 1: Legitimate sender (Google). All passing, no action needed. -->
  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>      <!-- A Google sending IP -->
      <count>150</count>                         <!-- 150 messages from this IP -->
      <policy_evaluated>
        <disposition>none</disposition>          <!-- No action taken -->
        <dkim>pass</dkim>                         <!-- DKIM aligned & passed -->
        <spf>pass</spf>                           <!-- SPF aligned & passed -->
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>      <!-- Visible From: domain -->
    </identifiers>
    <auth_results>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
      <dkim>
        <domain>example.com</domain>
        <selector>google</selector>
        <result>pass</result>
      </dkim>
    </auth_results>
  </record>

  <!-- RECORD 2: Known ESP. SPF passes but DKIM is not configured.
       Action: ask the provider to enable DKIM signing for your domain. -->
  <record>
    <row>
      <source_ip>198.51.100.42</source_ip>      <!-- Your email service provider -->
      <count>45</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>                         <!-- DKIM not aligned / not signed -->
        <spf>pass</spf>                           <!-- SPF passes -->
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
      <dkim>
        <domain>esp-vendor.example.org</domain>  <!-- Signed by vendor domain, not yours -->
        <selector>s1</selector>
        <result>fail</result>
      </dkim>
    </auth_results>
  </record>

  <!-- RECORD 3: Unknown sender. Both DKIM and SPF fail.
       Low volume here = monitor. High volume would signal active spoofing. -->
  <record>
    <row>
      <source_ip>203.0.113.17</source_ip>       <!-- Unrecognized IP -->
      <count>8</count>
      <policy_evaluated>
        <disposition>none</disposition>          <!-- Not blocked yet (p=none) -->
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>      <!-- Claiming to be your domain -->
    </identifiers>
    <auth_results>
      <spf>
        <domain>example.com</domain>
        <result>fail</result>
      </spf>
      <dkim>
        <domain>example.com</domain>
        <selector>unknown</selector>
        <result>fail</result>
      </dkim>
    </auth_results>
  </record>

</feedback>

Cómo leer tus informes DMARC: paso a paso

Paso 1: Abrir y descomprimir el informe

Los informes llegan como archivos adjuntos a un correo electrónico con un asunto del tipo «Informe de dominio: tudominio.com», «Remitente: google.com» e «ID del informe: …». Guarda el archivo adjunto, descomprímelo (las herramientas de descompresión integradas en tu sistema operativo gestionan sin problemas los formatos .zip y .gz) y abre el archivo .xml resultante en cualquier editor de texto. 

Si necesitas algo más que un simple vistazo, súbelo a nuestro analizador de informes DMARC en lugar de leer el XML sin procesar, para analizar los datos en profundidad en un formato legible para los humanos.

Paso 2: Identificar la organización que presenta el informe

Check <org_name> in the metadata so you know whose view you are looking at. Google’s report covers your Gmail recipients; Microsoft’s covers Outlook and Hotmail. You will get separate reports from each, so never assume one report is the whole picture.

Paso 3: Comprueba tu póliza publicada

Confirm <p>, <sp>, <adkim>, and <aspf> match what you intended to publish. If they do not, your record may have been propagated incorrectly or edited. Verify the live record with our DMARC Checker.

Paso 4: Revisar cada registro (origen del envío)

For each <record>: look up the <source_ip> with a reverse DNS or IP lookup to identify the service (for example, 209.85.220.41 resolves to Google). Check the <count>. High volume from an IP you do not recognize is a red flag. Then check the disposition and the DKIM/SPF results. A legitimate sender should show both dkim=pass and spf=pass; a failure on either for a sender you recognize means something needs fixing.

Paso 5: Clasificar cada fuente

Clasifica cada fuente en una de estas tres categorías:

1. Válido y conforme: no es necesario tomar ninguna medida.
2. Legítimo, pero ineficaz: necesita una revisión (véase el marco de actuación más abajo).
3. Desconocido y enviando: posible suplantación de identidad; supervisa el volumen y plantéate reforzar tu política si es elevado.

Análisis de informes DMARC a gran escala: herramientas y automatización

Cuando se reciben informes a diario de múltiples proveedores, la lectura manual de archivos XML deja de ser viable. Un dominio que envía mensajes a usuarios de Gmail, Outlook y Yahoo recibe al menos tres informes al día, todos los días, y leer cada uno de ellos a mano resulta inviable más allá de la primera semana. El análisis automatizado es el estándar del sector por una razón.

Para realizar una comprobación rápida y puntual, herramientas gratuitas como el «DMARC Report Analyzer» de PowerDMARC te permiten subir un archivo XML sin procesar y consultar su contenido en un formato legible para el usuario sin necesidad de abrir un editor de texto.

Para un seguimiento continuo a gran escala, una plataforma especializada se encarga de todo de forma automática: normaliza los informes de todos los proveedores en una única vista, te avisa cuando aparece un remitente desconocido, conserva el historial y genera exportaciones listas para auditorías. 

Para los usuarios de PowerDMARC, nuestro panel de informes se encarga de todo esto tanto en entornos de un solo dominio como en entornos con varios dominios, de modo que el análisis se realiza de forma continua y no solo cuando te acuerdas de comprobarlo.

• Todos tus informes en un solo lugar: En lugar de docenas de archivos XML independientes repartidos por la bandeja de entrada, todos los informes de todos los proveedores se agrupan en una única vista.
• Cobertura en todos los ámbitos: Para los equipos que gestionan más de un dominio, esa consolidación se extiende a toda la cartera, de modo que un único panel de control abarca todos los dominios de los que son responsables.
• Datos históricos, no solo instantáneas: El historial almacenado te permite hacer un seguimiento de tu tasa de éxito semana tras semana, confirmar que la solución aplicada a un remitente problemático ha surtido efecto y detectar un aumento gradual de la actividad sospechosa antes de que se convierta en un incidente.
• Filtrado y búsqueda: Aísla una fuente de envío específica o un tipo de fallo concreto, en lugar de revisar cada registro manualmente.
• Notificaciones sobre nuevos remitentes: Recibe una notificación cuando aparezca un nuevo remitente no autorizado, para que no tengas que esperar a la próxima revisión manual para detectarlo.
• Exportación preparada para auditorías: Genera informes exportables para revisiones de cumplimiento y para informar a las partes interesadas.

Qué hacer con tus informes DMARC

Leer el informe es el primer paso. Tomar medidas es lo que realmente protege tu dominio. Sigue estos pasos en el orden indicado cada vez que revises un nuevo lote de informes.

Corregir los remitentes legítimos que no pasan la verificación

Si un remitente que reconoces (tu proveedor de servicios de correo electrónico, CRM, servicio de asistencia técnica o plataforma de boletines informativos) muestra «dkim=fail» o «spf=fail»:

1. En caso de errores en el SPF: añade el rango de IP del remitente o incluye el mecanismo «include:» en tu registro SPF y, a continuación, vuelve a comprobarlo con nuestro comprobador de SPF.
2. En caso de errores de DKIM: pide al proveedor que active la firma DKIM personalizada para tu dominio y publica la clave que te faciliten; a continuación, compruébalo con nuestro comprobador de DKIM.

Identificar y supervisar a los remitentes desconocidos

Una dirección IP que no reconozcas y que envíe correo desde tu dominio podría ser una herramienta que un equipo haya adoptado sin decírselo a nadie, un servicio de reenvío legítimo o un intento activo de suplantación de identidad. Un volumen reducido de mensajes procedentes de una IP desconocida es habitual y supone un riesgo bajo. Un volumen elevado de mensajes procedentes de una IP desconocida es un claro indicio de suplantación de identidad, y ese es el caso en el que reforzar tu política para poner en cuarentena o rechazar los mensajes detiene de forma activa el abuso.

Realiza un seguimiento de tu tasa de aprobados a lo largo del tiempo

Tu tasa de superación de DMARC es el porcentaje de mensajes que superan la autenticación DMARC. Con el valor p=none, esto no afecta al envío, pero te indica en qué medida estás preparado para aplicar la política. Intenta alcanzar una tasa de superación superior al 95 % entre todos los remitentes legítimos, de forma sostenida, antes de endurecer tu política. Supervisa esta tasa semanalmente durante al menos dos a cuatro semanas, en lugar de reaccionar en función de los resultados de un solo día.

Decide cuándo ampliar tu póliza

Pasar a p=cuarentena cuando se cumplan las tres comprobaciones de preparación:

1. Todos los remitentes legítimos conocidos superan la comprobación DMARC.
2. En tus informes no aparecen remitentes con un volumen elevado de mensajes inesperado.
3. La tasa de aprobados se ha mantenido por encima del 95 % de forma constante.

Cambia a p=reject cuando esas mismas condiciones se mantengan durante una o dos semanas en cuarentena sin que surja ningún imprevisto. La progresión completa de la política se explica en nuestra guía de configuración de DMARC.

PowerDMARC automatiza todo este análisis. Nuestra plataforma realiza un seguimiento de los índices de aceptación, identifica a los remitentes por su nombre en lugar de por su dirección IP y te avisa en cuanto aparece un nuevo remitente no autorizado, de modo que la decisión sobre la idoneidad se toma por ti, en lugar de tener que reconstruirla a partir de datos XML sin procesar.

¿Por qué no recibo los informes DMARC?

Si has publicado un registro con el campo «rua=» establecido, pero no has recibido ningún informe, la causa suele ser, casi siempre, una de estas seis.

Problema 1: No hay ninguna etiqueta «rua=» en tu registro DMARC. Esta es la causa más habitual. Sin «rua=», has optado explícitamente por no recibir informes. Solución: añade «rua=mailto:[email protected]» a tu registro y compruébalo con nuestro verificador DMARC.

Problema n.º 2: Dirección de correo electrónico incorrecta o no válida. Un error tipográfico, una bandeja de entrada inexistente o un buzón lleno provocarán que los informes se descarten sin previo aviso. Solución: comprueba que la dirección rua= pueda recibir correo enviándole un mensaje de prueba.

Problema 3: Destino de notificación externo no autorizado. Si tu «rua=» apunta a una dirección de un dominio diferente al de tu registro DMARC (tu dominio es company.com, pero «rua=» apunta a [email protected]), el dominio externo debe publicar un registro de autorización en _report._dmarc.reportingservice.com que contenga «v=DMARC1». Sin él, los informes se descartan. La mayoría de las plataformas DMARC se encargan de esto automáticamente.

Problema n.º 4: Has publicado un nuevo registro, pero el DNS aún no se ha propagado. Los informes empiezan a llegar entre 24 y 48 horas después de que tu registro entre en vigor a nivel mundial, así que, para solucionar esto, confirma la propagación con nuestro comprobador de propagación de DNS.

N.º 5: Los informes están llegando a la carpeta de correo no deseado. Los informes se envían como archivos adjuntos comprimidos desde remitentes automáticos y, a menudo, son filtrados. Para solucionar esto, revisa tu carpeta de correo no deseado y añade a la lista blanca a los remitentes de los informes ([email protected], [email protected]).

N.º 6: Aún no se ha enviado ningún correo electrónico. Los informes solo se generan cuando tu dominio ha enviado realmente correos que han llegado a un proveedor. Si no se ha enviado nada desde que publicaste el registro, todavía no hay nada que informar.

RFC 9990: Norma sobre el informe agregado de 2026

A partir de mayo de 2026, el RFC 9990 regula el formato y el envío de los informes agregados de DMARC, asumiendo la función de generación de informes que antes correspondía a la RFC 7489. El esquema XML es compatible con versiones anteriores (los analizadores existentes y los informes que ya recibes siguen funcionando), y el principal cambio es la estandarización formal del formato de los informes y la periodicidad diaria. 

Para obtener un desglose completo de las últimas actualizaciones, puedes consultar nuestro guía sobre DMARC RFC 9989/9990/9991 . 

Preguntas frecuentes

¿Qué es un informe DMARC?

Un informe DMARC es un archivo XML diario que envían los servidores de correo receptores a la dirección indicada en la etiqueta «rua=», en el que se resumen todas las direcciones IP que han enviado correos electrónicos desde tu dominio y si las verificaciones SPF y DKIM han superado o no la comprobación en cada caso. Proveedores como Google, Microsoft y Yahoo los generan cada vez que reciben un correo que afirma proceder de tu dominio. Son la herramienta principal para supervisar el estado de autenticación del correo electrónico de tu dominio.

¿Cuál es la diferencia entre RUA y RUF en DMARC?

Los informes RUA (agregados) son resúmenes diarios en formato XML que recogen toda la actividad de correo electrónico de tu dominio. Los informes RUF (de error) son notificaciones de error por mensaje que pueden contener datos individuales de la cabecera del correo electrónico. La mayoría de los principales proveedores, entre ellos Google, Microsoft y Yahoo, ya no envían informes de error debido a restricciones de privacidad, por lo que los informes agregados son más habituales y compatibles a nivel mundial.

¿Con qué frecuencia se envían los informes DMARC?

La mayoría de los proveedores envían un informe agregado cada 24 horas. Dado que cada servidor de correo receptor envía su propio informe, recibirás uno de cada proveedor cuyos usuarios hayan recibido tu correo; por lo tanto, un dominio que envíe mensajes a usuarios de Gmail, Outlook y Yahoo debería esperar recibir al menos tres informes al día.

¿Cómo se lee un informe DMARC en formato XML?

Un informe XML de DMARC consta de tres secciones principales: «report_metadata» (quién lo envió y el periodo de tiempo), «policy_published» (tu registro DMARC tal y como se ha evaluado) y «records» (una entrada por cada IP remitente con sus resultados de SPF y DKIM). Para ver un ejemplo práctico, puedes consultar el ejemplo de XML que aparece más arriba en esta guía. Sin embargo, la mayoría de los equipos de TI utilizan un analizador automatizado que identifica a los remitentes por su nombre, en lugar de leer el XML sin procesar.

¿Por qué recibo informes DMARC de organizaciones que no reconozco?

Cualquier servidor de correo que reciba un correo electrónico que afirme proceder de tu dominio envía un informe si tienes configurado «rua=». Esto incluye a pequeños proveedores de servicios de Internet (ISP), pasarelas de correo corporativas y proveedores internacionales que utilicen tus destinatarios, no solo a Google y Microsoft. Recibir informes de organizaciones desconocidas es normal y simplemente significa que esos servidores han gestionado correo que parecía proceder de tu dominio.

• Acerca de
• Últimas publicaciones

Maitham Al Lawati

Experto en ciberseguridad, director general de PowerDMARC

Maitham es un emprendedor tecnológico, experto en ciberseguridad, CEO y fundador de PowerDMARC con más de 15 años de experiencia en el sector. Maitham posee un MBA Global por la Universidad de Manchester y varias certificaciones profesionales, entre ellas CISSP, CISM, CRISC e ISC2 CCSP.

Últimos comentarios de Maitham Al Lawati (ver todos)

• Cómo configurar DMARC: guía completa de configuración paso a paso (2026) - 20 de junio de 2026
• Cómo interpretar los informes DMARC: una guía completa sobre RUA y RUF - 10 de junio de 2026
• ¿Qué es DMARC? Definición, cómo funciona y por qué es importante - 28 de abril de 2026