¿Recibes un NDR con “Requested action not taken: mailbox unavailable (S2017062302)” desde *.mail.protection.outlook.com aunque el correo sí llega al buzón de Hotmail u Outlook.com? Este guía práctica explica por qué ocurre, cómo confirmarlo y qué pasos concretos siguen los equipos de soporte para resolverlo de forma definitiva.
Descripción del síntoma y contexto
Varios remitentes reportan que, tras enviar a una dirección @hotmail.com o @outlook.com, reciben un mensaje de no entrega (NDR). La notificación incluye el texto “Requested action not taken: mailbox unavailable (S2017062302)” y proviene de una pasarela de Microsoft (*.mail.protection.outlook.com). Sin embargo, el destinatario confirma que el correo sí aparece en la bandeja de entrada y puede leerlo. No hay reglas visibles de reenvío activas y el comportamiento se reproduce con diferentes remitentes y dispositivos.
Esta combinación —correo recibido + NDR devuelto— es contraintuitiva, pero tiene una explicación técnica clara: en algún punto del flujo de entrega se produce un salto adicional que falla (regla, reenvío, alias, destinatario oculto o condición temporal del servicio). El sistema devuelve el NDR a quien envió el mensaje, aunque la copia principal ya esté en el buzón.
Por qué sucede un rebote lateral
En un flujo de correo moderno, un mensaje puede tocar múltiples “saltos”: antispam, transporte, reglas del buzón, conectores de reenvío a otra cuenta, alias y sincronizaciones. Basta con que uno de esos saltos secundarios falle para que se emita un NDR, aun cuando la entrega primaria ya se hubiera completado.
Remitente → Entrada M365/Outlook.com → Entrega al buzón ✔
↘ Regla/redirección secundaria → Destino inválido ✖ → NDR al remitente
Ese rebote no implica pérdida del mensaje original; simplemente señala que alguna acción posterior a la recepción (p. ej., “reenvía una copia a…”, “redirige si el asunto contiene…”, “entrega también a un alias/contacto”) no pudo completarse.
Causas probables de mayor a menor
- Regla o reenvío posterior a la entrega que apunta a una dirección inválida. Es lo más común, especialmente tras un compromiso de cuenta en el que se añadió un reenvío clandestino.
- Destinatario adicional invisible (autocompletar o contacto desactualizado). El remitente cree enviar a una única dirección, pero hay un segundo destinatario que ya no existe y dispara el NDR.
- Alias obsoleto o cuenta conectada de sincronización que intenta redirigir fuera del servicio y falla.
- Condición transitoria del servicio que genera un NDR espurio pese a que la entrega principal se concretó.
Cómo confirmar el origen del problema
El objetivo es identificar qué salto está fallando. Para ello:
- Pedir el NDR completo a quien lo recibe. No basta el asunto o la primera línea. Se necesita la sección “Diagnostic information” o “Información de diagnóstico”.
- Localizar la dirección exacta que provocó el fallo. En muchos NDR figura el “Recipient” o “Final-Recipient”. Si no coincide con la cuenta real del destinatario, hay un destinatario extra, un alias o una regla de por medio.
- Comparar con el mensaje que sí llegó en el buzón: extraer el Message-ID y verificar si se corresponde con el NDR recopilado.
Muestra de NDR típica para análisis
From: postmaster@*.mail.protection.outlook.com
Subject: Delivery Status Notification (Failure)
Diagnostic-Code: smtp; 550 5.2.1 Requested action not taken: mailbox unavailable (S2017062302)
Final-Recipient: rfc822; destinatario-secundario@ejemplo.com
Action: failed
Status: 5.2.1
Message-ID original: <unique-message-id@dominio>Si el Final-Recipient no es tu dirección real, casi seguro existe una regla, reenvío o alias que intenta entregar a ese destino y falla.
Pasos de corrección recomendados
Higiene y seguridad del buzón
- Cambiar la contraseña de la cuenta Microsoft y activar MFA (autenticación multifactor).
- Revisar la actividad reciente de inicio de sesión y cerrar sesiones desconocidas.
- Comprobar alias y métodos de verificación en la cuenta; eliminar los que no reconozcas.
Revisión de reglas, reenvíos y conexiones ocultas
- En Outlook en la web: Configuración → Correo → Reglas. Desactiva o elimina reglas que redirijan, reenvíen o agreguen destinatarios.
- En Configuración → Correo → Reenvío, confirma que no haya reenvío activo.
- En Cuentas conectadas o Sync email (Outlook.com): elimina conexiones que ya no utilices.
- Si usas cliente de escritorio, revisa reglas del cliente y bórralas por prueba, quedándote solo con las del servidor.
Validación con remitentes
- Pedir que eliminen el contacto y la entrada de autocompletar; que escriban manualmente la dirección y reintenten.
- Solicitar el NDR completo y confirmar qué dirección exacta falló.
- Probar a enviar a un alias alternativo del mismo buzón, si existe. Si no hay NDR, la causa suele ser una regla del alias principal.
Mitigaciones rápidas
- Crear un alias nuevo temporal y pedir a los remitentes que lo usen mientras limpias reglas y contactos.
- Si el buzón pertenece a un dominio de Microsoft 365, pedir al administrador un Message Trace para ver saltos y reenvíos fallidos.
Escalación
- Recopilar tres ejemplos con: fecha y hora exactas (UTC), Message-ID del mensaje recibido y NDR completo del remitente.
- Abrir un caso con soporte técnico aportando esas evidencias y mencionando el código S2017062302.
Tabla de diagnóstico rápido
| Síntoma | Qué indica | Acción inmediata |
|---|---|---|
| NDR recibido por el remitente pero el mensaje sí está en la bandeja | Fallo en un salto secundario del flujo | Revisar reglas y reenvíos; buscar destinatarios adicionales en el NDR |
| El NDR menciona un destinatario distinto al principal | Regla de redirección o contacto oculto | Eliminar reglas y “Cuentas conectadas”; limpiar autocompletar y contactos |
| Solo ocurre con algunos remitentes habituales | Contacto desactualizado del lado del remitente | Pedir que escriban la dirección desde cero; que adjunten el NDR completo |
| Se reproduce incluso con alias nuevo | Posible incidencia transitoria del servicio | Mitigar con alias y recopilar evidencias para soporte |
Ruta sugerida de trabajo
- Asegurar el acceso. Cambiar credenciales y activar MFA.
- Eliminar condiciones que añaden saltos: reglas, reenvíos, cuentas conectadas.
- Normalizar la libreta: borrar contactos duplicados y completar la dirección a mano.
- Probar y aislar: enviar desde remitentes distintos y hacia alias alternativos.
- Documentar: recoger NDR y Message-ID para trazar el flujo.
Señales que delatan una regla o reenvío oculto
- El NDR contiene un Final-Recipient que no coincide con el buzón real.
- Los NDR aparecen solo en correos que cumplen cierta condición de asunto o remitente.
- El problema desaparece temporalmente al desactivar todas las reglas.
- El uso de un alias nuevo evita el NDR.
Ubicaciones típicas que conviene revisar
| Área | Qué buscar | Cómo afecta |
|---|---|---|
| Reglas de la bandeja | Acciones de “redirigir”, “reenviar” o “enviar a” otra dirección | Generan un salto adicional susceptible a fallo |
| Reenvío del buzón | Reenvío habilitado a dirección externa | Si el destino no existe, dispara NDR |
| Cuentas conectadas | Sincronizaciones POP/IMAP o envíos a proveedores antiguos | Intentan reenviar o replicar mensajes a un destino inválido |
| Autocompletar y contactos | Entradas obsoletas con direcciones antiguas | Añaden destinatarios invisibles que fallan |
Pruebas controladas para aislar la causa
- Prueba con alias. Crea un alias del mismo buzón y pide a dos remitentes afectados que envíen el mismo mensaje a la dirección original y al alias. Si solo rebota al original, la causa está en reglas o contactos vinculados al principal.
- Prueba sin reglas. Desactiva todas las reglas y repite el envío. Si desaparece el NDR, activa una por una hasta identificar la culpable.
- Prueba con remitente limpio. Pide a un remitente nuevo, que nunca te haya escrito, que envíe escribiendo la dirección manualmente. Si no hay NDR, el problema está en las libretas de los remitentes habituales.
Interpretación práctica del código
El texto “Requested action not taken: mailbox unavailable (S2017062302)” indica que una acción posterior no se pudo completar porque el destino que recibió el salto estaba “no disponible” para esa operación. No significa que tu buzón esté inaccesible; normalmente el buzón principal sí aceptó la entrega. Por eso lo denominamos rebote lateral.
Buenas prácticas para prevenir reincidencias
- Auditar reglas cada trimestre y documentar las necesarias.
- Evitar reenvíos encadenados a cuentas personales o proveedores en desuso.
- Usar alias por propósito (por ejemplo, uno público y otro operativo) para detectar anomalías con mayor precisión.
- Educar a remitentes frecuentes para que no dependan del autocompletar y verifiquen direcciones en cambios organizativos.
- Monitorear accesos y activar alertas de inicio de sesión inusual.
Preguntas frecuentes
¿Es un problema del lado de Microsoft?
Puede serlo si es intermitente y no se asocia a reglas o contactos. Aun así, la mayoría de casos se resuelven limpiando reenvíos, alias y cuentas conectadas.
¿Debo preocuparme por pérdida de correos?
No necesariamente. En la gran mayoría de incidentes el mensaje llegó y está seguro en tu buzón. El NDR refleja que otra acción posterior no pudo ejecutarse.
¿Cómo sé si mi cuenta fue comprometida?
Revisa actividad reciente, dispositivos iniciados y la presencia de reglas desconocidas. Si encuentras cambios que no recuerdas, procede con cambio de contraseña, MFA y limpieza de reglas.
¿Sirve crear un alias nuevo?
Sí, como mitigación temporal y como prueba diagnóstica. Si el alias no genera NDR, confirma que el problema está asociado a reglas o contactos del principal.
Resumen operativo
Cuando un remitente ve “Requested action not taken: mailbox unavailable (S2017062302)” pero el mensaje sí aparece en tu bandeja, está ocurriendo un rebote lateral. La entrega principal se completa, pero un salto adicional —regla, reenvío, alias o contacto oculto— intenta llevar el correo a otro destino y falla. La solución pasa por asegurar la cuenta, eliminar reglas no esenciales, desactivar reenvíos, limpiar contactos y autocompletar, y validar con pruebas controladas (alias, remitentes nuevos). Si persiste, recopila evidencias —NDR completo, Message-ID, fecha y hora— y escala a soporte mencionando el código.
Checklist accionable
- Contraseña nueva y MFA activos.
- Sesiones desconocidas cerradas.
- Aliases y métodos de verificación revisados.
- Reglas de bandeja y reenvío desactivadas o depuradas.
- Cuentas conectadas eliminadas si no se usan.
- Contactos y autocompletar limpiados.
- Prueba con alias y con remitente nuevo.
- Evidencias listas para soporte: NDR completo, Message-ID, hora UTC.
Resultado esperado: tras limpiar reglas, reenvíos y contactos, el NDR deja de generarse. Si fue una incidencia transitoria del servicio, el uso de un alias reduce fricción mientras soporte valida y corrige.