Respuesta breve
Un rebote permanente no suele resolverse reenviando el mismo mensaje sin cambios; uno temporal puede permitir un intento posterior. Lee el código completo y el diagnóstico, no solo la etiqueta hard o soft. Una dirección inexistente y un bloqueo por política necesitan correcciones distintas, aunque ambos impidan entregar.
Comprobación clave: Cada rebote conserva código, diagnóstico y decisión, sin reactivar contactos dados de baja.
Fuentes y límites de esta guíaDespués de enviar presupuestos aparecen contactos suspendidos. Borrar toda la lista oculta la causa; reenviarla completa puede repetir el problema. Empieza por un registro con destinatario, campaña, fecha, código y texto del servidor. Separa un fallo técnico de una baja voluntaria: resolver el primero no revoca la segunda. Esta guía diagnostica la devolución; las aperturas y clics de los correos que sí llegaron se interpretan en aperturas y clics sin asumir lectura.
Leer clase, categoría y detalle
La RFC 3463 define los códigos de estado ampliados con tres números. El primero es la clase: 2 indica éxito, 4 un fallo transitorio persistente (el mensaje es válido, pero una condición temporal ha impedido o retrasado la entrega) y 5 un fallo permanente, que según la norma no es probable que se resuelva reenviando el mensaje tal como está. El segundo número es la categoría: 1 se refiere a la dirección, 2 al buzón y 7 a seguridad o política. El tercero concreta el diagnóstico.
| Clase | Categoría | Detalle | Significado según la RFC 3463 | Acción antes de reenviar |
|---|---|---|---|---|
| 5 | 1 | 1 | El buzón indicado en la dirección no existe | Contrastar la dirección por un canal conocido |
| 5 | 1 | 2 | El sistema de destino no existe o no acepta correo | Revisar el dominio; no probar variantes al azar |
| 4 | 2 | 2 | Buzón lleno por cuota o capacidad | Dejar actuar la política de reintento |
| 5 | 7 | 1 | Remitente no autorizado; mensaje rechazado | Investigar política, autenticación y contenido |
No conviertas cualquier fallo de clase 5 en «correo mal escrito»: un rechazo por política exige investigar, no corregir letras. Conserva el diagnóstico completo y consulta al proveedor si código y explicación parecen incompatibles. Un fallo permanente describe el intento en esas condiciones, no demuestra que la persona haya dejado de existir como cliente.
Tres diagnósticos de ensayo
| Caso ilustrativo | Diagnóstico | Siguiente paso |
|---|---|---|
| Dirección | Buzón de destino inexistente | Contrastar la dirección por un canal autorizado |
| Capacidad | Buzón lleno temporalmente | Revisar política de reintento del proveedor |
| Política | Entrega no autorizada por política | Investigar el rechazo; no inventar otra dirección |
Para un rechazo por política, empieza por comprobar que tu dominio autoriza al CRM a enviar, con la guía de SPF y DKIM en el CRM. Si la autenticación es correcta, el texto del servidor suele indicar si el bloqueo se refiere al remitente, al contenido o a un límite de envío.
Qué revisar en EngageBay
La ayuda de EngageBay sobre rebotes, consultada el 27 de octubre de 2026, define el rebote permanente como un motivo permanente por el que no se puede entregar, con ejemplos como dirección inexistente o bloqueo total del servidor de destino. Entre los temporales incluye buzón lleno o inactivo, servidor caído, exceso de correos, mensaje demasiado grande, bloqueo por contenido o por políticas del servidor, DMARC o antispam, e incluso dominio inexistente. Indica que reintenta la entrega varias veces y que una dirección que sigue rebotando en campañas posteriores acabará considerándose permanente, sin decir tras cuántas. Por eso la etiqueta soft de EngageBay puede acompañar a un código de clase 5: decide con el código, no solo con la etiqueta.
Ejemplo trabajado: doce rebotes en una campaña
Campaña ficticia de seguimiento de presupuestos con 200 envíos y 12 rebotes, agrupados por código.
| Clase | Categoría | Detalle | Cantidad | Patrón | Decisión |
|---|---|---|---|---|---|
| 5 | 1 | 1 | 5 | Direcciones distintas en varios dominios | Contrastar cada una; no reenviar hasta corregir |
| 4 | 2 | 2 | 3 | Buzones distintos | Esperar reintentos y revisar en la siguiente campaña |
| 5 | 7 | 1 | 3 | Mismo dominio de destino | Pausar envíos a ese dominio e investigar política |
| 5 | 1 | 2 | 1 | Dominio con una errata | Contrastar con la persona por otro canal |
La tasa de rebote es 12 / 200 = 6 %, y la de fallos permanentes, 9 / 200 = 4,5 %. Pero la cifra agregada esconde la decisión: los tres rechazos por política se concentran en un dominio, lo que apunta a una regla de ese receptor y no a direcciones mal escritas. Borrar esos tres contactos no arreglaría nada y perdería clientes válidos. Los cinco buzones inexistentes, en cambio, son casos individuales que se corrigen uno a uno.
Contexto en España: corregir no reactiva la baja
Si un contacto rebotado se había dado de baja, corregir su dirección no restablece el consentimiento. El artículo 22.1 de la LSSI permite revocar en cualquier momento el consentimiento para recibir comunicaciones comerciales. Revisa la baja antes de reenviar y conserva ambos datos por separado: estado de entrega y preferencia comercial. Para altas nuevas, la confirmación se valida con el doble opt-in, no con la ausencia de rebote.
Errores frecuentes y cómo detectarlos
| Error | Síntoma | Comprobación |
|---|---|---|
| Decidir solo con la etiqueta hard o soft | Reintentos a direcciones con clase 5 | Exporta el código completo junto a la etiqueta |
| Borrar contactos rebotados en bloque | Clientes válidos desaparecen del CRM | Agrupa por código y dominio antes de borrar nada |
| Corregir letras en un rechazo por política | La dirección «corregida» también rebota | Lee la categoría: si es 7, no es la dirección |
| Reenviar toda la campaña tras un fallo temporal | Duplicados a quien sí recibió el primer envío | Reenvía solo a los afectados, tras su reintento |
| Reactivar una baja al corregir la dirección | Quejas de personas que habían pedido no recibir más | Cruza los rebotes corregidos con la lista de bajas |
Cierre verificable del incidente
Con datos ficticios, asigna una causa y una acción a cada fila. Para una incidencia real, registra qué corrigió el responsable y conserva cualquier prohibición de contacto. Evalúa el siguiente resultado de entrega por separado de aperturas o ventas. Cierre ilustrativo: «5.1.1; dirección contrastada por canal conocido; corrección confirmada; baja revisada; siguiente envío sujeto al procedimiento». Una corrección y posterior entrega resuelven ese incidente técnico sin cambiar la preferencia comercial. Una revisión manual sirve para pocos casos; EngageBay encaja si necesitas gestionar estos estados junto a campañas y contactos. Las tablas no proceden de envíos ejecutados por CallsIQ.
Desde la experiencia del autor
No tengo una distribución propia de códigos de rebote por dominios españoles, así que ante un rechazo examinaría siempre el código SMTP completo y su descripción, no solo la etiqueta resumida del proveedor. Si me encontrara un rebote etiquetado como soft con una clase 5 por detrás, revisaría esa clasificación para evitar reintentos inútiles y conservaría el diagnóstico original en vez de fiarme de la etiqueta.
Cuando los rechazos por política se concentran en un dominio, mi primer paso sería revisar autenticación, reputación y la política concreta del destinatario, pidiendo el rechazo completo antes de concluir que el problema está en la dirección de correo. Precisamente ese es el error más frecuente que evitaría al limpiar contactos rebotados: eliminar todas las direcciones con rebote sin distinguir causas, en lugar de separar errores permanentes, fallos temporales y bloqueos por política, que necesitan acciones distintas.
Para investigar una incidencia de rebotes, los datos mínimos que pediría en un ticket son identificador de mensaje, fecha con zona horaria, remitente, dominio destinatario y la respuesta SMTP completa, añadiendo la ruta de envío y las cabeceras disponibles cuando existan, pero limitando los datos personales que no sean necesarios para el diagnóstico.
Fuentes y límites de esta guía
Revisión documental: . Tipo de contenido: Guía documental con ejercicio original.
Las fuentes enlazadas describen las condiciones y funciones que publica cada proveedor. Los ejemplos con datos ficticios se identifican en el texto.
Alcance: Guía documental revisada el 16/10/2026. Los ejemplos son ficticios y los ensayos propuestos; CallsIQ no ha realizado pruebas de estos productos.
- RFC 3463www.rfc-editor.org
- ayuda de EngageBay sobre reboteshelp.engagebay.com
- artículo 22.1 de la LSSIwww.boe.es
Consulta las condiciones actuales
Valora estas opciones si resuelven el problema descrito. Confirma funciones, límites y contratación en tu país.
EngageBayEnlace de afiliaciónLos enlaces comerciales identificados pueden generar una comisión o recompensa por referido para CallsIQ. Nuestra política comercial.
Fuentes oficiales, cálculos explicados y ejemplos identificados. Consulta la metodología y el uso de IA en la redacción.