Microsoft empieza a retirar EWS en octubre de 2026: qué revisar en tu stack de outbound

Microsoft anunció en 2023 el retiro de Exchange Web Services (EWS) en Exchange Online y publicó en febrero de 2026 el plan operativo. El Exchange Team actualizó esa publicación el 1 de septiembre de 2026 para distinguir dos controles que suenan parecidos: EWSAllowedAppIDs, la nueva lista por App ID vinculada al retiro, y EWSAllowList, una política anterior basada en user agents. No son equivalentes.

A partir del 1 de octubre de 2026, Microsoft empezará a cambiar EWSEnabled de Null a False en tenants que no hayan tomado la acción administrativa prevista. Eso bloquea las llamadas EWS. Un administrador todavía podrá habilitarlas temporalmente durante la transición, con una AppID Allow List cuando use EWSEnabled=True, pero Microsoft advierte que puede existir interrupción. El 1 de abril de 2027 llega el cierre completo y sin excepciones anunciadas.

El alcance también merece precisión: el retiro aplica a Microsoft 365 y Exchange Online en todos sus entornos, no a EWS en Exchange Server local. Microsoft Learn mantiene además un roadmap de brechas de paridad. Decir simplemente “todo EWS desaparece en octubre” sería tan cómodo como incorrecto.

Un stack outbound puede enviar por SMTP o por una API moderna y aun depender de EWS en otra capa. Un conector de terceros podría usarlo para leer el inbox, reconocer respuestas, consultar Out of Office, mover mensajes, recuperar headers o sincronizar carpetas. Eso debe comprobarse con el proveedor y con telemetría del tenant; no se deduce por el logo de Outlook en la interfaz.

El fallo peligroso no siempre es “no salió el correo”. Imagina que el sender continúa enviando, pero el proceso que ingiere replies deja de actualizar el CRM. La secuencia puede insistir después de una respuesta positiva, no registrar una baja o perder una referencia hacia otra persona. La campaña conserva actividad mientras pierde contexto. Es una falla silenciosa y comercial, no solo técnica.

La lectura de picos.Ai es que el protocolo forma parte del diseño del pipeline. Cada mensaje enviado, respuesta, OOO, hard bounce, baja y cambio de etapa necesita una ruta observable hasta su sistema de verdad. Si una integración no puede declarar cómo accede al buzón, quién posee la App ID y qué ocurre cuando falla, todavía no está lista para octubre.

Microsoft incorporó un reporte de uso de EWS en el Microsoft 365 admin center. Muestra las aplicaciones activas, las acciones SOAP usadas y el volumen de llamadas exitosas; permite filtrar los últimos 7, 30 o 90 días. Esa evidencia es mejor que preguntar en un canal interno si “alguien recuerda” una integración antigua.

Exporta o registra application ID, acción, volumen, owner, proveedor y buzones afectados. Después traduce cada acción a un evento de negocio. FindItem o GetItem puede sostener lectura de replies; GetUserOofSettings, manejo de OOO; CreateItem o SendItem, envío; operaciones de carpeta, una regla de clasificación. La tabla oficial de mapeo EWS a Microsoft Graph ayuda a localizar el equivalente, pero un equivalente de API no valida por sí solo el workflow completo.

Revisa también periodos con poca actividad. Un conector que solo procesa replies tardíos, renovaciones mensuales o campañas estacionales puede no aparecer en siete días. Si la organización opera varios tenants o entornos soberanos, repite el inventario donde corresponda. El reporte identifica llamadas observadas; no reemplaza el contrato técnico del proveedor ni descubre código apagado que podría volver a ejecutarse.

Primero, congela la lista de componentes que tocan Microsoft 365: Clay, Instantly o Smartlead, middleware, n8n, funciones serverless, CRM, bandeja unificada, clasificadores de AI y scripts internos. Para cada uno registra protocolo de envío, protocolo de lectura, tenant, App ID, permisos, owner, última actividad y contacto del proveedor. “OAuth” no basta: OAuth describe autorización, no confirma si la aplicación llama EWS o Microsoft Graph.

Segundo, cruza esa lista con el reporte EWS de 90 días y con Enterprise Applications en Microsoft Entra ID. Pregunta a cada proveedor: ¿usa EWS en Exchange Online?, ¿en qué funciones?, ¿cuál es la versión migrada?, ¿qué permisos Graph necesita?, ¿cómo detecta replies y bajas?, ¿cómo hace backfill tras una interrupción?, ¿qué fecha garantiza para producción? Conserva la respuesta y no solo el ticket cerrado.

Tercero, ordena por impacto. El nivel crítico incluye cualquier dependencia capaz de enviar, leer replies, aplicar supresiones o cambiar etapas. El nivel alto incluye OOO, delegación y carpetas que alimentan routing. Lo analítico puede esperar menos, pero no debe desaparecer sin aviso. Asigna fecha de prueba y rollback a cada ruta. Una matriz pequeña con evidencia vale más que un proyecto de migración llamado “en progreso” durante cuatro meses.

Microsoft Graph ofrece APIs para crear, leer, responder, reenviar y enviar mensajes, además de notificaciones de cambio y delta query. Microsoft documenta que delta query recupera cambios sin volver a leer toda la colección y que puede combinarse con notificaciones. También advierte que pueden ocurrir replays y que un token vencido puede obligar a reiniciar una sincronización completa. La lógica de merge debe ser idempotente.

La identidad del mensaje requiere cuidado. Microsoft advierte que el ID normal de un elemento cambia cuando se mueve a otra carpeta, mientras los IDs regulares de contenedores como mailFolder ya son constantes. Solicitar IdType=ImmutableId permite que el identificador de un mensaje sobreviva a movimientos dentro del mismo buzón; cambia si el elemento pasa al buzón de archivo o se exporta y vuelve a importarse. Si el CRM usa un ID mutable como llave única, puede crear duplicados o perder el hilo.

Prueba al menos seis escenarios: reply normal, respuesta desde otro alias, OOO, baja escrita en lenguaje natural, mensaje movido de carpeta y reconexión después de perder una notificación. Añade reintentos, eventos duplicados y expiración de suscripción. El criterio de aceptación no es recibir un 200 de Graph; es conservar una sola historia por contacto y detener la secuencia cuando el estado lo exige.

Microsoft recomienda Graph por sus controles más granulares frente al modelo amplio de EWS. Exchange Online ofrece RBAC for Applications para asociar una aplicación con roles y scopes de buzones. Por ejemplo, una automatización que solo necesita leer respuestas en buzones outbound no debería obtener capacidad de enviar como cualquier usuario de la organización.

Hay una trampa de configuración: los permisos concedidos en Microsoft Entra ID y las asignaciones de RBAC pueden ser aditivos. Microsoft advierte que un permiso organizacional sin scope puede anular en la práctica la intención de restringir la aplicación mediante un scope adicional. El equipo debe revisar la autorización efectiva y probarla contra buzones dentro y fuera del alcance.

Separa identidades por función cuando sea viable: envío, ingestión de replies y administración no necesitan compartir una credencial omnipotente. Registra quién aprobó cada permiso, qué buzones cubre y cómo se revoca. Esta recomendación de picos.Ai no garantiza seguridad; reduce el radio de impacto y mejora la investigación cuando algo sale del patrón.

Ejecuta EWS y Graph en paralelo sobre una cohorte controlada si tu arquitectura y proveedor lo permiten. Compara conteos por inbox y ventana: mensajes enviados, replies detectados, OOO, bajas, hard bounces, referencias, reuniones y actualizaciones de CRM. Registra latencia y discrepancias por tipo de evento, no solo un porcentaje global.

Después simula una interrupción de EWS o usa un entorno de prueba con el acceso bloqueado. Confirma que el sistema alerta, deja de enviar follow-ups cuando no puede conocer el estado y recupera eventos al volver. Si el fail-open permite seguir enviando mientras reply ingestion está ciego, el diseño prioriza actividad sobre control. Para la mayoría de las secuencias, esa no es una buena apuesta.

No cambies al mismo tiempo proveedor, copy, dominios y lógica de CRM. La prueba busca validar continuidad de estado. Conserva un rollback temporal para octubre, pero no lo confundas con una extensión: Microsoft fijó el cierre definitivo para abril de 2027. La ventana extra sirve para terminar la migración, no para convertir una dependencia heredada en tradición corporativa.

Pide una respuesta binaria por componente: sin EWS comprobado, migrado a Graph y validado, o dependencia EWS con plan y fecha. “El proveedor maneja eso” no es un estado verificable. Exige App ID, funciones afectadas y evidencia de prueba. Si un proveedor no puede responder, limita su alcance y diseña una salida antes de que Microsoft haga la prueba en producción.

Conecta la auditoría con un runbook comercial: quién pausa campañas, quién revisa Microsoft 365, quién reconcilia replies, cómo se actualizan supresiones y cuándo se reanuda. La fecha importa porque el plazo preventivo de agosto ya terminó; el 3 de septiembre la prioridad es conocer la configuración real y corregirla antes del 1 de octubre.

picos.Ai puede mapear inboxes, secuenciadores, automatizaciones y CRM; documentar los eventos críticos; y diseñar una prueba de continuidad con criterios de salida. No promete que cualquier proveedor haya completado su migración. Sí puede evitar que el primer indicador de una dependencia EWS sea un prospecto preguntando por qué recibió el mismo follow-up después de responder.