Rebotes de correo: cómo leer códigos de rebote como un profesional (y solucionar la causa raíz)

Un modelo mental útil: qué es realmente un rebote

Un “rebote” no es una sensación. Es un servidor SMTP remoto (o una pasarela delante de él) que te dice que no aceptó tu mensaje para entrega. A veces lo rechaza inmediatamente durante la conversación SMTP. A veces lo acepta y más tarde genera una Notificación de Estado de Entrega (DSN) cuando no puede entregarlo localmente.

Para operaciones, la división más importante es:

• Rebote duro (típicamente 5xx): fallo permanente. Reintentar suele ser inútil y puede dañar tu reputación.
• Rebote blando (típicamente 4xx): fallo temporal. Se espera reintentar, pero las repetidas demoras también pueden causar problemas de reputación.

Luego planteas la siguiente pregunta: ¿de quién es el problema?

• Problema del destinatario: buzón inexistente, buzón lleno, políticas que bloquean en su lado.
• Tu problema: DNS/autenticación, reputación de IP, TLS roto, mensajes mal formados, picos de envío, MX mal enrutados, MTA mal configurado.
• Problema de red: timeouts, fallos de handshake, rarezas de path MTU, enrutado transitorio.

La mayoría de los equipos fallan aquí porque tratan todos los rebotes por igual. No lo son. “550 5.1.1 user unknown” es un problema de higiene de datos. “421 4.7.0 try again later” suele ser un problema de volumen/reputación/limitación. “554 5.7.1” es el atraco a plena luz del día de la entregabilidad: te han bloqueado.

Hechos e historia que realmente te ayudan a depurar

1. SMTP es más viejo que la mayoría de tu infraestructura. Se remonta a principios de los 80 (RFC 821). Muchos comportamientos son “porque así funcionaba en ARPANET”, no porque sea elegante.
2. Los códigos de estado mejorados (como 5.7.1) se introdujeron después para hacer las clases de error legibles por máquina (RFC 3463). No todos los servidores los usan correctamente.
3. El “mensaje de rebote” que recibes a menudo lo genera tu propio MTA. Si el remoto rechaza durante SMTP, tu servidor crea el DSN para decirle a tu app/usuario qué pasó.
4. El greylisting se popularizó a mediados de los 2000 como táctica anti-spam: rechazar temporalmente los primeros intentos de entrega (a menudo con un 4xx) para filtrar bots ingenuos.
5. Las RBLs (listas negras en tiempo real) preceden al rol “ingeniería de entregabilidad”. Comenzaron como listas mantenidas por la comunidad y evolucionaron a un ecosistema de señales de reputación desordenado.
6. SPF existió antes que DKIM (SPF a principios de los 2000; DKIM se estandarizó después). SPF autentica la IP remitente; DKIM autentica el contenido del mensaje con firmas.
7. DMARC llegó más tarde para unir SPF y DKIM con una política y un mecanismo de reporting. Una política DMARC estricta puede convertir “a veces entregado” en “consistentemente rechazado”.
8. Los grandes proveedores de buzones no sólo bloquean por contenido. Usan señales de comportamiento: tasas de queja, tasas de rebote, engagement y patrones de envío. Por eso “funcionó ayer” no es prueba.
9. Los textos de respuesta SMTP no están estandarizados. Los códigos numéricos son el contrato; el texto libre es una pista—a menudo críptica.

Anatomía de un mensaje de rebote (campos DSN que debes leer)

Cuando recibes un correo de rebote (DSN), suele contener una parte estructurada y una parte legible por humanos. Si sólo lees el asunto, estás depurando a ciegas.

Campos DSN clave

• Final-Recipient: a quién intentaba entregarse.
• Action: failed, delayed, delivered, relayed (la mayoría de rebotes son failed o delayed).
• Status: código de estado mejorado (como 5.1.1, 4.7.0).
• Remote-MTA: el nombre del servidor remoto (a veces una pasarela, no el buzón final).
• Diagnostic-Code: a menudo incluye la respuesta SMTP cruda.
• Reporting-MTA: tu sistema que generó el DSN.

Los operadores leen estos campos como un volcán de volcados: código de estado primero, texto diagnóstico segundo, luego correlacionan con logs por el ID de transacción SMTP. Si no puedes correlacionar rebotes con IDs de cola y marcas de tiempo, perderás horas discutiendo con capturas de pantalla.

Familias de códigos de rebote: 2xx, 4xx, 5xx y lo que implican

2xx: éxito (no es un rebote)

“250 2.0.0 Ok” significa aceptado. No necesariamente leído. No necesariamente entregado en la bandeja de entrada. Pero aceptado para entrega, que es la promesa del SMTP.

4xx: fallo temporal (rebote blando / deferido)

4xx significa “intentar más tarde”. Tu MTA hará cola y reintentará. Pero aún necesitas decidir si la causa raíz es transitoria (caída remota) o crónica (tu reputación causando throttling).

• 421: servicio no disponible / cerrando canal de transmisión. A menudo throttling o rechazo temporal.
• 450/451/452: buzón no disponible / error local / almacenamiento insuficiente del sistema. Podría ser greylisting, política o un problema de capacidad del receptor.

5xx: fallo permanente (rebote duro)

5xx significa “no reintentes esta entrega tal cual”. Tu MTA aún puede reintentar según configuración, pero normalmente no deberías seguir martillando un 550.

• 550: buzón no disponible, usuario desconocido, rechazo por política.
• 552: cuota de almacenamiento excedida (buzón lleno).
• 553: nombre de buzón no permitido (sintaxis mala o política de destinatario).
• 554: transacción fallida, a menudo relacionada con política (spam, listas negras, contenido).

Regla del operador: trata los 5xx como un problema de datos o política que necesita un cambio. Trata los 4xx como una señal de capacidad o reputación que necesita control de tasa y paciencia—salvo que persista.

Códigos de estado mejorados (x.y.z): lo bueno, lo malo y lo engañoso

Los códigos de estado mejorados te dan una segunda dimensión. El primer dígito sigue siendo 2/4/5. El segundo dígito es la clase (dirección, buzón, sistema de correo, red, seguridad/política). El tercer dígito es la condición específica.

Códigos mejorados de alta señal que verás a diario

• 5.1.1 — dirección de destino mala (usuario desconocido). Normalmente una dirección muerta.
• 5.2.2 — buzón lleno. Podría ser temporal, pero la mayoría de sistemas envían 5xx igualmente.
• 5.7.1 — entrega no autorizada / mensaje rechazado (política). Aquí es donde viven los bloqueos.
• 4.7.0 — fallo de política temporal (throttled, greylisted, rate-limited).
• 4.4.1 — tiempo de conexión agotado (red o problemas remotos).
• 5.3.0 — otro estado del sistema de correo (a menudo “mensaje demasiado grande” o fallo general).

Aquí está el truco: algunos proveedores etiquetan con “5.7.1” cualquier cosa que no les guste. Puede significar “spam”, “SPF faltante”, “DKIM malo”, “reputación de IP”, “tu HELO parece sospechoso” o “enviaste demasiado rápido”. Aún necesitas evidencia.

Idea parafraseada de Werner Vogels (reliability/ops): “todo falla, así que diseña para la falla”. Los rebotes son la manera honesta del correo de decir eso.

Playbook de diagnóstico rápido (primeras/segundas/terceras comprobaciones)

Este es el simulacro de “estás de guardia y alguien acaba de publicar una captura de rebote”. El objetivo es encontrar el cuello de botella en menos de 10 minutos: dirección, autenticación, reputación, contenido o capacidad remota.

Primero: clasifica la falla en 30 segundos

1. ¿Es 4xx o 5xx? Si es 5xx: deja de reintentar para esa clase de destinatarios; probablemente sea permanente o por política. Si es 4xx: busca throttling vs red.
2. ¿Está presente el código mejorado? 5.1.1 (dirección), 5.2.2 (cuota), 5.7.1 (política), 4.7.0 (política temporal) son los grandes.
3. ¿Afecta a todos los destinatarios o a un subconjunto? Un solo dominio sugiere política/reputación remota con ese proveedor; todos los dominios sugieren tu auth/DNS o tu MTA saliente.

Segundo: valida tu identidad (DNS/autenticación) rápidamente

1. Comprueba SPF para el dominio MAIL FROM / Return-Path.
2. Verifica que DKIM esté firmando y que exista el registro del selector.
3. Revisa la política DMARC y la alineación (especialmente después de cambios de dominio).
4. Confirma que el DNS inverso (PTR) coincide con las expectativas de HELO/EHLO.

Tercero: comprueba reputación y comportamiento de tasa

1. Busca “blocked”, “blacklist”, “spam”, “policy”, “too many connections” en el texto diagnóstico.
2. Revisa el crecimiento de la cola saliente y los patrones de reintento. Una cola diferida creciente es una alarma temprana de reputación/tasa.
3. Identifica si es una sola IP, todo un pool o un tipo de tráfico específico (restablecimientos vs boletines).

Cuarto: aisla contenido y problemas de transporte

1. Tamaño del mensaje, adjuntos y finales de línea.
2. Fallos de handshake TLS y incompatibilidades de cifrados.
3. Cabeceras malformadas (From, Message-ID, Date) o límites MIME extraños.

Tareas prácticas: comandos, salida esperada y qué decisión tomar

Estos son movimientos reales de operador. Cada tarea incluye: un comando, qué significa la salida típica y la decisión que tomas.

Task 1: Find the bounce reason in Postfix logs by queue ID

cr0x@server:~$ sudo grep -E "^[A-Z][a-f0-9]{9,12}:" /var/log/mail.log | grep "status=bounced" | tail -n 3
A1B2C3D4E5: to=<user@example.com>, relay=none, delay=0.2, delays=0.1/0/0/0.1, dsn=5.1.1, status=bounced (host mx.example.com[203.0.113.10] said: 550 5.1.1 <user@example.com> User unknown (in reply to RCPT TO command))
F6E7D8C9B0: to=<billing@corp.tld>, relay=mx.corp.tld[198.51.100.25]:25, delay=12, delays=0.2/0.1/10/1.7, dsn=4.7.0, status=deferred (host mx.corp.tld[198.51.100.25] said: 421 4.7.0 Try again later, rate limited (in reply to end of DATA command))
0AA11BB22C: to=<alerts@other.tld>, relay=none, delay=0.1, delays=0.05/0/0/0.05, dsn=5.7.1, status=bounced (host mx.other.tld[192.0.2.55] said: 550 5.7.1 Message rejected as spam (in reply to end of DATA command))

Qué significa: 5.1.1 es una dirección muerta; 4.7.0 es reintento/limitación; 5.7.1 es política/contenido/reputación.

Decisión: suprimir/limpiar destinatarios inválidos para 5.1.1; aplicar limitación de tasa y backoff para 4.7.0; iniciar investigación de autenticación/reputación/contenido para 5.7.1.

Task 2: Inspect the current mail queue size and whether it’s deferred-heavy

cr0x@server:~$ mailq | tail -n 5
-- 1230 Kbytes in 184 Requests.

Qué significa: el tamaño de cola por sí solo no basta, pero un pico súbito sugiere deferidos remotos o problemas locales.

Decisión: si el crecimiento de la cola se correlaciona con deferidos 4xx, limita el envío y investiga reputación; si ves errores locales, revisa disco y salud del MTA.

Task 3: Summarize DSN codes in logs (what’s dominant right now)

cr0x@server:~$ sudo grep -oE "dsn=[245]\.[0-9]\.[0-9]" /var/log/mail.log | sort | uniq -c | sort -nr | head
  412 dsn=4.7.0
  119 dsn=5.7.1
   88 dsn=5.1.1
   41 dsn=4.4.1

Qué significa: que 4.7.0 domine apunta a throttling/greylisting/deferidos por política. 5.7.1 son bloqueos. 4.4.1 sugiere timeouts de red.

Decisión: prioriza control de tasa y reputación si 4.7.0 domina; prioriza autenticación/contenido/política si 5.7.1; revisa conectividad si 4.4.1 aumenta.

Task 4: Check a domain’s MX records (are you even talking to the right servers?)

cr0x@server:~$ dig +short MX example.com
10 mx1.example.com.
20 mx2.example.com.

Qué significa: si el MX está mal o apunta a hosts caídos, verás timeouts (4.4.1) o fallos de conexión.

Decisión: si MX cambió recientemente, confirma propagación; si el dominio destinatario está mal configurado, no puedes arreglarlo—detén torbellinos de reintentos y notifica.

Task 5: Verify your sending IP has reverse DNS (PTR) set

cr0x@server:~$ dig +short -x 198.51.100.10
mailout1.yourdomain.tld.

Qué significa: PTR ausente o genérico es causa común de rechazos 5.7.1 por política, especialmente en dominios estrictos.

Decisión: si PTR falta o no coincide, arregla rDNS con tu proveedor y alinea HELO/EHLO a un nombre que resuelva y cumpla expectativas de política.

Task 6: Check SPF record for the envelope-from domain

cr0x@server:~$ dig +short TXT yourdomain.tld
"v=spf1 ip4:198.51.100.0/24 include:_spf.your-esp.tld -all"

Qué significa: SPF está presente. El calificador importa: -all es fallo estricto; ~all es softfail.

Decisión: si tus IPs de envío no están incluidas, añádelas. Si tienes demasiados includes, puedes alcanzar límites de consultas DNS y provocar fallos intermitentes.

Task 7: Validate DKIM selector record exists in DNS

cr0x@server:~$ dig +short TXT s1._domainkey.yourdomain.tld
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt..."

Qué significa: el selector está publicado. Si esta consulta no devuelve nada, los receptores no pueden verificar tu firma.

Decisión: publica el selector o corrige la desalineación de dominio/selector en la configuración de tu MTA/ESP.

Task 8: Check DMARC policy (and whether you accidentally set it to reject)

cr0x@server:~$ dig +short TXT _dmarc.yourdomain.tld
"v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.tld; adkim=s; aspf=s"

Qué significa: la alineación estricta (adkim=s, aspf=s) puede causar rechazos si tu From no se alinea con SPF/DKIM.

Decisión: si ves rebotes después de un cambio en DMARC, confirma la alineación; relaja la alineación temporalmente sólo si entiendes el trade-off contra spoofing.

Task 9: Test an SMTP session manually to see the raw rejection point

cr0x@server:~$ openssl s_client -starttls smtp -crlf -connect mx.other.tld:25
CONNECTED(00000003)
220 mx.other.tld ESMTP
ehlo mailout1.yourdomain.tld
250-mx.other.tld
250-STARTTLS
250 SIZE 52428800
mail from:<sender@yourdomain.tld>
250 2.1.0 Ok
rcpt to:<alerts@other.tld>
550 5.7.1 Blocked due to policy

Qué significa: el rechazo en RCPT TO suele ser a nivel de destinatario/política; el rechazo después de DATA es más sensible a contenido/reputación.

Decisión: si bloquean antes de DATA, céntrate en identidad/reputación; si bloquean después de DATA, inspecciona contenido, cabeceras y patrón de envío.

Task 10: Confirm your server presents the correct certificate chain for SMTP TLS

cr0x@server:~$ sudo postconf -n | grep -E "smtpd_tls_cert_file|smtpd_tls_key_file|smtpd_tls_CAfile"
smtpd_tls_cert_file = /etc/ssl/certs/mail.pem
smtpd_tls_key_file = /etc/ssl/private/mail.key
smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

Qué significa: sabes qué archivos están en juego. Los fallos TLS pueden aparecer como 4.4.1 timeouts o errores de handshake en los logs.

Decisión: si rotaste certificados recientemente y comenzaron los rebotes, verifica permisos, completitud de la cadena y configuraciones de cifrados.

Task 11: Identify top recipient domains in your deferred queue (who’s throttling you?)

cr0x@server:~$ mailq | awk '/^[A-F0-9]/ {id=$1} /@/ {print $0}' | sed -n 's/.*@//p' | tr -d '>,' | sort | uniq -c | sort -nr | head
  98 gmail.com
  71 corp.tld
  40 outlook.com
  19 yahoo.com

Qué significa: qué dominios te están diferiendo/poniendo en cola más en este momento.

Decisión: implementa límites por dominio y límites de conexión; considera segmentar tipos de tráfico en distintas IPs si mezclas transaccional con masivo.

Task 12: Check for “too many connections” and tune concurrency (without going feral)

cr0x@server:~$ sudo grep -iE "too many connections|rate limited|throttl" /var/log/mail.log | tail -n 5
Jan 03 10:11:22 mail postfix/smtp[23111]: F6E7D8C9B0: to=<billing@corp.tld>, relay=mx.corp.tld[198.51.100.25]:25, dsn=4.7.0, status=deferred (host mx.corp.tld[198.51.100.25] said: 421 4.7.0 Try again later, rate limited)
Jan 03 10:11:40 mail postfix/smtp[23112]: 9D8C7B6A5F: to=<ops@corp.tld>, relay=mx.corp.tld[198.51.100.25]:25, dsn=4.7.0, status=deferred (host mx.corp.tld[198.51.100.25] said: 421 4.7.0 Too many connections)

Qué significa: el lado remoto te está diciendo que frenes.

Decisión: reduce concurrencia hacia ese dominio y aumenta el backoff; no “optimices” abriendo más conexiones. Así conviertes un throttle temporal en un bloqueo.

Task 13: Confirm local disk isn’t the real reason you’re failing

cr0x@server:~$ df -h /var/spool/postfix
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       40G   37G  1.2G  97% /

Qué significa: tu spool está casi lleno. Postfix puede empezar a diferir, y tus logs pueden mentir por omisión.

Decisión: libera espacio inmediatamente y añade monitorización; si operas cerca del límite, tendrás comportamiento de “sistema de correo lleno” que parece problema remoto.

Task 14: Inspect a specific queued message (check headers, size, and envelope)

cr0x@server:~$ sudo postcat -q A1B2C3D4E5 | sed -n '1,40p'
*** ENVELOPE RECORDS ***
message_size:            48213            48159               54               54
sender: sender@yourdomain.tld
*** MESSAGE CONTENTS ***
Received: by mailout1.yourdomain.tld (Postfix, from userid 1001)
Date: Fri, 03 Jan 2026 10:10:05 +0000
From: "Your App" <noreply@yourdomain.tld>
To: user@example.com
Subject: Reset your password
Message-ID: <20260103101005.12345@mailout1.yourdomain.tld>
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8

Qué significa: puedes confirmar si las cabeceras son razonables y si el dominio remitente se alinea con tu configuración de autenticación.

Decisión: si el contenido está malformado (falta Date/Message-ID, MIME roto), arregla el generador; algunos proveedores rechazan mensajes malformados por política.

Chiste 1: El correo es el único sistema donde puedes hacerlo todo bien y aun así te dicen “intenta más tarde” una máquina que no se explica.

Tres micro-historias corporativas desde las trincheras de los rebotes

Incidente 1: La suposición incorrecta (5.1.1 que no era “culpa del destinatario”)

Una empresa migró de un CRM legado a una nueva plataforma de clientes. Durante el corte, ejecutaron ambos sistemas en paralelo. El equipo de correo notó un aumento súbito de rebotes 550 5.1.1 User unknown para un dominio en particular. La suposición inmediata fue la habitual: “nuestra lista está desactualizada”.

Hicieron lo que los equipos hacen bajo presión: suprimieron esas direcciones. Miles. Llegaron tickets de soporte en horas: clientes no recibían enlaces de acceso, y los clientes eran reales.

La causa raíz real vivía en un rincón aburrido: el nuevo sistema convertía a minúsculas y recortaba los emails correctamente, pero un servicio intermedio también estaba añadiendo un carácter Unicode oculto copiado desde una herramienta administrativa interna. Visualmente la dirección parecía idéntica. Los servidores SMTP no se inmutan por tus sentimientos; se fijan en bytes. El sistema receptor lo trató como una parte local distinta y respondió “usuario desconocido”.

La solución no fue “limpiar la lista”. Fue normalizar y validar direcciones al ingreso, registrar los bytes crudos y añadir pruebas que compararan formas normalizadas UTF-8. También actualizaron la lógica de supresión para requerir fallos repetidos y tratar las “direcciones que fallan de repente” con sospecha durante migraciones.

Después mantuvieron una regla: si las tasas de rebote suben justo después de un cambio en la canalización de datos, asume que rompiste las direcciones hasta que se demuestre lo contrario.

Incidente 2: La optimización que salió mal (más rendimiento, más bloqueos)

Otra organización manejaba su propia flota Postfix y enviaba mucho correo legítimo: facturas, recibos y notificaciones de eventos. Su cola empezó a atascarse en horas punta. A alguien se le ocurrió una idea razonable: “aumentar la concurrencia y acortar los intervalos de reintento para que el correo se vacíe más rápido”.

Aumentaron la concurrencia por destino y redujeron el backoff. La cola se despejó. Durante un día. Luego los rebotes se dispararon: los deferidos 421 4.7.0 se convirtieron en bloqueos 550 5.7.1. El texto diagnóstico del proveedor incluía “rate limited” y luego “blocked due to policy”.

Lo ocurrido es clásico: entrenaron al receptor para que desconfíe. Demasiadas conexiones paralelas, demasiados mensajes en poco tiempo y poca paciencia. Incluso correo conforme puede parecer abuso si lo envías como una prueba de denegación de servicio.

El rollback fue doloroso porque “deshacer la optimización” no restauró la reputación instantáneamente. Tuvieron que implementar throttling adaptativo por dominio, segregar el tráfico masivo del transaccional y dejar de reintentar agresivamente en 4xx. Con el tiempo, los bloqueos cedieron.

También aprendieron una lección aplicable a almacenamiento y red: la forma más rápida de romper un sistema compartido es optimizar por rendimiento sin respetar los límites del otro lado.

Incidente 3: La práctica aburrida que salvó el día (separación de tráfico y reintentos calmados)

Un SaaS empresarial tenía una regla de apariencia insulsa: correo transaccional y masivo no comparten IPs, no comparten dominios y no comparten comportamiento de reintento. Marketing lo odiaba porque implicaba más coordinación. Finanzas lo odiaba porque significaba más espacio de IP y más partidas de proveedor.

Entonces, una tarde, marketing lanzó una campaña con tasas de queja inesperadamente altas. Predeciblemente, la pool de IPs de marketing empezó a ser throttled y bloqueada. Pero los restablecimientos de contraseña y alertas de seguridad siguieron fluyendo. ¿Por qué? Reputación separada por IP y límites estrictos en el lado transaccional.

El ingeniero de guardia aún recibió páginas, pero la página fue un aviso, no un incendio. Pausaron los envíos de marketing, limpiaron la lista, ajustaron el targeting y esperaron a que la reputación se recuperara—sin la caída empresarial “nadie puede iniciar sesión”.

No fue ingenioso. Fue aburrido. Y funcionó porque redujo el radio del impacto. Eso es un objetivo de diseño SRE-amigable, incluso cuando el sistema es “solo correo”.

Chiste 2: La forma más rápida de descubrir que no tienes estrategia de entregabilidad es enviar un “confirma tu email” que nunca llega.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: Muchos 550 5.1.1 “User unknown” justo después de una migración

Causa raíz: bug en la transformación de direcciones (espacios, Unicode, plus-addressing eliminado, error en dominio) o mapeo de dominio destinatario incorrecto.

Solución: validar en el ingreso, normalizar con cuidado, registrar bytes crudos de la dirección y retrasar la supresión hasta fallos repetidos en múltiples entregas.

2) Síntoma: 421 4.7.0 “Try again later” contra un gran proveedor

Causa raíz: throttling por picos de tasa, mala reputación o IP nueva calentándose demasiado rápido.

Solución: limitación por dominio, rampa gradual, backoff más largo en deferidos y separar tipos de tráfico (transaccional vs masivo).

3) Síntoma: 550 5.7.1 “Blocked” o “Message rejected” de repente para muchos dominios

Causa raíz: fallo de autenticación (SPF/DKIM/DMARC), PTR faltante o IP listada por quejas o remitente comprometido.

Solución: verificar alineación SPF/DKIM/DMARC; confirmar PTR; revisar logs de envío por picos inusuales; rotar credenciales; aislar tráfico; remediar reputación (y dejar de masacrar).

4) Síntoma: 552 5.2.2 rebotes por buzón lleno

Causa raíz: cuota del destinatario excedida. No es tu infraestructura, pero tus reintentos pueden molestarlos.

Solución: tratar como “temporal pero lento”: suprimir intentos repetidos por un tiempo, notificar al usuario por canales alternativos y evitar reintentos inmediatos.

5) Síntoma: 4.4.1 timeouts y errores de conexión a dominios específicos

Causa raíz: problemas de ruta de red, preferencia IPv6 rota, MX equivocado, firewalls egress, o caídas remotas.

Solución: probar conectividad desde el MTA emisor, comprobar resolución DNS (A/AAAA), verificar firewall egress y preferir IPv4 si tu ruta IPv6 es poco fiable.

6) Síntoma: Rebotes mencionan “TLS” o fallos de handshake

Causa raíz: configuraciones TLS incompatibles, certificados intermedios faltantes, desajuste de reloj o expectativas SNI rotas en algunas pasarelas.

Solución: presentar cadena de certificados completa, mantener OpenSSL actualizado, monitorizar errores de handshake y evitar endurecimiento extremo de cifrados sin probar receptores reales.

7) Síntoma: Sólo los mensajes muy pesados en HTML rebotan como spam; el texto plano pasa

Causa raíz: disparadores de contenido (patrones de URL, dominios de tracking, From engañoso, MIME roto o mensajes “solo imagen”).

Solución: asegurar estructura MIME válida, incluir una parte de texto razonable, alinear dominios visibles de enlaces con dominios autenticados y reducir patrones de contenido riesgosos.

8) Síntoma: “Message size exceeds fixed maximum message size”

Causa raíz: adjunto o bloat por codificación (overhead base64) que excede límites remotos.

Solución: reducir tamaño de adjuntos, usar enlaces de descarga y aplicar límites de tamaño en la app antes de encolar correo.

Listas de verificación / plan paso a paso

Checklist A: Cuando los rebotes se disparan (respuesta a incidentes)

1. Detén la hemorragia: pausa envíos masivos; mantén lo transaccional si es posible.
2. Clasifica: DSNs principales (4.7.0 vs 5.7.1 vs 5.1.1) desde los logs.
3. Alcance: qué dominios, qué IPs, qué clase de tráfico, qué ventana de cambios/despliegue.
4. Identidad: verifica SPF/DKIM/DMARC y rDNS. Arregla roturas obvias primero.
5. Comportamiento de tasa: reduce concurrencia; aumenta backoff de reintentos; implementa throttles por dominio.
6. Saneamiento de contenido: confirma cabeceras, MIME, tamaño. Compara una muestra “buena” y una “mala”.
7. Salud de la cola: monitoriza tamaño de cola y conteos de diferidos; asegura espacio en disco y procesos MTA estables.
8. Remediar: limpiar destinatarios inválidos; desactivar remitentes comprometidos; segmentar tráfico.
9. Verificar recuperación: vigila la tendencia a la baja de DSN; confirma que las tasas de aceptación (250) aumenten.
10. Endurecimiento post-incidente: añade dashboards para códigos DSN, tasas de deferidos y efectividad de throttles por dominio.

Checklist B: Construir una política de manejo de rebotes (para no reaprender dolor)

1. Define lógica de rebotes duros vs blandos: no trates todos los 5xx como permanentes sin matices (la cuota es especial), pero no reintentes 5.1.1 por siempre.
2. Establece umbrales de supresión: supresión inmediata para 5.1.1; supresión basada en tiempo para 4.7.0; manejo cuidadoso para 5.2.2.
3. Separa clases de tráfico: transaccional vs masivo, idealmente IPs y dominios separados.
4. Throttling por dominio: diferentes proveedores, diferentes límites. Construye una superficie de configuración que puedas cambiar sin despliegues.
5. Bucle de retroalimentación: los rebotes deben actualizar tus datos de cliente, pero con salvaguardas durante migraciones e incidentes.
6. Audita tu estrategia From y Return-Path: asegúrate de que la alineación soporte DMARC.
7. Documenta runbooks: una captura de rebote debería traducirse en una serie predecible de comprobaciones.

Checklist C: Prevuelo para nueva infraestructura de envío (antes de lanzarla)

1. PTR/rDNS configurado y verificado.
2. Hostname de HELO/EHLO resuelve a la IP de envío.
3. SPF incluye todas las IPs salientes; no excede límites de consultas DNS.
4. DKIM habilitado; selectores publicados; plan de rotación existente.
5. Política DMARC elegida intencionalmente; alineación probada.
6. TLS saliente configurado; certificados válidos; sincronización horaria funcionando.
7. Monitorización de colas y logs en su lugar; alertas en picos de diferidos.
8. Límites de tasa y concurrencia conservadores por defecto.
9. Decisión sobre separación de tráfico tomada, no “más tarde”.

Preguntas frecuentes

1) ¿Cuál es la diferencia entre un rebote y un deferido?

Un rebote es una no entrega definitiva (típicamente 5xx). Un deferido es un rechazo temporal (típicamente 4xx) que tu MTA reintentará más tarde.

2) ¿5xx siempre es un rebote duro que debo suprimir inmediatamente?

Usualmente sí, pero no a ciegas. 5.1.1 es una señal fuerte de supresión inmediata. 5.2.2 (buzón lleno) suele tratarse mejor como “retrocede por días” en lugar de “eliminar al usuario”.

3) ¿Por qué veo 4.7.0 durante horas?

Porque el receptor te está limitando o haciendo greylisting. Si persiste, trátalo como un problema de reputación/tasa, no un mero transitorio.

4) El texto diagnóstico dice “spam”, pero el correo es legítimo. ¿Ahora qué?

“Spam” suele ser atajo para fallos de política/reputación. Revisa autenticación (SPF/DKIM/DMARC), rDNS, patrones de envío y estructura de contenido. Luego reduce volumen y reintentos mientras la reputación se recupera.

5) ¿Puede un SPF malo causar rebotes?

Sí. Con DMARC aplicado, fallos SPF (especialmente con política estricta) pueden convertirse en rechazos 5.7.1. Incluso sin DMARC, algunos receptores usan SPF como entrada de política.

6) ¿Por qué funciona para algunos destinatarios en un proveedor pero no para otros?

Los proveedores ejecutan múltiples clusters y capas de política. Un MX puede ser más estricto, o puedes estar golpeando throttles por destinatario o por dominio. Por eso necesitas visibilidad por dominio y por IP.

7) ¿Debo “arreglar” rebotes cambiando de IP?

Sólo si sabes por qué cambias. Cambiar IPs para esquivar reputación es una forma rápida de quemar múltiples IPs. Arregla la causa (auth, calidad de lista, volumen) y luego considera un calentamiento controlado.

8) ¿Cuál es la métrica más simple que predice problemas de entregabilidad?

El aumento de deferidos 4.7.0 y colas diferidas crecientes para proveedores grandes. Es el sistema de aviso temprano antes de que lleguen los bloqueos 5.7.1.

9) ¿Y si el mensaje de rebote no tiene código de estado mejorado?

Vuelve al código SMTP básico (4xx/5xx) y al texto diagnóstico, luego confirma en los logs del MTA. Algunos sistemas eliminan detalles; tus logs suelen tener más verdad que el correo DSN.

10) ¿Necesito dominios separados para transaccional y marketing?

No es estrictamente necesario, pero facilita la alineación DMARC y el aislamiento de reputación. Si mantienes un solo dominio, aceptas un radio de impacto mayor.

Próximos pasos (qué cambiar el lunes)

Si quieres menos incidentes de rebotes y recuperación más rápida cuando ocurren, haz el trabajo poco glamuroso:

1. Construye un dashboard DSN que muestre tendencias de 4.7.0, 5.7.1, 5.1.1 y 4.4.1 en el tiempo, por dominio receptor y por IP emisora.
2. Implementa throttling por dominio y deja de tratar a los servidores remotos como sumideros infinitos. Respeta “try again later”.
3. Endurece la identidad: SPF incluye a todos los emisores, DKIM firma todo lo importante, la política DMARC refleja tu realidad y PTR/rDNS no es una ocurrencia tardía.
4. Segmenta el tráfico para que errores de marketing no tumben los restablecimientos de contraseña.
5. Haz explícitas las reglas de supresión: inmediata para 5.1.1, basada en tiempo para 4xx, cuidadosa con buzones llenos y protegida durante migraciones.

El correo no es un transporte confiable. Es una tregua negociada entre tu MTA y las políticas de todos los demás. Lee los códigos, confirma con evidencia y arregla el sistema—no la captura de pantalla.