Soft bounce

Um soft bounce é uma falha transitória de entrega de email. O servidor receptor recusou a mensagem por enquanto, mas a causa é algo que pode se resolver sozinho — a caixa do destinatário está acima da cota, o servidor receptor está temporariamente caído ou com rate limiting, a mensagem foi greylisted na primeira tentativa, ou houve um hiccup no handshake TLS. Espera-se que o remetente retente. Compare a um hard bounce — uma rejeição permanente que nunca deveria ser retentada.

O mesmo enum BounceType que dirige o hard-bounce handling tem um segundo case:

enum BounceType: string
{
    case HARD = 'hard';
    case SOFT = 'soft';
}

Um evento de webhook SOFT do vendor de envio (SES, Mailgun, SparkPost, etc.) é registrado em BounceLog exatamente como um hard bounce, mas o listener RecordBounce não blacklist automaticamente o assinante em uma única ocorrência. O endereço permanece ativo e é incluído em campanhas subsequentes. Se soft bounces continuam a acumular ao longo de uma sequência configurável, o operador pode promover o endereço a blacklist via as policies do bounce-handler — mas um único soft bounce é tratado como ruído.

Confundir soft e hard bounces é o erro mais comum de bounce handling em plataformas pequenas. Auto-blacklistar em soft bounce encolhe a lista cada vez que o servidor de um destinatário tem um hiccup — uma única queda do Gmail pode tirar milhares de assinantes legítimos. Tratar hard bounces como soft (retentando mesmo assim) queima reputação do remetente. O AcelleMail força essa separação na camada de modelo de dados (BounceType::HARD vs BounceType::SOFT) para que listeners não tratem acidentalmente um como o outro.

• Respostas SMTP 4xx — toda a classe 4xx significa "falha transitória, retentar".
• Caixa cheia — o destinatário atingiu o limite de armazenamento; geralmente resolve em dias.
• Greylisting — técnica anti-spam que adia um remetente pela primeira vez; retries legítimos têm sucesso em minutos.
• Rate limiting — o receptor está restringindo tráfego desse IP/domínio; recue e retente.
• Problemas de TLS / conexão — problema transitório de rede ou certificado no lado receptor.

O playbook operacional completo — quando soft bounces devem escalar para blacklist, qual o comprimento sano da sequência, e como ler as razões cruas do vendor — está em entregabilidade §8.