El correo antiguo se abre, la lista de carpetas parece normal y un mensaje enviado esta mañana nunca sale de la Bandeja de salida. Esa combinación indica que la caché local está bien y que la conexión con Exchange no lo está, y es el síntoma peor interpretado en todo este terreno. Nada se ha bloqueado, y por eso el informe suele llegar como un Outlook lento y no como un Outlook desconectado.

Haga las comprobaciones en orden y anote antes que nada qué versión de Outlook está mirando, porque los controles cambian.

Confirme qué cliente y qué tipo de cuenta

El Outlook clásico para Windows, el nuevo Outlook y Outlook en la web son tres clientes distintos con tres rutas de conexión distintas, y el consejo para uno suele ser erróneo para otro. Dentro del Outlook clásico, una cuenta Exchange y una cuenta POP o IMAP se comportan de forma distinta cuando el servidor no es accesible, porque solo la cuenta Exchange tiene un transporte MAPI y un almacén de buzón en caché. Identifique el tipo de cuenta en la configuración de cuentas antes de interpretar cualquier estado. Una solución copiada de una configuración IMAP no describirá una conexión Exchange.

Anote el nombre y la versión del cliente. Los hilos de soporte los mezclan con frecuencia, y las capturas dejan de coincidir a medio camino.

Lea el estado de la conexión mientras falla

Con el Outlook clásico en marcha, mantenga pulsado Ctrl y haga clic con el botón derecho en el icono del área de notificación, y luego abra Connection Status. Hágalo durante la operación que falla y no después de reiniciar, porque la vista informa de lo que el cliente intenta en ese momento. Anote el nombre del servidor, el protocolo y el estado, y después compare ese servidor con el que espera que use la cuenta. Las guías de diagnóstico de Microsoft cubren esta vista y los registros más detallados que puede recopilar cuando el resumen no basta.

Las implementaciones modernas de Exchange transportan el tráfico de Outlook por MAPI over HTTP, así que abrir puertos de envío SMTP no es una reparación para una conexión de buzón. Si el transporte llega al servicio, conserve el error HTTP o de autenticación y trabaje en esa etapa en lugar de restablecer una contraseña que nunca fue el problema.

Compare el punto de conexión con la ruta del navegador

Un buzón web que funciona demuestra que un navegador puede llegar a un punto de conexión a través de un nombre y una configuración de proxy. No demuestra que Outlook haya resuelto la misma dirección, usado la misma ruta o aceptado el mismo certificado. Con una VPN activa, un DNS dividido puede enviar el nombre de Outlook a una dirección interna mientras el navegador usa una pública, y esa diferencia por sí sola explica una sesión web que funciona junto a un cliente roto. Compare la dirección resuelta, la ruta seleccionada y la identidad TLS en ambas rutas.

Los portales administrativos y PowerShell remoto no sustituyen una prueba de buzón de usuario, porque son servicios distintos con autenticación distinta.

Pruebe la caché con una operación nueva

El Cached Exchange Mode mantiene una copia local y se sincroniza con el servidor, lo que lo hace tolerante a las interrupciones y no lo hace independiente del servidor. Leer un mensaje antiguo en caché no es una prueba de red, y el interruptor Work Offline tampoco. Envíe un mensaje nuevo o fuerce una sincronización y observe esa operación concreta. Si los intercambios pequeños funcionan mientras las transferencias grandes se atascan, el tamaño de paquete y la MTU de la ruta merecen atención, con pruebas tomadas de la operación que falla.

Cambiar el modo de caché puede mover el síntoma sin reparar la ruta ni el servicio.

Tras cualquier corrección admitida, repita la operación original y confirme que los datos nuevos llegan al servidor y vuelven. Anote ese resultado por separado de la comodidad de leer correo que ya estaba en el disco.

Artículos relacionados