En resumen: La mayoría de los fallos DMARC se deben a problemas de alineación. SPF o DKIM pueden pasar, pero el dominio autenticado no coincide con tu encabezado From. Soluciona la alineación configurando los remitentes de terceros para que usen tu dominio en Return-Path y las firmas DKIM, valida la sintaxis de DNS y utiliza ARC para manejar el reenvío. Empieza con p=none, monitorea los reportes semanalmente y sólo cambia a políticas restrictivas después de lograr tasas de éxito superiores al 95%.
Puntos clave
- Alineación ≠ autenticación: SPF y DKIM pueden pasar pero DMARC aún puede fallar si el dominio autenticado no coincide con el dominio del encabezado From
- Sólo uno necesita alinearse: DMARC aprueba si SPF o DKIM se alinean. No necesitas ambos.
- Los remitentes de terceros suelen ser el problema: plataformas de marketing, CRMs y herramientas de atención suelen usar sus propios dominios, rompiendo la alineación
- Utiliza alineación relajada (por defecto) a menos que tengas requisitos de seguridad estrictos. Permite que subdominios se alineen con dominios principales.
- Empieza con p=none: Recopila reportes por al menos 2 semanas antes de pasar a cuarentena o rechazo
- Llega a tasas de aprobación del 95% por al menos un mes antes de aplicar p=reject
- Revisa los reportes agregados semanalmente: Una bajada repentina de aprobaciones indica algún cambio
- ARC preserva la autenticación tras el reenvío: No reemplaza SPF/DKIM pero ayuda cuando los correos son reenviados
- SPF tiene un límite de 10 búsquedas DNS: Superarlo causa fallos intermitentes. Aplana los includes a IPs si es necesario.
Los fallos de autenticación DMARC bloquean correos legítimos, dañan la reputación del remitente y abren brechas de seguridad que los atacantes pueden explotar. Un solo registro DNS desalineado puede enviar cientos de mensajes críticos para el negocio a la carpeta de spam. Cuando SPF pasa y DKIM firma correctamente pero DMARC aún falla, los equipos de IT deben analizar reportes XML, revisar configuraciones DNS y coordinar con proveedores para encontrar la causa raíz.
La buena noticia: la mayoría de los fallos DMARC se deben a configuraciones fácilmente corregibles. Desalineación, errores de sintaxis en DNS y problemas con remitentes de terceros cuentan por la mayoría de fallos de autenticación. Entender cómo depurar cada tipo de error convierte los problemas vagos de "DMARC no funciona" en soluciones concretas y realizables.
Los equipos de seguridad que gestionan la autenticación de correo necesitan enfoques sistemáticos de depuración para aislar rápidamente los problemas, sean registros internos de DNS, plataformas de marketing externas o configuraciones de reenvío de correo. Esta guía cubre pasos prácticos de depuración para lograr que tus correos se autentiquen y entreguen correctamente.
Índice de contenidos
- ¿Qué son los fallos DMARC?
- Soluciones de alineación SPF y DKIM
- Interpretando los reportes DMARC
- Corregir errores en registros DNS
- Manejo de reenvíos y remitentes de terceros
- Implementación de ARC para mejores resultados
- Reduciendo los fallos DMARC: mejores prácticas
- Monitoreo y mejora continua
- Preguntas frecuentes sobre la depuración DMARC
¿Qué son los fallos DMARC?
Los fallos DMARC ocurren cuando los correos no superan las comprobaciones de alineación, aunque SPF o DKIM pasen de forma individual. El protocolo DMARC requiere que SPF o DKIM se alineen con el dominio en el encabezado From. Alinear significa que el dominio autenticado coincide con el dominio visible para el destinatario.
Escenario común de desalineación:
Los boletines de marketing llegan a spam aunque SPF apruebe para mailserver.vendor.com y las firmas DKIM sean válidas. El encabezado From muestra marketing@company.com, pero la autenticación pasa para dominios vendor.com: esto genera 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 alineado, DMARC pasa y la entregabilidad vuelve a la normalidad.
DMARC evalúa dos tipos de alineación
Tipo de alineación | Qué compara | Resultados requeridos |
Alineación SPF | Dominio Return-Path vs. dominio del encabezado From | Los dominios deben coincidir |
Alineación DKIM | Parámetro d= de DKIM vs. dominio del encabezado From | Los dominios deben coincidir |
Aprobado DMARC | Alineación SPF o DKIM | Sólo uno debe pasar |
Un correo de marketing@company.com autenticado por mailserver.vendor.com falla DMARC porque los dominios no se alinean. La comprobación SPF puede pasar para el dominio del proveedor, pero DMARC requiere alineación con company.com.
Los fallos de autenticación aparecen en los reportes agregados como fallos de alineación SPF, fallos de alineación DKIM o ambos. Los servidores de correo receptores envían estos reportes XML diariamente a la dirección de correo especificada en tu registro DMARC.
Soluciones de alineación SPF y DKIM
Los fallos de alineación SPF se deben a desajustes en el dominio Return-Path. Cuando los correos se originan desde servicios de terceros, el Return-Path suele usar el dominio del proveedor en lugar del tuyo. La guía de SPF y DKIM explica cómo estos protocolos autentican la identidad del remitente.
Guía de decisión de modo de alineación
Tu configuración de envío | Modo recomendado | Razón |
Todos los correos del dominio principal solamente | Estricto (aspf=s) | Seguridad máxima, sin complejidad de subdominios |
El área de marketing usa news.example.com | Relajado (aspf=r) | Permite alineación de subdominios |
Varios servicios de terceros | Relajado (aspf=r) | Configuración de proveedores más sencilla |
Aprende cómo solucionar problemas de alineación SPF y DKIM
Interpretando los reportes DMARC
Los informes agregados DMARC llegan como archivos XML comprimidos adjuntos a correos diarios [4]. Cada reporte contiene los resultados de autenticación agrupados por origen de envío, mostrando conteos de aprobaciones y rechazos por alineación de SPF y DKIM.
La dirección IP de origen identifica cada sistema de envío. Cruza las IPs con tus servidores de correo internos conocidos, plataformas de marketing de terceros y aplicaciones SaaS. Las IPs desconocidas requieren investigación para determinar si representan servicios legítimos o emisores no autorizados.
Haz fácil la interpretación con Red Sift OnDMARC
Árbol de decisión para análisis de reportes
Escenario | Volumen | Autenticación | Acción requerida |
Remitente conocido | Alto | Aprobado | Monitorear cambios |
Remitente conocido | Alto | Fallido | Corregir de inmediato |
Remitente conocido | Bajo | Aprobado | Seguir monitoreando |
Remitente conocido | Bajo | Fallido | Investiga: mensajes de prueba o casos especiales |
IP desconocida | Cualquiera | Fallido | Investigación prioritaria: posible spoofing |
Cuando tanto SPF como DKIM fallan, analiza problemas de alineación específicos. Un fallo SPF indica problemas con Return-Path; un fallo DKIM apunta a errores de firma o registros faltantes.
Prioriza la depuración así: primero los fallos de alto volumen, luego las IP desconocidas y después los fallos de bajo volumen.
Corregir errores en registros DNS
Fundamentos de sintaxis DNS:
Los registros SPF deben iniciar con v=spf1 y terminar con -all o ~all. El modificador -all bloquea emisores no autorizados y ~all los rechaza suavemente. Usa herramientas de comprobación DMARC para validar la sintaxis antes de publicarla.
Comandos de validación DNS:
- DMARC: dig _dmarc.tudominio.com TXT
- SPF: dig tudominio.com TXT
- DKIM: dig selector._domainkey.tudominio.com TXT
- Propagación: nslookup -type=TXT _dmarc.tudominio.com 8.8.8.8
- Comprobar sintaxis: redsift.com/tools/investigate
Errores comunes de configuración DNS
Error | Síntoma | Solución | Validación |
Falta la etiqueta v=spf1 | SPF falla para todo el correo | Añade v=spf1 al inicio del registro | dig tudominio.com TXT |
Se excedieron 10 búsquedas DNS | Fallos SPF intermitentes | Aplana includes a direcciones IP o usa Dynamic SPF con Red Sift OnDMARC | Cuenta las instrucciones include: |
Selector DKIM incorrecto | DKIM falla pese a tener clave válida | Confirma que el selector en DNS coincida con el servidor de correo | Revisa en los encabezados del correo el valor s= |
Registro DMARC en subdominio incorrecto | Sin política DMARC aplicada | Coloca en _dmarc.tudominio.com | dig _dmarc.tudominio.com TXT |
Falta dirección rua= | No se reciben reportes agregados | Añade rua=mailto:direccion@dominio.com | Espera 24h por los reportes |
Consejo pro: la mayoría de fallos SPF se deben al límite de búsquedas o a desajustes de selector. Empieza por depurar en estas dos áreas para resolver más rápido.
Manejo de reenvíos y remitentes de terceros
El reenvío de correos rompe la autenticación SPF porque los mensajes reenviados provienen de servidores intermedios no listados en los registros SPF. Cuando user@company.com reenvía mensajes a personal@gmail.com, Gmail ve la IP del servidor que reenvía, no la original y autorizada.
Cómo el reenvío rompe la autenticación:
Antes del reenvío: IP original del remitente: 192.0.2.1 (autorizada en SPF) → Return-Path: sender@company.com → From: sender@company.com → SPF aprobado ✓ → DMARC aprobado ✓
Tras el reenvío a correo personal: IP de 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 refiriendo el dominio original, pero la IP de envío cambió al servidor de reenvío. Las firmas DKIM a veces sobreviven al reenvío si el mensaje no se modifica.
Configuración de remitentes de terceros:
- Usa envío por subdominios - news.tudominio.com en vez de tudominio.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 el proveedor gestiona la infraestructura
- Actualiza cuando los proveedores cambian - los servicios agregan servidores sin notificación
Implementación de ARC para mejores resultados
Authenticated Received Chain (ARC) preserva los resultados de autenticación a través de reenvíos y modificaciones de listas de correo. Cuando los mensajes pasan por intermediarios, ARC crea una cadena de resultados de autenticación que los servidores destinatarios pueden validar [1].
Estructura de cabecera ARC
Cabecera ARC | Propósito |
ARC-Authentication-Results | Registra el estado de autenticación original |
ARC-Message-Signature | Proporciona una firma criptográfica |
ARC-Seal | Crea un sello a prueba de manipulaciones |
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 necesidad de configuración)
- Postfix / Sendmail - Autohospedado mediante módulos OpenARC
- OnDMARC - Plataforma comercial con validación ARC
Importante: ARC no reemplaza a SPF ni DKIM. Los complementa preservando los resultados de autenticación cuando el reenvío de correos podría romper la alineación DMARC. Los servidores receptores que soportan ARC pueden validar la cadena y confiar en los mensajes que originalmente aprobaron la autenticación.
Reducción de fallos DMARC: buenas prácticas
Documenta todas las fuentes de envío autorizadas antes de implementar políticas DMARC. Consulta al personal sobre herramientas de envío de correos que utilizan. Algunos de los orígenes más comunes en el shadow IT son plataformas de soporte (Zendesk), herramientas de marketing (HubSpot, Mailchimp), sistemas CRM (SalesForce) y plataformas de encuestas.
Autoevaluación: ¿está en riesgo tu configuración DMARC?
- Ejecutar p=quarantine/p=reject sin al menos 2 semanas con p=none
- Tasa de aprobación de autenticación inferior al 95% para remitentes legítimos
- Servicios de terceros envían sin configuración de SPF/DKIM
- No hay un proceso de revisión semanal para informes agregados
- Registros DNS sin auditar en más de 6 meses
- Miembros del equipo pueden añadir herramientas de email sin aprobación de IT
Si has marcado 3 o más: Atiende estas carencias antes de avanzar hacia políticas de refuerzo.
Comienza con p=none y recopila informes durante dos semanas. Analiza para identificar todas las fuentes de envío y el estado de autenticación. Pasa a p=quarantine al 25% usando la etiqueta pct= y aumenta gradualmente hasta pct=100 antes de pasar a p=reject.
La guía de refuerzo DMARC describe los puntos de decisión para la evolución de la política. Solo pasa a p=reject tras conseguir tasas de autenticación superiores al 95% durante al menos un mes.
Supervisión y mejora continua
DMARC requiere gestión continua, no una configuración puntual. Los proveedores de terceros cambian su infraestructura de envío, nuevas aplicaciones envían correos sin aprobación de IT y, a veces, los registros DNS caducan durante renovaciones de dominio.
Buenas prácticas de monitoreo
Tarea | Frecuencia | Disparador de acción |
Revisar informes agregados | Semanal | Caída en la tasa de autenticación >5% |
Actualizar registros SPF | Trimestral | Nuevos proveedores o cambios en la infraestructura |
Audiatr configuraciones DNS | Cada 6 meses | Cambios de políticas o dominio |
Haz seguimiento a las tasas de éxito de autenticación por fuente de envío. Si una plataforma de marketing que mantiene tasas del 99% baja repentinamente al 85%, es señal de que se requiere investigación inmediata.
Los informes agregados revelan intentos de suplantación mediante IPs no autorizadas. Los informes forenses (ruf=) proporcionan mensajes de muestra para depuración pero contienen contenido de correo: utilízalos solo temporalmente para depuración activa.
OnDMARC ofrece 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.
Referencias
[1] Wikipedia contributors. "Authenticated Received Chain." Wikipedia, The Free Encyclopedia. https://es.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). Abril 2014. https://datatracker.ietf.org/doc/html/rfc7208
[4] Kucherawy, M. y Zwicky, E. "RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC)." Internet Engineering Task Force (IETF). Marzo 2015. https://datatracker.ietf.org/doc/html/rfc7489