Microsoft endurece Exchange híbrido: qué cambia para el correo B2B

El Exchange Team anunció el 2 de septiembre de 2026 que, a partir de la segunda semana del mes, elevará la versión mínima de Exchange Server 2016 y 2019 que puede enviar correo a Exchange Online mediante un inbound connector de tipo OnPremises. El nuevo piso corresponde, como mínimo, a las últimas actualizaciones públicas liberadas en octubre de 2025.

La fecha no debe convertirse en un falso minuto cero. Microsoft habló de una ventana de inicio, no de una hora universal para todos los tenants. La decisión operativa correcta es revisar el entorno ahora, no esperar a que un dashboard muestre retrasos para confirmar que el anuncio era serio.

También importa el verbo: Exchange Online puede aplicar reporting, throttling y, si el servidor sigue sin remediarse, blocking. Esto no significa que cada mensaje de un servidor antiguo desaparezca de golpe. Significa que una dependencia de infraestructura puede empezar a retrasar y luego rechazar correo legítimo.

El alcance anunciado es estrecho: servidores Exchange 2016/2019 que se conectan a Exchange Online por un inbound connector con ConnectorType OnPremises. Microsoft documenta esos conectores para organizaciones en modo híbrido y para mailboxes on-premises que retransmiten correo hacia internet mediante Exchange Online.

No es un bloqueo general contra todo mensaje enviado a Outlook, Microsoft 365 o un prospecto que usa Exchange Online. Tampoco describe automáticamente el tráfico que una plataforma de secuencias entrega por otra ruta. Si tu cold email sale desde Google Workspace, desde Microsoft 365 nativo o desde un proveedor externo, no puedes inferir impacto solo porque el destinatario usa Outlook.

Hay una advertencia adicional que conviene leer sin creatividad comercial: la propia FAQ de Microsoft dice que estos inbound connectors no están diseñados para retransmitir correo masivo hacia internet y considera ese uso un abuso de la función. Si una organización convirtió su ruta híbrida en motor de bulk email, tiene dos problemas distintos: versión vulnerable y arquitectura fuera del propósito documentado.

La página oficial de builds identifica las actualizaciones del 14 de octubre de 2025 para Exchange 2019 CU15 y CU14, además de Exchange 2016 CU23. El build exacto depende de la edición y del CU instalado; por eso no basta con que alguien recuerde haber aplicado “un parche el año pasado”. Hay que inventariar cada servidor y comparar su versión real.

Microsoft recomienda ejecutar Exchange Server Health Checker para identificar CUs, SUs y acciones manuales pendientes. La misma documentación advierte que Get-ExchangeServer muestra el CU, pero no necesariamente el estado completo de Security Updates o Hotfix Updates. Una captura del AdminDisplayVersion puede dar tranquilidad con información incompleta.

El baseline evita la primera fase anunciada, pero no convierte octubre de 2025 en un estado seguro permanente. El Exchange Team subraya que cualquier versión anterior al último update disponible sigue expuesta a correcciones posteriores. Cumplir el piso de transporte y mantener el servidor actualizado son controles relacionados, no equivalentes.

Microsoft adelantó que, si aplica el siguiente ajuste como lo anticipó —estima que ocurrirá en varios meses—, la versión requerida será posterior a cualquier actualización de acceso público general para Exchange 2016/2019. Bajo ese escenario anunciado, los clientes inscritos en el programa Extended Security Update correspondiente o quienes hayan migrado a Exchange Server Subscription Edition tendrían los builds soportados necesarios; el baseline exacto todavía deberá confirmarse cuando Microsoft lo publique.

El contexto se volvió todavía más concreto el 8 de septiembre. Microsoft publicó nuevas Security Updates para Exchange Server SE y, bajo Period 2 ESU, para Exchange 2019 CU14/CU15 y Exchange 2016 CU23. Exchange Online ya está protegido frente a esas vulnerabilidades, pero los servidores o estaciones con Exchange Management Tools dentro del entorno siguen requiriendo actualización según la guía oficial.

Esto no prueba que el update del 8 de septiembre sea el próximo baseline de transporte. Microsoft no anunció eso. Sí demuestra que el ciclo de seguridad continúa después del último baseline público y que postergar la decisión entre ESU y migración reduce el margen de maniobra.

Según el sistema de enforcement documentado por Microsoft en 2023, el proceso empieza con reporting. Si el servidor no se remedia, puede avanzar a throttling progresivo con respuestas SMTP temporales 450; el servidor emisor debe poner el mensaje en cola y reintentar. Más adelante puede incorporar bloqueos con respuestas permanentes 550 y generar un non-delivery report. La progresión es controlada por Microsoft y no implica una fecha idéntica para cada servidor o tenant.

La progresión documentada da tiempo para actuar, pero no debe confundirse con permiso para ignorar el problema. Un 450 puede verse en negocio como una respuesta que llegó tarde, una invitación que no apareció o un follow-up fuera de contexto. El protocolo sabe que fue un retraso. El prospecto solo sabe que nadie contestó a tiempo.

Microsoft ofrece una pausa temporal de enforcement bajo condiciones y límites publicados. Es una herramienta de contingencia, no una estrategia de actualización. Si el equipo usa el periodo para seguir enviando sin dueño, fecha y plan de remediación, solo transformó una alerta técnica en deuda con calendario.

Para el equipo que sí opera esa ruta híbrida, la consecuencia es directa: el estado del servidor entra al mismo mapa de riesgos que dominios, inboxes, secuenciador y CRM. Una campaña no está lista porque la plantilla pasó QA si el mail flow depende de un Exchange fuera del baseline.

Para quienes no usan esa ruta, la noticia deja una lección menos literal. Los proveedores están convirtiendo postura de seguridad y mantenimiento en políticas de transporte ejecutables. Nuestra interpretación es que deliverability seguirá acercándose a una disciplina de operaciones: inventario, versiones, propietarios, observabilidad y planes de cambio, no una colección de trucos sobre asuntos.

También evita un diagnóstico equivocado. Si aumentan retrasos o rebotes hacia Microsoft, no atribuyas automáticamente el cambio a este anuncio. Separa por dominio receptor, código SMTP, conector, versión, ruta y timestamp. Una coincidencia de fecha no demuestra causalidad, por más cómoda que resulte en la reunión.

Primero identifica si existe infraestructura Exchange Server 2016/2019 on-premises y quién la administra. Después, en Exchange Online PowerShell, revisa los conectores con Get-InboundConnector y conserva Name, ConnectorType, Enabled, ConnectorSource y la ruta de negocio asociada. El comando mostrado por Microsoft para una comprobación rápida es Get-InboundConnector | ft Name,ConnectorType.

Segundo, ejecuta Exchange Health Checker en cada servidor y conserva build, CU, SU/HU detectados y fecha. Compara contra la tabla oficial de builds. Si aparece una versión anterior a octubre de 2025, trata el hallazgo como remediación prioritaria; no intentes compensarlo subiendo volumen por otra bandeja sin entender la arquitectura.

Tercero, revisa el mail flow report en Exchange Admin Center, las colas on-premises y los eventos SMTP 450 4.7.230 o 550 5.7.230 descritos por Microsoft. Su presencia identifica el mecanismo documentado; no prueba que todos los servidores recorran las fases con el mismo calendario. Conecta esos eventos con campaign ID y message timestamp para saber qué ruta falló y qué mensajes requieren seguimiento humano.

La primera decisión es continuidad: actualizar, contratar ESU si corresponde o migrar a Exchange Server SE dentro de una ventana realista. Esa ruta requiere evaluación técnica y comercial; este artículo no sustituye la documentación de Microsoft ni el diseño de un especialista de Exchange.

La segunda es capacidad. Durante un cambio de servidor o conector, reduce campañas a un nivel que el equipo pueda observar y recuperar. Define una regla para pausar envíos ante errores por versión, un procedimiento para reintentos y una lista de conversaciones críticas que no deben quedar abandonadas por un fallo de transporte.

La tercera es ownership. Infraestructura puede aplicar un SU, revenue operations puede detener una secuencia y ventas puede retomar una conversación. Si nadie sabe quién toma cada decisión, el sistema tendrá tres dashboards impecables y un mensaje importante en cola.

Microsoft ha vinculado de manera explícita el estado de Exchange Server con la aceptación de correo en Exchange Online. Para una operación B2B híbrida, eso vuelve el mantenimiento parte del sistema comercial. No porque cada parche genere pipeline, sino porque una ruta vulnerable puede impedir que el pipeline avance.

La respuesta tampoco es migrar a ciegas o presentar Microsoft 365 como garantía de inbox. Una plataforma actualizada puede seguir enviando mensajes irrelevantes, acumular quejas o romper autenticación. La seguridad de la ruta es una condición necesaria; no reemplaza selección, permiso aplicable, copy ni seguimiento.

En picos.Ai auditamos el flujo completo: fuente del lead, dominio, inbox, proveedor, conector, eventos SMTP, respuesta y oportunidad. Si tu stack incluye Exchange híbrido, usa el enlace Hablemos al final de esta página. Podemos convertir el anuncio en un mapa de dependencias y un preflight medible antes de la siguiente campaña.