# Soft bounce vs hard bounce em email: Classificação SMTP URL: https://notificationharbor.com/pt/journal/soft-bounce-hard-bounce-email-guia-tecnico Type: blog Locale: pt Published: 2026-09-22 Updated: 2026-09-22 --- > Soft bounces e hard bounces dependem de um dígito SMTP: 4xx significa "tente novamente", 5xx significa "este endereço não existe". Classificar errado corrói reputação de domínio. Soft bounce vs hard bounce no email se reduzem a um dígito SMTP: 4xx significa "tente novamente mais tarde", 5xx significa "este endereço não existe mais". Envie para uma caixa de entrada cheia e receba um 4xx; infraestrutura retenta. Envie para endereço inexistente e o servidor retorna 5xx; lista de supressão atualiza no mesmo minuto. Classificar errado estraga reputação de domínio mais rápido que maioria dos erros operacionais. ## Códigos SMTP São a Única Classificação Que Importa Toda falha de entrega de email reporta código de resposta SMTP com três dígitos. O primeiro dígito é o que seu processador de bounce deveria usar para decidir. Códigos 4xx indicam condição transitória: servidor receptor aceitou conexão, avaliou mensagem, decidiu não conseguir entregar agora. Códigos 5xx indicam condição permanente: servidor receptor diz parar de tentar este endereço inteiramente. Esse branqueamento de lógica é de nível infraestrutura. Sua aplicação não precisa ler texto diagnóstico legível em humano para decidir se suprime; primeiro dígito faz essa chamada. Segundo e terceiro dígitos adicionam especificidade. Um 452 diz caixa de inbox cheia. Um 550 diz endereço não existe. Um 421 diz servidor está temporariamente indisponível. Maioria dos classificadores de bounce mapeiam esses sub-códigos para tipos de evento internos, mas split 4/5 permanece ramificação primária. Se seu pipeline trata todos os 4xx como retentáveis e todos os 5xx como terminais, cobrirá aproximadamente 95% dos casos de produção corretamente. ## O Que Causa um Soft Bounce -- e Por Quanto Tempo Retentar Cenários 4xx mais comuns que pipeline de email de produção encontra, em ordem aproximada de frequência: **Caixa de entrada cheia (452)**: Quota do destinatário está esgotada. Maioria dos ESPs retenta por 24 a 72 horas antes de converter para falha permanente. Este código é sobre-representado em caixas de inbox de consumidor; endereços B2B raramente o produzem isoladamente. **Greylisting (451)**: MTA receptor adia temporariamente remetentes desconhecidos como precaução contra spam. Retentativa 10 a 30 minutos depois geralmente funciona. Isto é parte normal do handshake de primeiro envio em domínio novo ou IP, não é sinal de problemas de qualidade de lista por si só. **Servidor temporariamente indisponível (421)**: Servidor remoto está fora do ar, rate-limiting, ou sobrecarregado. Retente com backoff exponencial. Maioria dos servidores se recupera em poucas horas; se persiste entre múltiplos dias para mesmo domínio, domínio em si pode estar em problema. **Mensagem muito grande (552/554 variante soft)**: Email excede limite de tamanho do servidor para esta caixa de inbox. Retentar sem reduzir tamanho do payload sempre falhará; rote para fila de tratamento separada e alerte remetente. ![Email envelope deflecting off a metallic surface, representing a soft bounce event](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/788605-image-inline1.webp) Janelas padrão de retry em produção: primeira retentativa após 5 minutos, depois 30 minutos, depois 2 horas, depois 6 horas, depois 24 horas. Após 5 dias sem entrega bem-sucedida, convenção SMTP é gerar relatório de não-entrega (NDR) e retornar mensagem ao remetente. Se seu ESP adere a esse intervalo de 5 dias ou corta mais curto vale a pena verificar em sua configuração. Uma métrica que vale a pena rastrear: proporção de soft bounces que se resolvem na primeira retentativa versus aqueles que precisam de mais de três tentativas. Lista saudável verá maioria dos códigos 452 e 421 se resolvendo em duas retentativas. Alta persistência entre muitos ciclos de retry é sinal que vale investigar no nível do segmento. ## Os Três Modos de Hard Bounce Que Seu Pipeline Verá Códigos 5xx não são monolíticos. Sub-códigos dizem coisas diferentes sobre o que fazer após suprimir. **Endereço inexistente (550/551)**: Domínio é válido mas parte local não mapeia para mailbox real. Este é hard bounce mais comum em produtos consumer-facing: typos de cadastro, contas abandonadas, endereços que eram válidos há seis meses depois foram deletados. Suprima imediatamente. Não há caminho de recuperação. **Domínio não existe ou não aceita mail (550/553/554)**: Lookup de MX record falhou, ou domínio explicitamente rejeita todo mail de entrada. Suprima no nível do domínio, não só endereço. Qualquer outro contato naquele domínio é igualmente inalcançável, e query no nível do domínio os encontrará mais rápido que esperar cada um bouncear individualmente. **Permanentemente bloqueado por política (550/5.7.1)**: Servidor receptor tem bloqueio em nível de política contra seu domínio de envio ou IP. Isto é mais raro mas operacionalmente mais sério porque pode afetar classe de endereços em toda organização. Referencie com seus logs de reputação de IP antes de decidir se deve suprimir só endereço disparador ou escalar para sua equipe de deliverability. ![Abstract network routing paths diverging, one path connected, one returning as a bounce](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/6b5951-image-inline2.webp) Uma nuance que causa bugs em produção: alguns MTAs retornam códigos 4xx para o que são efetivamente condições permanentes. Domínio que expirou e foi estacionado pode retornar 450 em vez de 550 por semanas enquanto registrador lentamente destrói MX record. Seu pipeline deveria tratar qualquer endereço retornando 4xx em cinco tentativas consecutivas ao longo de duas semanas como candidato para status de hard-bounce, independente do prefixo SMTP. ## Quando Soft Bounces Viram Funcionalmente Permanentes Limite de categoria limpo entre 4xx e 5xx não segura sob condições de produção. Três padrões deveriam disparar mesma lógica de supressão que hard bounce mesmo quando código permanece na faixa 4xx. Primeiro: **repeated full-mailbox bounces sem nenhum engajamento anterior**. Se endereço nunca abriu, nunca clicou, e bounceou 452 cinco vezes em 30 dias passados, mailbox é quase certamente abandonada. Continuar tentando entrega aumenta taxa de bounce sem nenhuma chance realista de ativação. Trate como hard. Segundo: **persistent greylisting sem resolução**. Greylisting se resolve em retry para remetentes legítimos. Se mesmo endereço consistentemente adia além de 48 horas, você está ou em blocklist ou enviando para spam trap. Nenhum dos casos justifica tentativas continuadas; ciclos de retry compõem dano de reputação. Terceiro: **códigos 4xx que aparecem só para seu domínio de envio**. Se outros remetentes alcançam mesmo endereço com sucesso mas seus envios consistentemente são adiados, problema é reputação do remetente, não estado da mailbox. Retentar mais agressivamente piora. Regra operacional para codificar: após três soft bounces sem resolução, mova endereço para estado de supressão probatória. Pare de enviar emails de lifecycle para ele. Mantenha elegível para email transacional crítico (reset de senha, alerta de faturamento) até confirmar que é verdadeiramente inalcançável. ## Lógica de Supressão: Remove vs. Park vs. Retry Nem todo evento de bounce justifica remoção completa de seu armazenamento de contato. Chamada correta depende do tipo de bounce e histórico de engajamento anterior do contato. **5xx hard bounce (qualquer engajamento anterior)** -- Supressão imediata, nenhuma retentativa. **4xx, primeira ocorrência (engajamento ativo)** -- Retente per schedule, sem supressão. **4xx, três ou mais ocorrências (sem engajamento anterior)** -- Supressão probatória. **4xx, cinco ou mais ocorrências (qualquer engajamento)** -- Trate como hard bounce. **4xx full-mailbox só (alto LTV ou transacional)** -- Retente semanalmente por 30 dias. Distinção entre "remove" e "park" importa na prática. Endereço removido cai completamente de seu armazenamento de contato. Endereço estacionado permanece com status suprimido: ainda pode consultá-lo, superficiá-lo em dashboard de saúde, reativá-lo se contato optar novamente através de novo envio de formulário. Para fluxos transacionais de alto valor, estacionar é chamada correta. Para listas de cold outreach, remoção é mais limpa. Ponto operacional que vale a pena reforçar em código: qualquer ação que tome deveria ser logada com código SMTP e timestamp como razão de supressão. Eventos de supressão sem razões explícitas são quase impossíveis de auditar depois quando quer entender por que coorte de endereços desapareceu entre duas campanhas. ## Limiares de Taxa de Bounce Que Mudam Comportamento de ISP Figura de taxa de bounce de 2% que circula como benchmark de indústria é um piso, não uma meta. Limiares reais que importam são mais granulares. Gmail e Outlook reportam taxa de spam no nível de remetente através de Google Postmaster Tools e Microsoft SNDS respectivamente. Aqueles dashboards não expõem diretamente sua taxa de bounce, mas dois sinais correlacionam fortemente. Taxa de bounce sustentada acima de 2% quase sempre precede aumento de taxa de colocação em spam visível naquelas ferramentas, tipicamente com lag de 3 a 5 dias. Limiares práticos para monitorar por domínio de envio: - **Abaixo de 0.5%**: Faixa normal. Nenhuma ação corretiva requerida. - **0.5 a 1.5%**: Monitore de perto. Investigue razões de bounce por segmento; normalmente alguns poucos cohorts com qualidade de dados degradada. - **1.5 a 2.5%**: Pause campanha e investigue antes de retomar. Maioria dos ESPs começam rate-limiting automatizado nesta faixa. - **Acima de 2.5%**: Pare envio. Limpe segmentos afetados antes de reiniciar. Neste nível, alguns ISPs já começaram filtrar mensagens para spam ou adiar conexões no gateway. ![Engineer monitoring email delivery metrics on multiple screens in a server operations center](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/bc5931-image-inline3.webp) Detalhe operacional que é frequentemente ignorado: taxas de bounce são calculadas contra tentativas de entrega, não tamanho total da lista. Se segmenta pesadamente e envia só para subscribers engajados, sua contagem absoluta de bounce cai mas taxa calculada pode não mudar proporcionalmente. Rastreie tanto contagem absoluta quanto taxa por envio. Picos em contagem absoluta são frequentemente sinal de aviso mais precoce, especialmente após import de lista ou campanha de re-engajamento. ## Lendo Sinais de Bounce em Seu Delivery Trace Eventos de bounce deveriam aparecer em seu delivery trace com mesma fidelidade de opens e clicks. Se não aparecem, seu setup de observabilidade tem brecha. No mínimo, cada evento de bounce deveria registrar: timestamp, código de resposta SMTP, mensagem diagnóstica completa do servidor remoto, IP de envio, domínio receptor, e ID do contato. Domínio receptor é frequentemente omitido e frequentemente necessário. Quando domínio começa retornando 550 5.7.1 entre múltiplos contatos, quer detectar esse padrão no nível de domínio antes que danifique sua pontuação de reputação no domínio completo de envio. Com aquele dado modelado corretamente, três views cobrem maioria das necessidades de monitoramento de bounce: taxa de bounce diária por domínio de envio, taxa de conversão soft-para-hard por cohort (quantos dos eventos 4xx de hoje ainda estarão bounceando em 10 dias), e tabela de frequência de bounce no nível de domínio para pegar supressões organizacionais antes que se compunham. Objetivo não é taxa de bounce zero. Isso não é alcançável em lista que cresce. Objetivo é pipeline de processamento de bounce que classifica com precisão na primeira resposta SMTP, suprime no limiar correto, e superficia sinais que indicam problema sistêmico antes que escale para incidente de entrega. ## FAQ ### O que é um soft bounce em email? Um soft bounce é uma falha temporária de entrega indicada por código SMTP 4xx. Significa que o servidor receptor aceitou a tentativa de conexão mas não conseguiu entregar por motivo temporário (caixa cheia, servidor indisponível, greylisting). O email deve ser retentado. ### O que é um hard bounce em email? Um hard bounce é uma falha permanente de entrega indicada por código SMTP 5xx. Significa que o servidor receptor rejeitou a mensagem por razão permanente (endereço inexistente, domínio inválido, bloqueio de política). O endereço deve ser suprimido imediatamente. ### Por quanto tempo devo retentar um soft bounce? Padrão de produção: primeiras retentativas em 5 minutos, 30 minutos, 2 horas, 6 horas, 24 horas. Após 5 dias sem sucesso, gere um NDR (non-delivery report). A maioria dos soft bounces se resolvem nas primeiras duas retentativas. Se persistir além de 48 horas, trate como supressão probatória. ### Qual taxa de bounce é considerada normal? Abaixo de 0.5% é normal. De 0.5% a 1.5%, monitore por segmento. De 1.5% a 2.5%, pause a campanha e investigue. Acima de 2.5%, pare o envio e limpe a lista. A taxa de bounce é calculada contra tentativas, não tamanho da lista. ### Como diferenciar entre endereço abandonado (soft bounce persistente) vs. verdadeiro soft bounce? Se um endereço retornar 452 (caixa cheia) cinco vezes em 30 dias sem nenhum engajamento anterior (nunca abriu, nunca clicou), trate como hard bounce. A mailbox está provavelmente abandonada. Continuar tentando degrada reputação sem chance realista de ativação. ### Devo suprimir no nível de endereço ou domínio para hard bounces 5xx? Para 550/551 (endereço inexistente), suprima o endereço. Para 550/553/554 (domínio inválido), suprima o domínio inteiro -- qualquer outro contato naquele domínio é igualmente inalcançável. Para 550/5.7.1 (bloqueio de política), referencie com logs de reputação antes de decidir se é só o endereço ou um problema de IP/domínio.