Depuración de fallos DMARC: una guía práctica

En resumen: La mayoría de los fallos DMARC se deben a problemas de alineación. SPF o DKIM pueden aprobar, pero el dominio autenticado no coincide con tu cabecera From. Corrige la alineación configurando los remitentes de terceros para que usen tu dominio en Return-Path y las firmas DKIM, valida la sintaxis DNS y usa ARC para gestionar el reenvío. Comienza con p=none, monitoriza los informes semanalmente y solo pasa a la aplicación tras alcanzar una tasa de éxito superior al 95 %.

Puntos clave

• Alineación ≠ autenticación: SPF y DKIM pueden aprobar mientras DMARC sigue fallando si el dominio autenticado no coincide con el dominio en From
• Solo uno debe alinearse: DMARC aprueba si SPF o DKIM se alinean. No necesitas ambos.
• Los remitentes de terceros suelen ser el problema: Las plataformas de marketing, CRMs y herramientas de soporte suelen enviar con su propio dominio, rompiendo la alineación
• Usa alineación relajada (por defecto), a menos que necesites una seguridad estricta. Permite que los subdominios se alineen con dominios principales.
• Empieza con p=none: Recopila informes durante al menos 2 semanas antes de pasar a quarantine o reject
• Alcanza tasas de éxito del 95 % por al menos un mes antes de aplicar p=reject
• Revisa los informes agregados semanalmente: Una caída repentina en la tasa de éxito significa que algo ha cambiado
• ARC preserva la autenticación tras reenvíos: No reemplaza SPF/DKIM, pero ayuda cuando los correos se reenvían
• SPF tiene un límite de 10 consultas DNS: Superarlo provoca fallos intermitentes. Aplana los includes a direcciones IP si es necesario.

Los fallos de autenticación DMARC bloquean correos legítimos, dañan la reputación del remitente y dejan brechas de seguridad que los atacantes pueden aprovechar. Un solo registro DNS mal alineado puede enviar cientos de mensajes críticos para el negocio a las carpetas de spam. Cuando SPF aprueba y DKIM firma correctamente pero DMARC sigue fallando, los equipos IT se enfrentan a horas de análisis de informes XML, resolución DNS y coordinación con proveedores para identificar la causa raíz.

La buena noticia: la mayoría de los fallos DMARC se deben a unos pocos problemas de configuración solucionables. Desalineaciones, errores de sintaxis DNS y problemas con remitentes de terceros causan la mayoría de los fallos de autenticación. Entender cómo depurar cada tipo convierte los difusos “DMARC no funciona” en soluciones concretas y accionables.

Los equipos de seguridad que gestionan la autenticación de correo necesitan métodos sistemáticos de depuración para aislar rápidamente los problemas, sean registros DNS internos, plataformas de marketing externas o configuraciones de reenvío de correo. Esta guía cubre los pasos prácticos para depurar y lograr que la autenticación y la entrega de correos sean fiables.

• ¿Qué son los fallos DMARC?
• Soluciones a la alineación de SPF y DKIM
• Interpretar informes DMARC
• Corregir errores en registros DNS
• Gestionar reenvío y remitentes de terceros
• Implementar ARC para mejores resultados
• Reducir fallos DMARC: buenas prácticas
• Monitorización y mejora continua
• Preguntas frecuentes sobre la depuración de fallos DMARC

Los fallos DMARC ocurren cuando los correos no pasan las comprobaciones de alineación, incluso si SPF o DKIM aprueban de forma individual. El protocolo DMARC exige que SPF o DKIM se alineen con el dominio en la cabecera From. Alinear significa que el dominio autenticado coincide con el dominio del remitente visible para los usuarios.

Escenario común de desalineación:

Los boletines de marketing acaban en spam aunque SPF apruebe para mailserver.vendor.com y las firmas DKIM sean válidas. El From muestra marketing@company.com, pero la autenticación fue exitosa para dominios vendor.com, generando un fallo de alineación.

Solución: configura tu plataforma de marketing para que use company.com tanto en Return-Path como en el parámetro d= de la firma DKIM. Una vez que la alineación está corregida, DMARC aprueba y la entregabilidad vuelve a la normalidad.

Un correo de marketing@company.com autenticado por mailserver.vendor.com falla DMARC porque los dominios no se alinean. La comprobación SPF puede aprobar para el dominio del proveedor, pero DMARC exige alineación con company.com.

Las fallas de autenticación aparecen en los informes agregados como fallos de alineación de SPF, fallos de alineación de DKIM, o ambos. Los servidores de correo receptores envían estos informes XML diariamente a la dirección de correo especificada en tu registro DMARC.

Los fallos de alineación SPF provienen de desajustes en Return-Path. Cuando los correos provienen de servicios de terceros, Return-Path suele usar el dominio del proveedor en vez del tuyo. La guía de SPF y DKIM explica cómo estos protocolos autentican la identidad del remitente.

Los informes agregados DMARC llegan como archivos XML comprimidos adjuntos a correos diarios [4]. Cada informe muestra los resultados de autenticación agrupados por origen de envío, mostrando el número de aprobados y fallidos para la alineación de SPF y DKIM.

La dirección IP de origen identifica cada sistema remitente. Cruza las IPs con tus servidores de correo internos, plataformas de marketing externas y aplicaciones SaaS conocidas. Las IPs desconocidas requieren investigación para determinar si corresponden a servicios legítimos o remitentes no autorizados.

Así es como se ve un registro dentro de un informe agregado:

<record>
  <row>
    <source_ip>192.0.2.10</source_ip>
    <count>438</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>company.com</header_from>
  </identifiers>
  <auth_results>
    <dkim><domain>company.com</domain><result>pass</result></dkim>
    <spf><domain>mail.vendor.com</domain><result>pass</result></spf>
  </auth_results>
</record>

Interprétalo así: 438 mensajes provinieron de una IP. DKIM autenticó para company.com y se alinea con la cabecera From, por lo que DMARC aprueba por DKIM. SPF autenticó para mail.vendor.com pero no se alineó con company.com, así que el resultado SPF en policy_evaluated muestra fail. El mensaje igualmente aprueba DMARC porque solo una de las dos debe alinearse. Leer mal esta línea y pensar que SPF "fail" significa que todo el mensaje falló es el error más común cuando los equipos abren su primer informe.

Cuando SPF y DKIM fallan, revisa las cuestiones específicas de alineación. Si falla SPF, revisa Return-Path; si falla DKIM, revisa problemas de la firma o registros ausentes.

Prioriza la depuración así: primero los fallos de alto volumen, luego las IPs desconocidas, luego los de bajo volumen.

Fundamentos de sintaxis DNS:

Los registros SPF deben empezar con v=spf1 y acabar con -all o ~all. El uso de -all rechaza remitentes no autorizados, ~all los marca como soft-fail. Usa herramientas de validación DMARC antes de publicar la sintaxis.

Comandos de validación DNS:

• DMARC: dig _dmarc.yourdomain.com TXT
• SPF: dig yourdomain.com TXT
• DKIM: dig selector._domainkey.yourdomain.com TXT
• Propagación: nslookup -type=TXT _dmarc.yourdomain.com 8.8.8.8
• Chequear sintaxis: redsift.com/tools/investigate

Consejo profesional: la mayoría de los fallos SPF se deben a límites de consultas o a problemas con el selector. Centra la depuración primero en estas áreas para resolverlo más rápido.

El reenvío de correo rompe la autenticación SPF, porque los mensajes reenviados vienen de servidores intermedios que no están en los registros SPF. Cuando user@company.com reenvía correos a personal@gmail.com, Gmail ve la IP del servidor de reenvío, no la autorizada originalmente.

Cómo el reenvío rompe la autenticación:

Antes de reenviar: IP del emisor original: 192.0.2.1 (autorizada en SPF) → Return-Path: sender@company.com → From: sender@company.com → SPF aprueba ✓ → DMARC aprueba ✓

Tras reenvío a correo personal: IP del servidor de reenvío: 203.0.113.5 (NO en SPF) → Return-Path: sender@company.com (sin cambios) → From: sender@company.com → SPF falla ✗ → DMARC falla ✗

SPF falla porque el envelope sender (Return-Path) sigue siendo de la empresa, pero la IP es del servidor de reenvío. Las firmas DKIM a veces sobreviven si el mensaje no se modifica.

Configuración de remitentes de terceros:

• Usa subdominios para envío – news.yourdomain.com en lugar de yourdomain.com
• Publica registros SPF para todos los subdominios – Los subdominios NO heredan del dominio principal
• Configura dominios Return-Path personalizados – Mantiene la alineación SPF mientras los proveedores gestionan la infraestructura
• Actualiza cuando los proveedores cambian – Los proveedores pueden añadir servidores sin aviso

Authenticated Received Chain (ARC) conserva los resultados de autenticación a través de reenvíos y modificaciones por listas de correo. Cuando los mensajes cruzan servidores intermedios, ARC crea una cadena de autenticaciones que los servidores destinatarios pueden validar [1].

Cada intermediario añade sus propios encabezados ARC, construyendo una cadena de autenticación auditable.

Opciones de implementación:

• Google Workspace / Microsoft 365 - Encabezados ARC automáticos (sin configuración)
• Postfix / Sendmail - Autogestionado mediante módulos OpenARC
• OnDMARC - Plataforma comercial con validación ARC

Importante: ARC no reemplaza SPF ni DKIM. Los complementa preservando los resultados de autenticación cuando el reenvío rompería la alineación DMARC. Los servidores receptores que admiten ARC pueden validar la cadena y confiar en los mensajes que originalmente pasaron la autenticación.

Documenta todas las fuentes autorizadas de envío antes de implementar políticas DMARC. Pregunta a los empleados sobre herramientas que usan para enviar correos. Las fuentes shadow IT más frecuentes incluyen plataformas de soporte (Zendesk), herramientas de marketing (HubSpot, Mailchimp), sistemas CRM (SalesForce) y plataformas de encuestas.

Autoevaluación: ¿tu configuración DMARC está en riesgo?

1. Ejecutar p=quarantine/p=reject sin 2+ semanas en p=none
2. Tasa de autenticación menor al 95 % en remitentes legítimos
3. Servicios de terceros envían sin configuración SPF/DKIM
4. Sin proceso de revisión semanal de los reportes agregados
5. Registros DNS no auditados en más de 6 meses
6. Miembros del equipo pueden agregar herramientas de correo sin aprobación de IT

Si has marcado 3 o más: Soluciona estas brechas antes de avanzar a políticas de aplicación.

Comienza con p=none y recoge reportes durante dos semanas. Analiza para identificar todas las fuentes de envío y su estado de autenticación. Avanza a p=quarantine en 25% usando la etiqueta pct= y aumenta gradualmente hasta pct=100 antes de pasar a p=reject.

La guía de aplicación DMARC recorre los puntos de decisión para la progresión de políticas. Avanza a p=reject solo después de lograr tasas de autenticación superiores al 95 % durante al menos un mes.

DMARC requiere gestión continua, no una configuración puntual. Los proveedores externos cambian la infraestructura de envío, nuevas aplicaciones envían correos sin aprobación de IT y los registros DNS pueden caducar durante renovaciones de dominios.

Haz seguimiento de la tasa de autenticación por fuente de envío. Si una plataforma de marketing que solía conseguir tasas del 99 % baja de repente al 85 %, es motivo de investigación inmediata.

Los reportes agregados revelan intentos de suplantación a través de IPs no autorizadas. Los reportes forenses (ruf=) proporcionan ejemplos de mensajes para depuración, pero contienen el contenido del correo—úsalos solo temporalmente para depuración activa.

OnDMARC proporciona alertas en tiempo real cuando bajan las tasas de autenticación, identifica automáticamente nuevas fuentes de envío y monitoriza el cumplimiento de políticas en múltiples dominios.

[1] Wikipedia contributors. "Authenticated Received Chain." Wikipedia, The Free Encyclopedia. https://en.wikipedia.org/wiki/Authenticated_Received_Chain

[2] InfraForge. "Why DMARC Fails When SPF and DKIM Pass." InfraForge AI Blog. https://www.infraforge.ai/blog/why-dmarc-fails-when-spf-and-dkim-pass

[3] Kitterman, S. "RFC 7208 - Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1." Internet Engineering Task Force (IETF). April 2014. https://datatracker.ietf.org/doc/html/rfc7208

[4] Kucherawy, M. and Zwicky, E. "RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC)." Internet Engineering Task Force (IETF). March 2015. https://datatracker.ietf.org/doc/html/rfc7489