Taxonomia de bounces de e-mail: hard, soft, blocked, invalid

O que são bounces e por que importam

Um bounce acontece quando um e-mail não pode ser entregue e o servidor de e-mail do destinatário envia uma mensagem de falha de volta. Em termos simples: você tentou enviar, mas o outro lado não pôde aceitar.

Bounces são normais em cold email e campanhas outbound. O que importa é o padrão. Alguns bounces em uma lista nova são esperados. Repetir as mesmas falhas, ou ignorá-las, é o que causa problemas.

Bounces vs outras respostas “negativas”

Nem toda resposta que parece ruim é um bounce. Separá-las cedo ajuda a tomar a ação certa.

• Bounce: uma falha de entrega retornada por um servidor de e-mail (seu e-mail não chegou).
• Resposta automática: o e-mail chegou, mas o destinatário está ausente ou um sistema respondeu.
• Reclamação de spam: o e-mail chegou e o destinatário o reportou como spam.
• Cancelamento (unsubscribe): o e-mail chegou e o destinatário pediu para parar.

Se você misturar tudo, seus relatórios ficam enganosos. Por exemplo, tratar respostas de ausência como “endereço ruim” pode fazer você excluir bons leads.

Por que bounces repetidos te prejudicam

A entregabilidade depende em parte de confiança. Quando provedores veem que você repetidamente envia para endereços que não podem receber mensagens, sinaliza baixa qualidade de lista ou práticas de envio descuidadas. Isso pode reduzir a colocação na caixa de entrada para e-mails que poderiam ter sido entregues.

Bounces repetidos também distorcem métricas de campanha. Suas taxas de abertura e resposta ficam piores porque você está contando e-mails que nunca tiveram chance.

Um cenário simples: você importa 2.000 prospects e 200 são endereços mortos. Se continuar tentando com eles em várias sequências, desperdiça capacidade diária de envio e alimenta os provedores com as mesmas falhas repetidas.

Por isso uma taxonomia de bounces é útil. Quando você rotula falhas de forma consistente (hard, soft, blocked, invalid), pode automatizar a ação correta: suprimir permanentemente, tentar de novo mais tarde, pausar envio ou sinalizar a origem da lista.

Uma taxonomia simples de bounces para seguir

Um tratamento previsível de bounces exige um conjunto compartilhado de rótulos. Esse é o objetivo de uma taxonomia: toda a equipe (e toda ferramenta que você usa) trata a mesma falha da mesma forma.

Mensagens de bounce são confusas. Um provedor diz “user unknown”, outro diz “mailbox unavailable” e um terceiro retorna apenas um código SMTP numérico. Algumas ferramentas também renomeiam o mesmo problema (por exemplo, “rejected” vs “blocked”). Uma taxonomia simples transforma esse ruído em alguns buckets que você pode automatizar.

Quatro rótulos (e o que geralmente significam)

Use estes rótulos de forma consistente entre campanhas e caixas:

• Hard: falha permanente. O endereço não existe, o domínio está inativo ou o servidor do destinatário diz que nunca aceitará e-mail para aquela caixa.
• Soft: falha temporária. A caixa pode estar cheia, o servidor está fora, ou o provedor pede para tentar de novo mais tarde.
• Blocked: recusa baseada em política. O provedor está rejeitando ativamente (reputação, autenticação, limites de taxa ou regras de conteúdo), mesmo que o endereço seja real.
• Invalid: problema de qualidade de dados que você poderia ter detectado antes (erros de digitação, endereços malformados, domínio ausente ou um domínio que não recebe e-mail).

A diferença-chave é a intenção: hard e invalid são “não tentar novamente”, soft é “tentar mais tarde” e blocked é “parar e corrigir as condições de envio”.

Por que consistência importa mais que a palavra perfeita

Sem rótulos consistentes, a automação fica arriscada. Uma ferramenta pode tratar “550 5.1.1” como hard enquanto outra chama de “invalid”. Se alguém marcar manualmente como “soft” para manter o lead, você acaba reencaminhando endereços que nunca vão funcionar, o que prejudica a entregabilidade.

Uma regra prática é padronizar nos quatro rótulos e guardar o texto e os códigos brutos do bounce como evidência. Se você vir “message rejected due to policy” em muitos destinatários de um mesmo provedor, categorize como blocked mesmo que a redação varie.

Hard bounces: falhas permanentes e a resposta correta

Hard bounces são o sinal mais claro de que um endereço de e-mail não pode receber mensagens. Na sua taxonomia, eles pertencem ao bucket de “falha permanente”, o que significa que reenviar geralmente é desperdício e pode prejudicar a entregabilidade.

A maioria dos hard bounces indica uma de duas coisas: a caixa não existe (“user unknown”) ou o domínio não está configurado para receber e-mails (domínio não encontrado, sem mail exchanger, ou domínio que não existe mais). Frequentemente você verá respostas SMTP na faixa 5xx, que os provedores usam para falhas permanentes.

Como hard bounces normalmente aparecem

Padrões comuns incluem:

• Erros do tipo 550 / 551 / 553
• “user unknown” ou “no such user”
• “domain not found” ou “host unknown”
• “no MX records”

Ao receber um hard bounce verdadeiro, a resposta é simples: suprima o endereço imediatamente e não continue tentando em sequências futuras. Bater repetidamente em caixas inexistentes é uma forma rápida de prejudicar a reputação do remetente.

Exemplo: você envia para [email protected] e recebe “550 5.1.1 user unknown.” O endereço está digitado errado, desatualizado ou nunca existiu. Marque como não entregue e pare todos os follow-ups.

Prevenindo hard bounces

Hard bounces são geralmente um problema de qualidade de lista. Você pode reduzi-los verificando e-mails antes de enviar (especialmente leads recém-obtidos), observando erros óbvios ou padrões estranhos (como pontos duplos) e mantendo uma lista de supressão compartilhada entre campanhas.

Um aviso: hard bounces podem ser classificados incorretamente em casos raros. Um problema do provedor ou um gateway agressivo pode retornar 5xx para algo temporário. Se o domínio for conhecido e isso aconteceu apenas uma vez, coloque em quarentena para revisão manual em vez de excluir automaticamente.

Soft bounces: falhas temporárias e reenvios inteligentes

Soft bounces são falhas temporárias de entrega. O endereço pode ser real e a caixa pode aceitar e-mails depois, mas algo atrapalhou agora. Esses são os casos em que reenvios inteligentes podem recuperar envios bons.

Causas típicas: caixa cheia, quedas curtas do servidor ou o provedor pedindo para reduzir o ritmo. Muitos provedores usam greylisting e limitação de taxa, que rejeitam a primeira tentativa com uma mensagem no estilo “tente novamente mais tarde”.

O indício técnico mais comum é uma resposta SMTP 4xx (falha temporária). Frequentemente você verá “temporarily unavailable”, “resources temporarily exhausted”, “mailbox full” ou “rate limit exceeded”.

Uma política prática de reenvio te mantém persistente sem ser barulhento:

• Reenvie com backoff (por exemplo: 30 minutos, 2 horas, 12 horas, 24 horas).
• Limite o número de tentativas (3 a 5 tentativas costuma ser suficiente para outreach frio).
• Espalhe as tentativas por horários diferentes para evitar ser novamente throttled.

Se continuar a bounces após o limite, pare e suprima o endereço (trate como efetivamente não entregável). E se muitos soft bounces ocorrerem de uma vez, pause a campanha e investigue volume e reputação.

Exemplo: você envia 500 e-mails em uma janela curta e 80 retornam “4.7.0 rate limited.” Isso raramente é uma lista ruim. É um sinal de que você está enviando rápido demais para aquele provedor (ou para uma caixa nova). Diminua a velocidade, espaçe os envios e reenvie depois em vez de insistir no mesmo domínio.

Quando um soft bounce vira “permanente”? Se o mesmo endereço soft-bouncear por vários dias ou depois do seu limite de tentativas, trate-o como uma falha permanente no seu sistema e suprima.

Blocked bounces: quando um provedor recusa seu e-mail

Um blocked bounce não é uma falha de entrega normal. É uma rejeição pelo provedor receptor porque ele não quer aceitar sua mensagem daquele remetente agora. Tratar isso como soft bounce leva a reenvios inúteis e mais danos.

Blocked normalmente aponta para uma de três questões: política do provedor (limites de taxa ou filtro estrito), reputação do remetente (histórico do domínio ou IP) ou sinal de conteúdo (texto com aparência de spam, links arriscados, formatação suspeita). Frequentemente você verá frases como “blocked”, “policy rejection”, “access denied” ou “message refused.”

A diferença prática é simples:

• Um soft bounce costuma ser temporário do lado do destinatário (servidor ocupado, caixa cheia).
• Um blocked bounce é um “não” deliberado do provedor.

O que fazer a seguir (ações para automatizar)

Comece estancando o problema, depois afine o padrão.

Pausa o envio para o provedor afetado (por exemplo, todos os endereços de um domínio) por um período de resfriamento. Procure agrupamentos: é um domínio receptor, uma campanha, um domínio remetente novo ou uma variante de mensagem? Retome gradualmente, não tudo de uma vez, e acompanhe o próximo lote de perto.

Ajuda também ter um limiar de escalonamento claro (por exemplo, quando bloqueios ultrapassam 2–5% das tentativas para um provedor em uma janela curta), para que alguém revise autenticação, sinais de reputação, volume e mudanças recentes no copy.

Exemplo: você envia 500 e 80 para um único provedor retornam “policy rejection.” Repetir tentativas a cada poucos minutos normalmente aumenta os bloqueios. Pausar aquele provedor, checar mudanças recentes no copy e diminuir a taxa de envio é o caminho mais rápido de volta.

Como prevenir blocked bounces

A prevenção é, na maior parte, seguir o básico de forma consistente:

• Mantenha SPF, DKIM e DMARC configurados corretamente.
• Faça warm-up de novas caixas e aumente o volume devagar.
• Mantenha o copy simples e específico; evite formatação pesada.
• Distribua volume por domínios e caixas configuradas corretamente em vez de sobrecarregar uma só.

Invalid bounces: problemas de qualidade de dados que você pode detectar cedo

Invalid bounces são o tipo mais prevenível. Geralmente significam que o endereço não é uma caixa válida ou o domínio não está configurado para receber e-mail.

A maioria dos casos inválidos vem de problemas simples de dados: formatação errada, erros de digitação ou valores não e-mail copiados de formulários e planilhas. Você não “fica com sorte” ao reenviar. Só cria falhas desnecessárias.

Padrões comuns incluem estrutura ausente (como namecompany.com, name@, @company.com), caracteres extras (espaços, vírgulas, pontos duplos como [email protected]), erros no domínio (gmal.com, hotmial.com), TLDs errados (company.cmo, company.con) ou domínios sem registros de e-mail.

O que fazer em seguida é simples: não reenvie. Suprima o endereço imediatamente e corrija a origem dos dados. Se veio de um formulário, endureça a validação. Se veio de um provedor ou API de enriquecimento, sinalize e solicite o e-mail correto.

A prevenção funciona melhor em duas camadas: validar na importação (para que endereços ruins não entrem na sua lista) e validar imediatamente antes do envio (porque listas mudam e pessoas colam novos leads na última hora). Mesmo checagens básicas como “exatamente um @” e “sem espaços” pegam uma quantidade surpreendente de erros.

Contas de função (como info@, sales@, support@) não são inválidas por definição, mas podem se comportar de forma imprevisível. Trate-as com uma regra separada: mantenha fora da sequência principal por padrão ou envie por uma campanha mais lenta e cautelosa.

Como categorizar bounces passo a passo

Um bom tratamento de bounces começa com uma regra: mantenha a evidência original. Se você só armazena um rótulo como “soft bounce”, não consegue melhorar regras depois.

Um fluxo prático em 5 passos

1. Salve o payload bruto do bounce: o código de status SMTP (4xx/5xx), qualquer status aprimorado (como 5.1.1) e o texto completo. Armazene com o message ID, domínio remetente, caixa e timestamp.

2. Tome uma decisão inicial usando a família de códigos. Como base, 5xx normalmente significa falha permanente e 4xx normalmente significa temporária.

3. Detecte “blocked” antes de decidir soft vs hard. Procure sinais como “blocked”, “denied”, “policy”, “spam”, “reputation”, “blacklist” e códigos como 5.7.1. Se vir esses sinais, trate como blocked mesmo que seja 5xx.

4. Normalize a redação do provedor em seus quatro rótulos (hard, soft, blocked, invalid). Provedores dizem a mesma coisa de maneiras diferentes, então mapeie variações para um rótulo único.

Um modelo mental simples:

• Invalid: endereço ou domínio não é real (sintaxe falha, “user unknown”, “domain not found”).
• Hard: formato ok, mas a entrega nunca vai funcionar para esse destinatário (por exemplo, conta desativada).
• Soft: problema temporário que você pode tentar de novo (por exemplo, mailbox full, deferred).
• Blocked: provedor recusa por regras ou reputação (por exemplo, “rejected for policy reasons”).

5. Registre a decisão e a regra que a gerou (por exemplo, matched_keyword=policy ou matched_code=5.1.1). Quando uma regra estiver errada, você pode corrigi-la e reprocessar eventos antigos.

Exemplos concretos: “550 5.7.1 Message rejected for policy reasons” é blocked (não hard). “450 4.2.2 Mailbox full” é soft e deve ser reenviado.

Ações automáticas: suprimir, reenviar, pausar e escalar

Quando você tem uma taxonomia consistente, os melhores resultados vêm de transformar o próximo passo em automático. O objetivo é simples: parar de repetir erros, proteger a entregabilidade e tirar a equipe da limpeza manual de caixas.

Suprimir: parar de enviar para endereços que não funcionarão

Trate hard bounces e endereços inválidos como eventos de supressão imediata. Não há benefício em “tentar mais tarde” quando a falha é permanente.

Uma abordagem de supressão limpa é:

• Hard bounce ou endereço inválido: suprimir imediatamente (sem reenvios).
• Suprimir no nível do endereço, não apenas na campanha.
• Mantenha as razões de supressão separadas (hard, invalid, complaint, unsubscribe) para que os relatórios continuem informativos.

Reenviar: dar uma segunda chance limitada aos soft bounces

Soft bounces muitas vezes são temporários, então reenvios podem funcionar, mas somente com limites rígidos.

Mantenha previsibilidade: use um cronograma com backoff (por exemplo, 4 horas, depois 24 horas, depois 72 horas), limite de tentativas (comum: 2–3) e pare cedo se o bounce virar hard/invalid.

Contar tentativas é importante. Sem isso, “temporário” vira tentativas infinitas.

Pausar e escalar: blocked bounces precisam de resposta mais ampla

Blocked bounces normalmente significam que um provedor está recusando seus e-mails por política, reputação ou limites. Isso não é problema do lead; é problema do envio.

A automação mais segura é pausar o envio para o segmento afetado, diminuir volume e encaminhar o caso para investigação com o texto do bounce, provedor e volume recente. Se a taxa de bloqueios subir, aplique um período de resfriamento.

Também mantenha histórico de bounces por endereço (data de primeira ocorrência, data da última, contagem de tentativas). Esse registro pequeno transforma o tratamento de bounces de tentativa e erro em um sistema.

Erros comuns no tratamento de bounces (e o que fazer em vez disso)

A maioria dos problemas de bounce não vem de um e-mail ruim. Vem de repetir o mesmo pequeno erro em milhares de envios. Uma taxonomia só ajuda se suas ações corresponderem ao rótulo sempre.

Padrões de erro que silenciosamente arruinam a entregabilidade

Tratar uma falha permanente como temporária é o erro clássico. Se você continua reenviando um hard bounce porque “talvez funcione”, transforma um endereço ruim em sinais repetidos de lista suja. A correção é simples: suprimir imediatamente e enviar o lead para limpeza de dados.

Interpretar “blocked” como “soft” é outro erro comum. Quando um provedor recusa seu e-mail, insistir em reenvios só piora. A correção é pausar ou desacelerar envios para aquele domínio e investigar a razão do bloqueio.

Mudar rótulos no meio do caminho também causa danos silenciosos. Se uma semana “mailbox full” é soft e na outra é blocked, os relatórios perdem sentido. Mantenha definições estáveis e só altere regras deliberadamente (e então reprocese dados históricos se necessário).

Por fim, não olhe só para a taxa total de bounces. 2% no total pode esconder um domínio de envio em 8% ou um domínio receptor rejeitando a maioria das mensagens. Monitore taxas por domínio remetente e por domínio destinatário para agir no nível correto.

Checklist rápido e próximos passos

Trate o manejo de bounces como rotina, não como correção única. Uma taxonomia só é útil se virar ações repetíveis antes, durante e depois de cada envio.

Antes do lançamento, confirme SPF, DKIM e DMARC, garanta que o warm-up está ativo e que seu plano de volume é realista para os primeiros 7 a 14 dias. Faça uma checagem de dados para remover formatos inválidos, erros óbvios (como gamil.com), contas de função que você não quer e duplicatas.

Durante o envio, fique atento a picos de “blocked” ou “policy”, mantenha o volume diário estável e limite reenvios para que um soft bounce não vire ruído repetido. Depois do envio, suprima hard bounces e endereços inválidos imediatamente e pare de enviar para qualquer endereço que bloqueie ou reclame repetidamente.

Semanalmente, agrupe bounces pelos principais motivos (bloqueios de provedores, caixa cheia, usuário desconhecido, domínio não encontrado) e ajuste uma coisa por vez: copy, fonte da lista, volume ou saúde da caixa.

Se quiser centralizar essas regras para que sejam aplicadas consistentemente entre domínios e campanhas, uma plataforma unificada como LeadTrain (leadtrain.app) pode ajudar ao combinar domínios, caixas, warm-up, sequências e classificação automatizada em um só lugar. O ganho é menos bounces preveníveis, listas mais limpas e performance de outreach mais estável.