Você dispara uma campanha às nove da manhã e, dez minutos depois, a caixa de entrada começa a encher de mensagens com assunto "Undelivered Mail Returned to Sender". Você abre uma, lê "a sua mensagem não pôde ser entregue", dá de ombros e joga tudo na lixeira. Pronto: a informação mais útil do seu dia acabou de ir embora.
O e-mail de retorno não é um bilhete de desculpas. É um relatório de diagnóstico escrito por máquina, com um número de três dígitos que diz por que a entrega falhou e se faz sentido tentar de novo. Ler esse número é a diferença entre corrigir um erro de digitação e queimar a reputação do domínio batendo numa porta já trancada. Antes de um disparo grande, vale passar a lista por uma verificação de endereços de e-mail: boa parte dos retornos que você receberia era previsível.
4xx e 5xx: a única divisão que você precisa decorar
O SMTP responde a cada comando com um código de três dígitos, e o primeiro deles já diz quase tudo.
- 4xx — falha temporária (soft bounce). O servidor do destinatário está dizendo "agora não, tente mais tarde". O seu servidor de envio guarda a mensagem numa fila e repete a tentativa sozinho, com intervalos cada vez maiores, normalmente por alguns dias — sem nenhuma ação sua.
- 5xx — falha permanente (hard bounce). "Não, e não adianta insistir." A mensagem é descartada. Reenviar na mão não muda o resultado; só acrescenta mais uma tentativa fracassada ao histórico do seu IP e do seu domínio.
Existe ainda um segundo código, mais detalhado: o status estendido, aqueles três blocos separados por ponto, como 5.1.1 ou 4.7.28. O primeiro bloco repete a lógica do 4 e do 5; os outros dois contam a história de verdade. Se você só olhar uma coisa no bounce, olhe esse número.
Os códigos que você vai encontrar de verdade
550 é a recusa genérica e a mais frequente. Sozinho, quase não informa nada: pode ser caixa inexistente, pode ser bloqueio por política. Quem desempata é o status estendido.
5.1.1 — a caixa postal não existe. O domínio está no ar, o servidor atendeu, mas aquele usuário não mora ali. Erro de digitação, funcionário que saiu, endereço inventado num formulário.
5.2.2 — caixa cheia, tratada como definitiva por parte dos servidores. O 4.2.2 é a mesma situação em versão temporária: lotada agora, com espaço amanhã.
5.7.1 — política. Aqui não há nada de errado com o endereço; o servidor decidiu não aceitar você. Falha de SPF, DKIM ou DMARC, IP em lista de bloqueio, conteúdo reprovado, reputação ruim.
4.7.x — greylisting ou limite de taxa. O greylisting recusa a primeira tentativa de propósito, contando que um remetente legítimo volte em minutos e um robô de spam não volte. O limite de taxa é o servidor dizendo que você manda rápido demais.
421 — serviço indisponível: fila cheia, manutenção, sobrecarga, conexão encerrada no meio do caminho. Temporário por definição.
552 — limite de tamanho ou de cota estourado, quase sempre um anexo grande demais.
Onde fica o código de verdade dentro do bounce
A frase amigável no topo do retorno ("não foi possível entregar a sua mensagem") é decoração para humanos. O que interessa está no corpo técnico, o DSN, num bloco anexado. Procure três linhas:
- Final-Recipient — o endereço que falhou de fato, que nem sempre é o que você digitou: pode ter havido redirecionamento.
- Status — o status estendido, no formato 5.1.1.
- Diagnostic-Code — a resposta literal do servidor remoto, com o 550 ou o 421 e a explicação em texto, às vezes com link para a política do provedor.
No Gmail, isso aparece em "Mostrar mensagem original"; em outros clientes, no anexo do tipo delivery-status. É ali que a diferença entre "escrevi errado" e "estou bloqueado" fica evidente.
O que fazer em cada classe
5.1.1 é um problema de lista. O endereço nunca existiu ou deixou de existir, e isso se resolve antes do envio: remova na hora, sem carência, e corrija a origem — formulário sem confirmação, planilha antiga, digitação manual.
5.7.1 é um problema de reputação, e insistir piora tudo: cada tentativa vira mais um registro negativo. O caminho é parar o envio para aquele provedor, conferir a autenticação do domínio, ver se o IP está listado e reduzir o volume. Se a recusa vier junto com entregas indo para a lixeira, o diagnóstico está em por que meus e-mails caem no spam.
Nos 4xx, a atitude correta é não ter atitude: deixe o servidor repetir. Só investigue se o mesmo endereço acumular falhas temporárias por dias seguidos — aí ele virou permanente na prática. E nos 552, hospede o arquivo e mande o link.
A regra que resume tudo: endereço com bounce permanente está morto e sai da lista na hora. Continuar mandando para ele é o sinal mais clássico de remetente descuidado, e os filtros leem esse sinal muito bem. Sobre a fronteira entre as duas categorias, vale ler bounce permanente e bounce temporário. E se a sua base é antiga, uma limpeza prévia da lista custa muito menos do que uma reputação queimada.
Perguntas frequentes
Um endereço que deu 550 pode voltar a funcionar?
Pode acontecer em domínios corporativos, quando alguém recria a conta de um ex-funcionário. Mas é raro e não vale manter o endereço na lista esperando. Se a pessoa quiser voltar a receber, ela se cadastra de novo — e aí você tem endereço válido e consentimento novo.
Qual porcentagem de bounces é aceitável?
Não existe número mágico oficial, mas a lógica é simples: quanto menor, melhor, e o que chama atenção é o padrão, não o valor isolado. Muitos hard bounces sugerem lista comprada ou nunca higienizada; uma taxa que sobe de repente indica importação de dados velhos.
O bounce chega sempre? Se não recebi nada, foi entregue?
Não necessariamente. Alguns servidores rejeitam em silêncio, sem gerar retorno, para não ajudar quem testa endereços em massa. Outros aceitam e depois descartam ou jogam no spam. Ausência de bounce é ausência de recusa explícita, não prova de entrega.
