← RFC Reference

Comprensión de los rebotes de correo electrónico

Rechazos duros, rechazos blandos, formato DSN, códigos de estado mejorados — y cómo manejarlos programáticamente sin destruir tu reputación de remitente.

Dos formas en que ocurren los rechazos

La entrega de correo electrónico puede fallar en dos puntos distintos, y el mecanismo difiere para cada uno:

Rechazo síncrono (durante la sesión SMTP)

El servidor receptor rechaza el mensaje en tiempo real, durante la conversación SMTP. Obtienes el error inmediatamente como un código de respuesta SMTP:

Este es el tipo de rechazo más limpio. Tu servidor de envío sabe inmediatamente que la entrega falló y puede actuar en consecuencia.

Rechazo asíncrono (DSN después de la aceptación)

El servidor receptor acepta el mensaje (250 OK en DATA), pero luego descubre que no puede entregarlo — el buzón está lleno, el filtrado de contenido lo rechazó, o un relé interno falló. El servidor genera una Notificación de estado de entrega (DSN) y la envía de vuelta a la dirección del remitente de envío (dirección MAIL FROM).

Esta es la razón por la que la dirección MAIL FROM importa. Es la dirección que recibe notificaciones de rechazo. Para correo electrónico transaccional, esta suele ser una dirección de procesamiento de rechazo dedicada como bounces+tag@yourdomain.com.

Rechazos duros vs. Rechazos blandos

La distinción es crítica. Continuar enviando a direcciones que rechazan duro daña tu reputación de remitente. Los proveedores de buzones rastrean tu tasa de rechazo — si supera aproximadamente el 2%, tu capacidad de entrega sufrirá en todos los ámbitos.

Códigos de estado mejorados

Los servidores SMTP modernos utilizan códigos de estado mejorados (RFC 3463, registro en RFC 5248) que proporcionan mucho más detalle que el código de tres dígitos. El formato es class.subject.detail:

• Clase: 2 = éxito, 4 = fallo temporal, 5 = fallo permanente
• Asunto: La categoría del problema
• Detalle: El problema específico

Categorías de asunto

Códigos de estado que verás más

Formato DSN: Cómo se ve un mensaje de rechazo

Cuando un rechazo se genera de forma asíncrona, llega como un mensaje estructurado definido por RFC 3464, envuelto en el tipo MIME multipart/report de RFC 3462. Un DSN tiene tres partes:

Las tres partes MIME:

1. text/plain — Explicación legible por humanos
2. message/delivery-status — Datos estructurados legibles por máquina con el código de estado, destinatario e información de diagnóstico
3. message/rfc822 — Los encabezados del mensaje original (o mensaje completo), para que puedas identificar qué mensaje fue rechazado

Los campos clave para procesamiento programático:

• Final-Recipient: La dirección que falló
• Action: failed (permanente), delayed (temporal), delivered, relayed, o expanded
• Status: El código de estado mejorado (p. ej., 5.1.1)
• Diagnostic-Code: La respuesta SMTP sin procesar

Manejo de rechazos programáticamente

Usa VERP para identificación confiable

VERP (Variable Envelope Return Path) codifica la dirección del destinatario en el MAIL FROM, de modo que cuando llega un rechazo, puedes identificar exactamente qué destinatario fue rechazado sin analizar el cuerpo del DSN:

Cuando bob@example.com falla, el DSN se entrega a bounces+bob=example.com@yourdomain.com. Analizas la parte local para extraer el destinatario original. Esto funciona incluso cuando el DSN está mal formado o no es estándar.

Lógica de procesamiento

Un procesador de rechazo confiable sigue esta lógica:

1. Analiza el DSN — Extrae la parte message/delivery-status. Lee el campo Status:.
2. Clasifica el rechazo:
   • El estado comienza con 5. → Rechazo duro. Suprime la dirección.
   • El estado comienza con 4. → Rechazo blando. Incrementa un contador.
3. Aplica reglas de supresión:
   • 1 rechazo duro → suprime inmediatamente
   • N rechazos blandos dentro de una ventana (p. ej., 3 dentro de 7 días) → suprime como duro
4. Identifica vía VERP si el análisis del DSN falla (muchos servidores envían rechazos no estándar)
5. Registra todo — Registra el código de estado, diagnóstico, marca de tiempo e ID del mensaje original para depuración

Ten cuidado con los rechazos duros falsos

Algunos servidores devuelven incorrectamente 5xx para condiciones temporales (como limitación de velocidad). Si ves 5.7.1 con un mensaje sobre "demasiadas conexiones" o "intenta más tarde," trátalo como un rechazo blando a pesar de la clase 5xx. Usa el texto de diagnóstico como una señal secundaria.

Tasa de rechazo y reputación

Los proveedores de buzones monitorean tu tasa de rechazo como una señal de higiene de lista:

• < 2% tasa de rechazo — Aceptable
• 2-5% — Zona de advertencia. Verás limitación de velocidad y aumento de colocación en carpeta de spam.
• > 5% — Tu reputación de IP y dominio se está degradando activamente. Algunos proveedores te bloquearán.

Para correo electrónico transaccional (restablecimiento de contraseña, recibos), las tasas de rechazo deben ser bien inferiores al 1%. Tasas altas de rechazo en correo transaccional sugieren que tu aplicación está aceptando direcciones inválidas en el registro. Agrega validación de correo electrónico antes de enviar nunca.

Qué puede salir mal

Ignorar rechazos completamente

El error más común. Si sigues enviando a direcciones que rechazan duro, los proveedores de buzones limitarán la velocidad y eventualmente bloquearán tu IP de envío. Tu capacidad de entrega se degradará para todos los destinatarios, no solo los inválidos.

Formatos de rechazo no estándar

No todos los MTA generan DSN compatibles con RFC. Algunos envían rechazos en texto plano sin parte message/delivery-status. Otros incluyen el código de estado solo en el texto legible por humanos. Tu analizador necesita manejar estos casos de forma elegante — por eso VERP es tan valioso como método de identificación alternativa.

Backscatter

Cuando un servidor acepta un mensaje de un remitente falsificado y luego genera un rechazo, ese rechazo va a la dirección MAIL FROM falsificada. El propietario del dominio inocente recibe mensajes de rechazo para correo que nunca envió. Esto se llama backscatter y es una forma de abuso. Los servidores modernos deberían rechazar durante la sesión SMTP (de forma síncrona) en lugar de aceptar y rebotar más tarde.

Bucles de rechazo

Si tu dirección de procesamiento de rechazo en sí rechaza (debido a una configuración incorrecta), puede crear un bucle. SMTP evita bucles infinitos requiriendo que los mensajes de rechazo (aquellos con MAIL FROM:<>) nunca sean rechazados ellos mismos — se descartan silenciosamente si la entrega falla.

Gestión de lista de supresión

Una vez que suprimes una dirección, necesitas un proceso para rehabilitarla. Las personas arreglan su buzón (limpian cuota, rehabilitan cuenta). Un patrón común: permite que los destinatarios se revaliden recibiendo exitosamente un correo de confirmación después de un período de enfriamiento (30-90 días).

Puntos clave

• Los rechazos duros (5xx) son permanentes — deja de enviar inmediatamente. Los rechazos blandos (4xx) son temporales — reintenta con retroceso.
• Los códigos de estado mejorados (X.Y.Z) te dan la razón específica. Aprende los comunes.
• Los DSN tienen una parte message/delivery-status estructurada para análisis de máquina. Úsala.
• VERP codifica el destinatario en la ruta de retorno para identificación confiable de rechazo.
• Mantén tu tasa de rechazo por debajo del 2%. Para correo transaccional, por debajo del 1%.
• Valida direcciones de correo electrónico en el punto de recopilación, antes de enviar nunca.

Lectura adicional

Related RFCs