31 jul 20267 minutos leídos
SendmarcCómo leer los informes XML de DMARC: qué revelan source_ip y policy_evaluated
Resumen de los informes XML de DMARC:
source_ipes lo primero que hay que comprobar; las IP no reconocidas necesitan atribución antes de remediarsepolicy_evaluatedrefleja la alineación, no solo la autenticación, por lo que un fallo aquí no significa que la propia firma no sea válidadisposition: rejecten una IP reconocida y de alto volumen necesita remediación el mismo día- Una revisión mensual de nuevas IP, aprobaciones solo por DKIM y cobertura de SPF convierte los datos de los informes en inteligencia
Tus informes XML de DMARC generan datos cada día. La mayoría de los equipos empresariales nunca extraen la información que importa y pasan por alto fallos de alineación que señalan intentos activos de suplantación o de impersonación.
Si los informes agregados están en un buzón o los analiza una herramienta que no está configurada para alertar de nada relevante, eso son datos sin acción. Esta guía se centra en los campos de los informes XML de DMARC que más importan: source_ip, policy_evaluated, disposition y auth_results. Juntos, apuntan a desviaciones de la infraestructura, remitentes no autorizados y servicios mal configurados.
Interpretar los informes XML de DMARC a escala empresarial significa superar la revisión manual, dominio por dominio. La plataforma de gestión de DMARC de Sendmarc expone los resultados de source_ip y policy_evaluated en todos los dominios, de modo que la revisión no depende de abrir los adjuntos XML de uno en uno.
Por qué source_ip es tu primera parada de diagnóstico
Un informe XML de DMARC tiene este aspecto:
<record>
<row>
<source_ip>203.0.113.45</source_ip>
<count>120</count>
<policy_evaluated>
<disposition>quarantine</disposition>
<dkim>fail</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>yourdomain.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>yourdomain.com</domain>
<result>fail</result>
<selector>20150623</selector>
</dkim>
<spf>
<domain>yourdomain.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>La primera pregunta es siempre: ¿esa IP está reconocida? Si no, no es una nota al pie; es un motivo de investigación.
En entornos empresariales con múltiples servicios en la nube y remitentes de terceros, aparecen IP de origen desconocidas con regularidad. Algunas son servicios legítimos que marketing o RR. HH. configuraron sin avisar a TI. Otras son herramientas SaaS recién incorporadas que aún no se han añadido al registro SPF. Un número reducido puede no estar autorizado.
Para cada source_ip desconocida, ejecuta una búsqueda de DNS inversa y compárala con el inventario de remitentes autorizados. Una IP que se resuelve en un proveedor conocido pero aún no autorizado apunta a una brecha de configuración. Una IP que se resuelve en infraestructura no reconocida debe escalarse.
Cómo leer policy_evaluated: qué hizo realmente el servidor receptor
El bloque policy_evaluated es donde el servidor receptor documenta su decisión. Contiene tres subcampos: disposition, dkim y spf. Estos reflejan la alineación, no solo la autenticación.
dkim: pass o fail. Un fail aquí significa que no había una firma DKIM válida, que la firma no coincidía con el dominio «De» (un fallo de alineación) o que la firma se rompió en tránsito, a menudo por la reescritura del mensaje.
spf: pass o fail. Un fail aquí, en el bloque policy_evaluated, significa que el dominio autenticado por SPF no se alineó con la cabecera «De».
disposition: el resultado que aplicó el sistema receptor. Son posibles tres valores: none, quarantine y reject.
- None significa que el mensaje se entregó con normalidad
- Quarantine significa que el mensaje se dirigió a Spam o Correo no deseado
- Reject significa que el mensaje se bloqueó por completo
La combinación de estos tres campos muestra qué está pasando y cuánto cuesta. Una fila con disposition: reject, dkim: fail y spf: fail en una IP reconocida es una configuración incorrecta que bloquea mensajes de forma activa. Esa fila necesita remediación hoy, no en la próxima revisión mensual.
Diagnóstico de combinaciones de campos comunes en los informes XML de DMARC
Ciertos patrones en los informes XML de DMARC se repiten en los entornos empresariales. Entender qué señala cada combinación acelera la clasificación.
SPF: pass, DKIM: fail, disposition: none
La política es p=none. La autenticación funciona parcialmente: SPF supera la alineación, pero DKIM no firma correctamente. Antes de avanzar hacia p=reject, esta IP necesita una firma DKIM válida. Comprueba si el servicio de envío tiene DKIM habilitado y si el dominio de firma se alinea con el dominio «De».
SPF: fail, DKIM: pass, disposition: none
La alineación SPF falla porque el dominio del remitente del sobre no coincide. Esta fuente sobrevivirá a la aplicación si la alineación DKIM sigue superándose, pero confirma que la clave DKIM se gestiona internamente, no solo por el proveedor, para poder rotarla cuando sea necesario.
SPF: fail, DKIM: fail, disposition: quarantine o reject
Urgente en una IP reconocida. O bien la IP se añadió recientemente sin actualizar el registro SPF, se eliminó la clave DKIM o el servicio está mal configurado. Contrasta con los errores de entrega SMTP que aparezcan en paralelo.
SPF: fail, DKIM: fail, disposition: none, desde una IP no reconocida
La política aún no se aplica, pero esto puede ser un remitente no autorizado que usa el dominio. Si la IP no puede atribuirse a un servicio conocido, trátala como un posible intento de impersonación e investígala.
Lista de comprobación mensual de los informes XML de DMARC
Una revisión mensual estructurada convierte los datos brutos de los informes XML de DMARC en inteligencia.
Usa esta lista de comprobación como base:
- Nuevas IP de origen: Identifica las IP que no aparecían en los informes XML de DMARC del mes pasado y asigna cada una a un servicio o escálala para investigación
- Aprobaciones solo por DKIM: Marca los remitentes que superan la validación solo por alineación DKIM y confirma que esas claves DKIM se controlan internamente y no por un proveedor externo
- Cobertura del registro SPF: Contrasta las IP de origen autorizadas con el registro SPF publicado; una IP que supera SPF pero no está en el registro puede estar autorizada a través de un
includede terceros
Cómo ayuda Sendmarc
Leer los informes XML de DMARC a escala requiere más que un script que analice archivos RUA. Sendmarc consolida los datos de los informes de todos los dominios gestionados, expone entradas de source_ip nuevas y anómalas con alertas, y asigna los resultados de policy_evaluated al remitente autorizado.
Para los equipos que gestionan implementaciones multidominio o carteras de MSP, elimina el cuello de botella manual de abrir los adjuntos XML dominio por dominio y ayuda a evitar que los fallos de alineación pasen desapercibidos entre ciclos de revisión.
Esto ayuda directamente a los equipos de seguridad y de TI sobrecargados al proporcionar visibilidad unificada de las configuraciones de SPF, DKIM y DMARC en todos los dominios, una identificación más rápida de remitentes no autorizados o desconocidos y menos investigación manual de configuraciones incorrectas y correos sospechosos.
La cobertura se extiende por entornos distribuidos, multiinquilino y regionales sin añadir carga de trabajo interna, algo que importa a los equipos que necesitan monitorización continua sin aumentar continuamente la plantilla.
Si el proceso actual consiste en descargar informes XML de DMARC y filtrarlos en una hoja de cálculo, descubre la plataforma de gestión de DMARC de Sendmarc para ver cómo el análisis centralizado sustituye la revisión manual a escala empresarial.
