Cuando un usuario informa de correo perdido, comience con una dirección completa del destinatario y una hora de envío aproximada. Los reinicios amplios o los envíos de prueba repetidos pueden ocultar la evidencia original y añadir carga a un receptor ya ocupado.
Siga el mensaje a través del sistema
- Remitente: ¿El mensaje fue enviado, encolado o rechazado antes de la entrega SMTP? Solicite un rebote o estado de entrega si está disponible.
- DNS: Compruebe los registros de enrutamiento de correo del dominio del destinatario y si apuntan al receptor previsto.
- SMTP: Busque registros de conexión, aceptación del destinatario y respuesta final.
- Almacenamiento: Confirme si el mensaje aceptado tiene un índice y cuerpo, y si hay un reintento pendiente.
- Visualización: Compruebe la dirección solicitada, el acceso a la sesión, los filtros y la conexión de actualización de la bandeja de entrada.
Elija evidencia que acote la falla
| Observación | Siguiente comprobación |
|---|---|
| Sin conexión con el receptor | Cola del remitente y DNS del destinatario. |
| Fallo temporal de SMTP | Temporización de reintentos y capacidad del receptor. |
| Aceptado pero no visible | Estado de persistencia y la ruta de lectura de la bandeja de entrada. |
| Almacenado y legible a través de la API | Sesión del navegador y comportamiento de actualización del frontend. |
Mantenga la recuperación bajo control
Use el mecanismo de reintento normal del sistema donde sea posible. Evite lanzar un bucle de reintento adicional sin un límite de concurrencia. Compare la antigüedad de la cola y la tasa de finalización a lo largo del tiempo; la longitud de la cola por sí sola no puede distinguir un pico breve de un trabajador estancado.
Registre la causa, la acción de recuperación y cualquier incertidumbre restante. No declare un mensaje perdido simplemente porque el primer intento de almacenamiento falló, ni lo declare entregado solo porque un trabajador aceptó la solicitud.