Não recebeu o e-mail de teste? Siga a cadeia de evidências

1. Estabeleça uma linha de base com o caso mínimo

Crie uma nova caixa de entrada de teste, copie o endereço e dispare imediatamente um e-mail simples, com assunto exclusivo. O assunto pode incluir o número deste teste, mas não use chaves de produção nem dados reais de clientes.

Registre o horário do clique na ação de negócio, da entrada na fila e da aceitação pelo provedor. Se o e-mail simples chega, mas o template complexo não, o problema provavelmente está na renderização, nos anexos ou na política de conteúdo, não na rede básica.

2. Confirme que a aplicação realmente gerou o e-mail

Verifique se o evento de negócio atende às condições de envio, como status da conta, flags de ambiente, regras de deduplicação e preferências de notificação. O log deve mostrar o endereço final de destino, e não apenas uma mensagem genérica como “tarefa de e-mail criada”.

Confira se o endereço é idêntico, caractere por caractere, especialmente quando o app continua usando um endereço antigo em cache após a troca da caixa de teste. Se não houver registro da mensagem, corrija primeiro o disparo e os parâmetros do template; não investigue o DNS ainda.

Evidências esperadas

• ID do evento de negócio e versão do template
• Endereço de destino normalizado
• Criação da mensagem concluída ou erro explícito

3. Verifique fila, tentativas e sequência de horários

E-mails assíncronos costumam travar na conexão com a fila, no worker, no horário agendado ou no backoff das tentativas. Compare o horário de entrada na fila, da primeira execução, de cada tentativa e do status final para confirmar que a tarefa não continua aguardando.

Se o mesmo evento gerar vários e-mails, verifique se a chave de idempotência é estável e se o consumidor atingiu timeout antes da resposta de sucesso. Não use tentativas infinitas para esconder erros determinísticos no template, pois isso gera mensagens duplicadas no recebimento.

4. Leia os eventos do provedor de envio

Um HTTP 2xx normalmente indica apenas que o provedor recebeu a solicitação, não que o servidor destinatário a aceitou. Procure também eventos como queued, sent, delivered, deferred, bounced ou rejected e guarde o ID da mensagem no provedor.

Respostas SMTP da classe 4xx geralmente indicam atraso temporário; aplique o backoff recomendado. Respostas 5xx costumam ser rejeições permanentes: corrija primeiro o endereço, a identidade ou a política. Se o provedor não tiver nenhuma mensagem correspondente, o problema ainda está entre a aplicação e o provedor.

5. Valide a identidade do domínio de envio

Verifique se o SPF inclui a origem real do envio, se o domínio da assinatura DKIM está alinhado ao domínio From e se o alinhamento e a política do DMARC correspondem ao ambiente de teste. Após uma alteração no DNS, considere o TTL e o cache de diferentes resolvedores.

Não confie apenas no indicador verde do painel: leia os eventos específicos do e-mail ou os resultados de autenticação nos cabeçalhos brutos. Em um domínio de teste compartilhado, trocar de plataforma de envio com frequência também pode deixar registros antigos e exceder o limite de consultas do SPF.

6. Isole problemas de template e política de conteúdo

Envie primeiro uma mensagem de texto simples como linha de base e depois adicione HTML, imagens, links e anexos gradualmente. Se a falha começar após adicionar um item, verifique a reputação das URLs, o tipo e a codificação do anexo, o tamanho da mensagem e as variáveis de template não substituídas.

Não imite linguagem de phishing no assunto ou no corpo e não use credenciais reais. Para testar códigos, use um valor fixo e identifique claramente o ambiente, evitando que alguém confunda a mensagem com uma notificação de produção.

7. Elimine problemas de estado no recebimento

Confirme que a contagem regressiva da caixa de entrada de teste ainda não terminou e confira se o endereço na barra de ferramentas corresponde ao destino do envio. Clique em atualizar manualmente. Se você acabou de trocar de endereço, os e-mails da caixa antiga não serão migrados para a nova.

Quando o e-mail real chegar, a linha de demonstração deve sair da lista e exibir apenas dados reais. Ao abrir os detalhes, confira também assunto, remetente, horário de chegada, corpo HTML e alternativa em texto simples; não julgue a integridade do template apenas pela prévia da lista.

8. Analise atrasos, inversões e duplicidades

Compare o disparo do negócio, a entrada na fila, a aceitação pelo provedor e o recebimento usando o mesmo fuso horário. Só atribua o atraso a um trecho quando um único ponto estiver claramente mais lento; timestamps em fusos diferentes levam a conclusões erradas.

Ao reenviar um teste, use um identificador de evento exclusivo e mantenha os IDs das mensagens antigas. Se a mensagem mais recente chegar primeiro, verifique prioridade da fila, consumidores concorrentes e novas tentativas do provedor, em vez de presumir que a ordenação da lista está errada.

9. Reduza o escopo com uma matriz de sintomas

10. Quando escalar e o que fornecer

Se ainda não for possível localizar o problema, reúna a linha do tempo, o endereço de destino, o ID do evento de negócio, o ID da mensagem no provedor, o status final e o que já foi descartado em um pacote mínimo de evidências. Remova dados sensíveis do corpo e mantenha apenas o necessário para reproduzir o problema.

Ao entrar em contato com o suporte do MSGTMP, informe quando a caixa foi criada e quando expira, se o endereço foi alterado e qual foi a resposta final registrada pelo provedor de envio. Não envie senhas, códigos de login nem chaves privadas completas; o e-mail de suporte é support@msgtmp.com.