Microsoft 365 "554 5.2.0 STOREDRV.Submission.Exception:SendAsDeniedException": cómo solucionarlo

Qué significa

Este error viene de tu propia organización de Microsoft 365, no del destinatario. Has intentado enviar un email con una dirección From que la cuenta conectada no tiene permiso para usar. El mensaje suele tener este aspecto:

554 5.2.0 STOREDRV.Submission.Exception:SendAsDeniedException.
MapiExceptionSendAsDenied; Failed to process message due to a permanent
exception with message Cannot submit message.

En Outlook puede llegarte como un informe de no entrega que dice "You can't send a message on behalf of this user unless you have permission to do so".

Por qué ocurre

Microsoft 365 comprueba que la cuenta que inicia sesión para enviar tiene derecho a usar la dirección del campo From. Rechaza el envío cuando:

• Envías desde un buzón compartido o desde la dirección de otra persona, sin el permiso Send As (Enviar como) o Send on Behalf (Enviar en nombre de).
• El permiso se acaba de añadir y todavía no ha llegado a todos los servidores.
• Outlook conserva una dirección From antigua en su lista de autocompletado, que apunta a un buzón o alias eliminado.
• Una impresora, un escáner, una web o un script inicia sesión con una cuenta (autenticación SMTP) pero pone otra dirección en el From, como scanner@yourdomain.com o noreply@yourdomain.com.
• Una aplicación (CRM, ERP, sistema de tickets) envía en nombre de los usuarios mediante una cuenta de servicio sin permisos.

Cómo comprobarlo

• Compara las dos direcciones: la cuenta usada para iniciar sesión (en la configuración de la app o del dispositivo) y la dirección From. Si son distintas, hace falta un permiso.
• Revisa los permisos del buzón en el Centro de administración de Exchange: abre el buzón usado en el From, luego su configuración de delegación, y mira Send As y Send on Behalf.
• Prueba el dispositivo o la app con Delivmail: una vez corregido, envía un email desde él a la dirección única de la página de inicio de Delivmail (/). Si llega, el envío funciona, y el informe muestra además si SPF, DKIM y DMARC se superan.

Cómo solucionarlo

1. Concede el permiso adecuado. En el Centro de administración de Exchange, abre el buzón (por ejemplo, el buzón compartido), ve a la delegación y añade al usuario en Send As (el email parece enviado por el propio buzón) o en Send on Behalf (se muestra como «usuario en nombre de buzón»). En PowerShell:

   Add-RecipientPermission -Identity shared@yourdomain.com -Trustee user@yourdomain.com -AccessRights SendAs

2. Espera a que se aplique el cambio. Los permisos pueden tardar hasta una hora. Reinicia Outlook después.
3. Borra la dirección From antigua en Outlook. Elimina la dirección de las sugerencias de autocompletado y vuelve a escribirla, o selecciónala en la libreta de direcciones.
4. Corrige los dispositivos y scripts. Usa como From la misma dirección que la cuenta con la que se inicia sesión, o da a esa cuenta el permiso Send As sobre la dirección From. Para las impresoras y escáneres que no pueden autenticarse bien, Microsoft documenta otras opciones como el envío directo (direct send) o un conector de relay SMTP.
5. Comprueba que la dirección sigue existiendo. Si el buzón o el alias se eliminó, usa una dirección vigente.

Comprueba que está solucionado

Vuelve a enviar el email desde el mismo usuario, app o dispositivo. Para los sistemas automáticos, envía primero a una nueva dirección de prueba de Delivmail: si llega, el problema de permisos está resuelto, y puedes comprobar que la nueva dirección From también está autenticada con SPF, DKIM y DMARC antes de enviar a destinatarios reales.