¿Necesitas que tu aplicación envíe correos por Microsoft 365 sin dolores de cabeza? Aquí tienes una guía práctica, actualizada y accionable sobre licencias, métodos (SMTP AUTH, Relay, Direct Send, Graph) y los cambios de autenticación que están rompiendo integraciones (“basic authentication is disabled”).
Resumen de la pregunta
- ¿Cómo usar SMTP para que una aplicación envíe correos a través de Microsoft 365?
- ¿Hace falta asignar una licencia a la cuenta usada para el envío?
- Si dejó de funcionar (p. ej., “Authentication unsuccessful, basic authentication is disabled”), ¿qué cambió y cómo se corrige?
- ¿Conviene usar un proveedor SMTP externo (SendGrid, etc.) en lugar de Microsoft 365?
Respuesta corta
- Hay cuatro rutas compatibles: SMTP autenticado (SMTP AUTH), SMTP Relay con conector, Direct Send, y sin SMTP usando Microsoft Graph.
- Licencia: SMTP AUTH requiere buzón con licencia; Relay y Direct Send no requieren licencia para el remitente.
- Qué cambió: la Autenticación Básica en Client Submission (SMTP AUTH) tiene retirada definitiva programada entre 1 de marzo y 30 de abril de 2026. Debes usar OAuth 2.0 (moderna) o alternativas.
- Recomendación: si tu app soporta OAuth en SMTP, úsalo. Si no, evalúa Graph o Relay. Un proveedor SMTP externo puede ser un “puente” rápido mientras migras a OAuth/Graph.
Opciones de envío en Microsoft 365
Método | Autenticación | Licencia | Puerto/Host | Alcance | Cuándo usar | Limitaciones clave |
---|---|---|---|---|---|---|
SMTP AUTH (Client Submission) | OAuth 2.0 (recomendado). La Básica se retira en 2026. | Sí, buzón con licencia. | smtp.office365.com :587, STARTTLS, TLS 1.2/1.3 | Interno y externo | Apps y servicios que sí soportan OAuth en SMTP y necesitan “From” coherente y guardado en Enviados. | Límites: aprox. 10.000 destinatarios/día, ~30 msg/min. “Send As” requiere permisos. |
SMTP Relay con conector | IP fija o certificado + conector entrante | No requiere buzón | MX del tenant, :25, TLS 1.2/1.3 | Interno y externo | Equipos/impresoras y servidores en red propia con IP pública propia o certificado. | No permitido desde servicios hospedados de terceros (incluida nube pública) sin IP/certificado dedicados. Riesgo de blocklists. |
Direct Send | Sin autenticación | No requiere buzón | MX del tenant, :25 | Solo interno al tenant | Notificaciones internas desde dispositivos que no pueden autenticarse. | No entrega a externos. Tratado como correo anónimo; aplica filtrado. |
Microsoft Graph (sendMail) | OAuth 2.0 (API) | Depende del escenario (delegado o app-only) | HTTPS (API) | Interno y externo | Nuevas integraciones o cuando la app no soporta SMTP OAuth. | Requiere cambios de código; diferente modelo de permisos (Mail.Send). |
Licenciamiento
- SMTP AUTH: necesitas un buzón con licencia para autenticar y enviar (la dirección del buzón aparece como remitente, salvo que otorgues permisos “Send As/Send on behalf”).
- SMTP Relay y Direct Send: no requieren licencia de buzón para el remitente; sí requieren conector/IP/certificado (Relay) y que el remitente pertenezca a un dominio aceptado en el tenant. Direct Send solo entrega interno.
Qué cambió y por qué “basic authentication is disabled”
Exchange Online culminó la deshabilitación general de Autenticación Básica en 2022, con la única excepción de Client Submission (SMTP AUTH). Esa excepción también desaparece: entre el 1 de marzo y el 30 de abril de 2026, el servicio rechazará por completo Basic en SMTP AUTH. Después verás respuestas como 550 5.7.30 Basic authentication is not supported for Client Submission
. La salida es migrar a OAuth 2.0 para SMTP o moverte a Graph/Relay según el caso.
Configuración recomendada: SMTP AUTH con OAuth 2.0
Si tu software soporta XOAUTH2 en SMTP, esta es la ruta más directa para mantenerte en Microsoft 365 sin reescribir a Graph.
Requisitos previos
- Servidor/puerto:
smtp.office365.com
:587, STARTTLS, TLS 1.2 o 1.3. - Habilitar SMTP AUTH en el tenant (global) o por buzón. En nuevos tenants suele venir deshabilitado; “Security defaults” lo bloquea si está activo.
- Buzón con licencia para el remitente que autentica.
- OAuth 2.0 con flujo de autorización (delegado) o credenciales de cliente (app-only).
Paso a paso en Entra ID (aplicación propia)
- Registra una aplicación en Microsoft Entra ID y anota Tenant ID, Client ID y el Client Secret o certificado (si usarás app-only).
- En API permissions → APIs my organization uses, busca Office 365 Exchange Online.
- Agrega permisos según tu escenario:
- Delegado (en nombre del usuario que envía):
SMTP.Send
. Scopes al pedir tokens:https://outlook.office.com/SMTP.Send
(o usaoffline_access
para refrescar). - Aplicación (app-only):
SMTP.SendAsApp
. Pide tokens para el recursohttps://outlook.office365.com/.default
. Registra el service principal en Exchange Online y otorga permisos “Send As” o define las identidades autorizadas.
- Delegado (en nombre del usuario que envía):
- Concede admin consent a los permisos.
- Implementa SASL XOAUTH2 al conectar por SMTP:
AUTH XOAUTH2 <base64("user=" + upn + "\x01auth=Bearer " + access_token + "\x01\x01")>
- Verifica que el buzón desde el que envías tiene SMTP AUTH habilitado y, si envías “como” otra identidad, que tienes Send As o Send on behalf.
Ejemplo mínimo en Python (XOAUTH2)
import base64, smtplib, ssl
SMTP\_HOST = "smtp.office365.com"
SMTP\_PORT = 587
USER\_UPN = "[appsender@contoso.com](mailto:appsender@contoso.com)"
ACCESS\TOKEN = "\"
def build\xoauth2\str(user, token):
auth\_str = f"user={user}\x01auth=Bearer {token}\x01\x01"
return base64.b64encode(auth\_str.encode("utf-8"))
context = ssl.create\default\context()
with smtplib.SMTP(SMTP\HOST, SMTP\PORT) as s:
s.ehlo()
s.starttls(context=context)
s.ehlo()
xoauth2 = build\xoauth2\str(USER\UPN, ACCESS\TOKEN)
code, resp = s.docmd("AUTH", "XOAUTH2 " + xoauth2.decode("utf-8"))
if code != 235:
raise RuntimeError(f"Auth failed: {code} {resp}")
from\addr = USER\UPN
to\_addrs = \["[destinatario@contoso.com](mailto:destinatario@contoso.com)"]
msg = ("From: [appsender@contoso.com](mailto:appsender@contoso.com)\r\n"
"To: [destinatario@contoso.com](mailto:destinatario@contoso.com)\r\n"
"Subject: Prueba SMTP OAuth\r\n"
"\r\n"
"Hola desde XOAUTH2.\r\n")
s.sendmail(from\addr, to\addrs, msg)
Notas:
- Para delegado, el usuario debe iniciar sesión al menos una vez para consentir, y tu app debe gestionar refresh tokens.
- Para app-only, además de
SMTP.SendAsApp
debes registrar el service principal en Exchange y conceder el acceso a los buzones/identidades que enviarán. - Si recibes
535 5.7.3 Authentication unsuccessful
, revisa el ámbito del token, el recurso (https://outlook.office365.com/.default
para SMTP app-only) y que la cadena XOAUTH2 esté bien codificada.
Activar o verificar SMTP AUTH en el tenant
La práctica recomendada es deshabilitarlo globalmente y activarlo solo para los buzones que lo necesitan:
# Deshabilitar/activar a nivel organización
Set-TransportConfig -SmtpClientAuthenticationDisabled $true # o $false
Habilitar por buzón concreto
Set-CASMailbox -Identity [usuario@contoso.com](mailto:usuario@contoso.com) -SmtpClientAuthenticationDisabled \$false
Comprobaciones rápidas
Get-TransportConfig | fl SmtpClientAuthenticationDisabled
Get-CASMailbox [usuario@contoso.com](mailto:usuario@contoso.com) | fl SmtpClientAuthenticationDisabled
Security defaults en Entra puede bloquear SMTP AUTH incluso si lo habilitas; desactívalo o aplica una política que lo permita para cuentas específicas.
Alternativas cuando tu app no soporta OAuth en SMTP
Microsoft Graph (sendMail)
Si puedes llamar APIs HTTP, Graph es la vía más alineada con la estrategia de Microsoft. Ventajas: autenticación moderna, granularidad de permisos (Mail.Send
), trazabilidad, adjuntos grandes vía uploads y envío en nombre de usuarios o con app-only.
POST https://graph.microsoft.com/v1.0/users/{user-id}/sendMail
Authorization: Bearer <accesstokenwith_Mail.Send>
Content-Type: application/json
{
"message": {
"subject": "Hola Graph",
"body": { "contentType": "Text", "content": "Mensaje desde Graph" },
"toRecipients": \[{ "emailAddress": { "address": "[destino@contoso.com](mailto:destino@contoso.com)" } }]
},
"saveToSentItems": true
}
SMTP Relay con conector
Para dispositivos/impresoras en red local o servidores con IP pública propia/certificado:
- Configura tu dispositivo hacia el MX de tu dominio (por ejemplo,
contoso-com.mail.protection.outlook.com
), puerto 25, TLS 1.2/1.3. - Crea un conector entrante en Exchange Online autenticando por certificado (recomendado) o lista de IPs.
- No requiere buzón con licencia. Permite enviar a externos, siempre que el remitente pertenezca a un dominio aceptado.
- No es válido desde nubes de terceros cuando no tienes IP dedicada o certificado propio. En entornos compartidos suele estar bloqueado.
Direct Send
Conecta al MX del tenant por el puerto 25, sin autenticación, para enviar solo a destinatarios internos. Útil para alertas internas. No funciona a externos (Gmail, etc.).
Errores frecuentes y cómo resolverlos
Error | Causa probable | Cómo se corrige |
---|---|---|
535 5.7.139 Authentication unsuccessful, basic authentication is disabled | La app está intentando Basic (usuario/contraseña). | Migra a OAuth en SMTP (XOAUTH2) o usa Graph/Relay. Verifica que el cliente soporte OAuth. |
550 5.7.30 Basic authentication is not supported for Client Submission | Respuesta estándar tras la retirada definitiva de Basic en SMTP AUTH. | Sólo OAuth funcionará en Client Submission. Ajusta tu integración. |
535 5.7.3 Authentication unsuccessful | Token inválido/expirado, ámbito incorrecto, cadena XOAUTH2 mal formada, o SMTP AUTH deshabilitado. | Renueva token, valida recurso https://outlook.office365.com/.default (app-only SMTP), revisa permisos y habilitación de SMTP AUTH. |
5.7.60 Client doesn't have permissions to send as this sender | Intentas “Send As” sin permisos. | Otorga Send As o usa el buzón autenticado como remitente. |
Time-out o fallo TLS | Firewall o TLS obsoleto. | Abre :587 (o :25 según método) y fuerza TLS 1.2/1.3; no uses :465. |
Direct Send no entrega a externos | Limitación del método. | Usa SMTP AUTH (OAuth), Relay o Graph para externos. |
Buenas prácticas de seguridad y cumplimiento
- Evita cuentas compartidas con privilegios altos. Usa buzones dedicados por aplicación.
- En app-only, limita el service principal a buzones/alias necesarios y revísalo periódicamente.
- Implementa rotación de secretos o, mejor, certificados con vida útil corta.
- Para Relay/Direct Send, configura SPF, DKIM y DMARC del dominio.
- Habilita auditoría y revisa los reportes de SMTP AUTH Clients en el centro de administración.
¿Cuándo conviene un proveedor SMTP externo?
Criterio | Microsoft 365 (SMTP/Graph) | Proveedor SMTP externo |
---|---|---|
Tiempo de integración | Más esfuerzo si migras a OAuth/Graph | Rápido (API Keys, SDKs) |
Entregabilidad y métricas | Correcta; métricas limitadas en SMTP | Especializados en reputación, métricas, webhooks |
Coste | Incluido en M365 (hasta límites) | Costo adicional por volumen |
Gobierno de datos | Todo en tu tenant | Datos salen a un tercero |
Casos de uso | Transaccional corporativo estándar | Marketing, alto volumen B2C, plantillas y analítica |
Recomendación: si tu aplicación hoy no soporta OAuth y necesitas salir ya, un proveedor externo puede ser un puente temporal. A medio plazo, planifica OAuth/Graph para reducir dependencias y centralizar la seguridad en tu tenant.
Checklist de configuración rápida
- Define el método adecuado: SMTP OAuth → Relay → Graph → Proveedor externo.
- Si eliges SMTP OAuth:
- Aplica
SMTP.Send
(delegado) oSMTP.SendAsApp
(app-only); admin consent. - Token para
https://outlook.office365.com/.default
(app-only SMTP). - Habilita SMTP AUTH en el buzón y confirma TLS 1.2/1.3.
- Aplica
- Si eliges Relay:
- IP fija o certificado y conector entrante al MX del tenant (puerto 25).
- Remitente en dominio aceptado; configura SPF/DKIM/DMARC.
- Si eliges Graph:
- Permiso
Mail.Send
(delegado o app-only) y flujos OAuth correspondientes.
- Permiso
Guía de diagnóstico
- Valida el método: ¿Client Submission, Relay, Direct Send o Graph? Evita mezclar configuraciones.
- Confirma TLS y puertos: :587 para SMTP AUTH, :25 para Relay/Direct Send; TLS 1.2/1.3 activo.
- Revisa permisos: Send As si el “From” difiere; service principal registrado en Exchange para app-only.
- Token: recurso/scope correcto, no expirado; base64 XOAUTH2 bien formado.
- Políticas: “Security defaults” y autenticación básica deshabilitada pueden bloquear SMTP AUTH; ajusta o crea excepciones controladas.
- Reportes: usa el reporte de SMTP AUTH Clients para ver si tu cliente está en Básica u OAuth.
Preguntas frecuentes
¿Puedo seguir usando contraseñas de aplicación (App Passwords) con SMTP?
No. Las App Passwords pertenecen a Básica; no resuelven la retirada de Basic en Client Submission.
¿Puedo usar el puerto 465/SSL directo?
No. Exchange Online soporta STARTTLS en :587 (recomendado) y :25; el 465 no es compatible para Client Submission.
¿“SMTP Relay” sirve desde un proveedor cloud?
Solo si tienes IP dedicada o certificado y configuras el conector en tu tenant. En entornos compartidos no podrás.
¿Se guardan los mensajes en “Enviados”?
Con SMTP AUTH sí (cliente/servidor los puede guardar); con Relay y Direct Send no.
¿Qué límites aplican?
Aproximadamente 10.000 destinatarios por día y ~30 mensajes por minuto en Client Submission. Para mayores volúmenes, evalúa Relay, Graph o servicios dedicados.
Decisión rápida
- Máxima alineación y seguridad: Graph o SMTP AUTH con OAuth 2.0.
- Equipos/impresoras con IP fija: SMTP Relay con conector.
- Apps sin soporte de OAuth y urgencia: proveedor SMTP externo, planificando migración a OAuth/Graph.
Plantillas de configuración
SMTP AUTH con OAuth (resumen)
- Servidor:
smtp.office365.com
- Puerto:
587
- Cifrado:
STARTTLS
(TLS 1.2/1.3) - Autenticación: OAuth 2.0
- Permisos:
SMTP.Send
(delegado) oSMTP.SendAsApp
(app-only) - Token resource (app-only):
https://outlook.office365.com/.default
SMTP Relay (resumen)
- Smart Host: MX del dominio (
contoso-com.mail.protection.outlook.com
) - Puerto:
25
- Autenticación: IP fija o certificado + conector entrante
- Ámbito: interno y externo (remitente en dominio aceptado)
Direct Send (resumen)
- Smart Host: MX del dominio
- Puerto:
25
- Autenticación: no aplica
- Ámbito: solo destinatarios del tenant
Cierre
El reloj corre para Basic en SMTP AUTH. Si tu app ya soporta XOAUTH2, habilita SMTP AUTH con OAuth y sigue con tu buzón con licencia. Si no, migra a Graph o configura un Relay con conector si tienes infraestructura propia. Y si necesitas salir hoy, un proveedor SMTP externo puede ser un paso intermedio sensato.