Herramienta gratuita

Analizador de informes DMARC gratuito

Name: Analizador de informes DMARC
Author: DMARCTrust

Suelta un informe agregado y este analizador DMARC convierte el XML en bruto en un resumen legible: IP de origen, resultados SPF y DKIM, alineación y la acción que tomó cada receptor. Usa el mismo analizador de código abierto con el que leemos los informes reales de nuestros clientes. Tu informe nunca sale de tu navegador.

Suelta tu informe DMARC aquí

o haz clic para seleccionar un archivo

Analizar informe

Admite archivos .xml, .xml.gz y .zip

Listo para analizar

Análisis del informe

Total de mensajes

Tasa de aprobación DMARC

SPF

Aprobado Fallido

DKIM

Aprobado Fallido

Disposición de mensajes

Ninguna (entregado)

Cuarentena

Rechazado

Información del informe

Emisor del informe
Período del informe
Dominio del informe

Tu política DMARC

Política (p)
Política de subdominio (sp)
Política de subdominios inexistentes (np)
Porcentaje (pct)
Modo de prueba (t)
Método de descubrimiento
Alineación DKIM
Alineación SPF

Principales fuentes de envío

IP de origen	Mensajes	Aprobados	Fallidos	Métodos de autenticación

¿Qué es un informe DMARC agregado?

Un informe DMARC agregado, también llamado informe rua, es un archivo XML que un receptor de correo como Gmail, Microsoft o Yahoo te envía aproximadamente una vez al día por cada uno de tus dominios. Resume los mensajes que afirmaron ser de tu dominio ese día: qué direcciones IP los enviaron, si SPF y DKIM se superaron y alinearon, y qué hizo el receptor con el correo que falló. El formato nació en el Apéndice C de la RFC 7489. La RFC 9989 (DMARCbis) ahora reemplaza a la RFC 7489 como norma principal, y la RFC 9990 especifica el esquema del informe agregado: pct salió del registro, y se añadieron los elementos np, testing y discovery_method.

Hay dos tipos de informe DMARC, y este analizador lee uno de ellos. Los informes agregados (rua) son los resúmenes XML estadísticos diarios descritos arriba. Llevan recuentos, no el contenido de los mensajes. Los informes de fallos (ruf), anteriormente llamados informes forenses y ahora especificados en la RFC 9991, son un formato distinto, por mensaje, enviado en el momento en que un mensaje falla. Esta herramienta analiza informes agregados, que es lo que envía casi cualquier receptor y lo que necesitas para ver cómo se usa tu dominio.

DMARCbis, publicado en mayo de 2026, rehízo este conjunto a través de las RFC 9989, 9990 y 9991. Nuestra guía de DMARCbis repasa qué cambió.

Cómo leer un informe DMARC, campo por campo

Cada informe agregado es un elemento <feedback> con tres partes: quién envió el informe, la política que publicaste, y un registro por cada grupo de mensajes con el mismo resultado. Esto es lo que significa cada campo, en el orden en que los lee el analizador de arriba.

<report_metadata>, quién envió este informe y cuándo

org_name: El receptor que generó el informe, por ejemplo google.com.
email: El buzón emisor en ese receptor.
report_id: Un identificador único de este informe. Úsalo para deduplicar si guardas los informes tú mismo.
date_range / begin, end: La ventana de 24 horas que cubre el informe, en segundos Unix (epoch). El analizador los convierte en fechas legibles por ti.

<policy_published>, la política DMARC que tenías activa ese día

domain: El dominio al que se aplica la política.
p: Tu política principal: none, quarantine o reject. Es la evaluación que publicaste para el correo que no supera la autenticación DMARC.
sp: La política para subdominios, si configuraste una.
np: La política para subdominios inexistentes. La RFC 9989 (DMARCbis) añadió la etiqueta np al registro, y la RFC 9990 transporta su valor como elemento del informe. El analizador la muestra solo cuando está presente.
pct: El porcentaje de correo fallido al que se aplica la política. La RFC 9989 quitó pct del registro DMARC en favor de la etiqueta t (modo de prueba), así que el analizador muestra pct solo cuando un informe heredado todavía lo lleva, y nunca inventa un valor por defecto.
adkim / aspf: Modo de alineación DKIM y SPF: r es relaxed (los dominios organizativos deben coincidir), s es strict (los dominios completos deben coincidir).
testing: El elemento del informe que transporta el valor de la etiqueta t (modo de prueba) de la RFC 9989. Cuando es yes, el receptor evalúa DMARC pero no lo aplica, así que puedes observar antes de activar la política. Los informes siguen llegando mientras pruebas.
discovery_method: Un campo de informe de la RFC 9990 que indica cómo encontró el receptor tu política: psl (Public Suffix List) o treewalk (el nuevo DNS Tree Walk).

<record>, una fila por grupo de mensajes con el mismo resultado

Cada registro tiene cuatro bloques hijos. Los dos primeros llevan el veredicto; los dos últimos, la evidencia.

row / source_ip, count: La dirección IP que envió el correo y cuántos mensajes envió en este grupo. count es el número por el que multiplicas todo lo demás.
policy_evaluated / disposition: Lo que el receptor hizo realmente: none significa entregado, quarantine significa enviado a spam, reject significa bloqueado.
policy_evaluated / dkim, spf: El veredicto DMARC que el receptor ya calculó para cada mecanismo, pass o fail, tras la alineación. Es el resultado que decide si DMARC se superó.
identifiers / header_from: El dominio del encabezado From visible, la dirección que DMARC protege.
auth_results / dkim, spf: La comprobación SPF y DKIM en bruto (dominio, selector, resultado) antes de aplicar la alineación. Aquí es donde diagnosticas por qué un veredicto salió como salió. Con la RFC 9990, el selector DKIM es obligatorio siempre que se informe una firma DKIM.

Para el significado de cada etiqueta de la política que publicas (los valores p, sp, adkim, aspf de arriba), consulta nuestra guía de etiquetas DMARC, o crea un registro con el generador de registros DMARC.

Ejemplo práctico: un informe real, decodificado

Aquí tienes un informe sano leído línea por línea. Es una muestra sintética (las IP y el identificador de informe no son reales), pero tiene la forma exacta que envía Google. Suéltalo en el analizador de arriba y obtienes el resumen de abajo.

Un informe de muestra recortado (se muestra uno de dos registros):

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <report_id>14987236590123456789</report_id>
    <date_range><begin>1717200000</begin><end>1717286400</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim><aspf>r</aspf>
    <p>reject</p><sp>reject</sp><pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>198.51.100.41</source_ip>
      <count>128</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim><spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers><header_from>example.com</header_from></identifiers>
  </record>
</feedback>

Leído en palabras claras

google.com envió este informe para example.com, abarcando un día.
La política publicada es p=reject con alineación relaxed (adkim=r, aspf=r).
Registro uno: 198.51.100.41 envió 128 mensajes. DKIM y SPF se superaron y alinearon, así que DMARC se superó.
Registro dos (no mostrado arriba): 198.51.100.12 envió 47 mensajes, también todos aprobados.
Total: 128 + 47 = 175 mensajes, una tasa de aprobación DMARC del 100%.

Fíjate en que cada disposición es none aunque la política sea p=reject. Es correcto, no una contradicción. p=reject es la evaluación que un receptor aplica al correo que no supera DMARC. Aquí todos los mensajes pasaron, así que el receptor no tuvo motivo para actuar y los entregó con normalidad.

Un intento de suplantación de dominio se ve diferente. Verías un source_ip desconocido con dkim=fail y spf=fail en policy_evaluated, y como la política es reject, su disposición normalmente mostraría reject. Esa fila es correo que alguien envió en nombre de tu dominio y que el receptor bloqueó. Esas son las filas que conviene vigilar.

policy_evaluated frente a auth_results, lo que la mayoría de herramientas hace mal

Un informe lleva el resultado SPF y DKIM dos veces, y ambos no son lo mismo. Dentro de auth_results tienes la comprobación en bruto: si SPF autorizó la IP de envío, si la firma DKIM se verificó. Dentro de policy_evaluated tienes el veredicto DMARC: el receptor tomó ese resultado en bruto y además comprobó si el dominio autenticado se alinea con el dominio del encabezado From visible. DMARC se supera cuando SPF o DKIM se supera y se alinea con ese dominio From.

Por eso un SPF en bruto puede mostrar pass mientras DMARC igual falla. Un mensaje enviado por un reenviador o por un proveedor de correo masivo sin configurar puede superar el SPF simple en el propio dominio del proveedor, pero fallar DMARC porque ese dominio no se alinea con el tuyo. El veredicto alineado en policy_evaluated es el que decide el manejo, así que es el número que cuenta este analizador.

Somos precisos sobre lo que hace la herramienta: informa el veredicto alineado que el receptor ya calculó en policy_evaluated. No vuelve a ejecutar la alineación sobre tus resultados en bruto. Eso coincide con la RFC 7489 Sección 7.2 (recogida en la RFC 9989), donde es el receptor quien evalúa la alineación de identificadores, no el lector del informe.

¿Por qué usar un analizador de informes DMARC?

Verifica tus fuentes de correo

Comprueba qué direcciones IP envían correo en nombre de tu dominio y si están autorizadas para ello.

Supervisa SPF y DKIM

Sigue las tasas de aprobación para que tu correo real siga autenticado a medida que avanzas hacia p=reject.

Detecta la suplantación

Localiza remitentes desconocidos que intentan enviar correo en nombre de tu dominio, y confirma que tu política está cumpliendo su función.

100% en tu navegador, no se sube nada

Tu informe nunca sale de tu equipo. El analizador lee el archivo con el DOMParser integrado de tu navegador y descomprime los archivos .gz y .zip en memoria con fflate. No hay subida, ni ida y vuelta al servidor, ni registro. El analizador no hace ninguna llamada de red, algo que puedes comprobar tú mismo: es de código abierto con licencia MIT. Esa es la diferencia entre esta herramienta y los analizadores que te piden subir primero un informe a sus servidores.

¿Quieres monitoreo DMARC automatizado?

Leer un informe a mano está bien. Cada día llegan informes nuevos de cada receptor, y eso no escala. DMARCTrust los recopila, analiza y registra por ti de forma automática, con este mismo analizador en el servidor.

Empezar monitoreo gratis Crear un registro DMARC Crear un registro SPF

Código abierto y autoalojable

El motor de este analizador es de código abierto con licencia MIT, y es el mismo analizador que lee los informes reales de nuestros clientes. Funciona por completo en tu navegador, así que tus informes nunca salen de tu equipo. Revisa el código, alójalo en tu propia infraestructura o envía una pull request.

Ver en GitHub

Preguntas frecuentes

¿Están seguros los datos de mi informe DMARC?

Sí. El analizador funciona por completo en tu navegador. Tu informe se lee de forma local con el DOMParser integrado y nunca se sube, registra ni envía a ningún servidor.

¿Qué formatos de archivo puedo analizar?

.xml sin comprimir, .xml.gz o .gz comprimidos con gzip, y archivos .zip. Dentro de un .zip se usa el primer archivo XML. El límite de tamaño es de 10 MB, mucho mayor que cualquier informe agregado real.

¿Qué contiene un informe DMARC agregado?

Un resumen diario del correo que afirma ser de tu dominio: el receptor que lo emite y el período, la política que publicaste, y un registro por cada grupo de mensajes con el mismo resultado, cada uno con la IP de origen, el número de mensajes, los veredictos SPF y DKIM, y la disposición que aplicó el receptor.

¿Cómo abro un informe DMARC .gz o .zip?

Suelta el archivo directamente en el analizador tal como llegó a tu bandeja de entrada. Descomprime los .gz y .zip en tu navegador de forma automática, así que no necesitas descomprimirlo antes.

¿Por qué la disposición es none cuando mi política es reject?

Porque p=reject es la evaluación que un receptor aplica solo al correo que no supera la autenticación DMARC. Un mensaje que superó SPF o DKIM y está alineado supera DMARC, así que el receptor lo entrega y registra la disposición como none. Solo verás reject en las filas que realmente fallaron.

¿Cuál es la diferencia entre informes agregados y informes de fallos?

Los informes agregados (rua) son resúmenes XML estadísticos diarios con recuentos, no el contenido de los mensajes. Los informes de fallos (ruf), anteriormente llamados informes forenses y ahora especificados en la RFC 9991, son un formato distinto, por mensaje. Este analizador lee informes agregados, que es lo que envía casi cualquier receptor.

¿Por qué SPF aparece como pass en auth_results pero DMARC igual falla?

auth_results contiene la comprobación SPF en bruto, que puede superarse en el propio dominio de un proveedor de envío. DMARC también exige alineación con el dominio de tu encabezado From. Si el dominio que pasa no se alinea con el tuyo, DMARC falla. El veredicto alineado en policy_evaluated es el que cuenta.

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

Por lo general una vez al día por dominio y por cada receptor, por ejemplo un informe diario de Google y otro de Microsoft. DMARCbis (RFC 9989 §8) ahora recomienda un intervalo diario y eliminó la antigua etiqueta ri, aunque un receptor puede informar con más o menos frecuencia. Como llegan informes cada día de cada receptor, leerlos a mano deja de ser viable rápidamente, y eso es lo que resuelve el monitoreo automatizado.

Protege la reputación de tu correo

El monitoreo DMARC no tiene por qué ser complicado. Déjanos gestionar los detalles técnicos mientras te concentras en tu negocio.

Iniciar monitoreo Ver precios