Los informes DMARC muestran parte del correo observado por destinatarios participantes: IP de origen, autenticación, alineación y tratamiento. Ayudan a investigar suplantación y errores de proveedores, y aportan datos para evaluar una política restrictiva, sin demostrar por sí solos que sea seguro activarla.
Publicar un registro y dirigir rua= a un buzón no basta. Si nadie analiza el XML, los problemas quedan sin investigar. Para revisar las bases, consulta correo empresarial para pequeñas empresas y correo con dominio propio. Después contrasta los informes con tu inventario: no incluyen necesariamente todos los emisores ni todo el tráfico.
Recoge los informes, identifica los sistemas, corrige la alineación y estudia los reenvíos. Si DKIM pasa alineado, DMARC puede aprobar, pero no conviene ignorar la ruta sin verificarla. Endurece la política con pruebas, no solo con porcentajes favorables.
Qué son los informes DMARC
Los destinatarios participantes envían información tras evaluar mensajes que declaran tu dominio como remitente. Incluye autenticación, alineación, IP de origen y decisiones de política, útil para seguridad y entregabilidad con una cobertura parcial.
Existen dos categorías principales.
Los informes agregados se solicitan normalmente con rua y llegan como resúmenes XML. Agrupan tráfico por destinatario, IP, resultados y disposición. Permiten investigar si Google Workspace, Microsoft 365, SendGrid, Mailchimp, una aplicación u otro servidor envían con tu dominio, sin identificar automáticamente al responsable de cada IP.
Los informes de fallos, solicitados con ruf, pueden aportar detalles de mensajes según los desencadenantes configurados y la implementación, no necesariamente solo fallos DMARC. El soporte es limitado y la privacidad restringe su contenido. Utilízalos como señal adicional, no como base única del proceso.
Los informes ayudan a responder:
- ¿Qué fuentes observadas envían con mi dominio?
- ¿Pasa SPF o DKIM y está alineado?
- ¿Qué tráfico observado se pone en cuarentena o se rechaza?
- ¿Qué podría verse afectado por
p=quarantineop=reject?
Cómo funcionan los informes DMARC
Publicas un TXT en _dmarc.yourdomain.com con la política y los destinos de informes. Los destinatarios que participan pueden enviar los datos allí. Un destino externo puede requerir autorización DNS del dominio receptor; comprueba esa configuración.
Este ejemplo utiliza supervisión con alineación estricta opcional:
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100"Solicita supervisión e informes agregados a dmarc@example.com. Las opciones adkim=s y aspf=s exigen coincidencia exacta de dominio. Son opcionales y pueden afectar a emisores que funcionan con alineación relajada entre subdominios del mismo dominio organizativo; no son la mejor opción universal.
Etiquetas importantes:
v=DMARC1: versión obligatoria.p=: tratamiento solicitado para fallos DMARC.rua=: destino de informes agregados.ruf=: destino de informes de fallos.pct=: porcentaje solicitado de aplicación a mensajes que fallan; no todos los destinatarios lo respetan igual.adkimyaspf: modo de alineación DKIM y SPF.
RFC 7489 define formato y lógica de política. Por eso los informes suelen llegar como XML comprimido, no como un panel legible directamente.
Qué contienen los informes agregados
Resumen el tráfico observado por organización informante, IP, cantidad, autenticación y disposición. Distingue los resultados SPF y DKIM sin procesar de los resultados evaluados para la política, que incorporan la alineación.
Suelen incluir:
- El destinatario informante, como Google o Microsoft.
- El periodo cubierto.
- La IP de origen.
- La cantidad de mensajes observados.
- Si SPF pasó.
- Si DKIM pasó.
- Si SPF se alineó con el From visible.
- Si DKIM se alineó con el From visible.
- La disposición DMARC: none, quarantine o reject.
No todo fallo SPF implica una configuración defectuosa: el reenvío cambia la IP. Si DKIM conserva los datos firmados, pasa y está alineado, DMARC puede aprobar.
Destinatario: gmail.com
IP de origen: 198.51.100.24
Cantidad: 842
From de cabecera: example.com
SPF: fail
DKIM: pass
DMARC: pass
Disposición: none
Es compatible con un reenvío que conserva DKIM. Comprueba la ruta y la alineación; la autenticación válida no demuestra que el contenido sea seguro o legítimo.
Destinatario: outlook.com
IP de origen: 203.0.113.77
Cantidad: 314
From de cabecera: example.com
SPF: fail
DKIM: fail
DMARC: fail
Disposición: quarantine
Investiga este patrón: puede ser un emisor legítimo mal configurado, un proveedor nuevo, modificaciones de intermediarios o suplantación. El informe no permite elegir automáticamente una causa.
Informes agregados frente a informes de fallos
Los agregados aportan una visión amplia pero parcial de fuentes y destinatarios participantes. Los de fallos ofrecen detalles de mensajes cuando están disponibles. Ninguno sustituye el inventario, las pruebas ni la revisión de flujos críticos poco frecuentes.
| Tipo | Solicitud | Datos | Uso principal | Situación en 2025-2026 |
|---|---|---|---|---|
| Agregado | rua=mailto:... | Resúmenes XML, habitualmente diarios, por fuente, autenticación y disposición | Inventario observado, alineación y evaluación de políticas | La base de datos habitual de muchos equipos |
| Fallos / forense | ruf=mailto:... | Detalles de mensajes, a menudo parciales o censurados | Investigar errores o abuso concretos | Soporte irregular; muchos destinatarios grandes envían pocos o ninguno |
Al valorar un proveedor de análisis, comprueba que explique la diferencia y permita actuar sobre los resultados, no solo mostrar gráficos.
Cómo leer los informes sin perder tiempo
Empieza por las fuentes de mayor volumen, relaciona cada una con sistemas conocidos y corrige fallos legítimos. No descartes fuentes pequeñas si corresponden a procesos críticos o poco frecuentes.
Procedimiento recomendado:
- Revisa las fuentes de mayor volumen observado.
- Identifica el sistema: Google Workspace, Microsoft 365, marketing, aplicación, soporte o fuente todavía desconocida.
- Comprueba que SPF o DKIM pase con alineación al From visible.
- Corrige los fallos legítimos antes de cambiar la política.
- Investiga las fuentes desconocidas antes de clasificarlas como abuso: pueden ser reenvíos o relays compartidos.
Priorizar volumen ayuda, pero una factura ocasional o un mensaje de recuperación también puede ser esencial. Combina el informe con la importancia de cada flujo.
| Patrón observado | Posible explicación | Acción |
|---|---|---|
| SPF pass, DKIM pass, DMARC pass | Autenticación alineada válida | Documentar la fuente; no implica contenido seguro |
| SPF fail, DKIM pass, DMARC pass | Reenvío o diferencia en la ruta SPF | Verificar DKIM alineado y su conservación |
| SPF pass, DKIM fail, DMARC pass | SPF alineado permite aprobar pese al fallo DKIM | Investigar y corregir DKIM |
| SPF fail, DKIM fail, DMARC fail | Abuso, configuración o modificaciones de ruta | Investigar el origen y el mensaje |
| IP desconocida con volumen | Servicio no inventariado, relay, reenvío o abuso | Identificarla antes de considerar medidas de bloqueo |
Las correcciones pueden consistir en:
- Añadir la autorización SPF adecuada de un emisor legítimo.
- Activar y comprobar DKIM en el proveedor.
- Configurar un return-path propio cuando ayude a la alineación SPF.
- Usar un subdominio para separar un servicio según tus necesidades.
- Revisar los reenvíos y preservar firmas, sin depender solo de SPF.
Estas consultas ayudan a revisar lo publicado:
dig TXT _dmarc.example.com +short
dig TXT example.com +short
dig TXT selector1._domainkey.example.com +shortSi hay errores DNS, consulta los registros DNS necesarios y la guía de mensajes que llegan al spam de TrekMail, sin atribuir todos los problemas al XML.
Problemas que pueden revelar los informes
Los informes ayudan a detectar autenticación incompleta de proveedores, falta de alineación, modificaciones de reenvíos y políticas sin seguimiento. Contrástalos siempre con la configuración real.
Un servicio recién añadido puede enviar con tu dominio sin haber terminado SPF o DKIM. Una IP desconocida es una pista para investigar, no una prueba de falsificación.
Otro caso es SPF válido para el dominio de sobre pero no alineado al From. Si tampoco hay DKIM válido y alineado, DMARC falla. Suele ocurrir con servicios de marketing o soporte sin un dominio de rebote personalizado.
Depender solo de SPF complica los reenvíos. Si DKIM falta o se invalida, puede perderse la autenticación alineada. Consulta configuración y reparación del reenvío para evaluar rutas indirectas.
Publicar p=none y acumular informes sin revisarlos no resuelve la configuración ni solicita bloqueo de fallos.
Pasar demasiado pronto a p=reject puede afectar a correo legítimo. Revisa emisores habituales y excepcionales antes de solicitar restricciones.
Cómo encaja TrekMail
Los informes solo ayudan si puedes aplicar las correcciones. TrekMail puede coordinar dominios y comprobaciones DNS según el plan, aunque también debes revisar los servicios externos.
Un entorno disperso exige gestionar dominios en alojamientos distintos, SMTP separados e informes en un buzón compartido, además de mantener un inventario de nuevos emisores.
Un panel coordinado puede reunir alojamiento multidominio, configuración SPF/DKIM/DMARC, comprobaciones DNS, SMTP propio o gestionado, buzones, reenvío y migración según las funciones disponibles. La guía de alojamiento de correo multidominio explica el modelo.
TrekMail ofrece dominios propios, buzones IMAP, catch-all, reenvío y migración IMAP compatible según el plan, con API en los planes que la incluyen. Para Nano, consulta SMTP propio. Los planes de pago que lo incluyen pueden usar SMTP gestionado; Starter se anuncia desde $3.50 al mes. Nano se ofrece gratuito sin tarjeta, y los planes de pago pueden incluir una prueba de 14 días con tarjeta requerida. Comprueba las condiciones vigentes.
Los informes no corrigen nada automáticamente: aportan pistas. La coordinación de configuración y pruebas puede facilitar el trabajo posterior.
Cuándo pasar de p=none a quarantine o reject
Los informes aportan evidencia de autenticación alineada en el tráfico observado, no una garantía de que todos los emisores estén preparados. Completa el inventario y prueba los flujos críticos antes de valorar quarantine y reject.
Estos registros representan etapas alternativas: publica solo el correspondiente, no todos a la vez.
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=25"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100"El porcentaje expresa la cobertura solicitada de mensajes que fallan y no todos los destinatarios lo aplican igual. Revisa varios ciclos y los procesos raros, confirma autenticación alineada y comprueba que los reenvíos preserven DKIM cuando dependas de él.
Google exige SPF o DKIM para remitentes generales a cuentas personales de Gmail; para remitentes masivos exige ambos y DMARC, con la alineación aplicable. Consulta las preguntas frecuentes sobre requisitos para remitentes de Gmail.
Conclusión: incorpora los informes a la operación
Los informes muestran fuentes y resultados observados, y ayudan a decidir qué investigar y corregir. Inclúyelos en una revisión periódica junto con inventario y pruebas, en lugar de dejarlos en un buzón sin supervisión.
Si gestionas muchos dominios y proveedores, coordinar las herramientas puede ayudar. Según el plan, TrekMail ofrece alojamiento multidominio, almacenamiento compartido, migración IMAP, SMTP propio o gestionado y configuración de autenticación. Revisa la opción gratuita o los precios de TrekMail según tus necesidades, sin asumir que una plataforma garantiza una política segura.
