Rebote duro vs rebote suave: códigos SMTP y supresión

Un rebote duro es un fallo permanente: el servidor receptor responde con un código 5xx y el mensaje no se entregará nunca a esa dirección (por ejemplo, 550 5.1.1 buzón inexistente). Un rebote suave es un fallo temporal, con código 4xx, como buzón lleno o servidor saturado, y el mensaje se puede reintentar. La regla operativa es simple: los rebotes duros por dirección inválida se suprimen al instante; los suaves se reintentan con backoff y solo se suprimen si persisten. La excepción importante son los rechazos por política (5.7.x), que no dicen nada sobre la dirección sino sobre ti.

Cómo leer una respuesta SMTP

Cada respuesta SMTP tiene tres partes: el código básico (RFC 5321), el enhanced status code (RFC 3463) y un texto libre.

550 5.1.1 <ana@example.es>: Recipient address rejected: User unknown
│   │     └── texto libre (útil para humanos, poco fiable para parsear)
│   └── enhanced status code: clase.sujeto.detalle
└── código básico: 2xx éxito, 4xx temporal, 5xx permanente

El enhanced status code es lo que deberías usar para clasificar. Su primer dígito repite la clase (2, 4 o 5); el segundo indica el sujeto:

Códigos frecuentes y qué hacer con cada uno

Algunas observaciones:

• El buzón lleno es ambiguo. Hay servidores que lo devuelven como 5xx aunque sea temporal por naturaleza. La mayoría de los equipos lo tratan como suave.
• No te fíes solo del texto libre. Varía entre proveedores e idiomas. Úsalo como dato secundario.
• Algunos servidores no usan enhanced status codes. En ese caso, el código básico y patrones conocidos del texto son lo único disponible.

Rebotes síncronos y asíncronos

Los rebotes llegan por dos vías:

1. Síncronos: el servidor receptor rechaza durante la transacción SMTP, normalmente tras RCPT TO o después de DATA. Tu MTA recibe el código en el momento.
2. Asíncronos: el servidor acepta el mensaje (250) y más tarde descubre que no puede entregarlo. Entonces envía un DSN (Delivery Status Notification, RFC 3464) al Return-Path del mensaje original.

Un DSN contiene una parte legible por máquinas como esta:

Content-Type: message/delivery-status

Reporting-MTA: dns; mx.example.es
Arrival-Date: Mon, 12 Oct 2026 10:15:02 +0200

Final-Recipient: rfc822; ana@example.es
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp; 550 5.1.1 User unknown

Action: failed indica un fallo definitivo; Action: delayed es solo un aviso de que el mensaje sigue en cola. Para asociar el DSN al envío original de forma fiable se usa VERP: el Return-Path codifica a qué destinatario y mensaje corresponde.

Política de supresión recomendada

Rebotes duros

• Suprimir la dirección al primer rebote duro por dirección inválida (5.1.x, 5.2.1).
• Aplicar la supresión a todos los streams del mismo dominio remitente: si la dirección no existe, no existe para nadie.
• Guardar el código, el texto y la fecha para auditoría.

Rebotes suaves

• Reintentar con backoff exponencial (por ejemplo, minutos al principio, luego horas) durante una ventana de cola razonable.
• Si el mensaje expira sin entregarse, contarlo como un fallo.
• Suprimir la dirección si acumula varios fallos consecutivos en distintos días sin ninguna entrega exitosa entre medias.

Rechazos por política (5.7.x)

• No suprimir la dirección automáticamente. El problema suele ser tu reputación, autenticación o contenido.
• Agrupar estos rechazos por proveedor y por IP. Un aumento repentino es un incidente de entregabilidad, no un problema de lista.

Quejas y bajas

Aunque no son rebotes, comparten la misma lista de supresión: una queja (feedback loop) o una baja también deben impedir futuros envíos de marketing a esa dirección.

Por qué los rebotes afectan a tu reputación

Los proveedores interpretan una tasa alta de rebotes duros como señal de que no gestionas tu lista: compraste contactos, no limpias direcciones abandonadas o no verificas los registros. Además, algunas direcciones abandonadas se reutilizan como spam traps. Enviar repetidamente a direcciones que rebotan es la manera más rápida de acabar ahí.

Errores comunes

• Tratar todos los 5xx como dirección inválida. Suprimir a miles de usuarios válidos por un bloqueo temporal de reputación es un error caro.
• Reintentar los 5xx. Un rechazo permanente reintentado sigue siendo un rechazo, y empeora la percepción del receptor.
• No procesar los DSN asíncronos. Si solo miras la respuesta SMTP inmediata, te pierdes una parte relevante de los rebotes.
• Reintentar sin backoff. Reintentos inmediatos ante un 421 prolongan la limitación.
• Listas de supresión por campaña. La supresión debe ser global por dirección, no algo que cada campaña reinicia.
• Borrar la dirección suprimida. Mejor marcarla como suprimida: si alguien la vuelve a importar, el sistema debe recordarla.

Checklist

• [ ] Clasificación basada en enhanced status codes, con el texto como apoyo.
• [ ] Procesamiento de DSN asíncronos vía Return-Path con VERP.
• [ ] Supresión inmediata de 5.1.x y 5.2.1.
• [ ] Reintentos con backoff para 4xx y umbral de supresión para fallos repetidos.
• [ ] 5.7.x monitorizados como incidente, sin suprimir automáticamente.
• [ ] Lista de supresión global y persistente, compartida con quejas y bajas.
• [ ] Alertas por tasa de rebote duro por envío.

En Pidgely

Pidgely procesa rebotes síncronos y DSN asíncronos con VERP, clasifica por enhanced status code y añade a la lista de supresión las direcciones que lo requieren. Si la tasa de rebotes de una cuenta supera el umbral, el guardián de reputación pausa el envío antes de que el daño llegue a la IP compartida por el stream.