Monitorización DMARC: cómo leer tus informes y llegar a p=reject con seguridad
Más de la mitad de los dominios con registro DMARC no recogen ningún informe. Así funciona la monitorización DMARC, así se lee un informe agregado, qué cambió la RFC 9990 en 2026 y cómo llegar a p=reject sin bloquear tu propio correo.
Ejecuta la misma comprobación ahora — gratis
Introduce tu dominio y obtén una auditoría de 9 puntos — DNS, SPF/DKIM/DMARC, SSL, cabeceras de seguridad, exposición en dark web — en 60 segundos.
Sin registro · <60s · Procesamiento GDPR/UE
La monitorización DMARC consiste en recoger y leer los informes agregados que los receptores de correo envían a tu dominio cada día, para que veas exactamente quién envía correo en tu nombre antes de cambiar tu política a quarantine o reject. Se activa añadiendo una etiqueta rua=mailto: a tu registro DMARC. Entre 24 y 48 horas después, proveedores como Google, Microsoft 365 y Yahoo empiezan a enviarte archivos XML comprimidos que resumen cada mensaje que decía venir de tu dominio. Esos archivos son la única evidencia que vas a tener, y sin ellos pasar a modo de aplicación es adivinar.
Qué es realmente la monitorización DMARC
DMARC (Domain-based Message Authentication, Reporting and Conformance) hace dos cosas. La mitad de política indica a los receptores qué hacer con el correo que no supera la autenticación. La mitad de informes te indica a ti qué están viendo los receptores. La monitorización es esa segunda mitad, y es la que casi todos los propietarios de dominios se saltan.
El mecanismo es sencillo. Cuando un proveedor receptor evalúa correo que declara tu dominio en el From, cuenta los resultados. Al final de cada día UTC empaqueta esas cuentas en un archivo XML y lo envía a la dirección de tu etiqueta rua=. La RFC 9990, sección 3.1.1.4, establece que el periodo de informe abarca un único día UTC que empieza a las 00:00 UTC. Por eso tu primer informe llega entre 24 y 48 horas después de publicar la etiqueta, y no de inmediato.
Los informes van comprimidos con gzip y son pequeños. Los tamaños medidos por proveedor oscilaron entre 3,6 kB y 4,8 kB (Google 3.962 bytes, Yahoo 4.626, Fastmail 4.839) en el conjunto de datos publicado por Ashiq y otros en USENIX Security 2023. El almacenamiento nunca es el problema. El volumen sí: un dominio con mucho tráfico puede recibir cientos de archivos al día, y por eso casi nadie los lee a mano.
Más de la mitad de los dominios DMARC vuelan a ciegas
Distribución de políticas DMARC entre los 1.670.975 dominios que publican un registro. Fuente: DMARCguard, State of Email Authentication 2026, análisis de 5.499.028 dominios de Tranco, 27 de febrero de 2026.
Ese mismo análisis encontró que solo 894.057 de esos 1.670.975 dominios (53,5 %) publican una etiqueta rua=. Los otros 776.918 tienen política y ninguna telemetría.
La consecuencia se ve en el reparto de políticas de arriba. El 57,9 % de los dominios con DMARC, 967.474 de ellos, siguen en p=none. El modo de solo monitorización está pensado como estación de paso, no como destino, y el motivo de que tantos no salgan de ahí es simple: sin informes no hay nada en lo que basar la decisión.
El riesgo no es teórico. El Internet Crime Complaint Center del FBI registró 2.770 millones de dólares en pérdidas por Business Email Compromise repartidas en 21.442 denuncias en su informe anual de 2024. En el otro platillo de la balanza: tras aplicar Google y Yahoo los requisitos de autenticación para remitentes masivos en febrero de 2024, Gmail declaró 265.000 millones de mensajes sin autenticar menos ese año (Neil Kumaran, Group Product Manager, Gmail Security and Trust, octubre de 2024).
Cómo activar los informes
Añade una etiqueta rua= al registro TXT en _dmarc.tudominio.com:
v=DMARC1; p=none; rua=mailto:informes-dmarc@tudominio.com; fo=1
Comprueba lo que hay publicado con una consulta DNS:
dig +short TXT _dmarc.tudominio.com
Tres reglas que conviene conocer antes de tocar el DNS:
- Un solo registro. La RFC 9989 exige exactamente un registro TXT DMARC por dominio. Si publicas dos, los receptores no aplican ninguna política, lo que desactiva DMARC en silencio.
- Sin
rua=no hay informes. Los receptores no deben generar retroalimentación agregada sin la etiqueta. No existe otra vía. - La cobertura es parcial por diseño. La documentación de Microsoft, actualizada el 14 de mayo de 2026, indica que no todos los receptores envían informes y que la cobertura suele situarse entre el 70 y el 90 por ciento del volumen total. Apple iCloud y Proton no están documentados como emisores de informes.
Enviar los informes a otro dominio
Si tu dirección rua= está en un dominio organizativo distinto al de la política, ese dominio receptor tiene que autorizarlo. La RFC 9990, sección 4, exige un registro TXT en <tu-dominio>._report._dmarc.<dominio-de-informes> que contenga v=DMARC1;. Sin él, los receptores dejan de enviar en silencio. Esta es la causa individual más frecuente de que una etiqueta rua= bien escrita no produzca ningún informe.
Informes agregados frente a informes de fallo
| Informes agregados (RUA) | Informes de fallo (RUF) | |
|---|---|---|
| Especificación | RFC 9990 | RFC 9991 |
| Frecuencia | Una vez por día UTC y proveedor | Casi en tiempo real, por mensaje |
| Contenido | Recuentos por IP de origen con alineación SPF y DKIM y la disposición aplicada | Detalles de un mensaje fallido, posiblemente con cabeceras y cuerpo |
| Privacidad | Recuentos agregados, sin contenido de mensajes | La RFC 9991 advierte de que pueden contener datos personales |
| Soporte de proveedores | Amplio: Google, Microsoft 365, Yahoo, Mail.ru, Fastmail, Zoho | Escaso. Microsoft 365 no los envía ni con un ruf= válido |
| Mejor uso | Construir el inventario de remitentes y decidir cuándo endurecer | Diagnosticar un fallo concreto que puedes reproducir |
Empieza por RUA. Casi todo lo que necesitas para llegar a p=reject con seguridad está en los datos agregados, y no arrastra la carga de privacidad de los informes de fallo.
Leer un informe: los cuatro resultados que importan
Cada bloque <record> del XML relaciona una IP de origen con un recuento de mensajes, los resultados brutos de SPF y DKIM y un veredicto policy_evaluated. Lo que importa es la alineación, no la autenticación en bruto. SPF o DKIM tiene que pasar y coincidir con tu dominio del From para que DMARC pase.
| SPF alineado | DKIM alineado | Qué significa | Qué hacer |
|---|---|---|---|
| Pasa | Pasa | Sano. Tu propia infraestructura, bien configurada | Nada. Este es el estado objetivo para cada remitente legítimo |
| Pasa | Falla | El remitente está autorizado pero no firma, o firma con su propio dominio | Activa DKIM en ese servicio y alinea el dominio d= con el tuyo |
| Falla | Pasa | Casi siempre reenvío o una lista de correo. DMARC pasa igualmente | Sin riesgo. No añadas el reenviador a tu registro SPF |
| Falla | Falla | O un remitente legítimo que olvidaste, o suplantación | Identifica la IP. Autorízala, o deja que se bloquee al endurecer |
La tercera fila es la que más se malinterpreta. El reenvío rompe SPF por diseño, porque el remitente del sobre cambia en el salto de reenvío. Precisamente por eso DKIM importa como respaldo, y por eso el 43,0 % de los dominios DMARC que dependen solo de la alineación SPF (DMARCguard, febrero de 2026) son más frágiles de lo que parecen.
Qué cambió en 2026: RFC 9989, 9990 y 9991
En mayo de 2026 el IETF publicó las RFC 9989, 9990 y 9991. Juntas dejan obsoleta la RFC 7489 y llevan DMARC a la vía de estándares como Proposed Standard por primera vez desde 2015, con los informes separados en documentos propios.
| Elemento | RFC 7489 (2015) | RFC 9989 / 9990 (2026) | Qué deberías hacer |
|---|---|---|---|
Etiqueta pct | Admitida, para despliegue parcial | Eliminada | Deja de depender de ella. Usa el nuevo modo de prueba t=y |
Etiquetas rf y ri | Definidas | Eliminadas | Bórralas en tu próxima edición de DNS |
| Descubrimiento del dominio organizativo | Public Suffix List | Recorrido del árbol DNS | Nada. Es un cambio del lado del receptor |
| Espacio de nombres XML | http://dmarc.org/dmarc-xml/0.1 | urn:ietf:params:xml:ns:dmarc-2.0 | Tu analizador debe aceptar ambos |
Campo DKIM selector | Opcional | Obligatorio | Corrige generadores o analizadores que lo omitan |
Valores de disposition | none, quarantine, reject | Añade pass | Gestiona el nuevo valor en lugar de rechazar el archivo |
| Elementos desconocidos | Sin definir | Ignóralos y continúa (RFC 9990 sección 5) | Nunca rechaces un informe que no entiendes del todo |
Tu registro actual sigue funcionando. Las etiquetas v=, p=, sp=, rua=, ruf=, adkim=, aspf= y fo= conservan su significado. En la práctica todos los grandes proveedores siguen emitiendo XML con la forma antigua, así que cuenta con una ventana mixta de varios años y analiza con tolerancia, no con rigidez.
Un despliegue seguro en cuatro fases hasta p=reject
- Semanas 1 y 2. Publica
p=noneconrua=. No cambies nada más. Recoge informes y arma una lista de cada IP y servicio que envía en tu nombre. - Semanas 3 a 6. Arregla la alineación. Añade los remitentes que faltan a SPF, activa DKIM en todas partes y confirma que cada servicio de terceros firma con tu dominio y no con el suyo.
- Semanas 7 y 8. Pasa a
p=quarantine, si quieres empezando por un subdominio consp=. Vigila los informes una semana entera por si se te escapó algún remitente legítimo. - Semana 9 en adelante. Pasa a
p=rejecty manténrua=de forma permanente. La monitorización no es un andamio que se retira al terminar la obra.
Correr en la fase uno es el fallo clásico. Una facturación trimestral o una campaña anual no aparecen en dos semanas de datos, y rebotarán el día que endurezcas la política.
Preguntas frecuentes
¿Con qué frecuencia se envían los informes DMARC?
Una vez por día UTC y proveedor que informa, cubriendo una ventana que empieza a las 00:00 UTC (RFC 9990, sección 3.1.1.4). Tu primer informe suele llegar entre 24 y 48 horas después de publicar rua=.
¿Por qué no recibo ningún informe?
Lo más habitual es que la dirección rua= esté en otro dominio y falte el registro de autorización obligatorio en <tu-dominio>._report._dmarc.<dominio-de-informes>. Otras causas: un error de sintaxis en el registro DMARC, dos registros DMARC publicados a la vez, o simplemente que nadie envió correo declarando tu dominio en ese periodo.
¿Es legítimo el informe DMARC de mi bandeja de entrada?
Casi con total seguridad. Los informes auténticos usan el patrón de asunto Report Domain: <dominio> Submitter: <emisor> Report-ID: <id> y adjuntan XML comprimido con un nombre de archivo separado por signos de exclamación. Un informe real no contiene enlaces, ni peticiones de pago, ni solicitudes de credenciales.
¿Sigo necesitando monitorización después de llegar a p=reject? Sí. Se añaden servicios nuevos, se edita el DNS, se rotan claves DKIM. Los informes son la forma de enterarte de que algo se ha roto antes que tus clientes.
¿Puedo borrar los informes sin más?
Puedes quitar rua= para detenerlos, pero cambias una bandeja desordenada por cero visibilidad sobre quién suplanta tu dominio. Apuntar rua= a un analizador es mejor respuesta.
Comprueba tu configuración en 60 segundos
Antes de tocar el DNS conviene saber exactamente dónde estás. El análisis gratuito de FortifyNet lee tus registros DMARC, SPF y DKIM y te dice si los informes están realmente configurados, si tu política está en modo de aplicación y qué falta. Tarda alrededor de un minuto y no requiere registro. Ejecuta un análisis gratuito en FortifyNet.
Guías relacionadas: Cómo configurar DMARC paso a paso · ¿Qué es DKIM? · Verificador de registros SPF · Configuración de seguridad DNS
