Hard bounce, soft bounce: códigos SMTP e regra de remoção

O Gmail devolve a mesma caixa de correio cheia com dois códigos opostos: um 452 4.2.2 temporário e um 552 5.2.2 definitivo quando a conta está também inativa (documentação do Google Workspace, consultada em outubro de 2026). O primeiro é um soft bounce, o segundo um hard bounce, para a mesma caixa cheia consoante esteja ativa ou inativa. Um hard bounce (rejeição permanente) é uma recusa definitiva: a mensagem não será entregue enquanto o endereço ou a mensagem não mudarem. Um soft bounce (rejeição temporária) é uma falha passageira que a plataforma de envio volta a tentar. Regra de remoção: elimine o endereço no primeiro hard bounce e retire-o no 3.º soft bounce consecutivo, em 3 envios espaçados por pelo menos 14 dias. O resto do artigo decifra um NDR linha a linha e liga cada limiar numérico à sua fonte.

Hard bounce e soft bounce: comparação ponto por ponto

Os valores da linha «Nova tentativa» vêm da RFC 5321 (secções 4.2.1 e 4.5.4.1). Cada plataforma fixa depois o seu próprio prazo de desistência, que consta da respetiva documentação.

Que códigos SMTP separam um hard bounce de um soft bounce?

Um código 4xx anuncia uma falha temporária (soft bounce), um código 5xx uma falha permanente (hard bounce): o primeiro algarismo da resposta SMTP define a classe.

O pormenor está no enhanced status code, definido pela RFC 3463 (janeiro de 2003). Tem três campos separados por pontos: classe, assunto, detalhe. A classe é 2 (sucesso), 4 (falha temporária persistente) ou 5 (falha permanente). O assunto indica a zona em causa. O 1 visa o endereço, o 2 a caixa de correio, o 3 o sistema de mensagens, o 4 a rede, o 5 o protocolo, o 6 o conteúdo, o 7 a segurança e a política.

O código 5.1.1 lê-se assim: falha permanente (5), problema de endereço (1), parte à esquerda da arroba inválida (1). A RFC reserva este código para falhas permanentes. O catálogo completo das respostas está no guia dos códigos de resposta SMTP. O detalhe dos casos 550 5.4.1 e 552 lê-se, um a um, nos códigos de erro SMTP.

Ler um NDR linha a linha: o exemplo do 550 5.1.1

O NDR (non-delivery report) é uma mensagem em formato DSN, descrita pela RFC 3464, devolvida ao remetente. O exemplo abaixo é reconstituído: os campos seguem a RFC 3464 e o diagnóstico reproduz o texto que a Google documenta para o 550 5.1.1. Os endereços e o anfitrião remetente são fictícios.

Reporting-MTA: dns; smtp.exemplo.pt
Final-Recipient: rfc822; nome.apelido@gmail.com
Action: failed
Status: 5.1.1
Remote-MTA: dns; gmail-smtp-in.l.google.com
Diagnostic-Code: smtp; 550 5.1.1 The email account that you tried to reach does not exist.

• Reporting-MTA indica o servidor que redige o relatório: aqui, a sua plataforma de envio.
• Final-Recipient dá o endereço que falhou. É a chave para cruzar com a sua lista.
• Action: failed indica que a entrega falhou em definitivo.
• Status: 5.1.1 é o enhanced status code: o 5 classifica a falha como permanente, o 1.1 aponta uma caixa de correio inexistente.
• Remote-MTA identifica o servidor que recusou, aqui a entrada MX do Gmail.
• Diagnostic-Code copia a resposta bruta do servidor: o 550 da camada SMTP, depois o 5.1.1 e por fim o texto legível. A Google sugere verificar se há um erro de digitação ou um espaço a mais.

O mesmo relatório para uma caixa que está a encher muda três linhas, segundo o texto da Google para o 452 4.2.2:

Action: delayed
Status: 4.2.2
Diagnostic-Code: smtp; 452 4.2.2 The recipient's inbox is out of storage space.

O relatório delayed avisa que a plataforma ainda está a tentar. Um pormenor muda a leitura de um dashboard. Uma notificação final pode mostrar Action: failed com um Status: 4.2.2. A RFC 3463 define a classe 4 como uma condição temporária que provocou o abandono ou o atraso do envio. A plataforma desistiu depois das tentativas, sem recusa definitiva do servidor. Este caso classifica-se como soft bounce esgotado.

Tabela de decisão: do código à ação

As descrições vêm da documentação do Google Workspace sobre os erros SMTP do Gmail e das definições da RFC 3463.

A última linha é a mais cara de ler mal. Um 5.7.26 significa, segundo a Google, que a mensagem é bloqueada por falta de autenticação (SPF ou DKIM) ou porque a política DMARC do domínio a rejeita. O endereço é válido: é o seu domínio que falha. Eliminar estes contactos esvazia a lista sem resolver a causa. O greylisting pertence à linha 4.7.x: o servidor recusa de propósito a primeira tentativa de um remetente desconhecido. A segunda passa.

Bounce síncrono e assíncrono: quando chega a recusa

Uma recusa síncrona surge durante a sessão SMTP. O servidor responde 550 5.1.1 ao comando RCPT TO (ou no fim do DATA): a sua plataforma conhece o resultado antes de fechar a ligação e não há NDR à espera.

O bounce assíncrono segue outro percurso. O servidor responde primeiro 250 e assume a mensagem. Se a entrega falhar depois, internamente, a RFC 5321 (secção 6.1) obriga-o a redigir uma notificação. Segue para o endereço de retorno com um remetente vazio: o comando MAIL FROM contém então <> (secção 3.6.3), o que evita ciclos de notificações. Este NDR cai na caixa de bounces do seu domínio, por vezes vários dias depois do envio, no formato DSN descrito acima. Para a sua lista, a consequência é direta: uma rejeição assíncrona não aparece no relatório imediato do envio. Liga-se ao endereço pelo campo Final-Recipient e segue depois as mesmas regras de uma recusa síncrona: hard bounce, remoção imediata. Uma plataforma que não lê essa caixa de retorno deixa estes endereços em circulação e infla a taxa de rejeição da campanha seguinte.

Consoante a configuração, os domínios catch-all produzem este segundo caso: aceitam qualquer endereço durante a sessão SMTP e só depois triam o correio. Um endereço inexistente pode então seguir num NDR diferido ou desaparecer sem qualquer resposta. Nenhum código recebido durante a sessão permite antecipá-lo. Por isso, só feche a taxa de rejeição de uma campanha depois da janela de desistência da sua plataforma. Trate também o silêncio de um domínio catch-all como informação incompleta. Os emails não entregues reúnem estes casos-limite, com a maneira de os triar.

Armadilhas de leitura: o 5xx a manter e a cache de supressão

O primeiro algarismo classifica a rejeição e nada diz sobre a validade do endereço: as famílias 5.7.x trazem muitas vezes um 5 em contactos válidos.

A resposta automática prova que a mensagem chegou à caixa de correio e não conta como rejeição. A cache de supressão age ao contrário: um endereço na lista de supressão interna da plataforma deixa de receber envios, mesmo com a caixa recriada. Um contacto que jura não receber nada procura-se primeiro nessa lista. Após corrigir um erro de digitação, o novo endereço passa, mas o antigo, mal escrito, fica em supressão.

Regra de remoção: quantos envios, em quanto tempo

Num hard bounce, o prazo é nulo. A Klaviyo elimina estes perfis automaticamente. A Mailchimp limpa o endereço da audiência (páginas de ajuda consultadas em outubro de 2026). Os 5.7.x são a exceção: visam a sua configuração. Um erro de digitação na recolha corrige-se na origem, com double opt-in.

Num soft bounce, aplique quatro regras:

• Conte uma rejeição por envio. As tentativas de uma mesma plataforma, espalhadas por vários dias, contam apenas como uma.
• Retire o endereço no 3.º soft bounce consecutivo, em envios distintos.
• Aconselhamos pelo menos 14 dias entre a primeira e a terceira rejeição, para separar uma caixa fora de serviço de forma duradoura de uma avaria passageira do lado do destinatário. Este prazo é uma escolha editorial: nenhuma norma o impõe.
• Reponha o contador a zero assim que um envio for entregue.

Exemplo: um endereço em 452 4.2.2 nas campanhas de 2 e 9 de outubro e depois na de dia 23 sai da lista a 23. Com três campanhas enviadas entre 2 e 4 de outubro, fica: três rejeições em 2 dias correspondem a uma única avaria e o endereço ainda não atingiu os 14 dias exigidos.

Esta regra de remoção é uma recomendação editorial. As plataformas publicam limiares diferentes. A MailerLite indica no seu guia dos bounces que um endereço que rejeita 3 vezes seguidas é convertido em hard bounce e passa a inativo. A Mailchimp converte um soft bounce em hard bounce após 7 rejeições para um endereço sem atividade de subscritor. Para um contacto com atividade anterior, o limite sobe para 15. O endereço é depois limpo (ajuda oficial da Mailchimp, consultada em outubro de 2026). A Klaviyo aplica um limiar mais alto: segundo a sua página de ajuda «Suppressed profiles» (atualizada a 30 de março de 2026), o perfil é eliminado depois de mais de 7 soft bounces consecutivos. Só contam os dos últimos 2 anos. O mesmo endereço pode assim sobreviver a 7 rejeições numa ferramenta e sair à 3.ª na outra. Numa plataforma permissiva, retire o endereço por si, através de um segmento de exclusão.

A duração depende também do seu ritmo de envio. A contagem faz-se por envio: uma campanha semanal atinge a 3.ª rejeição em 3 semanas, uma campanha mensal em 3 meses. Uma frequência demasiado baixa atrasa, portanto, a remoção: com um envio por mês, um endereço morto fica na lista um trimestre.

Limiares de bounce: o que mede cada percentagem

Os limiares a reter são 2 % e 5 % para as rejeições, 0,3 % para o spam assinalado. Não medem a mesma coisa.

O primeiro, 2 %, é uma referência do setor para a taxa de rejeição (MailerLite). O segundo, 5 %, é um limite contratual: a política anti-spam da MailerLite reserva-se o direito de suspender uma conta e investigar acima de 5 % de bounces ou de 0,2 % de queixas.

O terceiro, 0,3 %, vem da Google e mede outra coisa: a taxa de spam apresentada no Postmaster Tools, ou seja, a parte das mensagens que os destinatários assinalam como indesejadas. Desde 1 de fevereiro de 2024, todos os remetentes para o Gmail têm de a manter abaixo de 0,3 %. A Google recomenda ficar abaixo de 0,10 %.

Rejeição e denúncia são duas medidas distintas: a plataforma conta as primeiras, o Postmaster Tools as segundas. Uma lista pode mostrar 1,5 % de bounces, abaixo dos 2 %, com 0,05 % de spam e não ultrapassar nenhum limiar. O inverso também existe: 0,4 % de spam com 0,2 % de bounces ultrapassa a regra da Google. O limiar de 2 % aplica-se à média de uma campanha: em 10 000 envios, representa 200 rejeições no total. Uma única vaga de hard bounces numa lista antiga basta para o ultrapassar. Para fazer descer uma taxa de rejeição elevada abaixo da referência de 2 %, veja a gestão da taxa de rejeição.

Bounces, reputação do remetente e blocklists

Um envio para uma lista antiga faz subir 5.1.1 no relatório de campanha. Cada 5.1.1 prova que um endereço foi recolhido e nunca mais verificado: o relatório de campanha faz então o inventário do que a lista perdeu desde a recolha. Para ler a tendência, compare o número de 5.1.1 por envio em três campanhas sucessivas. Uma curva ascendente indica uma lista que envelhece, uma curva plana um problema pontual de importação. O acompanhamento faz-se pelo Postmaster Tools do lado do Gmail (a taxa de spam é aí comparada com o teto de 0,3 %) e pelo acompanhamento do Sender Score para a nota do endereço IP.

Num IP novo em aquecimento, cada 5.1.1 pesa mais: a Google pede que se comece por destinatários envolvidos, o que uma lista por limpar contradiz. O método está descrito em o aquecimento de um IP.

As spam traps (endereços-armadilha) escondem-se em listas antigas ou compradas e podem levar às blocklists. As spam traps e honeypots são explicados à parte. Uma vez na Spamhaus ou noutra lista, a saída passa por um pedido ao gestor, cujo passo a passo está descrito para remover uma blocklist. A triagem entre blocklists a monitorizar ou a ignorar indica quais merecem um alerta.

Causas a montante a tratar logo na recolha

As listas compradas concentram endereços inválidos e armadilhas: o primeiro envio produz aí um pico de hard bounces, e daí uma taxa de rejeição que ultrapassa todas as referências. O double opt-in elimina os erros de digitação e os emails falsos no registo. Um nome de domínio expirado ou sem registo MX produz um 5.1.2. As recusas 5.7.x de autenticação resolvem-se do lado do SPF, do DKIM e do DMARC, cuja versão DKIM2, em normalização no grupo de trabalho DKIM da IETF (datatracker.ietf.org, consultado em outubro de 2026), visa melhorar o valor das notificações de não entrega. Um conteúdo ou um assunto de email considerado suspeito desencadeia o mesmo tipo de recusa por política, sem que o endereço esteja em causa.

Perguntas frequentes sobre as rejeições

Devo eliminar um endereço depois de um único soft bounce?

Não. Um soft bounce isolado vem muitas vezes de uma caixa cheia ou de uma avaria passageira. Conte-o na sua regra: remoção à 3.ª rejeição consecutiva, em envios espaçados por pelo menos 14 dias. O contador volta a zero assim que uma mensagem for entregue.

Um hard bounce pode voltar a ser válido?

Sim, em casos raros: caixa recriada ou erro de digitação corrigido. A plataforma mantém o endereço em supressão e deixa de tentar. Retire-o dessa lista caso a caso, com confirmação do contacto.

Durante quanto tempo uma plataforma repete um soft bounce?

A RFC 5321 recomenda pelo menos 30 minutos entre duas tentativas e um prazo de desistência de pelo menos 4 a 5 dias. Cada plataforma aplica o seu próprio prazo: confirme-o na documentação antes de calcular uma taxa de rejeição final.

Verificar a lista antes do envio

Filtrar depois do envio equivale a enviar uma vez a cada endereço morto: o hard bounce já está contado na campanha quando a plataforma elimina o perfil. A verificação prévia retira estes endereços antes do primeiro envio. Um verificador controla o domínio e a existência da caixa de correio: exatamente o que o 5.1.1 e o 5.1.2 sancionam depois do facto. As ferramentas de verificação de emails são comparadas num guia. A manutenção regular de uma base de dados limpa evita que a lista volte a perder o que ganhou.

Antes da sua próxima campanha, passe uma amostra da lista pela ferramenta de verificação de listas de email da CaptainVerify e compare o resultado com a sua taxa de hard bounce atual.