Diagnóstico de errores de rebote SMTP y códigos de estado permanentes

Los rebotes permanentes (códigos 5xx) son señales claras de que un mensaje no será entregado mientras no se corrija la causa. En esta guía técnica y práctica, dirigida a administradores de servidores y responsables de entregabilidad, explico cómo interpretar los códigos SMTP, ejemplos reales de mensajes de rebote, pasos de diagnóstico y acciones recomendadas para solucionar problemas y reducir la tasa de rebote.

Qué son los códigos de estado SMTP y por qué importan

El servidor SMTP responde con códigos numéricos (p. ej., 250, 421, 550) y, desde RFC y documentación histórica, se estandarizaron los códigos de clase 2xx (éxito), 4xx (fallo temporal) y 5xx (fallo permanente). Los 5xx indican errores que requieren intervención: direcciones inválidas, políticas anti-spam o problemas de autenticación/dns.

Cómo leer un rebote: elementos clave

• Mensaje visible del MTA remitente/receptor: línea con el código y explicación breve.
• Enhanced Status Code (X.Y.Z): proporciona contexto (por ejemplo, 5.1.1).
• Diagnostic-Code en el DSN (Delivery Status Notification): contiene el mensaje exacto del servidor receptor.
• Cabeceras del mensaje original y recibos ‘Received’ para trazar la ruta.

Taxonomía práctica de códigos permanentes (5.x.x)

Los segundos dígitos ayudan a localizar la causa general. Aquí una guía práctica y frecuente:

• 5.1.x — Problemas de direccionamiento: usuario inexistente, dominio no resuelve.
• 5.2.x — Problemas con el buzón: cuota excedida, buzón inexistente por políticas.
• 5.3.x — Problemas del sistema de correo receptor.
• 5.4.x — Problemas de enrutamiento entre servidores.
• 5.5.x — Errores de protocolo o sintaxis SMTP (comandos/formatos inválidos).
• 5.6.x / 5.7.x — Contenido, políticas o seguridad (SPAM, autenticación fallida, bloqueos).

Errores comunes 5xx y cómo diagnosticarlos

550 5.1.1 «User unknown» (dirección no existe)

Significa que el destinatario no está registrado en el dominio receptor. Diagnóstico rápido:

• Verificar la ortografía de la dirección.
• Comprobar registros MX del dominio receptor y hacer un dig MX o revisar en DNS.
• Intentar una sesión SMTP manual: telnet mail.example.com 25 y ejecutar MAIL FROM:, RCPT TO: para ver la respuesta exacta.

Acción: eliminar o marcar la dirección como inválida en la lista de envíos; si es cliente, solicitar verificación al destinatario.

550 5.7.1 / 550 5.7.x «Relaying denied» o rechazos por políticas

Normalmente indica problemas de autenticación, IP en listas negras o políticas anti-spam del receptor.

• Revisar autenticación: SPF, DKIM y DMARC deben configurarse correctamente.
• Comprobar si la IP del servidor está en una RBL/blacklist.
• Verificar headers y el contenido del mensaje (palabras/URLs que disparen filtros).

Recursos técnicos y buenas prácticas están en las guías de envío masivo de proveedores como Google Developers y en documentación sobre enrutamiento y entregabilidad de Cloudflare.

552 5.2.2 «Mailbox full» o límites de tamaño

El receptor no acepta más correo por cuota o límite de tamaño. Diagnóstico:

• El mensaje de rebote suele indicar «Mailbox full» o «Exceeded storage».
• Comparar tamaño del mensaje con el límite máximo aceptado por el servidor receptor.

Acción: notificar al remitente y reintentar solo si corresponde; para envíos masivos, programar reintentos en ventanas largas o marcar como fallos temporales si 4xx aparece.

Proceso sistemático de diagnóstico (checklist técnico)

Sigue estos pasos en orden cuando recibas un rebote 5xx:

• 1) Captura y analiza el rebote: guarda el DSN completo (Diagnostic-Code y Enhanced Status Code).
• 2) Reproduce la sesión SMTP: conecta con telnet/openssl y prueba RCPT TO para replicar el rechazo.
• 3) Verifica DNS: MX, A, PTR inverso, y registros SPF/DKIM/DMARC.
• 4) Revisa reputación de IP: listas negras públicas y historial de envíos.
• 5) Comprueba contenido y encabezados: cabeceras Received, From y autenticación DKIM aplicada.
• 6) Consulta logs del MTA: Postfix/Exim/Sendmail generan trazas útiles con timestamps y códigos.
• 7) Contacta al administrador receptor si el motivo es ambiguo o apunta a políticas internas.

Ejemplos prácticos de mensajes y su interpretación

Ejemplo 1 (dirección inválida):

550 5.1.1 : Recipient address rejected: User unknown in virtual mailbox table

Interpretación: eliminar la dirección o pedir confirmación al usuario.

Ejemplo 2 (rechazo por política):

550 5.7.1 Message rejected due to content; IP 203.0.113.45 is temporarily blocked

Interpretación: revisar reputación IP, autenticación y contenido del correo.

Buenas prácticas para manejar rebotes permanentes en sistemas de envío

• Implementar una política de supresión automática: marcar direcciones con 5.x.x como inválidas y suspender envíos inmediatos.
• Registrar y almacenar el DSN completo para auditoría y análisis de tendencias.
• Usar reintentos diferenciados: solo reintentar códigos 4xx; evitar reintentos automáticos para 5xx salvo casos muy específicos.
• Notificar al remitente con información clara y acciones recomendadas (p. ej., verificar dirección, pedir confirmación).

Herramientas y comandos útiles

• telnet mail.example.com 25 o openssl s_client -starttls smtp -connect mail.example.com:587 para reproducir la sesión SMTP.
• Comandos DNS: dig MX example.com, dig TXT example.com para SPF/DMARC.
• Revisar logs del MTA: /var/log/mail.log, /var/log/maillog según sistema.

Cuándo escalar y contactar al receptor

Contacta al administrador del dominio receptor cuando:

• El DSN no es claro o sugiere política interna (5.7.x) y necesitas desbloquear una IP o explicar un patrón de envío.
• Existe un posible falso positivo por filtros anti-spam y se requiere aclaración técnica para ser removido.
• Has confirmado que tu infraestructura (SPF/DKIM/DMARC, PTR) está correcta y el rechazo persiste.

Conclusión

Los rebotes SMTP permanentes (5xx) son diagnósticos valiosos que permiten identificar problemas de dirección, cuotas, reputación y políticas del receptor. Un enfoque sistemático —capturar el DSN, reproducir la sesión SMTP, revisar DNS y encabezados, y aplicar políticas de supresión— reduce la fricción operativa y protege la reputación del remitente. Mantén registros, automatiza la gestión de rebotes y consulta documentación de proveedores (por ejemplo, SMTP en Wikipedia y las guías de envío de Google Developers o en Cloudflare) para alinear tus prácticas con los estándares actuales.