Microsoft 365 "535 5.7.139 Authentication unsuccessful": cómo solucionarlo

Qué significa

Tu aplicación, web, impresora o script se ha conectado a Microsoft 365 (smtp.office365.com) para enviar un email y ha intentado iniciar sesión con un usuario y una contraseña. Microsoft ha rechazado el inicio de sesión. El error llega durante la conversación SMTP, antes de que se envíe ningún email. Las variantes más habituales son:

535 5.7.139 Authentication unsuccessful, SmtpClientAuthentication is disabled for the Tenant.
535 5.7.139 Authentication unsuccessful, the user credentials were incorrect.
535 5.7.139 Authentication unsuccessful, user is locked by your organization's security defaults policy.
535 5.7.139 Authentication unsuccessful, the request did not meet the criteria to be authenticated successfully.

El texto que va después de la coma te dice qué ajuste ha bloqueado el inicio de sesión, así que léelo con atención. Iniciar sesión para enviar correo de esta manera se llama SMTP AUTH (o "authenticated client submission"), normalmente en el puerto 587.

Por qué ocurre

• SMTP AUTH está desactivado para toda la organización (tenant) o para ese buzón. Microsoft recomienda mantenerlo desactivado y activarlo solo para las cuentas que lo necesitan, y ya lo ha desactivado en los tenants que no lo usaban.
• Los security defaults están activados en Microsoft Entra ID. La documentación de Microsoft dice que, con los security defaults activados, SMTP AUTH está desactivado, aunque lo actives en un buzón.
• La autenticación básica está bloqueada por una directiva de autenticación o por una directiva de acceso condicional (Conditional Access) que bloquea la "autenticación heredada". En ese caso el mensaje suele decir que la petición "did not meet the criteria".
• Credenciales incorrectas o MFA. Una contraseña incorrecta o caducada, o una cuenta protegida con autenticación multifactor, no puede iniciar sesión con una simple contraseña. Las contraseñas de aplicación ya no funcionan con la autenticación básica.
• La cuenta no tiene un buzón utilizable: sin licencia de Exchange Online, o un buzón compartido con el inicio de sesión bloqueado.

La retirada de la autenticación básica

Microsoft está retirando la autenticación básica (un simple usuario y contraseña) para SMTP AUTH. El calendario ha cambiado varias veces. En el momento de escribir esto, el último anuncio de Microsoft (enero de 2026) dice que el comportamiento no cambia hasta diciembre de 2026; a finales de diciembre de 2026, la autenticación básica para SMTP AUTH quedará desactivada por defecto en los tenants existentes, los administradores aún podrán volver a activarla y se anunciará una fecha de retirada definitiva en la segunda mitad de 2027. Consulta el blog del equipo de Exchange para ver las fechas actuales. La solución a largo plazo es OAuth 2.0 ("autenticación moderna").

Cómo comprobarlo

1. Copia el error completo del log de tu aplicación. La parte que va después de "Authentication unsuccessful" apunta a la causa.
2. En Exchange Online PowerShell, revisa la configuración de la organización y del buzón:

   Connect-ExchangeOnline
   Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled
   Get-CASMailbox -Identity app@yourdomain.com | Format-List SmtpClientAuthenticationDisabled

   True significa desactivado. En el buzón, un valor vacío significa "seguir la configuración de la organización".
3. En el Microsoft 365 admin center, ve a Users > Active users, selecciona la cuenta, después Mail > Manage email apps y mira Authenticated SMTP.
4. En el Microsoft Entra admin center, comprueba si los security defaults están activados y si una directiva de acceso condicional bloquea la autenticación heredada. Los registros de inicio de sesión de Entra muestran el intento fallido y la directiva que lo bloqueó.
5. Haz una prueba manual con swaks (verás la respuesta exacta del servidor):

   swaks --server smtp.office365.com --port 587 --tls \
     --auth LOGIN --auth-user app@yourdomain.com --auth-password 'your-password' \
     --from app@yourdomain.com --to you@example.com

Si el servidor responde en cambio que debes autenticarte antes del MAIL FROM, tu herramienta ni siquiera está iniciando sesión: consulta 530 5.7.57 Client not authenticated.

Cómo solucionarlo

La mejor opción: pasa la aplicación a OAuth 2.0

Si tu aplicación admite el inicio de sesión "Microsoft 365 / OAuth", úsalo. Microsoft documenta cómo registrar una aplicación en Microsoft Entra ID y usar OAuth con SMTP AUTH. En nodemailer, por ejemplo, pasas un token de acceso en lugar de una contraseña:

const transporter = nodemailer.createTransport({
  host: 'smtp.office365.com',
  port: 587,
  secure: false,       // STARTTLS on port 587
  requireTLS: true,
  auth: { type: 'OAuth2', user: 'app@yourdomain.com', accessToken: token }
});

En tu propio código, enviar a través de la API de Microsoft Graph (sendMail) evita por completo SMTP AUTH.

Si de momento tienes que seguir con una contraseña

1. Activa SMTP AUTH solo para el buzón que envía, no para toda la organización:

   Set-CASMailbox -Identity app@yourdomain.com -SmtpClientAuthenticationDisabled $false

2. Si los security defaults están activados, SMTP AUTH sigue bloqueado. La alternativa es sustituir los security defaults por directivas de acceso condicional (requiere licencias Entra ID P1) que sigan exigiendo MFA a las personas pero permitan esta cuenta de servicio concreta. Piensa en el impacto en la seguridad antes de cambiarlo.
3. Usa un buzón dedicado con una contraseña larga y única, una licencia y sin solicitud de MFA, y asegúrate de que la aplicación usa el puerto 587 con STARTTLS (el puerto 465 con TLS implícito no es lo que Microsoft documenta para este endpoint).
4. Los cambios no son instantáneos: deja pasar un tiempo (a menudo hasta una hora) antes de volver a probar.

Dispositivos que no admiten OAuth

Las impresoras y escáneres antiguos a menudo solo admiten una contraseña. En lugar de SMTP AUTH, pueden enviar a través de un conector de relay SMTP (desde una IP pública fija) o mediante direct send a tu endpoint MX. Ambas opciones se comparan en la guía del 5.7.57.

Comprueba que está solucionado

• Envía un email desde la aplicación a la dirección única que aparece en la página de inicio de Delivmail. Si llega, el inicio de sesión funciona; el informe muestra además si SPF, DKIM y DMARC se superan para tu dominio a través de Microsoft 365. Si no es así, sigue SPF, DKIM y DMARC para Microsoft 365.
• Después envía un email real al destinatario que debía recibirlo.
• Planifica ya el paso a OAuth, para que el cambio de la autenticación básica no rompa la aplicación más adelante.