Microsoft bloquea Exchange Server obsoleto en 2026

En pocas palabras: Microsoft rebotará emails desde Exchange Server 2016 y 2019 desactualizados hacia la nube a partir de septiembre de 2026. La medida afecta conexiones híbridas OnPremises sin el parche de seguridad de octubre de 2025, forzando actualizaciones urgentes.

Microsoft empezará a rebotar (bounce) los emails enviados desde servidores Exchange Server 2016 y 2019 desactualizados hacia Exchange Online a partir de la segunda semana de septiembre de 2026. La medida aplica específicamente a conexiones híbridas vía conectores “OnPremises” que no cuenten con el baseline de seguridad de octubre de 2025, dejando fuera de servicio a cualquier instalación obsoleta. Cubrimos ese tema en detalle en la rivalidad entre ambas plataformas.

La política de bloqueo de Microsoft para Exchange Server es una actualización en su estrategia de seguridad que obliga a las organizaciones a mantener sus entornos on-premise alineados con los estándares más recientes. Básicamente, si tu servidor Exchange 2016 o 2019 envía correo a la nube a través de un conector híbrido tipo OnPremises y no tiene instalado el último parche público de octubre de 2025, Microsoft rechazará ese tráfico. No es un aviso amable: es un corte directo para mitigar riesgos de vulnerabilidades conocidas que siguen explotándose en versiones viejas del software. Para más detalles técnicos, mirá las certificaciones oficiales de Azure.

Exchange Server es el software de mensajería corporativa de Microsoft que gestiona email, calendario y contactos, disponible tanto en la nube (Online) como en instalaciones locales (on-premise). Esta noticia confirma que Microsoft está endureciendo los requisitos mínimos de versión para garantizar la integridad del ecosistema híbrido. Desde la segunda semana de septiembre de 2026, Microsoft rechaza activamente el correo saliente generado por instancias de Exchange Server 2016 y 2019 que no cumplan con los estándares de seguridad actuales. El mecanismo es simple: si detecta que el tráfico proviene de un servidor local que intenta hablar con Exchange Online mediante un conector híbrido configurado como “OnPremises”, y ese servidor no tiene la última actualización pública instalada, el mensaje no llega al destinatario. Es un rebote duro. No me cierra del todo que esto sorprenda a alguien. Microsoft viene advirtiendo sobre la necesidad de actualizar desde hace meses, pero siempre hay esa resistencia natural a tocar infraestructura crítica cuando funciona “bien”. Lo que pasa acá es que la definición de “funcionar bien” cambió: ya no basta con que el servidor encienda y reciba mail interno; ahora debe ser seguro para interactuar con la nube. Si alguna vez administraste un entorno híbrido, sabés que estos conectores son la arteria principal para muchas empresas que todavía tienen buzones locales o aplicaciones legacy que dependen de SMTP interno. La línea base obligatoria es el final public update baseline publicado en octubre de 2025. Cualquier versión anterior será considerada “significativamente obsoleta” y bloqueada automáticamente por los filtros de Microsoft. Esto incluye Service Packs, Cumulative Updates (CU) y security patches previos a esa fecha específica. El problema acá es que muchos admins tienden a postergar updates acumulativos porque rompen integraciones con terceros o requieren ventanas de mantenimiento largas. Pero fijate que esta actualización ya salió hace casi un año. Microsoft argumenta correctamente que “todas las organizaciones deberían haberse actualizado a este nivel”. Si tu servidor sigue corriendo un CU de 2024 o anteriores, estás en riesgo inminente de perder capacidad de salida de correo hacia Office 365. Y ojo, no es solo cuestión de parches de seguridad menores; estamos hablando de cambios estructurales en cómo Exchange valida su identidad ante la nube. Esta restricción NO impacta a todos los servidores de una organización, sino únicamente a aquellos que envían email a Exchange Online mediante un inbound connector de tipo OnPremises. Los servidores puramente locales que no interactúan con la nube, o que usan otros métodos de entrega (como relays directos a internet sin pasar por la validación híbrida de Microsoft), quedan fuera de este bloqueo específico. Ahora bien, la empresa añadió un detalle que debería poner nervioso a cualquiera: “Esto podría cambiar en el futuro”. Traducción: no asumas que tu método actual de escape va a seguir funcionando indefinidamente. Si tenés una arquitectura donde algunos servidores hablan con la nube y otros no, vas a tener que audicar cada conector. Hay casos reales donde equipos de desarrollo mantienen servidores Exchange aislados para pruebas de integración de aplicaciones ERP o CRM antiguos; esos zafan por ahora, pero el día que intenten conectarlos a Outlook Web App o sincronizar calendarios con la nube, se van a topar con el muro. Microsoft busca empujar a las empresas hacia ediciones más modernas (Subscription Edition) o servicios gestionados, reduciendo la superficie de ataque de versiones antiguas que ya no reciben soporte completo. Nino Bilic, Principal Project Manager de Microsoft, fue claro al explicar la lógica interna: “Con o sin este anuncio, el cambio habría ocurrido (igual que se hizo en el pasado, sin ningún anuncio)”. ¿Y qué pasó cuando lo probaron en producción? Exacto, se rompió todo para quienes no estaban atentos. La estrategia es conocida: primero avisan, luego aplican throttling (limitación de tasa), y finalmente blockeo total. Al hacerlo visible ahora, Microsoft evita la excusa de “no sabía”. Además, protege su reputación en ciberseguridad; permitir que servidores vulnerables interactúen con su nube abre vectores de ataque que podrían escalar hacia cuentas de usuarios finales. Es una decisión defensiva, aunque para el admin promedio signifique más trabajo operativo. Las organizaciones que deben mantener servidores on-premises por dependencias de aplicaciones heredadas tienen dos caminos principales: inscribirse en el programa Extended Security Update (ESU) o migrar a Exchange Server Subscription Edition. El ESU ofrece parches de seguridad adicionales para versiones fuera de soporte, pero implica costos licenciatarios extra y complejidad administrativa mayor. Si te interesa mantener Exchange 2016 o 2019 sin pagar ESU, tu única opción viable es aplicar el update de octubre de 2025 inmediatamente. No hay punto medio. Para quienes usan proveedores de hosting managed, verificar la compatibilidad de sus entornos virtuales con estos updates es clave antes de programar el mantenimiento. A veces, en infraestructuras compartidas o VPS específicos, los permisos de sistema impiden ciertas instalaciones de parches, así que coordiná con tu proveedor. Confirmado: * Bloqueo efectivo desde la segunda semana de septiembre de 2026. * Aplica solo a Exchange 2016 y 2019 usando conectores OnPremises hacia Exchange Online. * Requisito mínimo: Update baseline de octubre de 2025. * Citas textuales de Microsoft confirmando la inevitabilidad técnica del cambio. Pendiente / Ambiguo: * Extensión futura a otros tipos de conectores o protocolos de entrega. * Impacto exacto en herramientas de monitoreo de terceros que validan estado de conexión híbrida. * Posibles excepciones temporales para grandes clientes enterprise (históricamente Microsoft ha dado grace periods, pero no está garantizado aquí). Muchos admins caen en la trampa de asumir que “si funciona hoy, funcionará mañana”. Aquí van los errores que veo repetirse constantemente en foros y tickets de soporte: 1. Ignorar el alcance del conector: Creer que el bloqueo aplica a todo el tráfico saliente. Error grave. Solo afecta la ruta híbrida específica. Revisá tu flujo de datos real. 2. Postergar el update por miedo a downtime: Esperar al fin de semana largo para parchear, cuando la ventana de seguridad ya cerró. Acordate que el rebote es inmediato tras la fecha límite. 3. No validar la dependencia de aplicaciones: Muchas apps internas usan SMTP para notificaciones. Si esas apps apuntan a un servidor Exchange bloqueado, tus alertas críticas dejarán de llegar. Probá las rutas de notificación antes de confiar en que el correo interno sigue andando. Las versiones afectadas son Exchange Server 2016 y Exchange Server 2019 que no tengan instalado el final public update baseline de octubre de 2025. Cualquier build anterior será tratada como insegura y bloqueada para entregas hacia Exchange Online. Tienes hasta la segunda semana de septiembre de 2026. Después de esa fecha, los correos generados por servidores no actualizados serán rebotados (bounce) por la infraestructura de Microsoft. No hay extensión oficial anunciada para este plazo inicial. Sí, podés seguir usándolo para correo interno entre buzones locales sin problemas. La restricción de Microsoft solo aplica cuando el servidor intenta entregar mensajes a Exchange Online (la nube) a través de un conector híbrido tipo OnPremises. Tu red interna no se ve afectada directamente por este policy change. El bloqueo interrumpe la comunicación con la nube. Los usuarios con buzones locales podrán recibir mail interno, pero no podrán enviar mensajes desde cuentas de Exchange Online si su servidor local está desactualizado. Esto rompe la experiencia híbrida transparente que muchas empresas dependen para transiciones graduales. Microsoft está cerrando el cerco sobre las instalaciones descuidadas de Exchange Server, y esta vez no es una sugerencia suave. Si manejás infraestructura híbrida, tu checklist para septiembre de 2026 debe incluir la verificación inmediata del nivel de parche de tus servidores 2016/2019. Actualizar no es opcional si querés mantener la comunicación fluida con la nube. Evalúa si vale la pena pagar por ESU o si es momento de acelerar la migración a Subscription Edition. Ignorar esto te deja con correos rebotados y clientes molestos, algo que ninguna empresa quiere explicar a última hora.

• The Register – Microsoft to bounce mail from outdated Exchange servers

Preguntas Frecuentes

¿Qué ocurre con los correos enviados desde un Exchange Server obsoleto después de septiembre de 2026?

Microsoft rebotará automáticamente todos los mensajes generados por servidores no actualizados hacia Exchange Online. La entrega híbrida se interrumpirá, impidiendo la comunicación con la nube. Tema relacionado: el incidente de malware Miasma.

¿Cómo afecta el bloqueo a las comunicaciones internas en una red local?

El correo interno entre buzones locales seguirá funcionando sin interrupciones. La restricción aplica exclusivamente a las entregas hacia Exchange Online mediante conectores híbridos OnPremises. Lo explicamos a fondo en el rendimiento en Windows frente a Linux.

¿Cuánto tiempo tiene una empresa para actualizar su infraestructura antes del corte definitivo?

El plazo final vence durante la segunda semana de septiembre de 2026. No existe ninguna extensión oficial anunciada para este periodo crítico de migración o parcheo.

Conclusión