Caída de Microsoft 365: el filtro que falló abierto

Resumen#

Durante la caída global de Microsoft 365 del 12 y 13 de noviembre de 2026 (incidencias EX1550543 y MO1550821), un servidor de nuestro laboratorio consiguió entregar en un buzón de Exchange Online un correo que la plataforma rechazaba sistemáticamente desde hacía meses.

El correo es el informe nocturno de copias de seguridad de un hipervisor Proxmox VE. Sale directamente de una conexión residencial, sin relay autenticado, sin SPF, sin DKIM y con un remitente de un dominio .local que no existe en Internet. Exchange Online Protection (EOP) lo había rechazado 104 veces seguidas desde el 1 de agosto con el mismo error: la IP de origen figura en Spamhaus. La madrugada del 13 de noviembre, en plena incidencia, el mismo mensaje se aceptó, obtuvo una puntuación de spam de 1 (SCL 1) y se entregó en la bandeja de entrada.

Las cabeceras del mensaje y los registros del servidor apuntan a que, mientras la plataforma estaba degradada, el filtrado por reputación de IP en la conexión falló abierto (fail-open): ante la falta de respuesta, se dejó pasar el correo en lugar de rechazarlo. Este artículo documenta lo que hemos observado, lo que no podemos confirmar y qué deberían revisar los administradores de Microsoft 365.

El correo que nunca llega#

El servidor envía cada noche un informe al terminar las copias de seguridad. Proxmox VE lo entrega a Postfix, que no tiene ningún relay configurado (relayhost vacío), así que Postfix consulta el MX del dominio destinatario y entrega el mensaje directamente en EOP por el puerto 25.

Ese envío reúne todo lo que un filtro de correo debería rechazar:

IP de origen residencial, con DNS inverso genérico del operador (aXX-XXX-XXX-XXX.cpe.<operador>), del tipo que figura en las listas de Spamhaus para direcciones que no deberían enviar correo directamente.
Remitente root@<host>.local: un dominio que no existe en DNS, así que no puede tener SPF, DKIM ni DMARC.
Mensaje sin firmar.

EOP lo rechazaba durante la conversación SMTP, al recibir el destinatario (RCPT TO), antes de aceptar el contenido:

postfix/smtp: to=<[email protected]>, relay=<tenant>.mail.protection.outlook.com[52.101.x.x]:25,
  delay=0.53, delays=0.02/0.01/0.37/0.13, dsn=5.7.1, status=bounced
  (host said: 550 5.7.1 Service unavailable, Client host [IP residencial] blocked using Spamhaus.
   ... AS(1450) [ZR1PEPF0000E45F.eurprd04.prod.outlook.com 2026-11-12T03:29:54.527Z]
   (in reply to RCPT TO command))

Hay dos rechazos por noche, no uno. Al recibir el primero, Postfix genera un aviso de no entrega para root, Proxmox lo reenvía a la misma dirección externa y EOP lo vuelve a rechazar. Los registros del sistema, que empiezan el 1 de agosto, muestran 104 rechazos idénticos por Spamhaus y ninguna entrega hasta el 12 de noviembre.

La noche del 13 de noviembre#

La incidencia de Microsoft empezó la tarde del 12 de noviembre (hora UTC) y afectó a Exchange Online, Outlook, Teams, SharePoint y Defender XDR, entre otros servicios. Según Microsoft, una gran cantidad de servidores dejó de estar disponible, el resto tuvo que absorber la carga, los equipos afectados no superaban las comprobaciones de estado automáticas y el proceso que establece las conexiones seguras estaba saturado. Durante la recuperación, Microsoft amplió a 48 horas el tiempo que retiene el correo pendiente de entrega.

A las 03:29 UTC del 13 de noviembre, unas nueve horas después del inicio de la incidencia, Proxmox envió el informe de siempre. Esta vez, Postfix registró esto:

03:29:28 postfix/smtp: connect to <tenant>.mail.protection.outlook.com[2a01:111:f403:…]:25: Network is unreachable
03:29:44 postfix/smtp: to=<[email protected]>, relay=<tenant>.mail.protection.outlook.com[52.101.x.x]:25,
  delay=16, delays=0.02/0.01/0.37/16, dsn=2.6.0, status=sent
  (250 2.6.0 <…@<host>.local> [InternalId=…, Hostname=AS8P194MB1896.EURP194.PROD.OUTLOOK.COM]
   78553 bytes in 0.202, 379.010 KB/sec Queued mail for delivery)

El cuarto valor de delays es el tiempo de la fase de transmisión, la que incluye MAIL FROM, RCPT TO y DATA. Es justo la fase en la que EOP suele rechazar este correo.

	Noche normal (12 nov)	Noche de la incidencia (13 nov)
Establecimiento de la conexión	0,37 s	0,37 s
Fase de transmisión (`MAIL`/`RCPT`/`DATA`)	0,13 s	16 s
Respuesta de EOP	`550 5.7.1 … blocked using Spamhaus`	`250 2.6.0 Queued mail for delivery`
Avisos de no entrega generados	1 (también rechazado)	0
Resultado	Rechazado	Entregado en la bandeja de entrada

La conexión se estableció igual de rápido que cualquier otra noche, pero la parte del diálogo en la que se decide el rechazo tardó unas 120 veces más. Las cabeceras lo confirman desde el lado de Microsoft: el servidor frontal de EOP recibió el mensaje a las 03:29:28 y no lo pasó al siguiente salto hasta las 03:29:43. Los 15 segundos que faltan se quedaron dentro de EOP.

Lo que dicen las cabeceras#

El mensaje entregado lleva el veredicto antispam de EOP. Estas son las cabeceras relevantes, con la IP y el dominio anonimizados:

Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=<host>.local;
X-MS-Exchange-Organization-SCL: 1
X-Forefront-Antispam-Report: CIP:<IP residencial>;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;
 H:<host>.local;PTR:;CAT:NONE;…;DIR:INB;
X-Microsoft-Antispam-Mailbox-Delivery: ucf:0;jmr:0;auth:0;dest:I;…

IPV:NLI: según la documentación de Microsoft, la IP de origen no figura en ninguna lista de reputación de IP. Es la misma IP que EOP había rechazado la noche anterior, y que volvió a rechazar ese mismo día, precisamente por estar en Spamhaus.
CTRY: y PTR: vacíos: son el país de la IP de origen y su DNS inverso. La IP tiene un registro PTR válido, pero el campo está vacío. No tenemos un correo aceptado desde esta IP en condiciones normales con el que comparar, así que lo anotamos como indicio y no como prueba.
SFV:NSPM y SCL:1: el filtro de contenido marcó el mensaje como no spam.
dest:I: el mensaje se entregó en la bandeja de entrada, no en correo no deseado.
Sin resultado SPF ni compauth: Authentication-Results solo recoge DKIM y DMARC. En el formato que documenta Microsoft, esa cabecera incluye también el resultado de SPF y la autenticación compuesta (compauth), que EOP utiliza para detectar suplantaciones cuando el dominio del remitente no publica DMARC.

El dato decisivo es IPV:NLI: la comprobación de reputación de la IP de origen no devolvió ningún listado, y el mensaje siguió su camino como si la IP estuviera limpia.

Comprobación posterior#

El mismo 13 de noviembre a las 15:36 UTC repetimos la conversación SMTP desde la misma IP contra los servidores MX del dominio, deteniéndonos en RCPT TO sin llegar a enviar ningún mensaje. El resultado volvió a ser el habitual:

550 5.7.1 Service unavailable, Client host [IP residencial] blocked using Spamhaus. ... AS(1450)

Uno de los servidores frontales respondió además con 421 4.3.2 The maximum number of concurrent server connections has exceeded a limit: la plataforma seguía sin capacidad suficiente, pero el bloqueo por reputación de IP volvía a aplicarse.

A las 15:43 UTC lo repetimos contra los cuatro servidores MX, dos veces cada uno: los ocho intentos se rechazaron en unos 0,05 segundos. Por tanto, el filtro no estuvo desactivado durante toda la incidencia. Sabemos que falló al menos a las 03:29 UTC del 13 de noviembre y que por la tarde volvía a funcionar, con la incidencia todavía abierta, pero no cuánto duró ese hueco ni si hubo otros. Por eso conviene revisar todo el correo recibido durante la incidencia y no solo el de una hora concreta.

Interpretación: un filtro que falla abierto#

Microsoft no ha publicado todavía el informe posterior a la incidencia, así que no podemos confirmar qué componente falló. Lo observado encaja con este escenario:

El servidor frontal de EOP aceptó la conexión con normalidad.
Al llegar a RCPT TO, la consulta de reputación de la IP de origen no respondió a tiempo, o el componente que la resuelve estaba degradado o se había desactivado como medida de mitigación.
Ante la falta de respuesta, EOP trató la IP como no listada (IPV:NLI) en lugar de aplazar el mensaje con un error temporal 4xx.
El resto de la cadena (SPF, suplantación, contenido) se aplicó de forma parcial o no se aplicó, y un correo sin autenticar desde una IP residencial llegó a la bandeja de entrada con SCL 1.

No podemos descartar del todo que el fallo estuviera en la consulta a Spamhaus y no en EOP, pero para el destinatario el resultado es el mismo: el control dejó de aplicarse y el sistema siguió aceptando correo.

Fallar abierto no es necesariamente un error de diseño. En un servicio de correo del tamaño de Exchange Online, rechazar todo el correo entrante cada vez que una dependencia tarda en responder sería una caída en sí misma. Pero es una decisión con consecuencias de seguridad, y conviene que los clientes sepan que existe.

Por qué importa#

Las listas de reputación de IP son la primera barrera contra el spam y el phishing que envían las botnets, que salen sobre todo de equipos domésticos comprometidos con IP residenciales. Son exactamente las IP que Spamhaus clasifica como no aptas para enviar correo directamente, y exactamente el tipo de IP desde el que se envió nuestro correo.

Si esa barrera cae durante una incidencia, todo el correo que normalmente se corta en la conexión llega a los filtros siguientes, que en nuestro caso también estaban degradados. Además:

Las caídas de Microsoft 365 son públicas y se siguen en tiempo real. Un atacante puede programar una campaña para que coincida con una ventana de degradación.
Los usuarios están más expuestos durante una caída. Esperan correos de soporte, avisos de restablecimiento del servicio o mensajes reenviados con retraso, que son pretextos perfectos para el phishing.
El correo pendiente se entrega a la vez. Con un tiempo de retención ampliado a 48 horas, los mensajes llegan en bloque al terminar la incidencia, y uno malicioso puede pasar desapercibido entre ellos.

Recomendaciones#

Para administradores de Microsoft 365#

Revisar el correo recibido durante la incidencia. En Microsoft Defender XDR, una consulta de búsqueda avanzada sobre EmailEvents permite localizar el correo entregado sin autenticación durante la ventana de la incidencia y agruparlo por IP de origen:

EmailEvents
| where Timestamp between (datetime(2026-11-12T12:00:00Z) .. datetime(2026-11-14T12:00:00Z))
| where EmailDirection == "Inbound" and DeliveryAction == "Delivered"
| extend Auth = parse_json(AuthenticationDetails)
| where tostring(Auth.DMARC) != "pass" and tostring(Auth.SPF) != "pass"
| summarize Mensajes = count(), Destinatarios = dcount(RecipientEmailAddress)
    by SenderIPv4, SenderFromDomain
| order by Mensajes desc

Publicar DMARC con p=quarantine o p=reject en los dominios propios. Con p=none, la protección contra la suplantación del propio dominio depende por completo de las heurísticas de EOP, que son justo las que se vieron afectadas.
No confiar en una sola capa. Las reglas de transporte, las alertas sobre correo entregado sin autenticar y la formación de los usuarios siguen funcionando cuando una dependencia del filtro de conexión falla.
Avisar a los usuarios durante y después de una caída de que extremen la precaución con el correo que esperan recibir, sobre todo si pide credenciales o acciones urgentes.

Para quien envía alertas desde un laboratorio o un servidor propio#

Que nuestro informe llegara fue un fallo del destinatario, no un acierto de la configuración de origen. Lo correcto es:

Enviar a través de un relay autenticado, por ejemplo con el destino de notificaciones SMTP de Proxmox VE apuntando a un buzón de servicio o a un proveedor de correo transaccional, por el puerto 587 con STARTTLS.
Usar un remitente de un dominio real con SPF, DKIM y DMARC correctos.
Revisar el bucle de avisos de no entrega. Si el correo de root se reenvía a la misma dirección externa que está rechazando los mensajes, cada fallo genera un segundo intento que también fallará.

Limitaciones#

Es una sola observación, desde un solo origen y hacia un solo tenant. No sabemos si el comportamiento afectó a toda la plataforma o solo a parte de los servidores frontales.
No hemos podido consultar Spamhaus en el momento exacto del envío. Sí sabemos que EOP rechazaba la IP por Spamhaus el día anterior y volvió a hacerlo horas después.
La explicación del fallo abierto es una inferencia a partir de los registros y las cabeceras. Actualizaremos este artículo si el informe de Microsoft aporta más detalles.

Caída de Microsoft 365: el correo que Exchange Online rechazaba cada noche llegó a la bandeja de entrada