Cómo leer tu primer reporte DMARC, línea por línea

Un reporte agregado de DMARC es un resumen que los proveedores grandes de correo le envían a la dirección que pusiste en tu registro DMARC, normalmente una vez al día. Dice qué servidores, identificados por su dirección IP, enviaron correo con tu dominio a ese proveedor, cuántos mensajes mandó cada uno y si pasaron SPF y DKIM. Para leerlo, abre el archivo adjunto en un lector de reportes y clasifica cada fila en uno de cuatro grupos: tu propio correo, servicios que todavía no autorizaste, reenvíos y desconocidos.

De dónde salen los reportes

Cuando tu registro DMARC trae una etiqueta como rua=mailto:dmarc@example.com, los receptores que hacen reportes le mandan reportes agregados a esa dirección. Cada receptor grande envía el suyo, casi siempre uno al día. Llegan como un correo con un adjunto comprimido, por lo general .zip o .gz, que contiene un archivo XML: un formato de texto pensado para máquinas, con etiquetas entre signos de menor y mayor. No todos los receptores envían reportes, y el que no vio correo tuyo ese día normalmente no manda nada.

Un reporte trae conteos, direcciones IP, dominios y resultados. No trae el texto de los mensajes, ni asuntos, ni a quién iban dirigidos. Si todavía no has publicado DMARC, empieza por Cómo configurar DMARC en un día.

Abre el reporte

1. Guarda el adjunto. No hace falta descomprimirlo.
2. Arrastra el archivo .xml, .xml.gz o .zip al lector de reportes DMARC. Lo descomprime y lo lee en tu navegador, un reporte a la vez, y no sube nada.
3. Mira el resumen: qué organización envió el reporte, el rango de fechas y tu política publicada, tal como la vio el receptor.
4. Mira los totales: mensajes que pasaron, que fueron a cuarentena, que fueron rechazados y que fallaron SPF y DKIM a la vez.
5. Revisa la lista de IP que fallaron las dos. Por ahí empiezas a investigar.
6. Recorre la tabla completa: por cada registro, la IP, el conteo, SPF, DKIM, la disposición y el dominio del "De".

Las partes del reporte, en palabras simples

El formato está definido en el RFC 9990, sección 3.1.1 (de 2026; las guías más antiguas citan el RFC 7489, al que reemplazó). Una revisión está alineada cuando el dominio que verificó coincide con el dominio del "De" visible; en el modo normal, llamado relajado, un subdominio también cuenta.

Parte	Qué significa
report_metadata	Quién envió el reporte (org_name y un email de contacto), un report_id y el date_range, con inicio y fin en segundos desde el 1 de enero de 1970, en hora UTC.
policy_published	Tu registro DMARC tal como lo encontró el receptor: domain, p (la política), sp (la política para subdominios) y adkim/aspf (modo de alineación: r relajado o s estricto). Los reportes nuevos agregan testing (y mientras tu registro diga t=y); los antiguos muestran pct (el porcentaje del correo que falla al que se aplicaba la política).
record	Un grupo de mensajes con el mismo origen y los mismos resultados. Una IP puede aparecer en varios registros.
row: source_ip, count	La IP del servidor que le entregó el correo al receptor, y cuántos mensajes hay en el grupo.
policy_evaluated: disposition	Lo que hizo el receptor: none (ninguna acción por DMARC; el filtro de spam normal sigue funcionando), quarantine (normalmente a spam) o reject (rechazado).
policy_evaluated: dkim, spf	El veredicto de DMARC: pass solo si la revisión pasó y además quedó alineada. A veces aparece un reason, como forwarded o local_policy, que explica por qué el receptor no aplicó tu política.
identifiers: header_from	El dominio del "De" visible.
auth_results	Los resultados en bruto, antes de la alineación: para DKIM, el dominio que firmó, el selector y el resultado; para SPF, el dominio revisado y el resultado.

Las dos últimas partes responden preguntas distintas. auth_results dice si una revisión pasó y para qué dominio; policy_evaluated dice si contó para el tuyo. Las columnas SPF y DKIM del lector salen de policy_evaluated, y un registro cuenta como aprobado cuando cualquiera de las dos dice pass. Para ver el auth_results de una fila, abre el XML en un editor de texto y busca su IP.

Por qué tus propios servicios aparecen fallando

La app de facturación, la herramienta de boletines o la tienda en línea muchas veces envían correo con tu dirección en el "De", pero desde sus propios servidores. Mientras no los autorices, SPF falla, o pasa solo para el dominio de rebotes del servicio, y la firma DKIM sale con el dominio del servicio y no con el tuyo. En auth_results las dos pueden decir pass, pero para app-facturas.example, no para tu dominio. Nada queda alineado, así que policy_evaluated muestra fail en las dos, y con p=reject ese correo se rechazaría.

El arreglo está en la configuración del servicio, casi siempre con un nombre como "autenticar dominio" o "dominio de envío". Te da registros DKIM para tu dominio y a veces un include para SPF. Después de eso, sus filas muestran DKIM en pass.

¿Reenvío o suplantación?

Cuando alguien reenvía el correo de una dirección a otra, o una lista de correo lo vuelve a enviar, el receptor final lo recibe desde el servidor que reenvía, que no está en tu SPF. Por eso SPF falla. Las pistas:

• SPF falla, DKIM pasa. DMARC pasó. Casi siempre es un reenvío, que conserva la firma DKIM si no se modifica el mensaje, o un servicio que firma con tu dominio pero usa su propia dirección de rebotes. No hay nada que hacer.
• Fallan las dos, pero auth_results muestra un resultado DKIM de tu propio dominio. Tú firmaste el mensaje y algo lo cambió en el camino, muchas veces una lista de correo que agrega un pie de página o edita el asunto. Suelen ser pocos mensajes.
• Fallan las dos, no hay DKIM de tu dominio y la IP no te suena. Alguien está enviando a tu nombre. No hay nada que arreglar de tu lado: p=reject es lo que lo frena.

Para saber quién maneja una IP, escríbela en la consulta DNS para hacer una búsqueda inversa, que devuelve el nombre que la red le dio a esa dirección, si tiene. La consulta va de tu navegador al resolvedor DNS público de Cloudflare. Un nombre de un proveedor de correo o de un servicio que usas apunta a un reenvío o a una herramienta olvidada; un nombre genérico de hosting, o ninguno, es más sospechoso. Es una pista, no una prueba.

Un ejemplo completo

El reporte de un día para tienda-ejemplo.co, publicado con p=none. El lector muestra 477 mensajes: 418 aprobados (88 %), ninguno en cuarentena ni rechazado, y 59 (12 %) que fallaron las dos revisiones, desde dos IP.

IP, mensajes	SPF / DKIM	Qué es	Qué hacer
198.51.100.20, 412	pass / pass	Tu proveedor de correo	Nada.
198.51.100.77, 38	fail / fail	Tu app de facturación; auth_results muestra un pass para app-facturas.example	Activar la autenticación de dominio.
192.0.2.140, 6	fail / pass	Un cliente que reenvía tu correo a otro buzón	Nada.
203.0.113.9, 21	fail / fail	Un servidor de hosting que no usas, sin DKIM de tu dominio	Nada que arreglar; avanzar hacia reject.

Otra fila común: SPF en pass pero DKIM en fail desde tu propio proveedor de correo casi siempre significa que ahí no has activado DKIM para tu dominio.

De p=none a reject

Con p=none, la disposición es none en todas las filas: los receptores solo observan y reportan. El plan completo está en Cómo configurar DMARC en un día. En resumen:

1. Lee reportes durante al menos dos semanas, de varios receptores.
2. Arregla cada fuente legítima hasta que solo fallen reenvíos y desconocidos. El verificador de seguridad de correo confirma tus registros SPF, DKIM y DMARC después de cada cambio.
3. Cambia a p=quarantine. Las filas que fallan ahora muestran quarantine; revisa que ninguna sea tuya.
4. Después de unas semanas tranquilas, cambia a p=reject. Las filas que fallan ahora muestran reject.
5. Sigue leyendo reportes, al menos una vez al mes, y configura DKIM en cada servicio nuevo antes de que envíe.

Cada receptor igual toma su propia decisión: una fila que falla puede mostrar una disposición más suave que tu política, con un motivo como forwarded.

Lista de revisión

• Un buzón para los reportes rua que alguien revisa cada semana.
• Cada reporte abierto en el lector: resumen, totales e IP que fallan.
• Cada IP que falla las dos revisiones, identificada.
• Cada servicio legítimo firmando DKIM con tu dominio.
• Los reenvíos reconocidos y sin tocar.
• Quarantine y luego reject, cuando solo fallen desconocidos.

Preguntas frecuentes

¿Por qué me llegan varios reportes al día?

Cada receptor que vio correo de tu dominio manda su propio reporte, y cada uno cubre solo lo que ese receptor vio.

Los números no cuadran con lo que envié. ¿Por qué?

Un reporte cuenta solo el correo que vio un receptor, incluidos reenvíos y correos falsos. Los receptores que no envían reportes no aparecen.

¿También debo pedir reportes de fallas (ruf)?

Los reportes de fallas describen mensajes sueltos que fallaron y pueden incluir partes de ellos. Muchos proveedores grandes no los envían, así que la mayoría de dominios se apoya en los reportes agregados.

¿Es seguro abrir un reporte en el lector?

Sí. El archivo se descomprime y se lee en tu navegador, y no se sube nada. Un reporte trae IP, conteos y dominios, no el contenido de los mensajes.

Pruébalo

• 2.7Lector de reportes DMARCAbre un reporte agregado de DMARC (.xml, .xml.gz o .zip) y mira, por cada IP que envió, cuántos mensajes pasaron o fallaron SPF y DKIM.
• 2.2Seguridad de correoRevisa el SPF, DKIM, DMARC, MTA-STS, BIMI y DNSSEC de un dominio y obtén registros DNS listos para copiar para lo que falte.
• 2.4Consulta DNSConsulta los registros DNS de cualquier dominio (A, AAAA, CNAME, MX, TXT, NS, SOA, CAA, SRV) o el DNS inverso de una IP, con TTL y validación DNSSEC.