Soft bounce

Un soft bounce es una falla transitoria de entrega de email. El servidor de mail receptor rechazó el mensaje por ahora, pero la causa es algo que puede resolverse por sí solo — el buzón del destinatario superó su cuota, el servidor receptor está temporalmente caído o aplicando rate limiting, el mensaje fue greylisted en el primer intento, o hubo un hiccup en el handshake TLS. Se espera que el remitente reintente. Compare con un hard bounce — un rechazo permanente que nunca debería ser reintentado.

El mismo enum BounceType que gobierna el hard-bounce handling tiene un segundo case:

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

Un evento de webhook SOFT del vendor de envío (SES, Mailgun, SparkPost, etc.) se registra en BounceLog exactamente igual que un hard bounce, pero el listener RecordBounce no pone al suscriptor en blacklist automáticamente en una única ocurrencia. La dirección permanece activa y es incluida en campañas subsiguientes. Si los soft bounces continúan acumulando a lo largo de una racha configurable, el operador puede promover la dirección a blacklist vía las policies del bounce-handler — pero un único soft bounce se trata como ruido.

Confundir soft y hard bounces es el error más común de bounce handling en plataformas pequeñas. Auto-blacklistar ante un soft bounce encoge la lista cada vez que el servidor de un destinatario tiene un hiccup — una sola caída de Gmail puede tirar miles de suscriptores legítimos. Tratar los hard bounces como soft (reintentando de todos modos) quema la reputación del remitente. AcelleMail fuerza esa separación en la capa de modelo de datos (BounceType::HARD vs BounceType::SOFT) para que los listeners no traten accidentalmente uno como el otro.

• Respuestas SMTP 4xx — toda la clase 4xx significa "falla transitoria, reintentar".
• Buzón lleno — el destinatario alcanzó su límite de almacenamiento; normalmente se resuelve en días.
• Greylisting — técnica anti-spam que difiere a un remitente por primera vez; los retries legítimos tienen éxito en minutos.
• Rate limiting — el receptor está restringiendo el tráfico desde esa IP/dominio; haga back-off y reintente.
• Problemas de TLS / conexión — problema transitorio de red o certificado del lado receptor.

El playbook operativo completo — cuándo los soft bounces deben escalar a blacklist, qué largo de racha es sano, y cómo leer las razones crudas del vendor — vive en entregabilidad §8.