Bounce Triage Simulator

Read a real SMTP bounce and decide what it is and what to do about it. Twelve genuine failures from Gmail, Outlook, Postfix and Proofpoint: hard bounces, soft bounces, content blocks, rate limits and spam complaints. Learn why the 4xx and 5xx class digit is a hint rather than the answer, which bounces to suppress permanently, which to retry, and what each mistake costs you in lost subscribers or lost sending reputation.

O que você vai aprender

Como ler um bounce SMTP: o código de resposta, o código de status estendido, e o texto de diagnóstico
A diferença entre hard bounce, soft bounce, bloqueio e reclamação de spam
Por que o dígito da classe 4xx e 5xx é uma dica, não a resposta
Quais bounces suprimir permanentemente e quais tentar de novo com backoff
Por que suprimir um soft bounce silenciosamente custa assinantes reais
Por que tentar de novo um hard bounce danifica sua reputação de envio toda vez
O que uma rejeição DMARC 5.7.26 e um limite de taxa 421 realmente estão dizendo

Este simulador interativo requer JavaScript para funcionar. Por favor, habilite o JavaScript no seu navegador para usar esta ferramenta.

// simulador

Bounce Triage Simulator

Bounce 1 de 120 corretas

Para jhon@exmaple.comvia Postfix

550 5.1.1 <jhon@exmaple.com>: Recipient address rejected: User unknown in virtual mailbox table

Que tipo de falha é essa?

O que você faz com isso?

Sobre este simulador de triagem de bounce

O que você vai aprender

Como ler um bounce SMTP real sem precisar pesquisar nada
Quais falhas são permanentes e quais vão entregar na próxima tentativa
Por que algumas respostas 5xx não têm nada a ver com o destinatário
O que cada erro custa: assinantes perdidos, ou reputação perdida
Onde as reclamações se encaixam, e por que pesam muito mais

Como ler um bounce

O código de resposta: 4xx é temporário, 5xx é permanente. Trate como uma dica, não um veredito
O status estendido: 5.1.1 caixa inexistente, 4.2.2 sobre a cota, 5.7.x política ou autenticação
O texto de diagnóstico: texto livre, e geralmente a parte que realmente conta o que aconteceu
O próprio endereço: uma fração surpreendente dos hard bounces são simples erros de digitação no cadastro

O erro que mais custa

Os dois erros de triagem são caros, em direções opostas. Suprima um soft bounce e você perde permanentemente um assinante real porque a caixa dele estava brevemente cheia. Tente de novo um hard bounce e você danifica sua reputação de envio toda vez, porque os provedores de caixa postal interpretam entregas repetidas a um endereço conhecidamente morto como sinal de que você trabalha com uma lista comprada. As respostas 5xx que na verdade são sobre conteúdo ou ritmo são onde a maioria erra: o 5 parece permanente, então acabam arquivadas junto com os endereços mortos e um problema de template corrigível vira uma lista encolhendo.

Fazendo isso automaticamente em produção

Ninguém faz triagem de bounces manualmente em volume. Em produção, seu provedor envia um webhook para cada bounce e reclamação, e seu handler classifica e escreve numa lista de supressão que o próximo envio checa antes de enfileirar qualquer coisa. A parte que vale a pena observar ao escolher um provedor é se você recebe a resposta real do servidor destinatário, como as deste simulador, ou só um rótulo de categoria. "Bounced" não é suficiente para agir: 550 5.1.1 user unknown e 550 5.7.1 content rejected são a mesma categoria e precisam de respostas opostas. SMTPfast mantém o diagnóstico completo junto da mensagem que o causou, e a supressão é aplicada no envio em vez de ser apenas informativa.

Vá mais fundo

O simulador de fluxo SMTP cobre o handshake de onde vêm esses códigos de bounce, de forma interativa.

Por que aprender assim?

Códigos de bounce só ficam memoráveis depois que você erra um.
Cada resposta aqui é uma que um servidor de e-mail real de fato envia, texto incluído.
Ler rápido é a diferença entre uma lista que continua saudável e um domínio de envio que silenciosamente para de alcançar caixas de entrada.