Microsoft 365: la edición Fisher-Price de la informática

Los dos últimos posts montaron un servidor de correo que cumple un conjunto de reglas, una vez con cuatro paquetes y otra con un único binario. Casi nadie hace eso. Pagan a Microsoft, apuntan su dominio a Exchange Online y dejan que se encargue de todo. Así que la pregunta justa aquí no es «¿cómo lo monto?» sino «si ya he pagado por la plataforma sobre la que funciona casi todo el país, ¿puedo hacer que cumpla las mismas reglas?».

La respuesta, a partir de la propia documentación de Microsoft y de una mirada de solo lectura al DNS de inquilinos reales, es: algunas bien, varias nada en absoluto, y la plataforma no te dirá cuál es cuál. Esta es la edición Fisher-Price de la seguridad del correo. Las esquinas van redondeadas, las herramientas afiladas quedan guardadas, y unos cuantos de los controles a los que de verdad echarías mano no están ahí para activarlos. Cada afirmación se cita a una página de Microsoft consultada el 22 de octubre de 2026, y cada resultado de DNS se reproduce con dig.

El balance

Estas son las reglas de la casa del post principal, /es/email/why-every-mail-setting-has-to-be-right/, frente a lo que Exchange Online deja hacer de verdad a un administrador.

Cinco de ellas son un no rotundo o una ausencia. La forma que tiene son tres columnas: las cosas que Microsoft decide y acierta, el puñado que se te permite activar, y las que simplemente no están ahí para activarlas.

Sigue leyendo para ver por qué cada una está donde está, porque las razones son más condenatorias que los veredictos.

Lo que hace bien, dicho sin rodeos

Primero el mérito, porque está ganado. En la ruta saliente, Exchange Online es realmente bueno. La validación DANE está activa por defecto desde 2022, la validación MTA-STS es automática, con «nothing administrators need to do to apply it»,¹ y a principios de 2026 llegó un modo DANE Mandatory por conector.² Eso es más de lo que logran de serie la mayoría de servidores autoalojados.

El DANE entrante con DNSSEC pasó a disponibilidad general el 28 de octubre de 2024, y los registros TLSA validan en un inquilino que se ha movido al nuevo host.³⁴ Así que la capacidad existe. La trampa es todo lo que la rodea, que es el resto de este post.

Nada de texto plano entrante: no hay interruptor

La primera regla de la casa es que el servidor rechaza el correo que llega en claro. En Exchange Online no hay forma de exigirlo a cada remitente. Se puede exigir TLS, pero solo en un conector de partner, acotado a dominios nombrados o rangos de IP, y el parámetro «applies only to Partner type connectors».⁵ Para todos los demás, lo predeterminado es oportunista.⁶ Puedes exigir TLS a tus partners nombrados. No puedes exigirlo a internet en general, que es el conjunto de remitentes del que trata la regla. No hay documentado ningún control para exigir TLS entrante en todo el inquilino.

Descartar dominios de remitente desconocidos: no está documentado en absoluto

El montaje de Postfix rechaza el correo cuyo dominio de remitente no existe, en MAIL FROM, antes del cuerpo. Fui a buscar el equivalente en Exchange Online por la documentación de antispam, autenticación y antiphishing, y no hay ninguno. Lo más parecido es la autenticación compuesta, y Microsoft es explícito en que «a composite authentication failure doesn’t directly result in a message being blocked».⁷ Así que lo diré con cuidado: Microsoft no documenta ningún control que descarte el correo de un dominio de remitente inexistente. Si algo no documentado ocurre en el filtrado, no lo puedo ver desde fuera, y tú tampoco, que es justo la cuestión.

Rechazar fallos de SPF y DKIM: no, y no

Esta es la que debería frenar en seco a un administrador. La regla de la casa es rechazar un mensaje que falla SPF de forma rotunda, o cuya firma DKIM está presente y no verifica. Exchange Online no hace ninguna de las dos en la puerta.

Para SPF hay un ajuste, enterrado en el filtro de spam avanzado. Está en «Off» por defecto, y cuando se activa no rechaza el mensaje: marca el correo de un remitente no listado «as high confidence spam».⁸ Léelo dos veces. Lo más fuerte que hará Exchange Online ante alguien que falsifica un dominio cuyo SPF dice -all es archivarlo en Correo no deseado, e incluso eso viene desactivado de serie. Para DKIM no hay nada en absoluto: ningún ajuste rechaza un mensaje solo porque su firma no haya verificado. Una firma fallida alimenta DMARC y la puntuación compuesta, y ahí acaba la cosa.

El rechazo sí ocurre en un caso: cuando el dominio del remitente publica DMARC p=reject, Exchange Online lo respeta por defecto y rechaza en tiempo de SMTP con 550 5.7.1.⁹ Bien, y activo por defecto, pero depende por completo de que el remitente haya hecho lo correcto. Los controles que los otros montajes usaban para tu propia protección entrante, rechazar si falla SPF y rechazar si la firma está rota, no están ahí para activarlos.

IPv6: dos años después, al NCSC no se le puede llegar por él

IPv6 es obligatorio en esta serie. Exchange Online lo admite entrante, por dominio aceptado, tras una activación, y sujeto a que Microsoft excluya automáticamente a «a small percentage of our customers».¹⁰ Ese despliegue se anunció en octubre de 2024 con una duración de tres a seis meses. Así que leí el registro AAAA en el host de correo de veintidós organizaciones británicas con Microsoft 365. Nueve, dos años después, no tienen ninguno.

Al buzón del propio National Cyber Security Centre no se le puede llegar por IPv6, ni tampoco al de HMRC, el servicio de correo del NHS, el Ministerio de Defensa, el Information Commissioner o Lloyds Bank.⁴ Si a cada uno lo excluyó Microsoft o nunca se activó, no se puede saber por el DNS. El resultado es el mismo, y los veintidós están en el host de correo heredado que, como estamos a punto de ver, no se puede firmar.

DNSSEC: no previsto para el host que de verdad usas

Aquí es donde la documentación y el DNS dejan de coincidir, y es el hallazgo más afilado del post. El DANE entrante necesita DNSSEC, y DNSSEC necesita que el host de correo esté en una zona firmada. Cada inquilino corriente de Exchange Online tiene su MX apuntando a un host bajo mail.protection.outlook.com. Comprobé si esa zona está firmada, y es demostrable que no:

$ dig @1.1.1.1 +dnssec DS protection.outlook.com
;; flags: qr rd ra ad; ANSWER: 0
protection.outlook.com. 60 IN NSEC \000.protection.outlook.com. NS RRSIG NSEC

La zona padre está firmada, y devuelve un registro NSEC autenticado que prueba que no hay DS para protection.outlook.com. Eso es una afirmación firmada de que la delegación no está firmada. Así que cada MX *.mail.protection.outlook.com, es decir casi todos los inquilinos de Microsoft 365 del planeta, está en una zona sin firmar y no puede hacer DANE.

La nueva infraestructura firmada vive bajo otro nombre, mx.microsoft, y moverse a ella es un cambio manual y voluntario. ¿Cuántos lo han hecho? De unos treinta y cinco dominios británicos que muestreé, ni uno estaba en ella. Los inquilinos que pude encontrar en el host firmado eran todos neerlandeses. Y el propio post de Microsoft de abril de 2026 dice que el plan no es arreglar el host que todo el mundo usa:

Currently, there are no plans to enable DNSSEC on the mail flow domain mail.protection.outlook.com.²

Así que: DNSSEC y DANE están disponibles en un host nuevo, si te activas y migras, y el host en el que de hecho está cada inquilino existente, por declaración de la propia Microsoft, no se va a firmar. La capacidad se entregó. Lo predeterminado no se movió, y no se va a mover.

Los dos dominios más grandes de la propia Microsoft muestran la división, y uno de ellos está peor que los inquilinos a los que sermonea:

outlook.com, el servicio de correo de consumo, publica DMARC p=none: pide al mundo que compruebe su correo y luego no haga nada ante un fallo, que es el ajuste que el post principal llama un encogimiento de hombros.⁴ El dominio corporativo de Microsoft lo hace mejor. Ninguno de los dos hosts está firmado.

La documentación se contradice a sí misma

Cuando la propia documentación de un proveedor se contradice sobre un control de seguridad, eso no es un detalle quisquilloso. Es un cliente al que le cuentan dos cosas incompatibles sobre algo que decide si su correo está a salvo, y a eso le presto atención como se la prestaría a cualquier proveedor al que se le paga por hacerlo bien. Tres ejemplos, todos de páginas que Microsoft publicó, todos en línea el 22 de octubre de 2026.

La página de SPF recomienda -all, «hard fail».¹¹ El post de Direct Send recomienda «a Soft Fail SPF configuration».¹² Las dos están vigentes, y a un cliente que sigue una lo reprende la otra. En MTA-STS, la página de entrada le dice a un inquilino que publique mx: *.mail.protection.outlook.com, dice en la misma página que «wildcards or ‘*’ must not be used as the MX prefix in all MTA-STS scenarios»,¹ y luego imprime un ejemplo que usa exactamente ese comodín. No le pido a Microsoft que invente nada. Pregunto por qué la página que le dice a un cliente cómo proteger su flujo de correo no es capaz de ponerse de acuerdo consigo misma sobre la única línea que hace la protección.

Luego el agujero de Direct Send, que es la regla de identidad, la regla seis, fallando en la puerta de entrada.

Hay una forma de enviar correo a un inquilino como uno de sus propios usuarios sin autenticación alguna, porque «does not require any form of authentication»,¹² y está activa por defecto. El ajuste para desactivarla, RejectDirectSend, viene desactivado, comprueba solo el remitente del sobre y no el From: visible, y dieciocho meses después sigue con «no fixed date for General Availability».¹² Una plataforma de pago entregó una manera sin autenticar de suplantar el propio dominio de un inquilino, la dejó activa por defecto, y el arreglo es un interruptor voluntario sin fecha de publicación y con un hueco en lo que comprueba. Ese es el registro que reservo para un proveedor que sostiene que esto es difícil. No es difícil. Como tal, no voy a fingir que lo sea. Es un valor por defecto que se puso mal y se dejó así.

¿Puedes montarlo bien sobre esto? Casi nunca

Así que aquí está el balance honesto, y no es que Microsoft 365 sea mal correo. Entrega con fiabilidad, su seguridad saliente es realmente buena, y para una organización sin experiencia en correo es más seguro que el servidor que, de lo contrario, habría configurado mal. Todo cierto, y todo al margen de lo que esta serie plantea.

La cuestión es el control, y en los controles que más importan para las amenazas del post principal, Exchange Online no te lo da. No puedes exigir TLS entrante desde internet, rechazar un fallo rotundo de SPF, rechazar una firma falsificada, ni descartar correo de un dominio que no existe. La única protección de transporte infalsificable, DANE con DNSSEC, está desactivada en el host en el que estás y no hay plan para que llegue a él. Y el agujero sin autenticar de la puerta de entrada está activo por defecto sin fecha para cerrarlo.

Eso es lo que significa la edición Fisher-Price. No que sea para niños, sino que las herramientas afiladas se las han llevado, te entregan las de puntas redondeadas, y te dicen que es por tu propio bien. Lo cual, para muchos sitios, lo es. Para muchas organizaciones de verdad lo es. Para cualquiera que haya leído hasta aquí y haya entendido para qué servían las herramientas afiladas, es una plataforma que ha decidido, en tu nombre, cuáles de tus ajustes de seguridad puedes tocar. Los que más querías están tras el cristal.

Lo pagas de todos modos. Lo menos que puedes hacer es saber cuáles de estas reglas ha decidido en voz baja que no puedes cumplir.