# Hard bounce vs soft bounce: códigos SMTP e lista de supressão > Diferença entre hard bounce e soft bounce, como ler códigos SMTP e enhanced status codes e quando adicionar um endereço à lista de supressão. Source: https://pidgely.com/pt-br/blog/hard-bounce-vs-soft-bounce/ · Published: 2026-10-12 · Pidgely 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. ```text 550 5.1.1 : 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) | Resposta | Significado | Ação | |----------|-------------|------| | `550 5.1.1` | Usuário inexistente | Suprimir imediatamente | | `550 5.1.2` / `5.1.10` | Domínio inexistente ou sem MX | Suprimir imediatamente | | `552 5.2.2` | Caixa cheia (tratada como permanente pelo servidor) | Tratar como soft na primeira vez; suprimir se repetir | | `554 5.2.1` | Caixa desativada | Suprimir | | `550 5.7.1` | Rejeição por política | **Não** suprimir; investigar | | `550 5.7.26` | Falha de autenticação (Gmail) | **Não** suprimir; corrigir SPF/DKIM/DMARC | ### Temporários (soft bounce) | Resposta | Significado | Ação | |----------|-------------|------| | `421 4.7.0` | Tente mais tarde, conexão encerrada | Nova tentativa com backoff | | `450 4.2.1` | Caixa temporariamente indisponível | Nova tentativa | | `452 4.2.2` | Caixa cheia | Nova tentativa; suprimir se persistir | | `451 4.3.0` | Erro local no servidor | Nova tentativa | | `421 4.7.28` | Taxa incomum de mensagens (Gmail) | Reduzir volume para o provedor | ## 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`: ```text 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. ## Perguntas frequentes ### Qual a diferença entre hard bounce e soft bounce? Hard bounce é uma falha permanente, como endereço inexistente ou domínio sem servidor de email; o endereço deve ser suprimido na hora. Soft bounce é uma falha temporária, como caixa cheia ou limitação de volume, e a mensagem pode ser tentada de novo. ### Como saber se um bounce é permanente? Pelo código SMTP e pelo enhanced status code. Respostas 5xx com status 5.x.x são permanentes; respostas 4xx com status 4.x.x são temporárias. Mas leia o código completo: 5.7.x costuma indicar bloqueio por política, não endereço inválido. ### Quantos soft bounces antes de suprimir um endereço? Não há número padrão. Uma regra comum é suprimir quando o mesmo endereço falha temporariamente em vários envios ao longo de alguns dias, sem nenhuma entrega bem-sucedida no meio. ### Devo suprimir um endereço que recebeu 550 5.7.1? Normalmente não. O 5.7.1 indica rejeição por política ou reputação do remetente, não um endereço inexistente. Suprimir esconderia um problema seu; o certo é investigar a causa.