Microsoft construyó RejectDirectSend para cerrar un hueco específico: correo sin autenticar que dice venir del propio dominio interno de una organización. Investigadores de ReliaQuest descubrieron que el control puede evadirse por completo dejando vacío un solo campo SMTP. Sin credenciales robadas. Sin una vulnerabilidad de software en el sentido tradicional. Solo un mensaje enviado sin nada en el remitente del sobre.
Lo Que RejectDirectSend Debía Resolver
Direct Send es la función de Microsoft 365 que permite a impresoras, escáneres, aplicaciones de negocio y otros dispositivos enviar correo a través de la propia infraestructura de un tenant sin autenticarse primero. Es conveniente, y también ha sido un vector de suplantación bien documentado: un atacante externo que encuentra el endpoint de envío predecible de un tenant puede enviar correo que parece generado internamente. La respuesta de Microsoft fue RejectDirectSend, una configuración que bloquea los mensajes de Direct Send sin autenticar cuando el dominio en el remitente del sobre SMTP coincide con un dominio que la organización posee.
Esa descripción contiene el hueco. RejectDirectSend comprueba un dominio. Nunca contempla qué sucede cuando no hay ningún dominio que comprobar.
La Evasión: MAIL FROM Sin Nada Después
Cada transacción SMTP lleva dos identidades de remitente. La que ven los destinatarios es el encabezado From visible. La que usan los servidores de correo para el enrutamiento y la autenticación es el remitente del sobre, establecido por el comando MAIL FROM durante la conversación SMTP. Un mensaje puede enviarse legítimamente con un remitente de sobre vacío, escrito como MAIL FROM:<>, una ruta de retorno nula usada más comúnmente para mensajes de rebote, de modo que estos no puedan generar a su vez más rebotes.
ReliaQuest encontró atacantes reutilizando ese mecanismo legítimo. Enviar un mensaje con MAIL FROM:<>, un remitente de sobre vacío, mientras el encabezado From visible sigue mostrando una dirección interna falsificada, deja a RejectDirectSend sin nada que evaluar. El control está diseñado para comparar un dominio contra una lista de dominios aceptados. Un campo vacío no es un dominio que falla la comparación. Es la ausencia de una comparación. La propia documentación de Direct Send de Microsoft describe que la configuración aplica cuando el dominio del remitente del sobre es un dominio aceptado; no dice nada sobre qué ocurre cuando ese campo está vacío, porque el control nunca fue construido pensando en ese caso.
Lo Que Realmente Muestran los Encabezados de Autenticación
Este no es un mensaje que se cuela silenciosamente sin que nadie lo note. SPF y DKIM regresan sin resultado, ya que no hay un dominio de remitente de sobre que SPF pueda evaluar en primer lugar, y DMARC falla de forma directa. Sobre el papel, cada señal que un defensor querría tener está presente y apuntando a phishing. En un caso que ReliaQuest documentó, un mensaje falló todas las comprobaciones de autenticación de remitente y aun así fue clasificado como phishing de alta confianza por el filtrado posterior, pero llegó a la bandeja de entrada de todas formas, porque la dirección ejecutiva falsificada estaba, casualmente, en una lista de remitentes permitidos. RejectDirectSend ya había dejado entrar el mensaje al flujo de correo del tenant antes de que ocurriera cualquiera de esas evaluaciones. El fallo de autenticación fue real, quedó registrado y fue correcto. Simplemente llegó después de que ya se había tomado la decisión que importaba.
Quién Está Siendo Realmente Objetivo
ReliaQuest revisó casos desde septiembre de 2025 hasta agosto de 2026 y encontró un patrón claro sobre quién recibe estos mensajes de sobre vacío. El cuarenta por ciento fue dirigido a altos directivos. El veinticinco por ciento fue a gerentes y personal de ventas. El veinte por ciento llegó a colaboradores individuales, y el quince por ciento restante cayó en buzones de cuentas compartidas o de servicio. Los señuelos se inclinaban hacia procesos de negocio, no hacia teatro de urgencia: los avisos de compartición de archivos fueron la plantilla individual más común, seguidos de solicitudes de pago y remesas, invitaciones de adquisiciones, ofertas de préstamo o inversión, e invitaciones a reuniones. Ninguno de estos necesita un clic movido por el pánico. Necesitan solo una interacción de negocio ordinaria que resulte creíble, desde una dirección que parece pertenecer al interior del edificio.
Por Qué Esto Está Exactamente en el Punto Ciego de DMARC, No Fuera de Él
La mayoría de las campañas que vale la pena documentar pasan DMARC limpiamente y no le dejan nada que decir al protocolo. Esta es diferente, y más incómoda, porque aquí DMARC sí dice algo. Falla, correctamente, exactamente como fue diseñado. El hueco no está en lo que DMARC evalúa. Está en un control posterior que debía imponer una consecuencia a ese fallo y en su lugar nunca llegó a invocarse, porque fue construido para comprobar un campo que los atacantes aprendieron que podían simplemente dejar vacío. Una política DMARC estricta protege a un dominio de ser suplantado en la internet abierta. Hace muy poco por un control del lado del tenant con su propia definición, separada y más estrecha, de lo que cuenta como un dominio que merece ser comprobado.
Qué Significa Esto Para Tu Programa
No asumas que un control anti-suplantación con nombre cubre todas las entradas de ese vector de suplantación. RejectDirectSend hace un trabajo real contra el abuso de Direct Send para el que fue diseñado. No fue diseñado contra un remitente de sobre vacío, y los controles con lógica estrecha y específica tienden a tener exactamente este tipo de caso límite justo fuera de su alcance.
Audita tus listas de remitentes permitidos para direcciones ejecutivas y de finanzas. El caso que llegó a la bandeja de entrada aquí lo hizo porque una dirección interna falsificada ya estaba en una lista de permitidos. Una lista construida para reducir falsos positivos en remitentes internos legítimos es también, en silencio, una evasión para cualquiera que logre falsificar esas mismas direcciones.
Genera alertas sobre la combinación, no solo sobre el fallo. Un mensaje con SPF sin resultado, DKIM ausente y DMARC fallando, que llega con un nombre visible que coincide con el de un ejecutivo, es un patrón específico y detectable sin importar qué mecanismo de entrega lo dejó pasar. Construye la regla alrededor de esa combinación en lugar de confiar en que algún control anterior ya lo haya detectado.
Pregunta a tu proveedor, y a Microsoft, cómo se comporta hoy RejectDirectSend ante un remitente de sobre nulo. Este es el tipo de hueco que se corrige una vez que se hace público. Confirma el comportamiento actual de tu tenant en lugar de asumir que la mitigación del trimestre pasado sigue vigente.
La Conclusión
RejectDirectSend fue una solución genuina para un problema real de suplantación, y lo sigue siendo, para el caso específico que fue construido para comprobar. Lo que documentó ReliaQuest no es un fallo de DMARC. Es un recordatorio de que los controles que las organizaciones superponen sobre DMARC para hacer cumplir sus veredictos pueden tener sus propios huecos, huecos sobre los que una política DMARC estricta no tiene ninguna visibilidad ni capacidad de cerrar. El mensaje falló la autenticación exactamente como debía. Algo más debía actuar sobre ese fallo, y un solo campo vacío bastó para asegurarse de que nunca lo hiciera.
DMARC dijo la verdad en cada mensaje de esta campaña. El fallo ocurrió una capa más abajo, en un control que la mayoría de los equipos de seguridad nunca piensan en probar contra un campo vacío. Excello Mail te da visibilidad continua y en lenguaje claro sobre tu postura de autenticación real, para que huecos como este aparezcan antes de que un atacante los encuentre primero. Regístrate gratis en Excello Mail y mira hoy tu imagen de autenticación real.