Publicar un registro DMARC con p=reject se supone que es la meta final. Le dice por escrito a todo servidor de correo receptor que descarte cualquier mensaje que diga venir de tu dominio y no pueda demostrarlo. Investigadores de seguridad y administradores de Microsoft 365 han estado documentando una brecha en esa promesa: una etiqueta de confianza dentro de Exchange Online Protection llamada SCL:-1, capaz de dejar pasar correo suplantado por delante de la aplicación de DMARC, en dominios que hicieron todo correctamente.
Qué hace realmente SCL:-1
Todo mensaje que llega a un buzón de Microsoft 365 recibe un Spam Confidence Level, un encabezado que va de -1 a 9 y que Exchange Online Protection usa para decidir qué pasa a continuación. La mayor parte de ese rango alimenta el proceso normal de puntuación de spam. SCL:-1 es distinto. Significa “este mensaje proviene de una fuente confiable”, y un mensaje que lo lleva se salta por completo el filtrado, incluidas las verificaciones antiphishing que se supone deben actuar sobre una evaluación DMARC fallida. El resultado de autenticación se puede seguir calculando y registrando. Simplemente nunca llega a importar, porque el mensaje ya fue dejado pasar antes de que se ejecute la aplicación de la política.
Por dónde se filtra la confianza
SCL:-1 no es algo que establezca un atacante. Lo aplica la propia configuración del inquilino, casi siempre sin que nadie prevea la consecuencia. La fuente más común es la lista de direcciones permitidas dentro de la política de filtro de conexión: cualquier dirección añadida allí, muchas veces años atrás para desbloquear a un proveedor o un escáner que tenía problemas de entrega, queda confiable de forma permanente, sin importar qué correo llegue después desde ella. Las reglas de flujo de correo escritas para facilitar la entrega de una aplicación específica pueden producir el mismo efecto al establecer explícitamente el SCL en -1. Los conectores de entrada configurados para tratar a un socio o una puerta de enlace como totalmente confiable conllevan el mismo riesgo. Ninguno de estos se creó como un agujero de seguridad. Se crearon como soluciones de entrega, superpuestas silenciosamente unas sobre otras a lo largo de años de administración del inquilino, cada una invisible hasta que alguien traza toda la cadena y descubre que una política DMARC estricta está situada río abajo de una docena de formas de evitarla.
No es la misma brecha que Direct Send
Vale la pena ser preciso sobre lo que esto no es. Direct Send, la ruta de retransmisión anónima que ya hemos cubierto antes, permite que correo sin autenticar llegue a un inquilino conectándose directamente a su endpoint MX por el puerto 25, y la configuración RejectDirectSend de Microsoft cierra específicamente esa puerta. SCL:-1 es un mecanismo completamente distinto. Afecta a correo que llega por rutas totalmente normales y con apariencia autenticada, remitentes externos, conectores reales, enrutamiento real, pero que se etiqueta como confiable antes de que la política antiphishing lo evalúe siquiera. Activar RejectDirectSend no hace nada para corregir una IP en la lista de permitidos o una regla de transporte olvidada. Una organización puede cerrar por completo la puerta de Direct Send y aun así tener a SCL:-1 anulando silenciosamente su aplicación de DMARC por una ruta distinta hacia los mismos buzones.
Qué significa esto para tu programa
Audita primero la lista de permitidos del filtro de conexión. Cada dirección IP en ella debe tener una razón documentada y vigente para estar allí. Las entradas añadidas para resolver un problema de entrega puntual hace años son la fuente más común de esta brecha, y nadie recuerda haberlas añadido.
Busca en las reglas de flujo de correo acciones explícitas de SCL:-1. Las reglas de transporte que fijan directamente el nivel de confianza de spam son fáciles de escribir y fáciles de olvidar. Cada una es una excepción permanente a lo que diga tu política DMARC.
Activa el filtrado mejorado para conectores en cada conector de entrada, incluidos los que enrutan a través de una puerta de enlace de terceros. Esto permite que Microsoft evalúe SPF, DKIM y DMARC contra la IP de origen real en lugar de la IP de la puerta de enlace, lo que mantiene la autenticación significativa incluso cuando el correo no llega de forma directa.
No supongas que RejectDirectSend resuelve esto. Soluciona el abuso de retransmisión anónima. No tiene ningún efecto sobre los flujos de correo en lista de permitidos o marcados como confiables explícitamente, que es una auditoría totalmente distinta.
Revisa las acciones de la política antiphishing en el portal de Defender frente a lo que tu registro DMARC realmente declara. Una política estricta publicada en el DNS y una acción permisiva configurada en el inquilino pueden coexistir indefinidamente, sin que nada saque a la luz el conflicto a menos que alguien revise ambas cosas.
La conclusión
Un registro DMARC es una promesa hecha en el DNS, pero la propia configuración de Microsoft 365 decide si esa promesa se cumple. SCL:-1 no es un defecto de DMARC ni un defecto del motor de filtrado de Microsoft. Es lo que ocurre cuando años de pequeñas soluciones de entrega, cada una razonable en su momento, se acumulan hasta convertirse en una excepción permanente que nadie audita frente a la política de autenticación vigente del dominio. La aplicación no es algo que configuras una vez en un registro DNS y olvidas. Tiene que sobrevivir al contacto con cada lista de permitidos, cada regla de transporte y cada conector que una organización haya añadido alguna vez.
Excello Mail te da visibilidad continua sobre tus reportes DMARC, para que puedas ver exactamente qué fuentes se están autenticando bajo tu dominio y detectar la brecha entre lo que declara tu política y lo que tu plataforma de correo realmente aplica. Regístrate gratis en Excello Mail y respalda con monitoreo real la aplicación que crees tener.