O e-mail não chegou. E agora?

"O e-mail não chegou" é um sintoma. Antes de mexer em DNS, conteúdo ou provedor, descubra em que ponto do caminho a mensagem parou. São quatro lugares possíveis, e cada um deixa um rastro diferente.

1. Ela saiu da aplicação?

Comece pelos seus logs, não pelos do provedor. Existe registro da tentativa? Para qual destinatário, exatamente? Erro de validação, credencial vencida e limite de requisições param tudo antes da rede, e muita aplicação engole esse erro em silêncio.

Olhe o endereço com lupa: cliente@gmial.com, espaço no fim, e-mail de homologação indo para produção. Muitos casos terminam aqui, e é ótimo quando terminam.

2. O provedor aceitou?

Resposta 2xx da API ou 250 do SMTP quer dizer que o provedor pegou a mensagem para processar. Só isso. Abra o histórico dela no painel: provedores separam aceito, entregue ao destino, devolvido e reclamado, e mandam cada etapa por webhook.

Confira a lista de supressão. Endereço que já devolveu mensagem, marcou spam ou pediu descadastro costuma ser bloqueado automaticamente, e o provedor nem tenta mais. É proteção da sua reputação. Mas pega de surpresa quem não sabe que ela existe.

3. O que o destino respondeu?

O servidor do destinatário responde com um código. Começou com 2, aceitou. Com 4, falha temporária, e o provedor tenta de novo sozinho. Com 5, recusa permanente. Os códigos estendidos, como 5.1.1, dizem o motivo; a tabela está na RFC 3463.

• 5.1.1 e parecidos: o endereço não existe. Confirme com a pessoa e pare de tentar.
• Caixa cheia: é temporário até deixar de ser. Depois de alguns dias, trate como permanente.
• Recusa citando SPF, DKIM, DMARC ou política: o texto da resposta quase sempre diz qual. Leia até o fim.
• Adiamentos seguidos: o destino está limitando quantas mensagens aceita de você. Diminua o ritmo.

Copie a resposta inteira, com o horário. É a primeira coisa que qualquer suporte vai pedir.

4. Aceitou, mas sumiu

O destino aceitou e a pessoa não acha. Peça para procurar pelo remetente e pelo assunto em todas as pastas: spam, promoções, quarentena da empresa e aquela regra que ela mesma criou e esqueceu.

Achou no spam? Abra os cabeçalhos e leia o Authentication-Results com o guia de cabeçalhos. DMARC falhando por falta de alinhamento é uma das causas mais comuns, e dá para corrigir no mesmo dia.

Os grandes provedores publicaram regras para remetentes, e elas pegaram muita empresa de surpresa. As diretrizes do Gmail pedem SPF ou DKIM de todo mundo. De quem manda muito, pedem SPF, DKIM e DMARC alinhados, descadastro com um clique em marketing (RFC 8058) e taxa de spam baixa. O Yahoo vai na mesma linha. Os números mudam, então leia a página atual.

5. Reputação

Autenticação em ordem e, mesmo assim, spam? Aí entra o histórico. O destino olha quantas reclamações o seu domínio gerou, se você manda para endereço que não existe, se o volume saltou de repente e o que o conteúdo diz.

Domínio novo indo de zero a 50 mil mensagens num dia chama atenção, e com razão. Suba o volume aos poucos. Mande só para quem pediu. Deixe o descadastro fácil, porque quem não acha o link clica em "spam".

Na infraestrutura, o IP que envia precisa de DNS reverso (PTR) coerente e a conexão precisa de TLS. Com provedor de envio, isso é com ele. Com servidor próprio, é com você.

Quando o volume justificar, separe transacional de marketing em subdomínios diferentes. Uma campanha mal recebida não pode levar junto o e-mail de recuperação de senha.

O que juntar antes de pedir ajuda

1. Identificador interno, horário e destinatário exato.
2. Resposta do provedor e os eventos que vieram depois.
3. Código e texto do servidor de destino, se houve recusa.
4. Cabeçalho completo, se a mensagem apareceu em algum lugar.
5. Como estava o DNS na hora. A consulta DNS e o analisador de SPF mostram isso em segundos.

Com isso na mão, a conversa com qualquer suporte fica curta. Se a sua aplicação ainda não guarda nada disso, o guia de integração mostra por onde começar.