Los fallos de Microsoft 365 OAuth suelen estar en el registro de la app, políticas del tenant/cuenta o estado del token, no en la antigua contraseña SMTP. Separa aplicación Entra, redirect URI, permisos, identidad del buzón y política SMTP AUTH.
Haz coincidir tenant y tipo de cuenta
Single-tenant/multi-tenant y endpoint de autorización deben encajar con la organización del buzón y el plugin.
Verifica redirect URI e identidad de cliente
Compara callback HTTPS, client ID y tenant. Copiar staging a producción suele dejar una URI incorrecta.
Revisa permisos y consentimiento
Distingue consentimiento delegado/admin y concede solo scopes documentados.
Comprueba política SMTP AUTH
OAuth puede funcionar y SMTP AUTH estar desactivado para tenant o buzón. Confirma que el transporte elegido está permitido.
Gestiona refresh/revocación
Registra códigos como invalid_grant sin exponer tokens. Reautoriza tras cambios de seguridad o secreto cuando corresponda.
Prueba identidad From
El buzón autenticado debe poder enviar como el From configurado. Send-as/shared mailbox es una capa distinta a obtener token.
Interpreta transporte con logs SMTP seguros y compara con fallos de autenticación SMTP.
Separa tenant, app y buzón en una matriz
Registra tenant ID, application/client ID, host de redirect, cuenta autenticada, From previsto, tipo de consentimiento y si SMTP AUTH/send-as está permitido para ese buzón. No guardes secretos ni tokens. Muchos fallos se aclaran al ver que OAuth funcionó para una identidad pero WordPress intenta enviar como otra.