Desatados hablando sobre los rebotes de correo electrónico

marzo 13, 2026

 

Esta semana, el Bounce House se vuelve meta y habla sobre todo lo relacionado con los rebotes de correo electrónico.

Rebotar suena divertido, hasta que te caes de cu…
Es decir, los trampolines rebotan, pero son engañosamente peligrosos. Los duendes son saltarines, pero son unos tramposos. Los registros de rebotes de correo electrónico fluctúan, pero también son engañosos. 

Todos los expertos en correo electrónico que existen enseñan la misma reglita clara: 

4xx = rebote suave (¡temporal, vuelve a intentarlo!) 5xx = rebote duro (¡permanente, elimínalo!) 

Y admitiré que eso es a grandes rasgos cierto. De la misma manera que «verde significa avanzar» es cierto, pero aun así esperas a que el tráfico en sentido contrario despeje la intersección antes de pisar el acelerador. 

Esto es lo que la mayoría de los glosarios pasan por alto:
Los códigos de rebote son señales. Tratarlos como una regla estricta hará que te estrelles. 

Son estratégicos, son contextuales y definitivamente no se aplican de manera consistente en los distintos proveedores de buzones de correo, servidores privados o incluso en el tiempo y el espacio. 

No existe un tribunal mundial de rebotes. El Tribunal Supremo de las Bandejas de Entrada no dirá que una regla de rebote es injusta. Ningún escuadrón internacional de aplicación de estándares de rebote detendrá a los proveedores de buzones de correo diciéndoles: 

«Disculpa, Gmail, usaste un 4xx para algo que parece bastante de tipo 5xx. Vamos a necesitar ver tu identificación». 

Los proveedores de buzones de correo devuelven la respuesta que mejor proteja a sus usuarios, sin optimizarla para tu retorno de inversión (ROI). Lo que significa que, si estás tratando los rebotes como un diagrama de flujo en lugar de una conversación, es hora de pegar el salto. 

Es 2026, y estamos dejando atrás la lógica binaria de los rebotes. 

A los remitentes les encanta una regla general estricta, como: 

✅ 4xx = «¡No pasa nada, vuelve a intentarlo!»  

❌ 5xx = «¡Está muerto, suprímelo para siempre!» 

Pero la entregarealidad (acabo de acuñar ese término, de nada) es más complicada: 

• Algunos fallos 4xx nunca tendrán éxito, sin importar cuántas veces lo intentes. 

• Algunos fallos 5xx se resolverán más adelante cuando cambien las condiciones. 

• El mismo código puede significar cosas distintas en diferentes proveedores. 

• Los proveedores pueden cambiar cómo usan los códigos o introducir nuevos sin previo aviso. 

• A veces se equivocan y, probablemente, no lo admitirán. 

Optimizan pensando en la seguridad del usuario, no en la claridad de tus informes. Los proveedores de buzones de correo pueden etiquetar un fallo como quieran, y depende de nosotros interpretar qué sucedió realmente. 

1) El SMTP ofrece a los proveedores sugerencias de terminología, no plantillas inquebrantables 

Básicamente, el SMTP dice: «Así es como debes dar formato a una respuesta». No dice: «Aquí tienes exactamente cuándo debes usar cada respuesta y qué decir». 

Los proveedores de buzones de correo clasifican los fallos según lo que a ellos les importa, que es principalmente: 

• Prevención de abusos 

• Limitaciones de recursos 

• Patrones de spam 

• Señales de comportamiento del usuario 

• Cambios en las políticas 

• Puntuación de riesgo interna 

• Sus propias peculiaridades operativas 

• Mi seguridad laboral (gracias, Microsoft, por tu servicio continuo) 

2) Los fallos ocurren en diferentes puntos del protocolo de enlace (handshake) 

No todos los rebotes son iguales. «Fallido» podría significar: 

• El dominio está inactivo o roto 

• La dirección del destinatario no existe 

• El servidor quiere frenarte 

• El proveedor cree que eres sospechoso 

• Tu contenido provocó un bloqueo por políticas 

• Estás enviando correos como una manguera de bomberos, pero solo tienes la reputación de un aspersor 

Y todo eso se representa como… un par de dígitos y un enlace, probablemente a una página de postmaster que se actualizó por última vez en la época del internet por módem. 

3) Algunos fallos «temporales» son permanentes en la práctica 

Ejemplo clásico: buzón de correo lleno. 

Técnicamente temporal. Pero, ¿en la práctica? Puede que ese buzón lleve lleno desde la pandemia (QEPD el distanciamiento social, apenas te conocimos). 

Otros escenarios tipo «4xx, pero a quién queremos engañar»: 

• Bloqueos por políticas corporativas que requieren inclusión manual en listas de permitidos (y nadie lo va a hacer) 

• Bucles de listas grises (greylisting) que tu patrón de reintentos nunca logra satisfacer 

• Sin registro MX  

Reintentarlos sin fin es como enviarle un mensaje de «¿qué haces?» a un número desconectado, pero peor; en este escenario, T-Mobile podría simplemente decidir no entregar nunca más ninguno de tus mensajes de «¿despierto?» a nadie, aunque los quisieran y efectivamente estuvieran despiertos. 

4) A veces «permanente» no significa «para siempre» 

Por otro lado, a veces los 5xx pueden ser situacionales: 

• Los DNS se arreglan 

• Un usuario reactiva una cuenta antigua 

• Un proveedor revierte un bloqueo de política erróneo 

• Cambios en la autenticación 

Si tu sistema trata cada 5xx como un dramático botón de expulsión, poco a poco irás reduciendo tu audiencia alcanzable con el tiempo y te preguntarás por qué la interacción y los ingresos siguen cayendo. Como un ejemplo imaginario: buoncehouse@example.com rebota con un «usuario desconocido» y se siente como un fallo permanente rotundo. Parece un error tipográfico, el buzón no existe, caso cerrado. Pero las direcciones de correo electrónico se parecen más a los apartamentos que a las lápidas: la gente se muda a ellos y se va de ellos. Alguien podría llegar mañana, reclamar ese nombre de usuario exacto por cualquier motivo, y, de repente, tu fallo «permanente» es un ser humano muy real, con un botón de spam muy real y, posiblemente, opiniones muy reales y negativas sobre recibir tu boletín. 

Purificar la casa con salvia es bueno, pero no le apliques el método Konmari a tu lista hasta dejarla en el olvido. Incluso Marie tuvo arrepentimientos. 

Un aplazamiento (normalmente 4xx) significa: «Ahora no.» 

A menudo esto aparece por limitación de envíos (rate limiting), listas grises (greylisting), carga temporal del sistema o un comportamiento sospechoso que aún no ha cruzado un límite estricto. 

Un bloqueo (normalmente 5xx) significa: «Nunca.» 

Estos suelen estar vinculados a fallos de reputación, problemas de autenticación, infracciones de políticas o destinatarios inexistentes. 

Pero aquí es donde la cosa se pone interesante: 

Algunos proveedores usan intencionadamente los aplazamientos repetidos como una herramienta de corrección de comportamiento. Técnicamente están diciendo «puedes volver a intentarlo más tarde». En la práctica, están diciendo: «Corrige tu comportamiento antes de que dejemos pasar esto. El tiempo cura la mayoría de las heridas, pero no esta». 

El primer dígito te indica la clasificación, pero le falta contexto. 

Aquí es donde la cosa se complica. 

Cuando se produce un rebote, en realidad estás tomando dos decisiones separadas: 

1. ¿Debería reintentar este mensaje en específico? 

2. ¿Debería confiar en esta dirección en el futuro? 

No son lo mismo. Un límite temporal de envíos podría significar: reintenta este mensaje más tarde. No significa automáticamente que: esta dirección esté garantizada como válida para entregas en el futuro. 

Del mismo modo, un rechazo permanente podría significar: deja de intentar enviar este mensaje. No siempre significa: quema esta dirección de tu base de datos para toda la eternidad. 

Si las reduces a una única reacción instintiva, reintentarás direcciones tóxicas indefinidamente o suprimirás las recuperables. Los proveedores de buzones de correo esperan que conozcas a tu audiencia, y si ni siquiera sabes qué direcciones están realmente activas, no es exactamente una señal positiva de reputación. 

Todos los ESP, incluido Mailgun, implementan la gestión de rebotes. A gran escala, los reintentos infinitos son francamente peligrosos. 

Pero las estrategias de supresión varían mucho según la plataforma y la filosofía: 

• Algunas suprimen agresivamente después de unos pocos fallos temporales (soft bounces) 

• Algunas dejan que los rebotes temporales se extingan indefinidamente 

• Algunas reintentan de forma agresiva 

• Algunas son extremadamente conservadoras. 

Estos son cálculos de riesgo y no verdades universales. La lógica de la plataforma protege la infraestructura, pero ¿la calidad de tu lista? ¡Eso depende totalmente de ti! 

El error tipográfico de un remitente es la trampa de spam (spam trap) de otro. 
El «límite de envíos» de un remitente es la espiral de reputación de otro. 

Cuanto más limpia sea tu adquisición —especialmente con un opt-in confirmado—, más claras serán esas señales. 

Incluso si tu ESP es prudente, deberías revisar tus propios patrones. 

(Si eres cliente de Mailgun, puedes revisar cómo abordamos la gestión de rebotes y la supresión en nuestra documentación. Si usas otro proveedor, vale la pena preguntar cómo clasifican y suprimen las direcciones, y qué umbrales activan la supresión, si los hay). 

Triangula. No te limites a automatizar. 

No necesitas toda la Enciclopedia Bouncetannica, solo necesitas un modelo mental mejor: 

Los rebotes son pruebas, pero no son el veredicto. 

Cuando veas fallos, fíjate en: 

• El texto completo de la respuesta (¿política? ¿spam? ¿límite de envíos? ¿autenticación?).   

• El proveedor (importa si es un proveedor de buzones comerciales o una infraestructura privada) 

• Tu comportamiento de envío reciente (¿pico de volumen? ¿nueva lista? ¿reactivación de un segmento inactivo?) 

• El patrón a lo largo del tiempo (aislado frente a tendencia) 

• El comportamiento previo de este destinatario (¿confirmó el opt-in? ¿Interactuó anteriormente? ¿Hace cuánto tiempo? ¿Cuántos correos has enviado sin que interactúen?) 
   
   

Un solo rebote es un síntoma, pero un patrón es un diagnóstico. 

Perseguir la entregabilidad sin contexto es como perseguir a un duende. Puedes salir corriendo detrás de cada «fallo temporal» esperando que se convierta en oro para la bandeja de entrada, y acabar perdiéndote en el bosque, gritándole a un arcoíris, con tu reputación como remitente en ruinas. 

En su lugar: 

✅ Lee toda la respuesta del rebote, no solo el código  

✅ Observa los patrones a lo largo del tiempo y entre proveedores  

✅ Audita tu comportamiento de envío  

✅ Separa las decisiones de reintento de las de supresión 

✅ Busca qué está provocando los fallos, no solo el informe de impacto 

Porque la bandeja de entrada no está obligada a ser coherente. Pero tú sí. 

• 4xx frente a 5xx es una pauta, no una garantía. 

• La lógica de reintento y las decisiones de supresión son diferentes: no las fusiones. 

• Los aplazamientos pueden funcionar como bloqueos cuando los proveedores los usan como corrección de comportamiento. 

• Algunos fallos permanentes se resuelven. Algunos fallos temporales nunca lo harán. 

• La lógica de rebotes del ESP es la prevención, pero tu comportamiento de envío es la cura 

• Lo mejor para tu lista suele ser la triangulación, no la automatización ciega. 

Los códigos de rebote no son semáforos en rojo o verde; son amarillos. Como esa olla de oro de ROI que estará perpetuamente fuera de tu alcance si te tomas los rebotes al pie de la letra. 

Marzo es el momento perfecto para dejar de reaccionar ante el número y empezar a entender el mensaje.