Caída de Microsoft 365: qué pasó y qué sigue
Microsoft 365 sufrió una caída global que empezó el jueves 12 de noviembre de 2026 a las 16:17 UTC (13:17 en Argentina) y que seguía abierta en el último parte disponible, el viernes 13 a las 02:14 UTC (23:14 del jueves en el país). La empresa la sigue en dos incidentes: EX1550543, por Exchange Online, y MO1550821, por el impacto en el resto del paquete. El episodio también dejó a la vista un dato de dependencia: el 17,6% de los dominios co.id de Indonesia recibe su correo a través de Exchange Online.
En este artículo:
- Qué pasó con la caída de Microsoft 365
- ¿Por qué se cayó Microsoft 365, Outlook y Teams?
- ¿Cuánto duró la caída y a qué hora se restableció?
- ¿La caída de Microsoft 365 afectó a Argentina?
- ¿Qué pasa con los correos enviados durante la caída?
- El dato de Indonesia: 17,6% de los dominios co.id recibe correo por Microsoft 365
- Qué pueden hacer las empresas mientras el servicio sigue inestable
- Fuentes
Qué pasó con la caída de Microsoft 365
Un grupo grande de servidores dejó de responder y el resto de la infraestructura no pudo absorber el trabajo extra. Eso volteó Exchange Online y, en cadena, el acceso a buzones desde Outlook en la web, Outlook de escritorio por MAPI, Exchange ActiveSync y conexiones REST. La caída arrastró a Teams, SharePoint Online, Copilot 365 y Defender XDR, además de varias funciones que leen correo, calendario o contactos desde Exchange.
La lista de servicios con algún grado de afectación incluyó Planner, To Do, Intune, Defender for Office 365, Purview, Power BI, el centro de administración de Microsoft 365 y Universal Print. Microsoft aclaró que el chat y las reuniones centrales de Teams seguían “en gran medida funcionales” y que los archivos guardados directamente en SharePoint continuaban accesibles. Azure, en tanto, aparecía operativo según los partes citados por la prensa. Como detallamos en nuestra comparativa entre Microsoft y GitHub, profundizamos sobre esto.
El termómetro público fue Downdetector: más de 100.000 reportes por Outlook solo, cerca de 130.000 poco después de la 1 p.m. ET, y un descenso a 59.595 hacia las 3:50 p.m. ET y a unos 37.000 a las 5:41 p.m. ET, según los datos que recogió Blaze Trends. La propia página de estado de Microsoft falló al cargar para muchos usuarios. Hubo además una discrepancia entre medios sobre el alcance: Mashable leyó que solo se veía afectado el software empresarial, mientras Engadget reportó que también aparecían usuarios individuales.
¿Por qué se cayó Microsoft 365, Outlook y Teams?
Microsoft no publicó una causa raíz. Su explicación más concreta, del viernes a las 01:50 UTC, es que en los servidores afectados se saturaba un proceso encargado de establecer conexiones seguras y eso hacía que dejaran de procesar pedidos. La empresa también empezó a revertir un cambio reciente de configuración de red y no reportó indicios de un ciberataque.
El razonamiento oficial fue cambiando durante la madrugada. Primero se investigó un supuesto pico de tráfico; después la empresa descartó esa hipótesis: la carga elevada no venía de más tráfico sino de una gran cantidad de servidores que quedaron fuera de servicio y trasladaron su peso al resto. A las 19:57 UTC del jueves había dicho que no encontraba cambios recientes correlacionados con el inicio del problema; a las 01:50 UTC ya hablaba de revertir una modificación de red que sí correlacionaba. Lo explicamos a fondo en nuestra guía para conectarse por SSH a Azure.
Los partes, leídos en orden, describen un bucle: un servidor falla un chequeo automático de salud y sale de rotación, su tráfico se reparte entre los que quedan, esos hacen más trabajo cada uno y más de ellos fallan el mismo chequeo. Los servidores reintegrados volvían a quedar sin responder al recibir tráfico. Microsoft suspendió todos los despliegues y cambios de configuración a las 19:06 UTC, limitó algunos tipos de tráfico y fue sumando capacidad de a poco.
¿Cuánto duró la caída y a qué hora se restableció?
No hay una hora de restablecimiento completo publicada. A las 22:57 UTC del jueves Microsoft informó que algunos servidores habían vuelto y se mantenían estables, con recuperación limitada en algunas regiones; a las 02:14 UTC del viernes seguía agregando capacidad para las regiones que regresaban. El incidente continuaba abierto en el último parte disponible, así que la duración total todavía no está informada.
- 16:17 UTC del jueves: abre EX1550543 por problemas de acceso a buzones.
- 18:07 UTC: Microsoft reconoce que el problema puede afectar a usuarios de cualquier región.
- 22:00 UTC: admite que las acciones tomadas “no dieron el alivio esperado” y que un proceso central está desbordado.
- 01:50 UTC del viernes: apunta al proceso de conexiones seguras y empieza a revertir un cambio de red.
Como referencia de magnitud, la nota de Blaze Trends recuerda dos antecedentes: una caída mundial de Outlook que duró entre 19 y 21 horas en julio de 2025 y otra de agosto de 2026 que tardó 67 horas en resolverse del todo. Son episodios previos, no un pronóstico de este. Tema relacionado: nuestra guía de certificaciones Azure 2026 por roles.
¿La caída de Microsoft 365 afectó a Argentina?
Sí, en alcance declarado: a las 18:07 UTC del jueves Microsoft reconoció que el problema podía afectar a usuarios de cualquier región y no solo de América. Ninguna de las fuentes consultadas aporta una cifra de usuarios o empresas argentinas afectadas, así que el impacto local se puede afirmar por cobertura geográfica, no por magnitud medida.
En la práctica, un usuario local notaba el problema al abrir el buzón en Outlook web, en el cliente de escritorio o en el teléfono, y al enviar o recibir correo. El calendario y la programación de reuniones en Teams también dependían de Exchange, igual que el acceso de Copilot a datos de trabajo y las llamadas a la API de Graph para correo y calendario. El chat de Teams, en cambio, seguía funcionando en gran medida.
¿Qué pasa con los correos enviados durante la caída?
Lo más probable es que lleguen tarde, no que desaparezcan. Si el servidor receptor no acepta el mensaje, el servidor emisor lo guarda en cola y reintenta: la RFC 5321 indica que el plazo para darse por vencido “generalmente necesita ser de al menos 4 o 5 días”. Microsoft, además, advirtió que la entrega de correo podía demorarse.
Hay matices que conviene tener presentes. Algunos emisores abandonan antes, y muchas personas leen el aviso de “entrega demorada” que llega a las pocas horas como si fuera una falla definitiva. Si algo era urgente, lo sensato es revisar si hubo rebotes cuando el servicio vuelva y reenviar; para un tema crítico, conviene llamar o usar otro canal en lugar de esperar el reintento. Mirá también el proyecto Perception para vigilar agentes de IA.
El dato de Indonesia: 17,6% de los dominios co.id recibe correo por Microsoft 365
El relevamiento tomó los 4.573 dominios .id que figuran en el listado Tranco GQ32K, consultó sus registros MX el 13 de noviembre entre las 09:04 y las 09:06 WIB (23:04 y 23:06 del jueves en Argentina) y encontró 3.499 con un registro funcional. Cada dominio se clasificó por su host MX de menor preferencia, es decir, por donde entra el correo primero. Del total, 305 dominios (8,7%) apuntan a Microsoft 365, unos 1 de cada 11; entre los co.id, la proporción sube a 157 de 892, o 17,6%, cerca de 1 de cada 6. Ampliamos el tema en la nota sobre el modelo MAI-DxO, que supera a médicos en diagnóstico.
| Grupo | Con MX | Microsoft 365 | Google Workspace | Servidor propio u hosting | SPF con M365 |
|---|---|---|---|---|---|
| go.id | 452 | 15 (3,3%) | 20 (4,4%) | 404 (89,4%) | 24 (5,3%) |
| ac.id | 932 | 50 (5,4%) | 535 (57,4%) | 109 (11,7%) | 75 (8,0%) |
| co.id | 892 | 157 (17,6%) | 178 (20,0%) | 467 (52,4%) | 199 (22,3%) |
| or.id | 43 | 5 (11,6%) | 16 (37,2%) | 21 (48,8%) | 6 (14,0%) |
| sch.id | 111 | 5 (4,5%) | 46 (41,4%) | 58 (52,3%) | 6 (5,4%) |
| .id (plano) | 979 | 73 (7,5%) | 266 (27,2%) | 511 (52,2%) | 97 (9,9%) |
| Total | 3.499 | 305 (8,7%) | 1.063 (30,4%) | 1.646 (47,0%) | 407 (11,6%) |
La comparación más útil es entre correo entrante y saliente. En co.id, 157 dominios reciben por Exchange Online y 199 autorizan a Microsoft 365 en su registro SPF para enviar; los conjuntos se superponen pero no coinciden, porque una empresa puede recibir en otro lado y enviar por Microsoft, o al revés. En el conjunto .id, Google recibe correo para 3,5 veces más dominios que Microsoft: 1.063 contra 305. En ac.id la brecha es más amplia (57,4% contra 5,4%), posiblemente porque Google Workspace for Education Fundamentals es gratuito para escuelas y universidades que califican. Los go.id casi no dependen de Microsoft: 89,4% corre con servidor propio o compartido, y 67 usan el servicio estatal mail.go.id.
Qué no dice el dato de MX
Un registro MX solo indica dónde aterriza el correo entrante. Una organización puede recibir por Google y aun así usar Teams, SharePoint y Copilot, y esos usuarios también quedaron afectados. Tampoco es un censo: Tranco ordena dominios populares, así que la muestra refleja organizaciones visibles de Indonesia, no al país entero, y la consulta DNS es una foto de una mañana. El propio autor aclara que 305 es un piso, porque 51 dominios enrutan el correo entrante por pasarelas de filtrado como Proofpoint, Mimecast o Trend Micro, y 19 de ellos además autorizan a Microsoft 365 en SPF, lo que sugiere buzones alojados en Exchange Online.
Qué pueden hacer las empresas mientras el servicio sigue inestable
- No tocar los registros MX en plena caída. Cambiar de proveedor de correo exige buzones, ruteo y TTL vencidos, y después habría que volver atrás. Los emisores ya encolan y reintentan.
- Seguir el estado sin depender del centro de administración. status.cloud.microsoft es público; la vía soportada es la API de service health de Microsoft Graph, que requiere una aplicación registrada con el permiso ServiceHealth.Read.All y depende de que Graph esté arriba.
- Avisar por otro canal. Un mensaje por WhatsApp, un número de teléfono o un aviso corto en la web. La Oficina de Manejo de Emergencias de Nueva York hizo algo parecido al advertir que el correo a agencias municipales podía demorarse y derivar a los canales 311 y 911.
- Revisar dónde vive la lista de contactos de incidentes. Si solo está en Outlook, no sirve durante una caída de Outlook.
Como criterio de verificación, una propuesta editorial sencilla: para saber si un dominio depende de Exchange Online para recibir correo, alcanza con consultar sus registros MX y buscar un host terminado en mail.protection.outlook.com; para el envío, hay que mirar si el SPF incluye spf.protection.outlook.com. Es una comprobación reproducible en minutos y no requiere acceso al tenant. Lo que no permite concluir es cuánto usa esa organización Teams, SharePoint o Copilot, ni cuántos usuarios quedaron sin servicio.
Fuentes
- Microsoft, estado oficial del servicio: status.cloud.microsoft
- Kiel Tampubolon, “Microsoft 365 Went Down Overnight. 17.6% of Indonesian co.id Domains Get Their Mail Through It”, dev.to, 13 de noviembre de 2026: dev.to
- Alex Perry, “Microsoft global outage: What the company has said so far”, Mashable SEA, 12 y 13 de noviembre de 2026: sea.mashable.com
- “Microsoft 365 Outage Hits Outlook, Teams and 10 Other Services”, Blaze Trends, 13 de noviembre de 2026: blazetrends.com
- Madison Garcia, “Microsoft 365 outage disrupts Outlook, Teams and other services”, The Intelligent, 12 de noviembre de 2026: theintelligent.us
