Hard bounce vs soft bounce: códigos SMTP e lista de supressão

Hard bounce é uma falha de entrega permanente: o endereço não existe, o domínio não recebe email ou o servidor recusou a mensagem de forma definitiva. Soft bounce é uma falha temporária, como caixa cheia, servidor indisponível ou limitação de volume, e a mensagem pode ser tentada de novo mais tarde. A regra prática é suprimir hard bounces na primeira ocorrência e suprimir soft bounces apenas quando se repetem por vários dias sem nenhuma entrega bem-sucedida.

Onde o bounce acontece

Existem dois momentos em que um email pode "voltar":

1. Durante a transação SMTP (síncrono). O servidor de destino responde ao RCPT TO ou ao final do DATA com um código de erro. O seu MTA sabe na hora.
2. Depois da aceitação (assíncrono). O servidor aceitou com 250, mas não conseguiu entregar depois (por exemplo, porque repassou para outro servidor interno). Ele então envia uma notificação de falha (DSN, definida na RFC 3464) para o endereço do Return-Path.

Os dois casos precisam ser tratados. O primeiro aparece nos logs do MTA; o segundo chega como email e precisa ser lido e interpretado, o que é o papel do tratamento de bounces com VERP.

Como ler uma resposta SMTP

Uma resposta tem duas partes: o código básico da RFC 5321 e o enhanced status code da RFC 3463.

550 5.1.1 <joao@example.com.br>: Recipient address rejected: User unknown

• 550: código básico. O primeiro dígito diz a classe: 2 sucesso, 4 falha temporária, 5 falha permanente.
• 5.1.1: enhanced status code no formato classe.assunto.detalhe. Classe 5 permanente, 4 temporária. Assunto 1 endereçamento, 2 caixa postal, 3 sistema de email, 4 rede e roteamento, 5 protocolo, 6 conteúdo, 7 segurança e política.

Códigos que você vai encontrar

Permanentes (hard bounce)

Temporários (soft bounce)

A armadilha dos códigos 5.7.x

Muita gente classifica "todo 5xx é hard bounce" e suprime. Isso é um erro. Um 550 5.7.1 com o texto "message rejected due to reputation" não diz nada sobre o endereço do destinatário: diz que o seu envio foi bloqueado. Suprimir esses endereços:

• esconde o problema real (autenticação, lista de bloqueio, reputação);
• faz você perder destinatários válidos para sempre.

A classificação correta olha o enhanced status code e o texto. Bloqueios por política devem gerar alerta para o time, não supressão.

Notificação de falha (DSN) na prática

Quando o bounce é assíncrono, chega uma mensagem multipart/report com um bloco message/delivery-status:

Content-Type: multipart/report; report-type=delivery-status;
    boundary="limite123"

--limite123
Content-Type: text/plain

Não foi possível entregar a mensagem para joao@example.com.br.

--limite123
Content-Type: message/delivery-status

Reporting-MTA: dns; mx.example.com.br

Final-Recipient: rfc822; joao@example.com.br
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp; 550 5.1.1 User unknown

--limite123--

Os campos que importam são Action (failed é falha definitiva; delayed é só aviso), Status e Final-Recipient. Nem todo servidor gera DSN bem formada, então o parser precisa de heurísticas para textos livres.

Política de retentativa para soft bounces

Um esquema típico para falhas temporárias:

• Backoff exponencial: primeiras tentativas em minutos, depois em horas.
• Janela máxima de alguns dias. A RFC 5321 sugere que o tempo total de tentativas seja de pelo menos quatro a cinco dias, mas para mensagens transacionais sensíveis ao tempo (como código de login) faz sentido desistir antes.
• Respeitar limitações por provedor: se o Outlook está devolvendo 4.7.x, desacelere para todo o domínio de destino, não só para aquele endereço.

Listas de supressão

A lista de supressão é o registro de endereços para os quais você não deve mais enviar. Ela é consultada antes de cada envio e deve conter:

• Hard bounces (endereço ou domínio inexistente).
• Soft bounces persistentes (falhas repetidas por vários dias sem sucesso).
• Reclamações de spam vindas de feedback loops.
• Descadastros, por stream (descadastrar do marketing não deve bloquear o recibo de compra).

Boas práticas:

1. Escopo correto. Supressão por bounce vale para tudo; supressão por descadastro vale para o stream ou a categoria descadastrada.
2. Motivo registrado. Guarde o código, a data e a mensagem original. Isso ajuda a revisar remoções e a atender pedidos de clientes.
3. Remoção controlada. Às vezes o endereço volta a existir (o usuário recriou a conta). Permita remover da lista manualmente, com registro de quem fez.
4. Supressão antes de tudo. O envio precisa ser bloqueado na API, antes de entrar na fila, para não gastar reputação.

Por que isso afeta a reputação

Provedores interpretam muitos hard bounces como sinal de lista comprada, raspada ou mal cuidada. Endereços abandonados podem ser reciclados como spam traps. Continuar enviando para endereços que falham é uma das formas mais rápidas de cair no spam ou ser bloqueado. As boas práticas do M3AAWG tratam a remoção de endereços inválidos como requisito básico de higiene de lista.

Erros comuns

• Tratar todo 5xx como hard bounce, incluindo bloqueios por política.
• Ignorar DSNs assíncronas porque "o servidor já respondeu 250".
• Confundir auto-resposta de férias com bounce e suprimir quem só estava ausente.
• Suprimir globalmente quem se descadastrou só do marketing.
• Não ter limite para soft bounces e tentar a mesma caixa cheia por meses.

Checklist

• [ ] Classificação por enhanced status code e texto, não só pelo primeiro dígito.
• [ ] Parser de DSN (RFC 3464) para bounces assíncronos.
• [ ] Retentativa com backoff e janela máxima por tipo de mensagem.
• [ ] Supressão automática de hard bounces e de soft bounces persistentes.
• [ ] Alerta para bloqueios 5.7.x.
• [ ] Lista de supressão consultada antes de enfileirar.

Na Pidgely

A Pidgely processa respostas síncronas e DSNs com VERP, classifica cada falha pelo enhanced status code, alimenta listas de supressão automaticamente e envia eventos de bounce por webhook, para que a sua aplicação saiba o que aconteceu com cada endereço sem precisar ler logs de MTA.