Exchange apaga el SMTP básico en diciembre y su alternativa lo mantiene hasta 2028

550 5.7.30 Basic authentication is not supported for Client Submission. Esa es la línea que Microsoft publica como respuesta para cuando el básico quede apagado del todo. Si el apagado de diciembre llega por el interruptor de SMTP AUTH del inquilino, lo que verás es el 535 5.7.139 de siempre. Microsoft no ha dicho cuál de los dos te toca, y a efectos prácticos da igual: lo importante no es la fecha, ni el número de detrás. Es el cinco del principio.

En SMTP, un 4xx significa «ahora no, vuelve luego»: el mensaje se queda en cola y se reintenta. Un 5xx significa «no, y no insistas». La norma dice que el cliente no debería repetir, así que en la mayoría de los aparatos el correo deja de existir en el mismo segundo en que intentan mandarlo. Y ninguno tiene a quién quejarse, porque el rechazo ocurre al autenticarse, antes de que haya mensaje que devolver: no se genera informe de no entrega, no rebota nada, no llega un aviso a nadie.

Todo lo que sigue sale de dos avisos del equipo de Exchange y cuatro páginas de su documentación. Leídas por separado, cada una parece clara. Leídas juntas, una de ellas te dice que no vas a poder volver a encenderlo y otra te dice que sí.

La fecha ya ha cambiado tres veces

El motivo del último aplazamiento lo escribe Microsoft sin rodeos, y hay que reconocer que es honesto: «We understand that many customers continue to face real challenges modernizing legacy email workflows and need sufficient time to adopt viable, secure alternatives». Traducido: hay demasiada gente que todavía no puede.

Nuestra lectura, y la decimos marcada como lectura: planificar contra la fecha es planificar contra lo único que se ha movido. Lo que no se ha movido en dos años de aplazamientos es el código de error y lo que lo provoca.

«No podrás volver a encenderlo» y «podrás volver a encenderlo»

El anuncio original sigue publicado, con su aviso de actualización arriba apuntando al nuevo calendario, y mantiene intacta su sección de preguntas. Una de ellas es exactamente la que vas a hacer en enero: «Wait! I still need to use Basic auth; how can I get it re-enabled in my tenant once it gets disabled?». Y la respuesta es: «You will not be able to do this because Basic auth will be permanently disabled. Don't waste your time engaging Support, as they cannot re-enable Basic auth for you». La siguiente insiste: «We cannot offer any exceptions».

No es una contradicción de las que hay que denunciar: una frase describe diciembre y la otra describe el final. Pero el orden en que se leen cambia lo que haces. Si lees solo la de diciembre, la tarea de enero es «volver a encenderlo y cerrar la incidencia». Si lees las dos, la tarea de enero es otra.

Hay un precedente y está en la documentación oficial, no en un foro. Los otros protocolos (ActiveSync, POP, IMAP, EWS, PowerShell remoto, la libreta de direcciones, Autodiscover) pasaron por lo mismo en 2022, y la página que lo recoge lo cuenta así: «Before December 31, 2022, you could re-enable the affected protocols if users and apps in your tenant couldn't connect. Now no one (you or Microsoft support) can re-enable Basic authentication in your tenant». El interruptor de volver a encender existió exactamente durante una ventana, y luego desapareció. Eso es lo que contamos cuando le tocó a EWS, cuando le tocó al siguiente de la lista.

Quién está en el puerto 587

La respuesta no hay que imaginarla, porque Microsoft la enumera en su propia página de SMTP AUTH: «Applications, reporting servers, and multifunction devices that generate and send email messages», además de los clientes POP e IMAP, que necesitan SMTP autenticado para poder enviar. El protocolo vive «typically on TCP port 587» y los puntos de entrada afectados son smtp.office365.com y smtp-legacy.office365.com.

Esa lista, traducida a una oficina real, es la máquina de la planta dos que escanea a correo, el ERP que manda las facturas, el servidor de informes que envía el resumen de los lunes, el sistema de alarma, la plataforma de fichajes y aquel script que alguien dejó en una tarea programada. Casi ninguno de ellos tiene a nadie delante cuando falla. Y aquí es donde el 5xx se vuelve interesante: la impresora enciende un piloto rojo que nadie mira, el ERP escribe una línea en un registro que nadie lee, y la factura que creías enviada no se envió. Lo normal no es enterarse esa tarde. Lo normal es enterarse cuando el cliente llama en febrero preguntando por qué no ha recibido nada.

Por eso la pregunta útil para cada emisor de tu lista no es «¿sabe hacer OAuth?». Es «¿qué hace esto cuando el envío se rechaza para siempre, y dónde se ve?». En la mayoría de los sitios esa pregunta no se ha hecho nunca, porque hasta ahora el correo siempre salía.

La salida oficial sigue aceptando una contraseña

Para los aparatos que no pueden hacer OAuth, Microsoft señala High Volume Email como destino. Y en la misma página en la que lo anuncia escribe esto: «continued support for Basic Authentication until September 2028», con el motivo explícito de que «certain line-of-business (LOB) applications and devices may not support modern authentication yet».

Es decir: la respuesta oficial a «mi impresora solo sabe usuario y contraseña» es un servicio que sigue aceptando usuario y contraseña veintiún meses más. No hay nada escandaloso en ello, es pragmatismo, pero conviene llamarlo por su nombre antes de montarlo: no es modernizar nada, es mudar el problema a otro sitio con una fecha nueva. Y hay letra pequeña de verdad.

La fila que importa es la tercera, y Microsoft la justifica así: «HVE will support exclusively internal (within the tenant) messaging capabilities. As a result, the ability to send email to external recipients will be removed». Para enviar fuera, remite a Azure Communication Services. Así que la factura que tu ERP manda a un cliente no cabe ahí. Tampoco el aviso de entrega al proveedor ni el acuse del formulario de la web.

Cinco salidas, y la que decide es el destinatario

Mirando la tabla entera se ve lo que no dice ningún titular: la columna que decide no es la autenticación, es el destinatario. Antes de poder elegir salida hay que clasificar cada emisor por adónde manda —solo dentro, solo fuera, o las dos cosas—, y esa clasificación no está escrita en ningún sitio. Un multifunción que escanea a compañeros y a clientes está en las dos filas a la vez. Y conviene no saltarse la cuarta salida por poco glamurosa: para esa máquina de la planta dos, en una oficina con IP fija, un conector de entrada suele ser más barato y más rápido que abrir una suscripción de Azure, y además quita la contraseña de en medio en lugar de mudarla.

Tres interruptores, y no tienen el mismo alcance

Microsoft dice «disabled by default», y en Exchange Online «por defecto» tiene un significado técnico muy concreto. Hay tres mecanismos documentados que pueden decir que no a un usuario y una contraseña por SMTP, y no alcanzan a los mismos buzones. Por cuál de ellos llega diciembre no lo ha publicado nadie todavía, y no hace falta deducirlo: el propio mensaje del centro de mensajes cierra el bloque diciendo «We will provide detailed information in a follow up Message Center Post». Así que el detalle está pendiente, y lo que sigue es una comprobación que puedes hacer hoy, no una afirmación sobre cómo lo van a implementar.

Las dos últimas filas admiten excepciones puestas a mano, buzón a buzón o usuario a usuario. Y en la mayoría de los inquilinos esas excepciones existen: se pusieron durante la limpieza de 2022, para que la impresora siguiera funcionando, y las puso alguien que a lo mejor ya no trabaja ahí. Esa es la lista que conviene tener delante antes de que llegue diciembre, se implemente como se implemente.

Hay además un informe que hace la mitad del trabajo y que lleva puesto desde octubre de 2024: en el centro de administración de Exchange, el informe de clientes de envío SMTP AUTH distingue desde entonces si cada emisor se autentica con básico o con OAuth. No te dice a quién manda cada uno —esa columna la tienes que poner tú—, pero te da los nombres.

Qué haríamos nosotros en noviembre

Nada heroico, y cabe en una mañana. Sacar el informe y quedarse con los emisores que van con básico. Cruzarlo con los buzones que tienen la excepción puesta a mano, porque casi siempre aparece alguno que ya nadie usa y que lleva cuatro años con una contraseña permanente encima. Añadir a cada fila dos columnas que el inventario nunca trae: adónde manda —solo dentro, solo fuera, las dos cosas— y dónde se vería el error si mañana le dijeran que no.

Con esa tabla delante las decisiones salen solas, y la mitad son de apagar: lo que se mueve a OAuth, lo que se pasa a un conector, lo que se jubila porque llevaba dos años mandando a una lista de distribución vacía, y lo que se queda esperando con una fecha propia escrita. Lo bueno es que esa tabla no caduca cuando Microsoft mueva la fecha otra vez, y la van a mover. Las políticas del inquilino, qué buzón usa cada aparato y qué se ve cuando algo se rechaza es gobierno de Microsoft 365; qué integración del ERP manda ese correo, si puede hablar OAuth y cuánto cuesta que lo hable es terreno de datos y aplicaciones. Si quieres que lo miremos contigo, está el formulario de contacto.

A finales de diciembre no va a sonar ninguna alarma. Un 5xx no suena: es un silencio muy limpio, y los silencios limpios son los caros. La diferencia entre el equipo al que esto le cuesta una mañana y el equipo al que le cuesta una reclamación de un cliente en febrero no la marca lo rápido que reaccione en enero. La marca si alguien se sentó en noviembre a escribir la lista.

Fuentes. Consultadas el 3 de noviembre de 2026. El calendario vigente y sus hitos citados literalmente son del aviso «Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline», del equipo de mensajería de Microsoft 365, publicado el 27 de enero de 2026, que a día de hoy sigue siendo el último. El calendario anterior (1 de marzo y 30 de abril de 2026, y antes septiembre de 2025), el código 550 5.7.30 y su condición «once Basic auth is permanently disabled», los dos puntos de entrada, las alternativas y las dos preguntas del FAQ sobre volver a encenderlo son del aviso original, «Exchange Online to retire Basic auth for Client Submission (SMTP AUTH)», que sigue publicado con su nota de actualización. La pausa de junio de 2025 («has been put on hold») y la frase sobre el detalle pendiente («We will provide detailed information in a follow up Message Center Post») son del mensaje MC786329 del centro de mensajes, que también recoge la columna de protocolo de autenticación añadida al informe en octubre de 2024. El precedente de 2022, la frase sobre que ya nadie puede reactivarlo y los protocolos afectados entonces son de «Deprecation of Basic authentication in Exchange Online». La lista de quién usa SMTP AUTH, el puerto 587, el ajuste por organización y por buzón, la precedencia del buzón y la nota sobre los valores predeterminados de seguridad son de «Enable or disable SMTP AUTH in Exchange Online». El conmutador AllowBasicAuthSmtp y la precedencia de las políticas asignadas sobre la política por defecto son de «Disable Basic authentication in Exchange Online». El relay SMTP con conector de entrada, su autenticación por certificado o IP fija, el puerto 25 y la frase sobre cuándo aplica son de «How to set up a multifunction device or application to send email». El soporte de básico hasta septiembre de 2028, el paso a destinatarios exclusivamente internos y la tabla de límites son de «High Volume Email: Continued support for Basic Authentication»; la disponibilidad general, el inicio de facturación el 1 de junio de 2026, los 42 dólares por millón de destinatarios y el aviso de interrupción si no se configura la facturación son del mensaje MC1243552. El 535 5.7.139 es el error documentado cuando SMTP AUTH está deshabilitado en el inquilino o en el buzón, y lo citamos como la otra posibilidad precisamente porque el mecanismo de diciembre no está publicado. Las citas se dejan en su inglés original para que se puedan buscar literalmente. La fotografía de la imagen social es «Konica Minolta Bizhub C454e photocopier», de Baron Maddock, CC BY 4.0 vía Wikimedia Commons.