Taxa de bounce de email: como medir e o que corrigir

A taxa de bounce de email é a parcela das mensagens enviadas que o servidor do destinatário recusou, dividida pelo total de envios. Em uma lista saudável, mantenha os hard bounces abaixo de 1%, comece a investigar em 2% e trate 5% como incidente. A maioria das equipes lê um único número no painel e não percebe que o denominador, o tipo de bounce e a janela de tempo mudam a resposta.

O resto deste texto trata de acertar o número primeiro e, depois, decidir o que fazer com ele.

A fórmula é simples. O denominador é onde as equipes divergem.

A taxa de bounce é igual a mensagens devolvidas dividido por mensagens enviadas, vezes 100. Alguns ESPs dividem pelas mensagens entregues, o que faz o número parecer maior, já que as entregues já excluem os bounces. Confirme qual dos dois o seu provedor usa antes de comparar com qualquer benchmark.

O Amazon SES, por exemplo, calcula a taxa apenas com hard bounces, medida sobre o que foi enviado pela conta. Esse detalhe importa: um painel que mistura soft e hard bounces mostra um número mais alto do que aquele que o provedor usa para avaliar você.

Escolha uma definição e registre-a junto da métrica, no título do painel se for preciso. Nós usamos hard bounces sobre envios, por domínio de envio, em janelas de 24 horas e de 7 dias. Se duas pessoas da equipe citam números diferentes para a mesma semana, compare o denominador antes de qualquer outra coisa.

Hard, soft e block bounces são três sinais diferentes

Um hard bounce é uma falha permanente. O endereço não existe, o domínio não resolve ou a caixa foi desativada. O SMTP informa isso com um código de status aprimorado 5.x.x, definido na RFC 3463.

Um soft bounce é uma falha temporária: caixa cheia, servidor fora do ar, mensagem grande demais. Ele volta com códigos 4.x.x, e um remetente bem configurado tenta de novo. Se quiser a classificação completa, já cobrimos o mapeamento dos códigos SMTP no nosso guia anterior sobre soft bounce e hard bounce.

A terceira categoria é a que os painéis escondem. Um block é uma rejeição 5.x.x que não diz nada sobre o endereço e tudo sobre você: um IP em blocklist, uma falha de autenticação, um filtro de conteúdo ou de reputação. Contar um block como hard bounce faz a sua lista parecer suja quando o problema é a configuração de envio.

Desconfie de qualquer relatório com uma única linha de "bounce". Separe em três séries, senão você vai limpar uma lista que nunca foi o problema.

Qual é uma boa taxa de bounce em 2026?

Não existe um número oficial publicado, e isso vale saber antes de citar um. Gmail e Yahoo publicam limites para reclamações de spam, não para bounces. O Google pede que remetentes em volume mantenham a taxa de spam reportada no Postmaster Tools abaixo de 0,10% e nunca cheguem a 0,30%, segundo o FAQ das diretrizes para remetentes.

Para bounces, os números de referência vêm dos ESPs e da prática. Os limites abaixo são os níveis de alerta que usamos, não garantias de nenhum provedor de caixa de entrada.

Taxa de hard bounce por domínio em 24 horas, e como tratamos:

• Abaixo de 0,5%: normal para uma lista engajada e verificada.

• De 0,5% a 1%: observe e confira a origem dos novos endereços.

• De 1% a 2%: investigue e pause o segmento com a taxa mais alta.

• De 2% a 5%: pare os envios em massa desse fluxo e encontre a importação ou o formulário por trás dele.

• Acima de 5%: incidente. O Amazon SES coloca contas nesse nível em análise.

A última linha é um limite documentado. Na documentação do painel de reputação, a Amazon SES afirma que uma conta com taxa de 5% ou mais é colocada em análise, e que o envio pode ser pausado se a taxa continuar acima de 10%. Outros provedores usam números e formulações diferentes, então leia os termos do seu contrato.

Segmente primeiro: uma taxa agregada esconde o fluxo que está falhando

Uma taxa geral de 0,8% pode conter um fluxo transacional a 0,1% e uma importação de reengajamento a 6%. A média parece aceitável, e o segundo fluxo está, em silêncio, prejudicando o domínio de envio.

Calcule a taxa por fluxo, por origem e por domínio de destinatário. Quatro cortes pegam a maioria dos problemas:

• Por fluxo. Transacional, lifecycle e campanhas em massa nunca deveriam compartilhar um único número.

• Por origem de cadastro. Formulários, cadastros via API, importações em CSV e listas de parceiros têm qualidades de endereço muito diferentes.

• Por domínio de destinatário. Um pico em um provedor costuma indicar uma política de rejeição, não uma lista suja.

• Por idade do endereço. Endereços coletados há mais de 12 meses dão bounce com mais frequência do que os recentes.

Isso não é um detalhe de relatório. É a diferença entre corrigir um bug de validação em um formulário em uma hora e limpar uma lista saudável em pânico.

Um quinto corte vale a pena quando os outros já estiverem no lugar: por IP ou domínio de envio. Se você usa um IP dedicado para transacional e um pool compartilhado para campanhas, um pico em um deles indica onde olhar antes de abrir qualquer log.

Leia os eventos de bounce do provedor sem perder dados

Todo ESP sério expõe bounces como eventos: um webhook, um tópico de notificação ou uma API de eventos. Trate esse fluxo como fonte da verdade e grave-o no seu próprio armazenamento, porque painéis agregam e perdem o detalhe de que você vai precisar depois.

Persista estes campos para cada evento: id da mensagem, destinatário, tipo de bounce, código de status aprimorado, texto de diagnóstico e timestamp. Com esses seis, você responde quase qualquer pergunta que surge em um postmortem.

{
  "event": "bounce",
  "message_id": "msg_01H9",
  "recipient": "user@example.com",
  "bounce_type": "permanent",
  "status": "5.1.1",
  "diagnostic": "550 5.1.1 user unknown",
  "stream": "lifecycle",
  "ts": "2026-11-02T09:14:03Z"
}

Torne o handler idempotente, usando como chave o id do evento no provedor somado ao id da mensagem. Provedores reenviam webhooks, e um evento de hard bounce duplicado que incrementa um contador duas vezes distorce a sua taxa e pode suprimir um endereço que está em ordem.

Postmark e Resend separam os tipos de bounce nos eventos e permitem filtrar por stream de mensagens, o que torna barata a separação por fluxo descrita acima.

A regra de supressão que faz a maior parte do trabalho

O controle de maior alavancagem é a supressão automática. Depois de um hard bounce, pare de enviar para aquele endereço, de forma permanente, na camada da aplicação, e não apenas confiando na lista do provedor.

A maioria dos ESPs suprime hard bounces por você. A lacuna aparece quando você troca de provedor, roda dois em paralelo ou envia de um sistema que nunca consulta a lista de supressão. Uma tabela sua, indexada por endereço normalizado, fecha essa lacuna.

Para soft bounces, use um contador em vez de um evento isolado. Nosso padrão é suprimir após três soft bounces consecutivos, em pelo menos sete dias. Uma caixa cheia há uma semana está, para fins de lifecycle, perdida.

Não apague da sua tabela de usuários os endereços que deram bounce. Marque-os com o código de status e a data. Uma linha apagada não diz que o mesmo endereço deu bounce duas vezes no trimestre passado, e você precisa desse registro para não reimportar o mesmo endereço no próximo CSV, que é a forma mais comum de uma lista "limpa" voltar a ficar suja.

Por que a taxa sobe de repente: as causas mais comuns, em ordem

Quando a taxa muda, procure a causa nesta ordem. As três primeiras explicam a maioria dos picos.

1. Uma importação nova. Um CSV de um evento, de um parceiro ou de uma exportação antiga do CRM. Confira a taxa de bounce por origem antes de qualquer outra coisa.

2. Um formulário de cadastro sem validação. Erros de digitação como gmial.com e domínios descartáveis. Uma checagem de sintaxe e MX no envio remove a maioria, e um e-mail de confirmação elimina o resto antes que ele conte como envio em um fluxo lifecycle.

3. Uma mudança de envio. Um IP novo, um domínio novo ou um warmup que acelerou demais, o que vira bloqueios em vez de hard bounces.

4. Uma quebra de autenticação. Alinhamento de SPF, DKIM ou DMARC falhando depois de uma mudança de DNS.

5. Uma política de rejeição do provedor. Um domínio de destinatário apertou os filtros. Sua taxa sobe só naquele domínio.

O diagnóstico é a distribuição dos códigos de status, agrupada por fluxo e por domínio de destinatário, na mesma janela do pico. Uma alta em 5.1.1 (usuário desconhecido) aponta para a lista. Uma alta em 5.7.x aponta para política, autenticação ou reputação. Essas causas pedem correções opostas, e por isso você guarda o código.

O que alertaríamos

Alertar sobre a média diária é lento demais. Uma importação ruim pode enviar 40 mil mensagens em uma hora. Alerte sobre uma janela deslizante.

• Taxa de hard bounce acima de 1% nos últimos 1.000 envios de qualquer fluxo.

• Qualquer domínio de destinatário acima de 5% em pelo menos 200 envios em uma hora.

• Uma contagem de bloqueios 5.7.x que supere claramente a sua linha de base normal.

Ligue os dois primeiros a uma pausa do fluxo responsável, não a uma página para uma pessoa. A pessoa pode investigar depois. A pausa é o que protege sua reputação nos próximos dez minutos.

Exporte a taxa para o monitoramento que você já usa, seja Grafana, Datadog ou algo caseiro, e mantenha o rótulo do fluxo nas séries para que a separação sobreviva à exportação.

Para reportar para cima, use a taxa de hard bounce por fluxo em uma janela de 7 dias, junto com a contagem de bloqueios. Deixe os soft bounces na visão de engenharia, onde são úteis, e fora da visão executiva, onde geram confusão. Nunca reporte somente o número geral da conta, porque ele se move por motivos que ninguém na sala consegue explicar.

Se alguém pedir um único número, dê a taxa de hard bounce do fluxo transacional. É onde uma falha custa um reset de senha ou uma fatura, e é a leitura mais limpa de que a sua infraestrutura está saudável.

O próximo passo concreto é pequeno: extraia os eventos de bounce dos últimos 30 dias, agrupe por fluxo e código de status, e veja qual linha você não esperava.