¿No puedes responder correos cifrados desde el Outlook clásico de escritorio y ves el aviso “Microsoft Outlook was not able to create a message with restricted permission”? Aquí te explico por qué ocurre tras los cambios de 2024 y cómo salir del apuro hoy mismo, con pasos claros y reversibles.
Descripción del problema en Outlook clásico
Organizaciones que reciben mensajes cifrados desde remitentes externos que usan el cifrado de Microsoft (IRM/OME) reportan que, en el Outlook clásico de escritorio, los usuarios pueden redactar correos nuevos con normalidad pero no pueden responder a esos hilos cifrados. Al intentar hacerlo, aparece el error:
“Microsoft Outlook was not able to create a message with restricted permission.”
El mismo buzón, en Outlook en la web (OWA) y en el Nuevo Outlook (cliente basado en OWA), sí permite responder sin incidencias. La creación de un perfil nuevo en el escritorio clásico no resuelve el fallo.
En numerosos entornos el comportamiento cambió a principios de mayo de 2024. Además, algunos mensajes comenzaron a llegar como un stub con el botón “Click here to read the message” y, posteriormente, se mostraron incrustados en el cuerpo del correo. Esta alternancia es una pista clave del cambio de motor de cifrado.
Causa técnica y contexto
Con las compilaciones de Office de la versión 2402 se completó la transición del motor antiguo MSIPC hacia el MIP SDK para etiquetas de sensibilidad y cifrado. Desde ese cambio se han observado incidencias conocidas que afectan específicamente a las respuestas de correos cifrados en el Outlook clásico. El lector web de OWA y el Nuevo Outlook no se ven afectados, lo que explica por qué ahí funciona responder y en el escritorio clásico no.
El error aparece en escenarios de IRM/OME (cifrado con permisos restringidos), habitualmente cuando el mensaje original procede de un tercero externo. En la práctica, el cliente clásico intenta crear una respuesta respetando la protección, pero encuentra un conflicto con el nuevo flujo del MIP SDK y aborta la composición del mensaje protegido.
Soluciones rápidas para salir del paso
Si tu prioridad es responder ya, aplica cualquiera de estos atajos sin tocar la configuración de Office:
- Responder desde OWA o desde el Nuevo Outlook. Ambos usan el lector web compatible con el cifrado y evitan el bug.
- Si debes responder desde el escritorio clásico, redacta un correo nuevo al remitente en lugar de usar Responder. Es menos cómodo, pero permite avanzar hasta aplicar la mitigación.
Mitigaciones recomendadas hasta la corrección oficial
Para recuperar la capacidad de responder desde el cliente clásico mientras Microsoft libera la corrección, hay dos caminos validados por administradores:
Volver temporalmente a MSIPC mediante clave de registro
Microsoft ha documentado una clave de registro que re-habilita el motor MSIPC en lugar del MIP SDK. Es una medida temporal, pensada para entornos que requieren mantener el escritorio clásico operativo. Al publicarse la corrección, deberás retirar la clave para regresar a MIP SDK.
Importante: realizar cambios en el Registro conlleva riesgo. Haz copia de seguridad y pruébalo primero en un equipo piloto o en un anillo de pruebas. Aplica exactamente los valores que recomiende Microsoft para tu canal de actualización.
Retroceder Office a 2401 para validar y estabilizar
Otra vía es hacer rollback a la versión 2401 (canal Actual), que en muchos entornos elimina el problema. Desde un símbolo del sistema elevado:
cd %programfiles%\Common Files\Microsoft Shared\ClickToRun
officec2rclient.exe /update user updatetoversion=16.0.17231.20236
Este cambio es reversible. Si más adelante quieres volver al último build disponible, ejecuta la actualización normal desde Cuenta de Office o con tu herramienta de gestión.
Comprobaciones de IRM que conviene realizar en el cliente clásico
Si decides seguir con el escritorio clásico, estas verificaciones ayudan a despejar errores residuales. No sustituyen a la mitigación anterior, pero mejoran la estabilidad:
- Forzar la conexión a RMS: en Outlook, abre “Nuevo correo” → pestaña Opciones → Permisos → Conectarse a Rights Management Services (RMS). Cierra y vuelve a abrir Outlook.
- Comprobar en el tenant que IRM/OME está habilitado aunque no usen etiquetas propias. Esto asegura que el cliente pueda adquirir plantillas y licencias de uso.
- Limpiar la caché de certificados del usuario en Windows:
- Win + R →
inetcpl.cpl
→ pestaña Contenido → Certificados… (o ejecutarcertmgr.msc
), y elimina certificados obsoletos relacionados con IRM/Azure Information Protection si procede. - Reinicia Outlook después de la limpieza.
- Win + R →
- Descartar interferencias de complementos de cifrado de terceros: inicia
outlook.exe /safe
y prueba. Si en modo seguro funciona, deshabilita complementos sospechosos y revalida.
Explicación del modo con botón “Click here to read the message”
Microsoft puede entregar mensajes cifrados como un stub que abre el portal OME o como contenido incrustado (.rpmsg
), según la compatibilidad del cliente. Cuando el motor del cliente cambia (p. ej. de MSIPC a MIP SDK) o hay variaciones del lado del remitente, es normal alternar entre ambos modos. Esto coincide con que OWA y el Nuevo Outlook sí funcionan (lector web) y el Outlook clásico falle al componer respuestas protegidas tras la transición a MIP SDK.
Procedimiento paso a paso recomendado para administradores
A continuación, una guía operativa para equipos de IT que necesiten estabilizar a escala y documentar evidencia:
Identificar versión y canal de Office
- En cualquier app de Office: Archivo → Cuenta → Acerca de. Anota “Versión” y “Compilación”.
- Desde PowerShell, también puedes consultar la versión de Click-to-Run:
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Office\ClickToRun\Configuration" ` | Select-Object -ExpandProperty VersionToReport
- Registra si el equipo está en Canal Actual, Canal Mensual Enterprise, o Semestral (según tu política).
Aplicar la mitigación temporal más adecuada
Opción | Cuándo elegirla | Impacto | Reversibilidad |
---|---|---|---|
Responder desde OWA/Nuevo Outlook | Necesidad inmediata de respuesta sin cambios de cliente | Continuidad total; no corrige el bug del escritorio | Total, sin cambios locales |
Correo nuevo en lugar de “Responder” | Solo casos puntuales desde escritorio clásico | Evita el bloqueo; pierde contexto de hilo | Total |
Volver a MSIPC con Registro | Plantilla de productividad en escritorio clásico | Restaura respuestas protegidas; medida temporal | Quitar la clave y reiniciar Outlook |
Rollback a Office 2401 | Validar que el problema desaparece en build previo | Congela en un build anterior; requiere control de actualizaciones | Actualizar de nuevo cuando salga la corrección |
Implementar a escala de forma segura
- Pilota primero en un grupo reducido de usuarios con el mismo perfil de uso (departamentos que responden a clientes externos con IRM/OME).
- Registra riesgo y reversión: documenta cómo volver a MIP SDK (retirar clave) o volver al último build estable.
- Distribuye con tu gestor (Intune, GPO, herramientas de software center). Si optas por rollback, bloquea temporalmente actualizaciones automáticas para evitar el re-salto inmediato al build problemático.
Validar que la reparación ha surtido efecto
- Pide a un afectado que responda a un correo cifrado recién recibido de un remitente externo.
- Confirma que ya no aparece el error y que el mensaje sale protegido según lo esperado.
- Revisa el flujo del destinatario (si es posible) para verificar que recibe y puede abrir la respuesta cifrada.
Higiene de IRM en el puesto
Para mejorar la salud del cliente y reducir casos residuales, considera estas acciones adicionales:
- Renovar plantillas de RMS en el cliente si llevan tiempo sin actualizarse (la conexión manual a RMS suele forzar dicha actualización).
- Reiniciar el servicio de inicio de sesión de Office/AAD tras cambios de cuenta o licencia.
- Revalidar hora y zona horaria del sistema: el desfase excesivo puede invalidar tokens de IRM.
- Evitar software de inspección HTTPS que intercepte tráfico de Office hacia los servicios de Microsoft sin exclusiones adecuadas.
Resolución de problemas avanzada
Si el problema persiste incluso tras aplicar la mitigación principal, prueba lo siguiente:
- Modo seguro de Outlook:
outlook.exe /safe
. Si funciona, reintroduce complementos uno a uno hasta encontrar el conflicto. - Nuevo perfil: aunque a muchos no les ha servido, sigue siendo una comprobación básica para descartar perfiles corruptos.
- Limpieza selectiva de cachés:
- Carpetas de MSIPC y de Information Protection dentro de
%LOCALAPPDATA%\Microsoft\
. En lugar de eliminar, renómbralas añadiendo.old
para poder revertir si es necesario. - Carpeta
%LOCALAPPDATA%\Microsoft\Office\16.0\DRM
si existe. Cierra todas las apps de Office antes de tocar estos directorios.
- Carpetas de MSIPC y de Information Protection dentro de
- Eventos del sistema: revisa el Visor de eventos en Registros de aplicaciones y servicios de Office y Aplicación, por si aparece error relacionado con licencias o protección de la información.
Preguntas frecuentes
¿Por qué redactar un correo nuevo al remitente sí funciona y “Responder” no?
Porque redactar un nuevo mensaje no intenta mantener la misma protección del hilo original. Al responder, el cliente debe crear un mensaje con permisos y cifrado heredados, que es justo el paso que falla con el nuevo flujo del MIP SDK en el cliente clásico.
¿Debo deshabilitar permanentemente MIP SDK?
No. La clave para volver a MSIPC es un puente temporal. Lo recomendable es quitarla cuando Microsoft publique la corrección correspondiente y regresar al flujo soportado del MIP SDK.
¿Qué riesgos tiene revertir de versión?
Estarás en un build anterior con posibles correcciones de seguridad pendientes. Mitiga ese riesgo limitando el periodo de rollback, monitorizando alertas de seguridad y planificando el retorno al build más reciente estable.
¿El Nuevo Outlook sustituye al clásico en este escenario?
El Nuevo Outlook usa el lector web y, por ello, no reproduce este fallo al responder. Si tu organización está lista para adoptarlo, puede ser una solución estructural; si no, úsalo como vía temporal para los casos afectados.
Checklist de verificación rápida
- Registrar versión de Office y canal de actualización.
- Reproducir el error con un correo cifrado real y capturar evidencia.
- Elegir mitigación: OWA/Nuevo Outlook, clave para MSIPC o rollback a 2401.
- Validar que la respuesta cifrada se envía correctamente tras la mitigación.
- Conectar RMS desde Outlook y reiniciar el cliente.
- Limpiar caché de certificados si persiste.
- Monitorear los comunicados de Microsoft y retirar la clave temporal cuando se publique la corrección.
Guía para equipos de soporte
Cuando un usuario reporte el error:
- Comprueba si en OWA/Nuevo Outlook puede responder. Si la respuesta es afirmativa, etiqueta el caso como afectado por el bug de respuestas cifradas en el cliente clásico.
- Ofrece como solución temporal usar OWA/Nuevo Outlook o redactar un correo nuevo al remitente para ese caso concreto.
- Escala a IT para que evalúe aplicar la clave de registro de MSIPC o el rollback a 2401 en el anillo afectado.
- Una vez implementada la mitigación, valida con el usuario y cierra el caso dejando constancia de la reversión planificada cuando se publique la corrección.
Buenas prácticas de despliegue y comunicación
- Comunica el alcance: “el fallo afecta a respuestas cifradas en Outlook clásico; OWA/Nuevo Outlook no están afectados”.
- Define ventanas de mantenimiento para rollback/mitigación y detalla los pasos de reversión.
- Documenta en el portal interno: qué verán los usuarios, a quién llamar y cómo trabajar mientras tanto.
Matriz de síntomas y acciones sugeridas
Síntoma observado | Interpretación probable | Acción recomendada |
---|---|---|
Error “not able to create a message with restricted permission” al responder | Conflicto del flujo de respuesta protegida en MIP SDK | OWA/Nuevo Outlook, clave para MSIPC o rollback a 2401 |
Mensajes alternan entre stub y contenido incrustado | Cambio de motor/compatibilidad del cliente | Mitigar en escritorio clásico y usar OWA temporalmente |
OWA y Nuevo Outlook funcionan sin problema | El lector web no reproduce el bug | Usarlos como vía operativa hasta la corrección |
Nuevo perfil no resuelve | Incidencia no ligada a perfil de Outlook | Aplicar mitigación del motor o rollback |
Plan de acción recomendado
- Usar OWA/Nuevo Outlook para responder mientras tanto.
- En el Outlook clásico, aplicar de forma temporal la clave de registro para volver a MSIPC (según las indicaciones de Microsoft) o retroceder a 2401 con el comando:
cd %programfiles%\Common Files\Microsoft Shared\ClickToRun officec2rclient.exe /update user updatetoversion=16.0.17231.20236
- Conectar RMS desde Outlook, reiniciar y, si persiste, limpiar caché de certificados.
- Vigilar la corrección oficial y quitar la clave de Registro (si se usó) para volver a MIP SDK en cuanto sea seguro.
Resumen ejecutivo
El bloqueo al responder correos cifrados en el Outlook clásico se debe a la transición al MIP SDK en versiones recientes de Microsoft 365 Apps. OWA y el Nuevo Outlook no presentan el problema. Como mitigación inmediata, responde desde el lector web o redacta un nuevo mensaje. Como mitigación estructural temporal, vuelve a MSIPC con la clave de registro documentada por Microsoft o haz rollback a la versión 2401 para estabilizar mientras llega la corrección. Complementa con comprobaciones de RMS, limpieza de certificados y desactivación de complementos conflictivos. Mantén un plan de reversión para regresar a MIP SDK cuando el fabricante publique el fix.
Este artículo prioriza pasos prácticos y reversibles para minimizar el impacto en la productividad, manteniendo la seguridad del contenido protegido y la compatibilidad futura con MIP SDK.