Fin de Basic Auth SMTP en Microsoft Exchange Online: calendario, error 550 5.7.30 y guía de migración

Desde 2019, Microsoft elimina progresivamente la autenticación Basic (usuario + contraseña) de sus protocolos en Exchange Online. EAS, POP, IMAP, EWS, PowerShell: todos migraron a Modern Auth a finales de 2022. El último bastión era SMTP AUTH Client Submission, el protocolo utilizado por impresoras multifunción, scripts de envío y aplicaciones de negocio para enviar correos a través de smtp.office365.com en el puerto 587.

En abril de 2024, Microsoft anunció el fin de este último bastión. Tras varios aplazamientos (septiembre de 2025, luego marzo de 2026), el calendario revisado de enero de 2026 concede un plazo adicional, pero el mensaje es claro: Basic Auth SMTP está condenado y cada organización debe planificar su migración.

Este artículo detalla el calendario exacto, los sistemas afectados, las cinco alternativas disponibles y un checklist concreto de migración.

¿Qué es Basic Auth SMTP y por qué es un problema?

La autenticación Basic para SMTP funciona de forma sencilla: el cliente codifica el usuario y la contraseña en Base64 y los transmite al servidor con el comando AUTH LOGIN o AUTH PLAIN. Aunque la conexión esté cifrada con TLS (STARTTLS en el puerto 587), las credenciales son reutilizables, sin expiración y sin segundo factor.

C: AUTH LOGIN
S: 334 VXNlcm5hbWU6
C: dXNlckBjYXB0YWluZG5zLmNvbQ==
S: 334 UGFzc3dvcmQ6
C: bW90ZGVwYXNzZQ==
S: 235 2.7.0 Authentication successful

Este mecanismo plantea tres problemas principales:

OAuth 2.0 resuelve estos tres problemas: los tokens son temporales (60 min por defecto), revocables, asociados a un scope preciso (SMTP.Send) y compatibles con MFA y acceso condicional.

SMTP AUTH Client Submission vs SMTP Relay

Es importante distinguir dos mecanismos de envío a través de Exchange Online:

La retirada de Basic Auth afecta únicamente a Client Submission. Los relays SMTP basados en dirección IP (opción 2 de la documentación de Microsoft) no se ven afectados.

Calendario completo de la retirada

El calendario se ha revisado varias veces. Esta es la línea temporal consolidada al 19 de febrero de 2026:

El error 550 5.7.30

Tras la desactivación, cualquier cliente que intente una autenticación Basic recibirá:

550 5.7.30 Basic authentication is not supported for Client Submission.

Este error es un rechazo permanente (código 5xx). El servidor remitente no reintentará. Los correos no se ponen en cola: se pierden inmediatamente.

¿Quién se ve afectado?

Cualquier aplicación o dispositivo que envíe correos a través de smtp.office365.com o smtp-legacy.office365.com con usuario y contraseña está afectado.

Sistemas típicamente afectados

¿Cómo identificar a los remitentes con Basic Auth?

Microsoft actualizó el informe SMTP AUTH en el Exchange Admin Center (EAC) en octubre de 2024 para distinguir las conexiones Basic Auth de las conexiones OAuth.

1. Inicia sesión en admin.exchange.microsoft.com
2. Ve a Informes > Flujo de correo > Informe de clientes SMTP Auth
3. Filtra por tipo de autenticación para aislar los remitentes con Basic Auth

Cada línea indica la dirección del remitente, el número de mensajes y el tipo de autenticación utilizado.

Alternativa 1: OAuth 2.0 para SMTP AUTH

Es la solución recomendada por Microsoft para los clientes y aplicaciones capaces de gestionar tokens OAuth.

Requisitos previos

1. Registrar una aplicación en Microsoft Entra (Azure AD)
2. Agregar el permiso SMTP.Send (flujo interactivo) o SMTP.SendAsApp (flujo de aplicación)
3. Obtener el consentimiento del administrador del tenant

Dos flujos posibles

Sesión SMTP con OAuth

El cliente utiliza el mecanismo SASL XOAUTH2:

C: AUTH XOAUTH2 dXNlcj1hbGVydHNAY2FwdGFpbmRucy5jb20BYXV0aD1CZWFyZXIgZXl
KMGVYQUlPaUpLVjFRaUxDSmhiR2NpT2lKU1V6STFOaUo5Li4uAQE=
S: 235 2.7.0 Authentication successful

El token Base64 codifica user=alerts@captaindns.com seguido del Bearer token OAuth. El token expira a los 60 minutos; el cliente debe gestionar la renovación mediante el refresh token.

Limitaciones

• Las impresoras MFP y dispositivos IoT generalmente no soportan OAuth
• Requiere un registro de aplicación en Entra ID
• El flujo Client Credentials requiere el registro de un Service Principal en Exchange Online a través de PowerShell

Alternativa 2: High Volume Email (HVE)

El servicio HVE está diseñado para envíos internos de gran volumen desde aplicaciones y dispositivos.

¿Cuándo usar HVE?

HVE es adecuado cuando:

• El dispositivo no soporta OAuth (MFP, IoT)
• Los correos son exclusivamente internos (alertas, notificaciones, scan-to-email hacia buzones del tenant)
• El volumen es elevado (sin rate-limit en destinatarios)

Creación de una cuenta HVE

A través del EAC: Flujo de correo > High Volume Email (Preview) > Agregar una cuenta HVE.

O a través de PowerShell:

New-MailUser -HVEAccount -Name "Scanner Alerts" -PrimarySmtpAddress "scanner-alerts@captaindns.com"

Atención: HVE está en preview pública. Microsoft se reserva el derecho de suspender el servicio. No asignes licencias a las cuentas HVE.

Alternativa 3: Azure Communication Services Email

Azure Communication Services (ACS) Email permite el envío interno y externo a través de una API REST o SDKs (.NET, Python, JavaScript, Java).

ACS es pertinente para aplicaciones cloud-native que puedan integrar un SDK. No es adecuado para dispositivos físicos (impresoras, escáneres) que solo hablan SMTP.

Alternativa 4: relay SMTP on-premises

Para organizaciones en configuración híbrida (Exchange Online + Exchange Server on-premises), el relay SMTP local sigue siendo una opción.

Funcionamiento

1. Los dispositivos (MFP, IoT, scripts) envían al servidor Exchange local a través del puerto 25 (anonymous relay)
2. El conector Receive está configurado para aceptar conexiones desde una red IP interna
3. El servidor Exchange local retransmite hacia Exchange Online a través del conector Send

Configuración del conector Receive

New-ReceiveConnector -Name "Anonymous Relay" `
  -TransportRole FrontendTransport `
  -Usage Custom `
  -Bindings 0.0.0.0:25 `
  -RemoteIPRanges 192.168.1.0/24 `
  -PermissionGroups AnonymousUsers

Ventajas e inconvenientes

Alternativa 5: Microsoft Graph API

Para scripts y aplicaciones, la API Graph ofrece el endpoint /users/{id}/sendMail que reemplaza ventajosamente a SMTP.

curl -X POST "https://graph.microsoft.com/v1.0/users/alerts@captaindns.com/sendMail" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "message": {
      "subject": "Alerta monitoring",
      "body": {"contentType": "Text", "content": "Le serveur DNS est indisponible."},
      "toRecipients": [{"emailAddress": {"address": "ops@captaindns.com"}}]
    }
  }'

Graph API es ideal para reemplazar scripts PowerShell (Send-MailMessage está obsoleto) y aplicaciones de servidor. No es adecuado para dispositivos hardware que solo pueden ejecutar SMTP.

Tabla comparativa de las alternativas

Checklist de migración

Impacto en la entregabilidad y la seguridad

La retirada de Basic Auth no afecta a SPF, DKIM ni DMARC. Estos protocolos de autenticación de correo funcionan a nivel DNS y son independientes del método de autenticación SMTP.

En cambio, la migración ofrece una oportunidad para reforzar tu postura de seguridad:

• MFA en todas partes: OAuth permite imponer la autenticación multifactor en las cuentas de envío interactivas
• Tokens revocables: a diferencia de una contraseña comprometida que sigue siendo válida hasta el cambio, un token OAuth expira automáticamente
• Acceso condicional: puedes restringir el envío SMTP a rangos de IP, dispositivos conformes u horarios específicos
• Auditoría granular: las conexiones OAuth son trazables en los logs de Entra ID con el detalle de la aplicación y el scope utilizado

Este movimiento de Microsoft se inscribe en una tendencia más amplia. Google y Yahoo impusieron requisitos de autenticación reforzados para los remitentes masivos desde 2024. La securización del canal de envío SMTP es la continuación lógica.

Glosario

• Basic Auth: método de autenticación que transmite el usuario y la contraseña codificados en Base64. Sin protección intrínseca contra la repetición.
• OAuth 2.0: protocolo de autorización basado en tokens temporales. Soporta MFA y acceso condicional.
• SASL XOAUTH2: mecanismo SASL utilizado para transmitir un token OAuth 2.0 en una sesión SMTP, IMAP o POP.
• Client Submission: método de envío SMTP autenticado a través de smtp.office365.com (puerto 587). El remitente se autentica con credenciales.
• SMTP Relay: método de envío SMTP basado en la dirección IP de origen, sin credenciales. Utiliza un conector entrante Exchange Online.
• HVE (High Volume Email): servicio Microsoft 365 que permite el envío interno de gran volumen a través de smtp-hve.office365.com. Preview pública.
• Microsoft Entra: nuevo nombre de Azure Active Directory. Gestiona los registros de aplicaciones, los permisos y los tokens OAuth.
• Service Principal: identidad de aplicación en Exchange Online, necesaria para el flujo Client Credentials OAuth.
• MFA: autenticación multifactor. Imposible con Basic Auth, nativa con OAuth 2.0.

Fuentes

• Exchange Online to retire Basic auth for Client Submission (SMTP AUTH) - Exchange Team Blog, abril de 2024
• Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline - Exchange Team Blog, enero de 2026
• Deprecation of Basic authentication in Exchange Online - Microsoft Learn
• Authenticate an IMAP, POP or SMTP connection using OAuth - Microsoft Learn
• Manage High Volume Email for Microsoft 365 - Microsoft Learn