Tu reporte DMARC muestra SPF aprobado y DKIM aprobado. Cada verificación de autenticación devuelve verde. Sin embargo, el correo electrónico sigue llegando a spam—o nunca llega.

La brecha entre el éxito de autenticación y el fallo de entrega a menudo se remonta a un límite técnico mal entendido: la alineación DMARC. Pasar las verificaciones de autenticación no significa automáticamente pasar DMARC. Y pasar DMARC no garantiza la colocación en la bandeja de entrada.

Este artículo explica por qué fallan los correos autenticados, cómo la alineación DMARC difiere de la autenticación, dónde falla el sistema y qué deben verificar las organizaciones más allá de las marcas verdes.

I. Por Qué Pasar la Autenticación No Significa Pasar DMARC

Flujo de cuatro pasos que muestra la validación de SPF y DKIM, seguida de la comprobación de alineación que determina el resultado de DMARC.

SPF y DKIM validan la identidad del remitente. DMARC impone alineación entre los identificadores autenticados y la dirección From visible.

Un correo electrónico puede pasar SPF y DKIM pero aún fallar DMARC si el dominio autenticado no se alinea con el dominio From del encabezado.

Qué Valida Realmente SPF

SPF verifica si la dirección IP de envío está autorizada para enviar en nombre del dominio del remitente de sobre (el dominio en el comando MAIL FROM durante SMTP).

Dónde SPF puede fallar silenciosamente:

  • El tiempo de espera de búsqueda DNS devuelve temperror en lugar de aprobar o fallar
  • Más de 10 búsquedas DNS activan permerror antes de que se complete la validación
  • El dominio del remitente de sobre difiere del dominio From del encabezado—SPF aprueba, pero la alineación DMARC falla

Ejemplo: Un correo electrónico transaccional de servicio envía desde bounce.sender.com (sobre) pero muestra tu-empresa.com en el encabezado From visible. SPF aprueba para bounce.sender.com. DMARC falla porque los dominios no se alinean.

Qué Valida Realmente DKIM

DKIM firma criptográficamente el mensaje y valida que la firma coincida con una clave pública publicada en DNS para el dominio de firma DKIM (d= en el encabezado DKIM-Signature).

Dónde DKIM puede fallar silenciosamente:

  • La clave de firma rota pero el registro DNS no se actualiza o está en caché
  • Una lista de correo o reenviador modifica la línea de asunto, pie de página o archivos adjuntos—la firma se rompe
  • El dominio de firma DKIM difiere del dominio From del encabezado—DKIM aprueba, pero la alineación DMARC falla

Ejemplo: Una plataforma de marketing firma mensajes con d=platform.com. La dirección From visible muestra tu-empresa.com. DKIM aprueba. DMARC falla porque platform.com no se alinea con tu-empresa.com.

II. Alineación DMARC: La Capa de Cumplimiento Que La Autenticación Por Sí Sola No Proporciona

Tabla comparativa entre la alineación relajada, que permite variaciones de subdominios, y la alineación estricta, que exige una coincidencia exacta de los dominios.

La alineación DMARC requiere que al menos un identificador autenticado coincida con el dominio organizacional en la dirección From del encabezado.

DMARC aprueba cuando:

  • SPF alineado aprueba: el dominio del remitente de sobre coincide con el dominio From del encabezado (o comparte el mismo dominio organizacional)
  • O DKIM alineado aprueba: el dominio de firma DKIM coincide con el dominio From del encabezado (o comparte el mismo dominio organizacional)

DMARC falla cuando:

  • SPF aprueba pero el dominio del remitente de sobre no se alinea con el From del encabezado
  • DKIM aprueba pero el dominio de firma no se alinea con el From del encabezado
  • Tanto SPF como DKIM fallan
  • Tanto SPF como DKIM aprueban pero ninguno se alinea

Alineación Relajada vs Estricta

DMARC admite dos modos de alineación:

Alineación relajada (predeterminada): Los dominios organizacionales deben coincidir. Se permiten subdominios.

Alineación estricta: Los dominios deben coincidir exactamente.

La mayoría de las organizaciones usan alineación relajada para acomodar remitentes de subdominios legítimos. La alineación estricta puede romper flujos de trabajo transaccionales que dependen de subdominios específicos del servicio.

Cuando la Autenticación Aprueba Pero DMARC Falla

Tres escenarios comunes en los que la autenticación se supera correctamente, pero la alineación falla, lo que provoca el rechazo por DMARC.

Escenarios comunes donde SPF o DKIM aprueba pero la alineación DMARC falla:

Servicios transaccionales de terceros:

  • El servicio envía usando su propio remitente de sobre o dominio de firma DKIM
  • El From del encabezado muestra el dominio del cliente
  • La autenticación aprueba para el dominio del servicio
  • DMARC falla porque los dominios no se alinean

Mensajes reenviados:

  • El remitente original aprueba SPF y DKIM
  • El reenviador retransmite el mensaje desde una nueva dirección IP
  • SPF falla (nueva IP no autorizada para el dominio original)
  • DKIM puede sobrevivir si el mensaje no se modifica
  • DMARC depende de si sobrevive la alineación DKIM

Listas de correo:

  • La lista modifica la línea de asunto, pie de página o archivos adjuntos
  • La firma DKIM se rompe
  • SPF puede aprobar para el dominio del servidor de lista, pero no para el remitente original
  • DMARC falla a menos que la lista reescriba la dirección From

III. Por Qué Pasar DMARC Aún No Garantiza la Colocación en la Bandeja de Entrada

Pasar DMARC elimina una condición de fallo. No anula la reputación, el análisis de contenido, las tasas de quejas o las señales de abuso internas.

Los proveedores de buzones evalúan:

  • Autenticación y alineación DMARC
  • Reputación de IP y dominio de envío
  • Tasas de quejas y señales de participación
  • Características del contenido (enlaces, imágenes, patrones de lenguaje)
  • Contexto de reenvío y comportamiento de listas de correo

Filtrado Silencioso A Pesar del Cumplimiento DMARC

Un correo electrónico puede pasar DMARC en p=reject y aún ser filtrado a spam o bloqueado si:

  • La IP de envío tiene mala reputación por abuso previo
  • Las tasas de quejas exceden los umbrales del proveedor de buzones
  • El contenido activa señales de clasificación de spam
  • El historial de participación del destinatario muestra bajas tasas de apertura o altas tasas de eliminación
  • El dominio de envío está recién registrado o carece de historial de envío

Cuando el cumplimiento depende del comportamiento del receptor:

  • Algunas listas de correo y reenviadores no respetan las políticas DMARC
  • Algunos proveedores de buzones aplican anulaciones de reputación que desestiman las señales DMARC
  • Los equipos internos de abuso pueden anular la autenticación si las señales de comportamiento indican abuso coordinado

El cumplimiento de DMARC (p=quarantine o p=reject) instruye a los receptores a rechazar o poner en cuarentena mensajes no autenticados. Si los receptores respetan esa instrucción depende de su arquitectura de filtrado, manejo de reenvío y política local.

IV. Qué Puede Fallar y Cómo Detectarlo

Modo de Fallo 1: La Autenticación Aprueba Pero la Alineación Falla

Qué sucede:

  • SPF o DKIM devuelve aprobado
  • El reporte DMARC muestra dmarc=fail con reason=alignment_failure
  • El servidor receptor aún puede entregar el mensaje, dependiendo de la política DMARC y la reputación

Detección:

  • Revisar reportes agregados DMARC para filas donde auth_results.spf.result=pass o auth_results.dkim.result=pass pero policy_evaluated.dmarc=fail
  • Verificar si el dominio del remitente de sobre o el dominio de firma DKIM se alinea con el From del encabezado

Solución:

  • Configurar remitentes de terceros para usar dominios de remitente de sobre o de firma DKIM alineados
  • Usar alineación de subdominio si la coincidencia exacta no es factible
  • Verificar que los servicios transaccionales admitan firma DKIM con tu dominio

Modo de Fallo 2: DMARC Aprueba Pero el Mensaje Es Filtrado

Qué sucede:

  • El reporte DMARC muestra policy_evaluated.dmarc=pass
  • El mensaje no llega a la bandeja de entrada
  • No ocurre rechazo SMTP ni rebote

Detección:

  • Monitoreo de tasa de quejas a través de herramientas de postmaster (Google Postmaster Tools, Microsoft SNDS)
  • Métricas de participación que muestran bajas tasas de apertura o alta colocación en carpeta de spam
  • Monitoreo de reputación para IPs y dominios de envío

Solución:

  • Auditar reputación de envío y fuentes de quejas
  • Revisar contenido para patrones desencadenantes de spam
  • Verificar consentimiento de suscriptores e higiene de listas
  • Probar capacidad de entrega en múltiples proveedores de buzones

Modo de Fallo 3: El Reenvío Rompe la Autenticación

Qué sucede:

  • El remitente original aprueba DMARC
  • El reenviador retransmite el mensaje desde nueva IP
  • SPF falla (nueva IP no autorizada)
  • DKIM puede sobrevivir si el mensaje no se modifica
  • DMARC depende de la supervivencia de la alineación DKIM

Detección:

  • Reportes DMARC que muestran disposición forwarded o SPF fail con DKIM pass
  • Problemas de entrega reportados por usuarios que reenvían a cuentas personales

Solución:

  • Usar p=quarantine en lugar de p=reject para reducir el impacto del reenvío
  • Monitorear reportes DMARC para patrones de reenvío
  • Comunicarse con usuarios sobre comportamiento de reenvío

Modo de Fallo 4: Suplantación de Subdominio A Pesar del Cumplimiento del Dominio Principal

Qué sucede:

  • El dominio principal impone DMARC en p=reject
  • El subdominio carece de registro DMARC explícito
  • El atacante envía mensajes suplantados desde subdominio
  • La política DMARC se aplica, pero la evaluación de alineación puede diferir dependiendo del uso del subdominio

Detección:

  • Reportes DMARC que muestran fallos de autenticación para subdominios
  • Reportes de phishing dirigidos a direcciones de subdominio

Solución:

  • Publicar registros DMARC explícitos para subdominios activos
  • Usar sp=reject en el registro del dominio principal para imponer política de subdominio
  • Monitorear reportes DMARC para uso no autorizado de subdominios

V. Qué Documentar y Verificar

Las organizaciones que asumen que aprobar la autenticación significa cumplimiento DMARC introducen puntos ciegos operacionales. Documenta lo siguiente:

Identificadores autenticados para cada remitente:

  • Dominio del remitente de sobre (dominio de verificación SPF)
  • Dominio de firma DKIM (valor d=)
  • Dominio From del encabezado (remitente visible)
  • Si la alineación es relajada o estricta

Configuración del remitente por flujo de correo:

  • Correo transaccional: CRM, tickets de soporte, restablecimiento de contraseñas
  • Correo de marketing: Plataformas de boletines, campañas promocionales
  • Correo operacional: Notificaciones internas, alertas del sistema
  • Servicios de terceros: Herramientas SaaS, plugins, integraciones

Condiciones de fallo observadas en reportes DMARC:

  • Volumen de dmarc=fail con spf=pass o dkim=pass
  • Frecuencia de fallos relacionados con reenvío
  • Intentos de remitentes no autorizados
  • Patrones de suplantación de subdominios

Contexto de reputación y filtrado:

  • Tasas de quejas por dominio de envío e IP
  • Tendencias de colocación en carpeta de spam
  • Métricas de participación (tasas de apertura, tasas de eliminación)
  • Retroalimentación de herramientas de postmaster de receptores principales

VI. Cómo Skysnag Apoya la Verificación y Monitoreo de Alineación

Skysnag Protect identifica fallos de alineación, remitentes no autorizados y brechas de autenticación a través de flujos de correo y servicios de terceros.

Visibilidad de alineación:

  • Análisis de reportes DMARC agregados que muestran estado de SPF, DKIM y alineación por remitente
  • Detección de autenticación aprobada con alineación fallida
  • Identificación de servicios de terceros usando identificadores desalineados

Autorización de remitentes:

  • Inventario de fuentes de correo autorizadas y no autorizadas
  • Detección de TI en la sombra y remitentes de terceros no gestionados
  • Validación de inclusiones SPF y configuraciones de firma DKIM

Etapas de cumplimiento:

  • Cumplimiento gradual de políticas por dominio, subdominio y grupo de remitentes
  • Monitoreo de impacto antes de pasar de p=none a p=quarantine o p=reject
  • Recopilación de evidencia para programas de cumplimiento y auditoría

Inicia el monitoreo DMARC con Skysnag y verifica si tus remitentes autenticados se alinean con tu dominio:

VII. Conclusiones Clave

  • Pasar SPF o DKIM no significa pasar DMARC. La alineación requiere que el dominio autenticado coincida con el dominio del encabezado From.
  • Pasar DMARC no garantiza la colocación en la bandeja de entrada. Los proveedores de buzones evalúan la reputación, el contenido, las tasas de quejas y la interacción además de la autenticación.
  • La alineación DMARC puede fallar incluso cuando la autenticación pasa. Los desajustes del dominio del remitente del sobre (SPF) y los desajustes del dominio de firma DKIM causan fallos de alineación.
  • El reenvío y las listas de correo comúnmente rompen la autenticación. SPF falla cuando cambia la IP del relay. DKIM falla cuando se modifica el mensaje.
  • La suplantación de subdominios puede eludir la aplicación del dominio padre. Use registros DMARC explícitos de subdominio o sp=reject para aplicar la política de subdominios.
  • La autenticación es necesaria pero no suficiente. La capacidad de entrega depende de la autenticación, reputación, contenido y comportamiento del destinatario.
  • Los informes DMARC muestran dónde falla la alineación. Monitoree los informes agregados en busca de filas donde spf=pass o dkim=pass pero dmarc=fail.
  • Los remitentes externos comúnmente introducen brechas de alineación. Verifique que los servicios transaccionales, plataformas de marketing y herramientas SaaS usen identificadores alineados.
  • Las organizaciones deben documentar los identificadores autenticados por flujo de correo. El dominio del remitente del sobre, el dominio de firma DKIM y el dominio del encabezado From deben ser rastreados y validados.
  • Skysnag Protect identifica fallos de alineación y remitentes no autorizados. Use Skysnag para verificar la alineación, detectar shadow IT y aplicar la política de forma segura.