Quando um usuário relata correio ausente, comece com um endereço completo do destinatário e um horário aproximado de envio. Reinícios amplos ou envios de teste repetidos podem ocultar a evidência original e adicionar carga a um receptor já ocupado.
Acompanhe a mensagem pelo sistema
- Remetente: A mensagem foi enviada, enfileirada ou rejeitada antes da entrega SMTP? Solicite um bounce ou status de entrega, se disponível.
- DNS: Verifique os registros de roteamento de correio do domínio do destinatário e se eles apontam para o receptor pretendido.
- SMTP: Procure por registros de conexão, aceitação do destinatário e resposta final.
- Armazenamento: Confirme se a mensagem aceita tem um índice e corpo, e se há uma nova tentativa pendente.
- Exibição: Verifique o endereço solicitado, o acesso à sessão, os filtros e a conexão de atualização da caixa de entrada.
Escolha evidências que restrinjam a falha
| Observação | Próxima verificação |
|---|---|
| Sem conexão com o receptor | Fila do remetente e DNS do destinatário. |
| Falha temporária de SMTP | Tempo de nova tentativa e capacidade do receptor. |
| Aceita mas não visível | Status de persistência e o caminho de leitura da caixa de entrada. |
| Armazenada e legível através da API | Sessão do navegador e comportamento de atualização do frontend. |
Mantenha a recuperação controlada
Use o mecanismo normal de nova tentativa do sistema sempre que possível. Evite iniciar um loop adicional de nova tentativa sem um limite de concorrência. Compare a idade da fila e a taxa de conclusão ao longo do tempo; o comprimento da fila sozinho não consegue distinguir um breve surto de um worker travado.
Registre a causa, a ação de recuperação e qualquer incerteza restante. Não declare uma mensagem perdida simplesmente porque a primeira tentativa de armazenamento falhou, nem declare-a entregue apenas porque um worker aceitou a solicitação.