Informe DMARC y protocolo DMARC: qué revelan los informes

Has configurado DMARC y empiezas a recibir adjuntos XML de Google, Microsoft o Yahoo. Es momento de distinguir un informe DMARC del propio protocolo DMARC.

DMARC es un protocolo de autenticación, políticas e informes; su registro DNS configura la política solicitada. El informe contiene datos que algunos receptores envían después de evaluar mensajes con tu dominio. La configuración expresa una petición; el informe aporta observaciones parciales.

Si aún configuras el correo, consulta cómo crear correo con tu dominio. Si los reenvíos afectan a la autenticación, revisa cómo reenviar correo del dominio a Gmail. Aquí nos centraremos en interpretar los informes después de la configuración.

Los informes pueden llegar después de publicar el registro, pero no hay un plazo garantizado ni participan todos los receptores. Confundir el registro, la política, el destino de informes y los resultados puede llevar a modificar DNS que no causaba el problema.

Veremos qué contiene un informe, en qué se diferencia del registro, qué campos revisar y cómo investigar fallos sin atribuir automáticamente al abuso o al reenvío un resultado de autenticación.

Qué es un informe DMARC

Un informe DMARC agregado resume datos de un receptor participante: los resultados SPF y DKIM, la alineación con From, la política encontrada y el tratamiento comunicado para los mensajes observados.

El informe no es la política. Los receptores que admiten informes pueden consultar el registro, evaluar mensajes con tu dominio en From y enviar resúmenes al destino rua. RFC 7489 define estos informes agregados como ayuda para entender la autenticación, las correcciones necesarias y el efecto de las políticas. Su envío es opcional.

Informe DMARC y registro DMARC

El registro DNS configura DMARC; el informe contiene telemetría de los receptores participantes. Ninguno equivale a un inventario completo de todos tus envíos.

La corrección depende del problema. Un registro inválido puede impedir aplicar la política; un registro válido con fallos en los informes exige investigar servicios autorizados, reenvíos, alineación y posibles fuentes no autorizadas. Los informes no deciden por sí solos cuál es el caso.

Qué contiene un informe DMARC

Los informes agrupan mensajes por IP y resultados. Revisa origen, cantidad, SPF, DKIM, alineación y disposición aplicada. En XML, auth_results contiene resultados de autenticación sin evaluar la alineación y policy_evaluated resultados SPF y DKIM con consideración de la alineación; no los confundas.

El XML puede incluir política publicada, disposición, identificadores SPF y DKIM y resultados. DMARC pasa cuando SPF o DKIM pasa con alineación. Una disposición none no demuestra un resultado satisfactorio de DMARC ni necesariamente una política de supervisión; quarantine o reject comunica una acción, no la legitimidad o seguridad del mensaje.

Ver un fallo SPF no significa que todo el correo falle. Si DKIM pasa con alineación, DMARC pasa; lo contrario también es válido para SPF alineado.

Lee el informe en este orden:

1. Revisa la IP de origen y la organización que informa.
2. Comprueba el volumen. Un mensaje y 20,000 mensajes requieren valorar impactos distintos; un envío aislado también puede ser crítico.
3. Revisa la disposición: none, quarantine o reject, sin confundirla con el resultado DMARC.
4. Examina SPF y DKIM juntos y distingue resultados de autenticación de los evaluados con alineación.
5. Comprueba la alineación con el dominio real de From.

Informes agregados e informes de fallos

Normalmente, un informe DMARC es el agregado solicitado mediante rua. Los informes de fallos o forenses usan ruf, pueden aportar datos de mensajes concretos y tienen soporte más limitado. No requieren siempre mensajes completos y pueden contener información sensible.

Si eliges un único destino de informes, suele ser útil empezar por rua, con supervisión, controles de acceso y autorización DNS en el destino externo cuando corresponda. Las directrices de envío de Google explican que los fallos de autenticación pueden influir en el tratamiento del correo según los requisitos aplicables. Los informes aportan información operativa, no garantías de entrega.

Publicar un registro que solicite informes DMARC

Publica el TXT en _dmarc con una política y un destino válido. Una política de supervisión permite solicitar datos antes de evaluar restricciones, aunque los filtros locales siguen activos.

Este ejemplo usa alineación estricta: no es una configuración inicial universalmente segura. Adáptala tras verificar los flujos y sus dominios:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100"

Como sustitución posterior, después del inventario y las pruebas de flujos legítimos, puedes evaluar esta política restrictiva:

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100"

El modo estricto exige coincidencia exacta; el relajado compara el dominio organizativo. El muestreo porcentual depende del receptor y no impone restricciones con supervisión. Considera rechazo solo tras pruebas, revisión de flujos poco frecuentes y un plan de reversión, no por informes aparentemente limpios.

Comprueba la publicación mediante una consulta:

dig TXT _dmarc.example.com +short

En TrekMail, el asistente y los controles DNS disponibles pueden ayudar a detectar registros ausentes o conflictos. Contrasta consultas externas y mensajes reales: el panel no demuestra todos los flujos. Consulta cómo añadir un dominio y mensajes que llegan a spam.

Interpretar un informe sin conclusiones precipitadas

Investiga por separado fallos esperables y fuentes potencialmente abusivas. Un reenvío puede explicar SPF fallido; una IP desconocida no demuestra suplantación.

El informe ayuda a medir resultados de las fuentes observadas y conocer el tratamiento comunicado. No prueba que el receptor entregara el mensaje ni que su contenido fuera seguro.

Por qué el reenvío complica los informes

En el reenvío, el siguiente receptor evalúa SPF para la IP del intermediario y el dominio real de MAIL FROM. Eso puede generar fallos aunque el mensaje original sea legítimo.

No añadas automáticamente IP de buzones personales o intermediarios antiguos a SPF. DKIM puede conservar un resultado alineado si la firma sigue válida y se mantienen los datos firmados tras la canonicalización; decir que el mensaje no cambió de forma importante no basta.

SRS puede modificar el remitente del sobre para SPF, pero no restablece la alineación con el From original. ARC puede informar excepciones locales, no convertir un fallo en autenticación DMARC válida. Consulta la configuración y resolución de problemas del reenvío.

Cuándo un informe justifica cambiar DNS

Modifica DNS cuando la investigación identifica un remitente autorizado cuya configuración necesita cambios. Primero confirma el servicio real y el mecanismo que falla.

Evalúa cambios en estos casos:

1. El dominio real del sobre necesita autorizar en SPF al proveedor que envía desde la IP observada.
2. El proveedor firma con otro dominio y no queda ningún mecanismo válido y alineado; configura y activa DKIM propio o Return-Path adecuado, no solo seguimiento de enlaces.
3. Una aplicación usa una ruta SMTP antigua: confirma que debe cambiar y prueba la configuración nueva.
4. El registro no tiene destino rua, presenta sintaxis inválida o una política inadecuada para la etapa verificada.

No cambies SPF solo porque un informe muestre una IP de reenvío de Gmail u Outlook que falla.

TrekMail puede ayudar a centralizar dominios, controles DNS, buzones, migración y SMTP según el plan, frente a la coordinación de registradores, XML y cinco proveedores sin inventario. Sigue verificando el envío real y los límites SPF de mecanismos y modificadores que requieren DNS, también anidados, sin duplicar registros. Consulta configuración IMAP y SMTP o alojamiento de correo multidominio.

¿Debes leer manualmente todos los informes?

En dominios pequeños puede servir una revisión manual inicial. Con más datos, un analizador o un buzón dedicado ayuda a organizar los XML y controlar el acceso.

Con un dominio y pocos remitentes, leer los informes disponibles durante la implantación puede ser viable. Con diez dominios requiere más tiempo; con cincuenta, conviene planificar el análisis y estandarizar la configuración sin asumir que todos los receptores informan diariamente.

Un informe sin fallos de fuentes conocidas puede ser una buena señal, pero no prueba un inventario completo. Contrasta también mensajes raros o críticos y recuerda que la disposición restrictiva no demuestra por sí sola suplantación.

Proceso recomendado para los informes DMARC

Publica, observa, contrasta el inventario, corrige autenticación y alineación y después evalúa restricciones. Usa los informes como una fuente de datos parcial, no como una autorización automática para endurecer la política.

1. Publica DMARC con p=none y un buzón de informes dedicado y supervisado.
2. Reúne informes durante varios días como observación inicial, sin garantizar que cada receptor los envíe ni que el plazo cubra todos los flujos.
3. Investiga tres categorías posibles: remitente autorizado, efecto del reenvío o suplantación; mantén sin clasificar las fuentes no identificadas.
4. Corrige los remitentes autorizados y verifica los reenvíos con DKIM válido y alineado, sin ignorarlos indiscriminadamente.
5. Evalúa quarantine y después reject tras contrastar informes, registros y pruebas de flujos críticos poco frecuentes, con un plan de reversión.

Cada nueva herramienta requiere comprobar SPF, DKIM y el Return-Path realmente usado. Un cambio en el servicio puede alterar la alineación aunque el TXT DMARC permanezca igual.

TrekMail y la coordinación de DNS

TrekMail no sustituye DMARC. Según el plan, puede centralizar parte de su gestión, pero sigues publicando y verificando registros y remitentes.

Dominios personalizados, buzones IMAP, catch-all, reenvío, copia IMAP y SMTP propio o gestionado dependen de la oferta y del plan. Para agencias y MSP, la gestión multidominio y el almacenamiento compartido pueden ayudar a organizar clientes. La copia de mensajes no sustituye el cambio de MX ni migra todas las aplicaciones.

La facturación por usuario tampoco implica falta de inventario o herramientas. Compara procesos, límites y costes: la oferta descrita presenta planes desde $3.50 al mes, Nano sin coste ni tarjeta según sus condiciones y una prueba gratuita de 14 días para planes de pago sujeta a los requisitos aplicables. Consulta la página de precios de TrekMail; no se garantiza ahorro ni ausencia de incidencias.

Conclusión sobre los informes DMARC

El informe aporta observaciones sobre la política DMARC y el envío real. No sustituye DNS ni demuestra por sí solo que toda la configuración y todos los flujos coincidan.

Recuerda la diferencia: DMARC es el protocolo; el registro DNS configura su política y los informes parciales ayudan a investigar remitentes, posibles suplantaciones y el momento de evaluar cuarentena o rechazo. Combínalos con inventario, registros y pruebas para tomar decisiones operativas, sin garantías de entrega.