Enrutamiento de email mal configurado: la alerta de Microsoft sobre el spoofing interno (enero de 2026)
Por CaptainDNS
Publicado el 28 de marzo de 2026
- Microsoft reveló en enero de 2026 que las configuraciones MX que apuntan a servicios de terceros (antispam, archivado) crean un punto ciego explotado por los atacantes para suplantar dominios internos
- La plataforma Tycoon2FA generó 13 millones de correos de phishing bloqueados por Defender en un solo mes (octubre de 2025), explotando este vector combinado con ataques AiTM
- El trío SPF
~all+ DKIM ausente + DMARCp=nonedeja pasar el 100 % de los intentos de suplantación mediante enrutamiento MX indirecto - El análisis forense de los encabezados de email revela el mecanismo exacto: saltos inesperados en la cadena Received,
spf=softfail,dkim=none,dmarc=fail action=none - El plan de corrección en 5 pasos: DMARC progresivo hacia
p=reject, SPF-all, DKIM activado, conectores de terceros auditados, MX directo hacia Microsoft 365
En enero de 2026, el equipo de Microsoft Defender for Office 365 publicó una advertencia que sacudió a los equipos de seguridad: miles de organizaciones que usan Microsoft 365 eran vulnerables a una suplantación de identidad interna, no por un bug de software, sino por su propia configuración DNS. El mecanismo es simple y devastador. Cuando el registro MX de un dominio apunta a un servicio de terceros (pasarela antispam, solución de archivado, relay de filtrado) en lugar de apuntar directamente a Microsoft 365, los correos entrantes pasan por un intermediario que no recalcula correctamente los resultados de autenticación SPF, DKIM y DMARC. Los atacantes lo entendieron y explotan esta falla a gran escala.
No es un escenario teórico. Microsoft documentó que la plataforma de phishing-as-a-service Tycoon2FA generó por sí sola 13 millones de correos maliciosos bloqueados por Defender en octubre de 2025. Estos correos explotaban el enrutamiento MX indirecto combinado con técnicas de adversary-in-the-middle (AiTM) para robar credenciales y cookies de sesión, incluso de usuarios protegidos por autenticación multifactor. Los señuelos utilizados imitaban restablecimientos de contraseña, mensajes de RR. HH. y notificaciones de documentos compartidos, enviados desde la dirección interna de la víctima hacia sí misma.
Este artículo detalla el mecanismo técnico de este ataque, el análisis forense de los encabezados de email que permite detectarlo, un diagnóstico DNS en cinco minutos para saber si tu dominio es vulnerable y un plan de corrección completo.
Analiza tus encabezados de email
El contexto: ¿qué revela la advertencia de Microsoft de enero de 2026?
Un problema de enrutamiento, no de protocolo
La advertencia de Microsoft no trata sobre una vulnerabilidad en SPF, DKIM o DMARC en sí mismos. Estos protocolos funcionan exactamente como se diseñaron. El problema se encuentra en la arquitectura de enrutamiento de los correos.
En una configuración estándar, el registro MX de un dominio apunta directamente a los servidores Exchange Online Protection (EOP) de Microsoft 365:
captaindns.com. IN MX 10 captaindns-com.mail.protection.outlook.com.
Con esta configuración, Microsoft 365 recibe los correos directamente del emisor. Evalúa SPF verificando la IP de origen contra el registro SPF del dominio del sobre. Valida la firma DKIM. Aplica la política DMARC. Cada verificación se realiza en el contexto correcto.
Pero miles de organizaciones tienen un MX que apunta a un servicio de terceros:
captaindns.com. IN MX 10 mx.filtrado-terceros.com.
El servicio de terceros recibe el correo, realiza su procesamiento (antispam, archivado, análisis de contenido) y luego transmite el mensaje a Microsoft 365. El problema: cuando Microsoft 365 recibe el mensaje, la IP de origen es la del servicio de terceros, no la del emisor original. El contexto de autenticación ha cambiado.
El mecanismo de ataque en detalle
El atacante explota esta cadena de la siguiente manera:
Paso 1: reconocimiento. El atacante consulta el MX del dominio objetivo. Si el MX apunta a un servicio de terceros en lugar de *.mail.protection.outlook.com, el dominio es potencialmente vulnerable.
Paso 2: verificación de la postura de autenticación. El atacante verifica tres registros DNS:
_dmarc.captaindns.com: si la política esp=none, los fallos DMARC no provocan ninguna accióncaptaindns.com(TXT SPF): si el mecanismo es~all(softfail) en lugar de-all(hardfail), el fallo SPF se tolera- Selectores DKIM comunes: si no se publica ninguna clave DKIM, el campo
dkim=noneno activa nada
Paso 3: envío del correo suplantado. El atacante envía un correo desde un servidor que controla. Coloca la misma dirección en los campos From y To: por ejemplo, contabilidad@captaindns.com hacia contabilidad@captaindns.com. Este "self-spoofing" da la impresión de que el mensaje proviene de un colega interno.
Paso 4: tránsito a través del servicio de terceros. El MX del dominio enruta el correo hacia el servicio de terceros. Este realiza un primer nivel de filtrado. El problema: muchos servicios de terceros no verifican SPF/DKIM/DMARC en absoluto, o los verifican pero no propagan los resultados de manera explotable por Microsoft 365.
Paso 5: entrega en Microsoft 365. Microsoft 365 recibe el correo desde la IP del servicio de terceros. Sin el mecanismo Enhanced Filtering for Connectors (EFC), Exchange Online ve la IP del tercero, no la IP del atacante. El SPF pasa (porque la IP del tercero está en el SPF del tercero) o falla en softfail. El DKIM está ausente. El DMARC falla pero la política p=none no provoca ningún bloqueo. El correo llega a la bandeja de entrada.
Por qué "skip authentication" es el punto de ruptura
El problema fundamental es la configuración del conector entrante en Exchange Online. Cuando una organización configura un conector para recibir correos desde un servicio de terceros (Barracuda, Mimecast, Proofpoint, Sophos), el asistente de configuración suele proponer "confiar" en los resultados de autenticación del tercero, o "saltar la autenticación" para las IP del conector. En la práctica, muchos administradores activan esta opción para evitar falsos positivos: si el tercero ya verificó SPF/DKIM/DMARC, ¿por qué repetirlo?
El problema: Exchange Online deja entonces de verificar la autenticación contra la fuente original. Consume los encabezados Authentication-Results insertados por el tercero, o peor, evalúa SPF sobre la IP del conector (la del tercero) en lugar de la IP del emisor real. El encabezado Authentication-Results visible en la bandeja de entrada refleja los resultados vistos por el tercero, no los de la fuente real.
Microsoft introdujo Enhanced Filtering for Connectors (EFC) para corregir este problema. EFC pide a Exchange Online que remonte la cadena Received para identificar la IP del emisor original, saltando las IP conocidas del servicio de terceros (la "skip list"). Pero EFC no está activado por defecto. Las organizaciones que no configuraron EFC, o que lo configuraron con una skip list incompleta, siguen siendo vulnerables.
El self-spoofing: el correo interno que no lo es
El golpe de gracia de este ataque es el self-spoofing. El atacante coloca el mismo dominio en los campos From y To: rrhh@captaindns.com envía a juan.garcia@captaindns.com. Para el destinatario, el correo parece provenir de un colega. Pero el mecanismo es más insidioso: muchas organizaciones configuran reglas de transporte Exchange que tratan los correos "internos" de manera diferente. Un correo cuyo dominio From es un dominio interno puede no recibir el banner "Este correo proviene de un remitente externo", no estar sujeto a los mismos filtros antiphishing y mostrarse sin advertencia visual. El atacante explota no solo la confianza humana, sino también las excepciones de seguridad configuradas para las comunicaciones internas.
El rol crítico del servicio de terceros
El problema central es que el servicio de terceros actúa como un "blanqueador" involuntario de autenticación. Cuando retransmite el mensaje a Microsoft 365, reemplaza el contexto de autenticación original:
- La IP de origen cambia. Microsoft 365 ve la IP del servicio de terceros, no la del atacante. La verificación SPF se realiza sobre la IP incorrecta.
- Los encabezados Authentication-Results del tercero no son de confianza. Microsoft 365 no tiene razón para confiar en los resultados de autenticación insertados por el tercero.
- El Return-Path puede ser reescrito. Algunos servicios de terceros reescriben el sobre SMTP, enturbiando aún más las pistas.
Microsoft documentó que incluso los servicios de terceros que verifican correctamente SPF/DKIM/DMARC e insertan los encabezados correctos no resuelven el problema si Microsoft 365 no sabe mirar más allá de la IP del tercero para encontrar la IP del emisor original.
Es exactamente el problema que resuelve Enhanced Filtering for Connectors: permite a Exchange Online "saltar" la IP del tercero en la cadena Received y evaluar la autenticación sobre la IP real del emisor.
¿Cuál es la magnitud del problema?
El enrutamiento MX indirecto no es una configuración marginal. Según los datos publicados por los equipos de seguridad de Microsoft, una proporción significativa de los tenants de Microsoft 365 utiliza un servicio de terceros frente a Exchange Online. Las razones son múltiples y a menudo históricas:
- Herencia de migración: muchas organizaciones migraron a Microsoft 365 desde un alojamiento on-premise. Ya tenían un servicio antispam de terceros (Barracuda, Mimecast, Proofpoint, Sophos) y conservaron el enrutamiento existente durante la migración.
- Requisitos normativos: ciertos sectores (finanzas, salud, administración pública) imponen un archivado o filtrado de correos por un servicio de terceros certificado. El enrutamiento MX indirecto es el medio técnico habitual para cumplir con este requisito.
- Estrategia de defensa en profundidad: algunos equipos de seguridad consideran que apilar dos capas de filtrado (terceros + Defender) ofrece mejor protección. Es cierto para el filtrado antispam, pero el coste en términos de autenticación rara vez se mide.
- Desconocimiento del riesgo: antes de la advertencia de enero de 2026, la relación entre enrutamiento MX indirecto y debilitamiento de la autenticación de correo no estaba ampliamente documentada. La mayoría de las guías de despliegue de servicios de terceros no mencionan el impacto en SPF/DKIM/DMARC del lado de Microsoft 365.
El resultado: organizaciones que invierten en seguridad de correo (compra de un servicio antispam premium, despliegue de DMARC) se encuentran paradójicamente más vulnerables que las que usan únicamente Defender con un MX directo.
Tycoon2FA: la plataforma PhaaS que explota esta falla
Un servicio de phishing llave en mano
Tycoon2FA es una plataforma de phishing-as-a-service (PhaaS) activa desde agosto de 2023, identificada y documentada por Sekoia.io y por el Threat Intelligence Center de Microsoft. Funciona como un SaaS para cibercriminales: los operadores pagan una suscripción (alrededor de 120 dólares al mes en canales de Telegram dedicados) y reciben a cambio una infraestructura completa de phishing con paneles de control, plantillas de correos, páginas de inicio de sesión clonadas y recopilación automatizada de credenciales. La barrera de entrada es casi nula: no se requiere ninguna competencia técnica, el kit lo proporciona todo, desde el dominio de phishing hasta la página de captura.
La magnitud de la operación es masiva. Según las estimaciones consolidadas de los equipos de Threat Intelligence de Microsoft y Sekoia.io, Tycoon2FA genera más de 30 millones de correos de phishing al mes a través del conjunto de sus operadores. Microsoft informó haber bloqueado el 62 % de los correos de phishing dirigidos a sus usuarios en el primer semestre de 2025, pero el volumen restante basta para comprometer miles de cuentas. En marzo de 2026, Europol intentó desmantelar la infraestructura de Tycoon2FA en el marco de una operación coordinada. La plataforma volvió a estar operativa en 48 horas, habiendo migrado sus servidores a nuevas jurisdicciones.
Lo que distingue a Tycoon2FA de los kits de phishing clásicos es su capacidad para eludir la autenticación multifactor (MFA) mediante una técnica de adversary-in-the-middle (AiTM).
El mecanismo AiTM en detalle
El funcionamiento técnico se basa en un proxy inverso transparente. El punto crucial: el MFA no protege contra este ataque porque el proxy no intercepta el segundo factor en sí. Intercepta la cookie de sesión emitida por Microsoft 365 después de que el usuario haya completado con éxito toda la cadena de autenticación, MFA incluido. La víctima se autentica normalmente, en la infraestructura real de Microsoft, pero el token de sesión es capturado en tránsito.
Este es el desarrollo completo:
- La víctima recibe un correo de phishing que suplanta un dominio interno mediante el mecanismo de enrutamiento MX descrito anteriormente.
- El enlace en el correo pasa por una cadena de redirecciones. Microsoft documentó el uso de redirecciones a través de Google Maps (
maps.google.com/url?q=...) para eludir los filtros de reputación. La técnica es devastadora: los filtros de correo inspeccionan el dominio del enlace, venmaps.google.com(un dominio de confianza con reputación máxima) y lo dejan pasar. El parámetroq=contiene la URL real de la página de phishing, pero los filtros no decodifican sistemáticamente las redirecciones anidadas. La URL final lleva a una página de phishing alojada en un dominio efímero. - La página de phishing actúa como un proxy transparente hacia la verdadera página de inicio de sesión de Microsoft 365. El servidor Tycoon2FA se coloca entre el navegador de la víctima y
login.microsoftonline.com. Visualmente, la víctima ve una interfaz de inicio de sesión idéntica a la de Microsoft, con el logotipo de la organización, los colores personalizados y el branding de Entra ID. - La víctima ingresa su identificador y su contraseña. El proxy transmite las credenciales a Microsoft 365 en tiempo real. Microsoft las valida normalmente.
- Microsoft 365 solicita el segundo factor (MFA). El proxy retransmite la solicitud MFA a la víctima. La víctima ingresa su código TOTP o aprueba la notificación push. Desde el punto de vista de Microsoft, la autenticación es legítima.
- El proxy captura la cookie de sesión. Una vez completada la autenticación, Microsoft 365 emite una cookie de sesión. El proxy la intercepta antes de transmitirla a la víctima. La víctima recibe una cookie válida y accede a su correo normalmente, sin sospechar nada.
- El atacante usa la cookie de sesión robada para acceder a la cuenta desde otro navegador, sin necesidad de pasar nuevamente por el MFA. La cookie es válida durante la duración de la sesión (a menudo 24 horas o más según la política de la organización). El atacante puede leer los correos, exfiltrar archivos de OneDrive, enviar correos en nombre de la víctima y propagarse lateralmente dentro de la organización.
Las cifras documentadas por Microsoft
Los datos publicados por Microsoft en su boletín de enero de 2026 revelan la magnitud de la explotación:
| Métrica | Valor |
|---|---|
| Correos maliciosos bloqueados por Defender (octubre de 2025) | 13 millones |
| Plataforma PhaaS principal identificada | Tycoon2FA |
| Técnica de elusión de MFA | Adversary-in-the-middle (AiTM) |
| Técnica de ofuscación de URL | Redirecciones Google Maps |
| Principales señuelos | Restablecimiento de contraseña, mensajes de RR. HH., documentos compartidos |
| Vector de entrada | Enrutamiento MX indirecto + SPF ~all + DKIM ausente + DMARC p=none |
Estos 13 millones de correos corresponden únicamente a los mensajes bloqueados por Defender. Las organizaciones sin Defender for Office 365, o con configuraciones de filtrado menos estrictas, no se beneficiaron de esta protección.
Los señuelos utilizados
Las campañas de Tycoon2FA documentadas por Microsoft explotan escenarios con alta urgencia percibida:
- Restablecimiento de contraseña: "Tu contraseña caduca en 24 horas. Haz clic aquí para renovarla." El enlace lleva a la página AiTM.
- Mensajes de RR. HH.: "Nuevo documento para firmar para la actualización de tu contrato." El archivo adjunto o el enlace redirige a la página de phishing.
- Documentos compartidos: "María García ha compartido un archivo contigo en OneDrive." El correo imita una notificación legítima de SharePoint.
- Self-spoofing: en los casos más sofisticados, la dirección
Fromes idéntica a la direcciónTo. La víctima recibe un correo que parece provenir de sí misma o de un colega del mismo dominio.
El self-spoofing es particularmente eficaz porque los usuarios confían en los correos que provienen de su propio dominio. Un correo de rrhh@captaindns.com recibido por un empleado de captaindns.com no activa ninguna alerta humana.
Análisis forense de los encabezados: detectar el ataque
Cuando un correo sospechoso llega a un buzón de Microsoft 365, los encabezados contienen las pruebas del enrutamiento anormal. A continuación se explica cómo leerlos con un analizador de encabezados de email.
Ejemplo de encabezados de un correo suplantado
Este es un ejemplo realista anonimizado de encabezados provenientes de un correo de phishing que explota el enrutamiento MX indirecto. Todas las señales de alerta están presentes simultáneamente:
Return-Path: <bounce@malicious-relay.net>
Received: from mail-protection.captaindns.com (10.0.0.5) by
exchange01.captaindns.com (10.0.0.10) with SMTP; Thu, 9 Jan 2026 08:15:23 +0000
Received: from gateway.thirdparty-filter.com (203.0.113.50) by
mail-protection.captaindns.com with ESMTPS; Thu, 9 Jan 2026 08:15:21 +0000
Received: from unknown (198.51.100.77) by
gateway.thirdparty-filter.com with SMTP; Thu, 9 Jan 2026 08:15:19 +0000
Authentication-Results: mail-protection.captaindns.com;
spf=softfail (sender IP is 198.51.100.77) smtp.mailfrom=captaindns.com;
dkim=none (message not signed);
dmarc=fail action=none header.from=captaindns.com;
X-MS-Exchange-Organization-SCL: 5
From: Dirección RR. HH. <rrhh@captaindns.com>
To: juan.garcia@captaindns.com
Subject: Documento de política de RR. HH. para firmar - Acción requerida
Análisis línea por línea
Return-Path: <bounce@malicious-relay.net>
El Return-Path revela la dirección de rebote real. El dominio malicious-relay.net no tiene ninguna relación con captaindns.com. Esta discrepancia entre el Return-Path y el From mostrado (rrhh@captaindns.com) es la primera señal de alerta. En un correo legítimo enviado desde Microsoft 365, el Return-Path contiene el dominio de la organización o un subdominio de protection.outlook.com. Aquí, es la infraestructura del atacante la que aparece.
Cadena Received (leída de abajo hacia arriba):
Received: from unknown (198.51.100.77) by
gateway.thirdparty-filter.com with SMTP
Primer salto: el correo parte de una IP desconocida (198.51.100.77) identificada como unknown por el servicio de terceros. Es el servidor del atacante. La ausencia de resolución DNS inversa (sin nombre de host verificado) es una señal fuerte: los servidores de correo legítimos tienen un registro PTR configurado. El uso de SMTP simple (no ESMTPS) confirma que el emisor no soporta cifrado TLS, lo cual es anormal para un servidor empresarial en 2026.
Received: from gateway.thirdparty-filter.com (203.0.113.50) by
mail-protection.captaindns.com with ESMTPS
Segundo salto: el servicio de terceros (gateway.thirdparty-filter.com) retransmite hacia Exchange Online. Es esta IP (203.0.113.50) la que Microsoft 365 ve como origen. El contexto de autenticación se evalúa sobre esta IP, no sobre 198.51.100.77. El servicio de terceros aceptó el mensaje y lo transmitió.
Received: from mail-protection.captaindns.com (10.0.0.5) by
exchange01.captaindns.com (10.0.0.10) with SMTP
Tercer salto: enrutamiento interno de Microsoft 365 hacia la bandeja de entrada. Las direcciones IP en 10.x.x.x confirman un enrutamiento interno. Este salto es normal.
Authentication-Results: el triple fallo
Esta es la línea más reveladora, y contiene tres fallos simultáneos:
spf=softfail (sender IP is 198.51.100.77): la IP de origen real (198.51.100.77, el servidor del atacante) no está en el SPF decaptaindns.com. Con un mecanismo~all, es un softfail, no un reject. El softfail se trata como una advertencia, no como un bloqueo.dkim=none (message not signed): no hay ninguna firma DKIM presente. El atacante no posee la clave privada DKIM decaptaindns.com, por lo que no puede firmar. El servicio de terceros tampoco agregó una firma. La ausencia de DKIM priva a DMARC de su segundo vector de alineación.dmarc=fail action=none: DMARC falla (ni SPF ni DKIM pasan con alineación de dominio). Peroaction=nonesignifica que la política DMARC del dominio esp=none, por lo que no se toma ninguna acción a pesar del fallo. El correo se entrega normalmente.
X-MS-Exchange-Organization-SCL: 5
El Spam Confidence Level (SCL) está en 5 en una escala de 0 a 9. Un SCL de 5 indica un nivel de sospecha moderado. Por defecto, Exchange Online pone en cuarentena los mensajes con un SCL de 6 o más. Un SCL de 5 pasa justo por debajo del umbral de bloqueo predeterminado. Defender detectó señales sospechosas (fallos de autenticación, Return-Path incoherente), pero no las suficientes para bloquear categóricamente con la configuración actual.
From y To en el mismo dominio: self-spoofing
El From muestra Dirección RR. HH. <rrhh@captaindns.com> y el To es juan.garcia@captaindns.com. Mismo dominio. En Outlook, el usuario ve un correo de "Dirección RR. HH." con la foto y el cargo asociados a rrhh@captaindns.com en la libreta de direcciones. El banner "Este correo proviene de un remitente externo" puede estar ausente si la organización ha configurado excepciones para los dominios internos.
Subject: Documento de política de RR. HH. para firmar - Acción requerida
El asunto combina dos palancas psicológicas: la autoridad ("Dirección RR. HH.", "política de RR. HH.") y la urgencia ("Acción requerida"). Este tipo de señuelo está documentado por Microsoft como uno de los más eficaces en las campañas de Tycoon2FA.
Comparación con un correo legítimo
Para contrastar, estos son los encabezados de un correo legítimo enviado desde la misma organización:
Return-Path: <rrhh@captaindns.com>
Authentication-Results: mail-protection.captaindns.com;
spf=pass (sender IP is 40.107.22.83) smtp.mailfrom=captaindns.com;
dkim=pass (signature was verified) header.d=captaindns.com;
dmarc=pass action=none header.from=captaindns.com;
X-MS-Exchange-Organization-SCL: 1
From: Dirección RR. HH. <rrhh@captaindns.com>
To: juan.garcia@captaindns.com
Las diferencias son claras: el Return-Path corresponde al dominio From, SPF pasa con una IP de Microsoft (40.107.x.x), DKIM pasa con una firma verificada, DMARC pasa y el SCL está en 1 (confianza alta). Es el perfil típico de un correo legítimo.
Lo que revela el conjunto
Combinando estos elementos, el diagnóstico es claro:
- El correo no proviene de la infraestructura de captaindns.com (Return-Path en
malicious-relay.net) - Transitó por un servicio de terceros que no bloqueó la suplantación
- Triple fallo de autenticación: SPF softfail, DKIM ausente, DMARC fail sin consecuencias
- El SCL moderado indica que Defender tiene dudas, pero la configuración actual no permite el bloqueo
- El self-spoofing (mismo dominio en From y To) explota la confianza en las comunicaciones internas
Para detectar sistemáticamente este tipo de correo, analiza tus encabezados con un analizador de encabezados y busca estos cuatro marcadores: cadena Received con salto inesperado desde una IP desconocida, spf=softfail, dkim=none y dmarc=fail action=none.
Diagnóstico en 5 minutos: ¿tu dominio es vulnerable?
Tres comandos DNS son suficientes para evaluar tu exposición. Abre un terminal y ejecuta las siguientes verificaciones.
Verificación 1: ¿a dónde apunta tu MX?
dig MX captaindns.com +short
Resultado seguro:
10 captaindns-com.mail.protection.outlook.com.
El MX apunta directamente a Microsoft 365. Los correos llegan sin intermediario. La autenticación se evalúa sobre la IP del emisor original.
Resultado en riesgo:
10 mx.filtrado-terceros.com.
20 mx2.filtrado-terceros.com.
El MX apunta a un servicio de terceros. Todos los correos entrantes pasan por este intermediario antes de llegar a Microsoft 365. Si Enhanced Filtering for Connectors no está activado, la autenticación se evalúa sobre la IP del tercero.
Resultado mixto (verificar):
10 mx.filtrado-terceros.com.
20 captaindns-com.mail.protection.outlook.com.
El MX prioritario es el servicio de terceros, pero Microsoft 365 está como respaldo. En funcionamiento normal, todo el tráfico pasa por el tercero. El riesgo es idéntico al escenario anterior.
Verificación 2: ¿cuál es tu política DMARC?
dig TXT _dmarc.captaindns.com +short
Resultado vulnerable:
"v=DMARC1; p=none; rua=mailto:dmarc@captaindns.com"
La política p=none significa que los fallos DMARC se reportan pero no se toma ninguna acción sobre los correos. Combinada con un enrutamiento MX indirecto, es una puerta abierta.
Resultado parcialmente protegido:
"v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@captaindns.com"
La política p=quarantine envía a spam los correos que fallan DMARC, pero pct=50 significa que solo la mitad de los correos está sujeta a esta política. La otra mitad se trata como si la política fuera p=none.
Resultado protegido:
"v=DMARC1; p=reject; rua=mailto:dmarc@captaindns.com; ruf=mailto:dmarc-forensic@captaindns.com"
La política p=reject pide a los servidores de recepción que rechacen los correos que fallan DMARC. Es la protección máxima.
Verificación 3: ¿cuál es tu mecanismo SPF terminal?
dig TXT captaindns.com +short | grep spf
Resultado vulnerable:
"v=spf1 include:spf.protection.outlook.com ~all"
El mecanismo ~all (softfail) indica que las IP no listadas probablemente no deberían enviar en nombre de este dominio, pero el resultado es un softfail, no un reject. Los servidores de recepción son libres de ignorarlo.
Resultado protegido:
"v=spf1 include:spf.protection.outlook.com -all"
El mecanismo -all (hardfail) indica que cualquier IP no listada está explícitamente no autorizada. Los servidores de recepción que respetan SPF rechazarán esos correos.
Matriz de vulnerabilidad
| MX | DMARC | SPF | DKIM | Nivel de riesgo |
|---|---|---|---|---|
| Terceros | p=none | ~all | Ausente | Crítico |
| Terceros | p=none | -all | Ausente | Alto |
| Terceros | p=quarantine | ~all | Ausente | Alto |
| Terceros | p=quarantine | -all | Activo | Moderado |
| Terceros | p=reject | -all | Activo | Bajo (si EFC activado) |
| Directo M365 | p=reject | -all | Activo | Mínimo |
Si tu dominio se encuentra en las líneas "Crítico" o "Alto", la corrección es urgente. Pasa a la siguiente sección.
Plan de corrección en 5 pasos
Paso 1: DMARC progresivo hacia p=reject
Nunca pases directamente de p=none a p=reject. La escalada progresiva evita bloquear correos legítimos de cuya existencia no tienes conocimiento (newsletters, SaaS, CRM que envían en nombre de tu dominio).
Fase 1: monitorización (2 semanas mínimo)
_dmarc.captaindns.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@captaindns.com; ruf=mailto:dmarc-forensic@captaindns.com; fo=1"
La opción fo=1 solicita un informe forense por cada fallo individual (SPF o DKIM), no solo cuando ambos fallan. Analiza los informes agregados (rua) para identificar todas las fuentes de envío legítimas.
Fase 2: cuarentena progresiva (2 semanas)
_dmarc.captaindns.com. IN TXT "v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@captaindns.com"
Solo el 10 % de los correos que fallan DMARC se envían a cuarentena. Monitoriza los informes y las quejas de los usuarios.
Fase 3: cuarentena completa (2 semanas)
_dmarc.captaindns.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@captaindns.com"
El 100 % de los fallos se ponen en cuarentena. Si no se reporta ningún falso positivo, pasa a la siguiente fase.
Fase 4: reject progresivo (1 semana)
_dmarc.captaindns.com. IN TXT "v=DMARC1; p=reject; pct=10; rua=mailto:dmarc-reports@captaindns.com"
El 10 % de los fallos se rechazan, el resto se mantiene en cuarentena.
Fase 5: reject completo
_dmarc.captaindns.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@captaindns.com; ruf=mailto:dmarc-forensic@captaindns.com"
Protección máxima. Todo correo que falla DMARC es rechazado por el servidor de recepción.
El proceso completo toma aproximadamente de 7 a 9 semanas. No acortes las fases: cada periodo de observación revela fuentes de envío que habías olvidado. Un servicio de facturación SaaS, una antigua herramienta de marketing, un formulario de contacto que envía a través de un ESP no configurado en tu SPF.
Paso 2: SPF en hardfail (-all)
Reemplaza ~all por -all en tu registro SPF:
captaindns.com. IN TXT "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
Antes de modificar, verifica que todas tus fuentes de envío legítimas estén incluidas en el registro SPF. Un hardfail combinado con una fuente olvidada bloqueará correos legítimos.
Puntos de atención:
- Número de lookups DNS: SPF permite un máximo de 10 lookups DNS recursivos. Cada
include:cuenta como un lookup, más los anidados. Por encima de 10, el resultado es unpermerrory la evaluación falla. - Incluye todas tus fuentes: Microsoft 365, Google Workspace, ESP (Mailgun, SendGrid, Amazon SES), CRM (HubSpot, Salesforce), herramientas de ticketing.
- Prueba antes de publicar: utiliza nuestra herramienta de verificación DMARC para validar tu configuración antes de ponerla en producción.
Paso 3: activar DKIM
DKIM es la pieza que falta en la mayoría de las configuraciones vulnerables. Sin DKIM, DMARC solo puede apoyarse en SPF para la alineación. Si SPF falla (lo cual sucede sistemáticamente en un escenario de enrutamiento indirecto), DMARC también falla.
En Microsoft 365:
- Accede al portal Defender (
security.microsoft.com) - Navega a Email & collaboration > Policies & rules > Threat policies > Email Authentication Settings > DKIM
- Selecciona tu dominio
- Activa "Sign messages for this domain with DKIM signatures"
- Microsoft genera dos registros CNAME para publicar en tu DNS:
selector1._domainkey.captaindns.com. CNAME selector1-captaindns-com._domainkey.captaindns.onmicrosoft.com.
selector2._domainkey.captaindns.com. CNAME selector2-captaindns-com._domainkey.captaindns.onmicrosoft.com.
- Publica los CNAME, espera la propagación DNS (generalmente de 15 a 30 minutos) y luego valida en el portal Defender.
Con DKIM activo, incluso si SPF falla por el enrutamiento indirecto, DMARC puede pasar mediante la alineación DKIM, siempre que el servicio de terceros no modifique el cuerpo del mensaje ni los encabezados firmados.
Paso 4: auditar los conectores y activar el filtrado mejorado
Enhanced Filtering for Connectors (EFC) es la solución técnica que Microsoft recomienda para las organizaciones que deben conservar un enrutamiento MX indirecto. EFC permite a Exchange Online "mirar más allá" de la IP del servicio de terceros para encontrar la IP del emisor original en la cadena Received.
Activación en Exchange Online:
- Accede al Exchange Admin Center (
admin.exchange.microsoft.com) - Navega a Mail flow > Connectors
- Identifica el conector entrante desde tu servicio de terceros
- En las propiedades del conector, activa "Enhanced Filtering for Connectors"
- Configura las IP del servicio de terceros a "saltar" (skip listing)
Una vez activado EFC, Exchange Online remonta la cadena Received para encontrar la última IP externa antes del servicio de terceros. La evaluación de SPF, DKIM y DMARC se realiza sobre esta IP, restaurando el contexto de autenticación correcto.
Puntos de atención:
- Prueba EFC en modo auditoría antes de aplicarlo en producción
- Asegúrate de que las IP del servicio de terceros en la skip list estén actualizadas
- Verifica que el servicio de terceros no reescriba los encabezados Received de forma que impida a EFC encontrar la IP de origen
Paso 5: considerar un MX directo hacia Microsoft 365
La solución más radical y eficaz es eliminar al intermediario. Si tu servicio de terceros se usa para el filtrado antispam, Microsoft Defender for Office 365 (plan 1 o plan 2) ofrece capacidades equivalentes o superiores:
- Exchange Online Protection (EOP): incluido en todas las licencias de Microsoft 365, proporciona un filtrado antispam y antimalware básico.
- Defender for Office 365 Plan 1: añade Safe Links (reescritura y análisis de URLs en tiempo real), Safe Attachments (detonación en sandbox) y antiphishing.
- Defender for Office 365 Plan 2: añade Threat Explorer, Automated Investigation and Response (AIR), Attack Simulation Training y Threat Trackers.
Si el servicio de terceros se usa para archivado o cumplimiento normativo, existen soluciones de archivado que funcionan en sentido descendente (journal rules) sin requerir un enrutamiento MX indirecto.
Para pasar a MX directo:
captaindns.com. IN MX 10 captaindns-com.mail.protection.outlook.com.
Elimina las entradas MX antiguas que apuntan al servicio de terceros. Actualiza tu SPF si es necesario. Verifica que tus conectores de Exchange Online estén configurados correctamente.
Más allá de la autenticación de email: la cuestión del MFA
El enrutamiento MX indirecto abre la puerta al phishing. Pero la advertencia de Microsoft recuerda que Tycoon2FA no se limita a robar contraseñas. La plataforma roba sesiones autenticadas, eludiendo el MFA. La corrección del enrutamiento de email no es suficiente si tu MFA sigue siendo vulnerable a los ataques AiTM.
Por qué el MFA clásico ya no protege
El MFA basado en códigos TOTP (aplicaciones de autenticación como Microsoft Authenticator en modo código, Google Authenticator) o notificaciones push es vulnerable a los proxies AiTM. El mecanismo es estructural: el código TOTP es un secreto compartido entre el usuario y el servidor. Si un proxy se coloca entre ambos, captura el código en tránsito y lo reproduce inmediatamente. La notificación push es aún más fácil de explotar: el proxy desencadena la solicitud de autenticación en el servidor real, el usuario aprueba en su teléfono y el proxy captura la cookie de sesión resultante.
Esto no significa que el MFA sea inútil. Sigue protegiendo contra el credential stuffing, los ataques de diccionario y las filtraciones de bases de datos. Pero contra el phishing AiTM, se necesita una solución resistente al phishing.
FIDO2 y passkeys: la única solución resistente al phishing
Las llaves FIDO2 (YubiKey, Feitian, Google Titan) y las passkeys (implementadas en Windows Hello, Apple iCloud Keychain, Android) ofrecen una resistencia nativa al phishing. El mecanismo se basa en la vinculación al origen (origin binding):
- Durante el registro, la llave FIDO2 o la passkey se vincula a un dominio preciso (por ejemplo,
login.microsoftonline.com). - Durante la autenticación, el navegador verifica automáticamente que el dominio de la página corresponde al dominio registrado. Si la página es un proxy de phishing en
login-microsoftonline.attacker.com, el navegador se niega a enviar las credenciales. - No hay secreto compartido que interceptar. La autenticación utiliza un mecanismo challenge-response basado en un par de claves asimétricas. Incluso si el atacante intercepta el intercambio, no puede reproducirlo.
Un proxy AiTM no puede eludir este mecanismo: el navegador verifica el origen a un nivel que el proxy no puede falsificar. Esta es la razón por la que Microsoft, Google y Apple impulsan colectivamente la adopción de las passkeys desde 2024.
MFA number matching como solución intermedia
Si el despliegue de FIDO2/passkeys no es inmediato, activa como mínimo el number matching en Microsoft Authenticator. En lugar de un simple "Aprobar / Rechazar", el usuario debe ingresar un número de dos dígitos mostrado en la pantalla de inicio de sesión. Esta medida no protege contra un proxy AiTM sofisticado (el proxy puede mostrar el número), pero bloquea los ataques de MFA fatigue (bombardeo de notificaciones push) y añade una fricción que reduce la tasa de éxito de los ataques.
Activación en Entra ID:
- Accede al Microsoft Entra Admin Center (
entra.microsoft.com) - Navega a Protection > Authentication methods > Microsoft Authenticator
- En la pestaña Configure, activa "Require number matching for push notifications"
- Aplica a todos los usuarios o a un grupo piloto
La prioridad sigue siendo el despliegue de FIDO2/passkeys para las cuentas con privilegios elevados (administradores, directivos, equipos financieros), y luego la extensión progresiva a todos los usuarios.
El rol de ARC en las cadenas de relay
El protocolo ARC (Authenticated Received Chain) fue diseñado precisamente para resolver el problema de pérdida de contexto de autenticación durante el tránsito a través de intermediarios. ARC permite a cada relay firmar los resultados de autenticación que observó, creando una cadena de confianza verificable.
En teoría, si el servicio de terceros implementa ARC correctamente:
- El servicio de terceros recibe el correo y evalúa SPF/DKIM/DMARC
- Agrega un conjunto de encabezados ARC (
ARC-Authentication-Results,ARC-Message-Signature,ARC-Seal) documentando los resultados observados - Microsoft 365 recibe el correo y verifica la cadena ARC
- Si la cadena ARC es válida y proviene de un emisor ARC de confianza, Microsoft 365 puede utilizar los resultados de autenticación originales en lugar de sus propios resultados (que están distorsionados por el enrutamiento indirecto)
En la práctica, la eficacia de ARC depende de dos condiciones: el servicio de terceros debe implementar ARC (lo cual no es sistemático) y Microsoft 365 debe confiar en el emisor ARC (configurable en el portal Defender). Sin estas dos condiciones, ARC no cambia nada.
Microsoft recomienda ARC como solución complementaria, pero no como sustituto de Enhanced Filtering for Connectors o del paso a MX directo.
Vigilancia y respuesta ante incidentes
La protección del enrutamiento de email no es un proyecto puntual. Los atacantes adaptan sus técnicas, las configuraciones evolucionan y se agregan nuevos servicios de envío regularmente. Una vigilancia activa es necesaria para detectar rápidamente cualquier regresión o intento de explotación.
Configurar las alertas en Microsoft Defender
Microsoft Defender for Office 365 permite crear alertas personalizadas que detectan los patrones de ataque descritos en este artículo:
Alerta sobre fallos DMARC recurrentes:
En el portal Defender (security.microsoft.com), accede a Email & collaboration > Explorer. Filtra por DMARC = fail y action = none para tu dominio. Si observas un volumen anormal de fallos DMARC sin acción, es la señal de que tu política p=none está siendo explotada. Configura una alerta automatizada para ser notificado cuando el volumen supere un umbral (por ejemplo, más de 50 fallos DMARC por día para un dominio interno).
Alerta sobre self-spoofing:
Busca correos donde el campo From contenga un dominio interno pero el Return-Path contenga un dominio externo. Este patrón es característico del self-spoofing. En Exchange Online, una regla de flujo de correo (transport rule) puede detectar esta condición y agregar una advertencia visual al mensaje o ponerlo en cuarentena.
Monitorización de informes DMARC agregados:
Los informes DMARC agregados (enviados a la dirección rua) contienen los resultados de autenticación de todos los correos enviados en nombre de tu dominio. Analízalos al menos una vez por semana. Un pico repentino de fallos desde IP desconocidas indica una campaña de suplantación en curso. Herramientas gratuitas como DMARC Analyzer, Postmark DMARC o los informes agregados de Microsoft permiten visualizar estos datos sin procesamiento manual.
¿Qué hacer si detectas un ataque en curso?
Si identificas correos de phishing que explotan el enrutamiento MX indirecto contra tu dominio:
- Activa inmediatamente EFC si no lo has hecho. Es la medida más rápida para restaurar el contexto de autenticación correcto.
- Pasa DMARC a
p=quarantinecomo mínimo, incluso sin la escalada progresiva recomendada. En una situación de ataque activo, el riesgo de falsos positivos es secundario frente al riesgo de compromiso. - Bloquea las IP de origen identificadas en los encabezados Received mediante las reglas de flujo de correo de Exchange Online o a través del servicio de terceros.
- Informa a los usuarios afectados. Si se entregaron correos de self-spoofing, los usuarios deben saber que no deben hacer clic en los enlaces ni abrir los archivos adjuntos.
- Verifica las conexiones sospechosas en los registros de auditoría de Entra ID. Si el ataque AiTM logró capturar cookies de sesión, verás conexiones desde IP inusuales poco después de la entrega de los correos de phishing.
- Revoca las sesiones activas de las cuentas potencialmente comprometidas a través de Entra ID (
Revoke Sessions). Fuerza un cambio de contraseña y una reautenticación MFA.
Automatizar la detección a largo plazo
Para las organizaciones con un volumen significativo de correos, la automatización de la detección es indispensable. Microsoft Sentinel (el SIEM en la nube de Microsoft) puede ingerir los registros de Exchange Online y disparar playbooks automatizados bajo las siguientes condiciones:
- Volumen anormal de correos con
dmarc=fail action=nonepara un dominio interno - Correos entrantes donde el dominio
Fromes un dominio interno pero la IP de origen no está en la lista de IP autorizadas - Conexiones de Entra ID desde una IP geográficamente incoherente en los minutos siguientes a la entrega de un correo sospechoso
Estas automatizaciones transforman una detección reactiva ("encontramos un correo sospechoso") en una detección proactiva ("el sistema aisló el correo y bloqueó la cuenta antes de que el usuario hiciera clic").
Checklist de protección completa
Esta es la checklist consolidada para proteger tu dominio contra el vector de ataque documentado por Microsoft. Cada elemento está clasificado por prioridad.
Prioridad crítica (semana 1)
- Verificar tu MX:
dig MX captaindns.com +short - Verificar tu política DMARC:
dig TXT _dmarc.captaindns.com +short - Verificar tu mecanismo SPF terminal:
dig TXT captaindns.com +short - Si MX indirecto + DMARC p=none: activar Enhanced Filtering for Connectors inmediatamente
- Activar DKIM para tu dominio en Microsoft 365
Prioridad alta (semanas 2 a 4)
- Comenzar la escalada progresiva de DMARC hacia p=quarantine
- Reemplazar SPF
~allpor-alltras inventario de fuentes de envío - Auditar los conectores entrantes en Exchange Online
- Verificar la configuración de IP de la skip list para EFC
- Activar el number matching en Microsoft Authenticator
Prioridad media (meses 2 a 3)
- Continuar la escalada DMARC hacia p=reject
- Evaluar la migración hacia un MX directo a Microsoft 365
- Comenzar el despliegue de FIDO2/passkeys para cuentas con privilegios
- Configurar los emisores ARC de confianza si se mantiene el enrutamiento indirecto
- Establecer un seguimiento regular de los informes DMARC agregados
Prioridad baja (trimestre siguiente)
- Extender FIDO2/passkeys a todos los usuarios
- Eliminar el enrutamiento MX indirecto si no es necesario
- Automatizar el análisis de informes DMARC con una herramienta dedicada
- Formar a los usuarios para reconocer los correos de phishing
Lo que la advertencia de Microsoft cambia para tu organización
La advertencia de enero de 2026 no reveló un bug. Puso de manifiesto un punto ciego arquitectónico que los atacantes explotan a gran escala. La combinación enrutamiento MX indirecto + SPF softfail + DKIM ausente + DMARC p=none es una configuración que miles de organizaciones usan sin saber que es vulnerable.
La corrección no es un parche de software. Es un trabajo de configuración DNS y arquitectura de email. Algunas organizaciones lo corregirán en un día (activar DKIM, pasar SPF a hardfail, activar EFC). Otras necesitarán varios meses para migrar su MX y desplegar FIDO2.
Las tres acciones inmediatas:
- Diagnostica ahora. Los tres comandos
digde la sección de diagnóstico toman 30 segundos. Sabrás inmediatamente si tu dominio está en la zona crítica. - Activa Enhanced Filtering for Connectors si tu MX apunta a un tercero. Es la corrección más rápida con la mejor relación impacto/esfuerzo.
- Activa DKIM. Es la pieza que falta en la mayoría de las configuraciones vulnerables. Con DKIM activo, DMARC puede pasar incluso cuando SPF falla por el enrutamiento indirecto.
El objetivo final es simple: tu dominio debe estar protegido por SPF -all, DKIM activo y DMARC p=reject. No es un ideal teórico, es la línea base que Google, Yahoo y Microsoft exigen a los remitentes desde 2024. La advertencia de enero de 2026 recuerda que los correos terminan en spam cuando esta línea base no se alcanza, y peor aún, que los atacantes explotan activamente los dominios que no la cumplen.
