# Rebote duro vs rebote suave: códigos SMTP y supresión > Diferencia entre rebote duro y suave, cómo leer códigos SMTP y enhanced status codes, cuándo suprimir una dirección y cuándo reintentar sin perder reputación. Source: https://pidgely.com/es/blog/rebote-duro-vs-rebote-suave/ · Published: 2026-10-12 · Pidgely 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. ```text 550 5.1.1 : 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: | Sujeto | Significado | |---|---| | `x.1.x` | Dirección (destinatario o remitente) | | `x.2.x` | Buzón | | `x.3.x` | Sistema de correo | | `x.4.x` | Red y enrutamiento | | `x.5.x` | Protocolo | | `x.6.x` | Contenido o formato | | `x.7.x` | Seguridad o política | ## Códigos frecuentes y qué hacer con cada uno | Respuesta | Significado | Acción recomendada | |---|---|---| | `550 5.1.1` | El buzón no existe | Suprimir de inmediato | | `550 5.1.10` | Dirección nula o inexistente (lo usa Microsoft) | Suprimir de inmediato | | `550 5.1.2` | El dominio o sistema de destino no existe | Suprimir; revisar si es un error tipográfico (`gmial.com`) | | `552 5.2.2` / `452 4.2.2` | Buzón lleno | Tratar como suave aunque venga con 5xx; suprimir si persiste semanas | | `550 5.2.1` | Buzón deshabilitado | Suprimir | | `421 4.7.0` | Demora por volumen o reputación | Reducir ritmo y reintentar | | `451 4.3.0` / `4.4.x` | Error temporal del servidor o red | Reintentar con backoff | | `550 5.7.1` | Rechazo por política | No suprimir la dirección; investigar el motivo | | `550 5.7.26` | Falla de autenticación (Gmail) | Corregir SPF/DKIM/DMARC | | `554 5.7.1` con mención a una lista de bloqueo | IP o dominio bloqueado | Revisar listas de bloqueo y reputación | | `4.4.7` en un DSN | El mensaje expiró tras reintentos | Tratar como fallo de entrega; contar hacia la supresión | 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: ```text 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. ## Preguntas frecuentes ### ¿Qué es un rebote duro? Un fallo permanente de entrega, normalmente con código SMTP 5xx y un enhanced status code como 5.1.1 (buzón inexistente). La dirección debe pasar a la lista de supresión de inmediato. ### ¿Qué es un rebote suave? Un fallo temporal, con código 4xx: buzón lleno, servidor no disponible, límite de velocidad. Se reintenta con backoff y solo se suprime si el fallo se repite durante un periodo prolongado. ### ¿Un 5.7.1 significa que la dirección no existe? No. Los códigos 5.7.x indican rechazo por política o seguridad, a menudo por reputación o autenticación. La dirección puede ser válida; lo que hay que corregir es el envío. ### ¿Por qué importa suprimir los rebotes duros? Porque seguir enviando a direcciones inexistentes es una señal clásica de mala higiene de listas y daña tu reputación ante los proveedores.