Recuperação · Tratamento de bounces
Guia de tratamento de bounces de email
Bounces fazem parte do email transacional. A forma como você classifica, suprime e recupera esses eventos define se sua reputação de envio resiste a operações de alto volume.
UI representativa do produto — dados ilustrativos, não métricas reais de clientes.
Plano de controle
Como a Sendarix classifica, suprime e roteia sinais de bounce
Eventos de bounce alimentam decisões de routing e supressão por tenant, não apenas uma blocklist estática. Hard bounces são suprimidos imediatamente; soft bounces seguem sua política de retry antes de escalar.
O isolamento por tenant impede que uma lista ruim de um cliente afete os demais. Eventos webhook (bounce, soft_bounce, complaint) dão ao seu app os detalhes para atualizar CRM e acionar fluxos de recuperação. Veja email routing para configurar políticas.
| Caminho relay | Sinal | Status |
|---|---|---|
| Transacional UE | Entrega estable | saudável |
| Bulk EUA | Deferrals bajos | saudável |
| Dedicated tenant | Deferrals elevados | degradado |
UI representativa do produto — dados ilustrativos, não métricas reais de clientes.
Hard bounce vs soft bounce - classificação
Nem todos os bounces são iguais. O código de resposta do servidor receptor indica se a falha é permanente ou temporária, e seu sistema precisa tratar cada caso de forma diferente.
Hard bounce
Falha permanente de entrega. A caixa postal não existe, o domínio é inválido ou o destinatário rejeitou permanentemente emails do seu domínio.
Códigos de resposta:550 Mailbox unavailable, 550 User unknown, 550 No such recipient
Ação necessária: Adicionar imediatamente à lista global de supressão. Não tentar enviar para esse endereço novamente.
Soft bounce
Falha temporária de entrega. A caixa postal está cheia, o servidor está temporariamente indisponível ou há um problema de conexão.
Códigos de resposta:450 Mailbox full, 421 Service temporarily unavailable, 451 Server busy
Ação necessária: Tentar novamente com backoff exponencial. Converter para hard bounce após N falhas consecutivas.
Estratégia de retry e backoff
Soft bounces devem ser tentados novamente, mas não imediatamente nem indefinidamente. Um cronograma estruturado evita que o sistema pressione servidores já degradados.
| Tempo | Ação |
|---|---|
| Imediato | Primeira tentativa no momento do envio |
| +15 min | Primeiro retry - erro de servidor ou rede |
| +1 hora | Segundo retry |
| +4 horas | Terceiro retry |
| +12 horas | Quarto retry |
| Descartar | Após 5 falhas consecutivas, converter para hard bounce e suprimir |
Gestão de listas de supressão
A lista de supressão é sua principal defesa contra envios para endereços que não podem receber email.
Hard bounces
Permanente. Nunca tentar reenviar. Armazenado permanentemente com timestamp.
Reclamações (FBL)
Usuário marcou como spam. Supressão de longo prazo. Armazenar com data da reclamação.
Pedidos de descadastro
Devem ser suprimidos imediatamente conforme requisitos CAN-SPAM e GDPR.
Falhas transitórias
Não suprimir durante a janela de retry. Suprimir apenas após exceder o máximo de tentativas.
Em plataformas SaaS multi-tenant, listas de supressão precisam ser isoladas por tenant. Veja tenant isolation para limites de supressão por domínio.
Rastreamento de eventos webhook para bounces
Eventos de bounce entregues por email webhooks fornecem mais detalhes. Acompanhe estes tipos de evento:
bounce— hard bounce. Suprimir o destinatário imediatamente.soft_bounce— falha temporária. Agendar retry conforme sua política de backoff.complaint— destinatário marcou como spam. Suprimir no longo prazo.delivery— confirma aceitação pelo servidor receptor.reject— servidor recusou antes da fila. Verificar registros SPF/DKIM/DMARC.
A Sendarix classifica bounces automaticamente
Eventos de bounce são rastreados por mensagem, classificados como hard ou soft, e as listas de supressão são atualizadas automaticamente. Cronogramas de retry e lógica de failover são configuráveis pela API de email routing.
