El 10 de noviembre de 2026, Microsoft cerro uno de los incidentes de entregabilidad mas comentados del ano. En su portal de estado del servicio de Microsoft 365, bajo el incidente EX1545193 titulado “Some users may be intermittently unable to send email messages to Outlook.com, Hotmail.com, or Live.com email addresses”, la empresa confirmo la causa: una actualizacion de las reglas de aplicacion antispam marco y bloqueo incorrectamente mensajes de correo, lo que provoco el impacto.
Dicho de otro modo: la ola de rechazos que afecto a remitentes entre el 5 y el 9 de noviembre no fue una extension silenciosa de los requisitos de DMARC de Microsoft para remitentes pequenos. Fue una actualizacion defectuosa de una regla que ya ha sido revertida por completo.
La cronologia oficial
Microsoft situa el impacto entre las 18:00 UTC del 6 de noviembre y las 11:02 UTC del 9 de noviembre. Durante esa ventana, Outlook.com, Hotmail, Live y MSN rechazaron parte del correo enviado desde dominios sin registro DMARC, devolviendo el error 550 5.7.1 “Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)”. El 9 de noviembre a las 05:24 UTC, Microsoft pidio a quien siguiera afectado identificadores de mensaje y ejemplos en formato .eml, y a las 05:36 UTC del 10 de noviembre cerro el incidente confirmando que la actualizacion estaba totalmente revertida y que revisa sus procedimientos de actualizacion para reducir los falsos positivos.
La evidencia independiente respalda la version de los remitentes. MailRoute registro los primeros rechazos el 5 de noviembre, antes de la hora de inicio indicada por Microsoft, y EasyDMARC reprodujo el rechazo con un dominio de prueba que tenia SPF y DKIM validos y alineados pero sin registro DMARC. Las pruebas con buzones semilla de DMARKOFF mostraron que publicar incluso un registro DMARC minimo con p=none en el dominio principal bastaba para que los 16 buzones de prueba de Outlook.com y Hotmail aceptaran un mensaje que habian rechazado sin el.
Que deben hacer los remitentes ahora
Del incidente se siguen tres conclusiones practicas.
Primera: reenvie todo lo que reboto. Un rechazo permanente 550 nunca se reintenta, por lo que facturas, presupuestos y respuestas a clientes rechazados en esos dias simplemente no llegaron, y el destinatario no sabe que se enviaron.
Segunda: si publico un registro DMARC la semana pasada como medida de emergencia, mantenlo. Con p=none no cambia como tratan los buzones a su correo, cumple las reglas para grandes volumenes que Google y Yahoo aplican desde febrero de 2024 y que Microsoft aplica desde mayo de 2025 a los remitentes de alto volumen hacia Outlook.com, y le da informes agregados que muestran quien envia correo en nombre de su dominio. Esa visibilidad es el primer paso hacia p=reject, donde los receptores rechazan directamente las falsificaciones de su dominio.
Tercera: tome el episodio como una prueba de estres gratuita. Microsoft dice que el fallo no era intencionado, pero durante tres dias su infraestructura rechazo dominios sin autenticar sin importar el volumen, y los dominios con DMARC publicado fueron los que pasaron. El seguro mas barato frente al siguiente cambio de exigencia, previsto o no, es tener el registro ya publicado, con SPF y DKIM correctamente alineados, en cada dominio desde el que envia correo, incluidos dominios aparcados y herramientas internas de notificaciones.
Si prefiere que la autenticacion y la higiene DNS se gestionen por usted en cada dominio de envio, registrese gratis en Excello Mail.