¿Cómo debe diagnosticar y gestionar un equipo de producto los correos rebotados de forma segura?

Identifique dónde se observó el fallo

Un producto puede enterarse de una no entrega durante la transacción SMTP en vivo, mediante una notificación de estado de entrega posterior o mediante un evento autenticado del proveedor. Estas observaciones aportan evidencia distinta. Un rechazo inmediato en RCPT TO se aplica a ese destinatario antes de que se acepten los datos del mensaje. Un rechazo en la etapa DATA puede aplicarse a toda la transacción enviada. Un DSN posterior informa que un sistema aceptó la responsabilidad y luego no pudo entregar ni retransmitir el mensaje. Registre la etapa, el servidor, el alcance del destinatario, el intento, la marca de tiempo, la respuesta SMTP, el código de estado extendido, el diagnóstico y los identificadores de correlación originales. No agrupe todos los casos como rebotados. Conserve el payload sin procesar del proveedor o el DSN en formato estándar solo durante el tiempo que exijan las necesidades operativas y de política, con acceso restringido. Una captura de pantalla de soporte o una paráfrasis humana no es evidencia suficiente para reintentos automáticos, supresiones ni estados visibles para el cliente.

Separe los resultados temporales de los permanentes

SMTP usa respuestas 4yz para una finalización negativa transitoria y respuestas 5yz para una finalización negativa permanente. Los códigos de estado extendidos agregan una clase que empieza por 4 para un fallo transitorio persistente o por 5 para un fallo permanente, seguida de los valores de asunto y detalle. Conserve tanto los códigos básicos como los extendidos, porque el texto por sí solo es específico de cada proveedor y puede cambiar. Un resultado temporal puede justificar reintentar el mismo mensaje lógico después de una espera; no justifica bucles inmediatos ni una permanencia ilimitada en la cola. Un fallo permanente del destinatario debe detener la repetición automática para ese destinatario e intento hasta que la dirección o la política cambien mediante un proceso autorizado. No deduzca si es permanente o temporal solo a partir de las etiquetas informales del proveedor. Construya la política a partir del estado exacto, la etapa, el diagnóstico, la clase de mensaje, el destinatario y la documentación vigente del proveedor. Las respuestas desconocidas o malformadas deben fallar de forma cerrada y pasar a revisión o a una cola de mensajes fallidos (dead-letter), en lugar de reenviarse por defecto.

Analice las notificaciones de estado de entrega de forma defensiva

El RFC 3464 define un formato legible por máquina para las notificaciones de estado de entrega, transportado en multipart/report con campos message/delivery-status. Entre los campos útiles puede haber Reporting-MTA, Final-Recipient, Action, Status, Remote-MTA, Diagnostic-Code y las horas de llegada o del último intento. Trate cada campo como entrada no confiable, aunque la estructura MIME se analice correctamente. Limite el tamaño del mensaje, la cantidad de encabezados, la cantidad de partes, el anidamiento, la decodificación de caracteres y la longitud del diagnóstico almacenado. Nunca ejecute adjuntos, siga automáticamente enlaces del diagnóstico ni acepte una dirección de destinatario como identidad del tenant. Correlacione con un intento propio de la aplicación mediante un identificador de mensaje estable del proveedor, los metadatos originales del sobre o un encabezado de correlación que respete la privacidad. Un DSN puede contener partes del mensaje original y datos del destinatario, así que restrinja los logs y la retención. Si la correlación es ambigua, conserve la evidencia sin suprimir una dirección no relacionada ni revelar el historial de mensajes de otro tenant.

Modele las transiciones de estado por destinatario

Un mensaje puede dirigirse a varios destinatarios y recibir resultados distintos. Guarde el estado por destinatario y por intento, no solo en la fila del mensaje. Un proveedor puede aceptar algunos comandos RCPT y rechazar otros, o informar más tarde la entrega para un destinatario y el fallo para otro. Defina transiciones monótonas para que un evento aceptado o aplazado que llega tarde no pueda sobrescribir un fallo permanente, una queja o una baja confirmados posteriormente. Conserve el registro de eventos y derive el estado que se muestra mediante reglas de precedencia explícitas. Separe enviado, aceptado por el proveedor, aceptado por el servidor del destinatario, aplazado temporalmente, fallido de forma permanente, suprimido, con queja, dado de baja y desconocido. La aceptación por el servidor de destino sigue sin revelar la carpeta final del buzón ni si una persona lo leyó. Haga que los reintentos creen intentos vinculados con la misma clave de evento lógico, para que el riesgo de duplicados y la evidencia sigan siendo visibles. No marque un reintento planificado como una nueva acción del cliente.

Reintente los fallos transitorios con límites estrictos

Para los resultados transitorios elegibles, programe un backoff exponencial con jitter, una cantidad finita de intentos y una antigüedad máxima en la cola. Use el comportamiento de reintento documentado por el proveedor y no agregue un bucle agresivo en la aplicación encima de un relay que ya reintenta. Mantenga la misma identidad lógica del mensaje y la misma comprobación de supresión en cada intento. Deje de reintentar cuando el destinatario quede suprimido, cambie el consentimiento, venza el evento, se revoque la identidad del remitente o llegue una respuesta permanente posterior. Aplique límites de frecuencia por tenant, dominio de destino, remitente y clase de fallo, para que la caída de un solo receptor no acapare la cola. Respete Retry-After o las indicaciones de aplazamiento documentadas cuando existan, pero nunca tome contenido arbitrario del mensaje como instrucciones de reintento. Genere alertas cuando aumente la antigüedad en la cola, se repitan códigos temporales, aparezcan dominios inusuales o haya intentos cerca de vencer. Un código transitorio puede ocultar un problema persistente de política o de reputación; los reintentos acotados dan tiempo para recuperarse, no permiso para ignorar la causa.

Suprima los fallos permanentes confirmados del destinatario

Un fallo permanente confirmado de la dirección o del buzón debe actualizar un registro de supresión propio del producto antes de que se envíe cualquier trabajo posterior. Guarde el tenant, la clave normalizada del destinatario, el alcance, el evento de origen, la categoría del estado y del diagnóstico, la hora de entrada en vigor y la referencia a la evidencia, sin exponer ampliamente la dirección. Aplique la supresión en el momento del envío, no solo al importar listas. Diferencie dirección no válida, dominio inexistente, rechazo por política, rechazo por contenido del mensaje, fallo de autenticación, cuota y reputación del remitente, porque las soluciones seguras son distintas. Un destinatario no válido justifica una supresión limitada a ese destinatario; un rechazo por autenticación del remitente debe pausar la configuración del remitente en lugar de suprimir a todos los destinatarios. Proteja la eliminación manual con una autorización sólida, un motivo y un historial de auditoría. Una reconfirmación o corrección debe crear una nueva decisión verificada, no borrar la evidencia anterior. Las listas de supresión de los proveedores son útiles, pero no sustituyen un registro de consentimiento y seguridad propio de la aplicación, sobre todo durante una migración de proveedor.

Evite los bucles de rebote y el backscatter

SMTP usa una ruta inversa nula para las notificaciones de estado de entrega, de modo que un fallo al entregar la notificación no genere otro rebote. Mantenga este comportamiento en los relays y no envíe respuestas automáticas a DSN, a respuestas automáticas ni a mensajes con señales de generación automática. El RFC 3834 ofrece recomendaciones para las respuestas automáticas de correo electrónico, incluidas las preocupaciones sobre bucles y amplificación. Nunca genere un rebote hacia una dirección From visible no verificada después de aceptar un mensaje sospechoso, porque las identidades de remitente falsificadas pueden convertir el sistema en una fuente de backscatter. Rechace los destinatarios no válidos durante la sesión SMTP siempre que sea posible, en lugar de aceptarlos y notificar más tarde a una dirección falsificada. Limite las respuestas automáticas por remitente y por conversación, y use identidades de respuesta controladas. Un webhook del producto o un evento de error interno suele ser más seguro que generar correo nuevo en Internet. Pruebe en fixtures aislados un From falsificado, un remitente de sobre nulo, DSN repetidos, encabezados Auto-Submitted, tráfico de listas de correo e informes malformados.

Autentique los eventos del proveedor antes de aplicarlos

Si un proveedor entrega eventos de rebote mediante webhooks, valide la firma o el mecanismo de autenticación documentado sobre la solicitud exacta antes de analizar los campos de negocio. Exija marcas de tiempo recientes, protección contra repeticiones, límites de tamaño del cuerpo y correlación con el tenant. Persista o encole el evento autenticado antes de devolver una respuesta correcta, y luego elimine duplicados con un identificador de evento estable del proveedor o con una clave compuesta conservadora que no pueda fusionar destinatarios ni intentos. Guarde la hora en que ocurrió el evento por separado de la hora de procesamiento, porque los eventos pueden llegar con retraso y fuera de orden. Rechace los eventos cuyo dominio de remitente, cuenta, espacio de trabajo, identificador de mensaje o alcance de destinatario no se puedan vincular con el tenant esperado. Rote los secretos de webhook por separado de las credenciales SMTP o de API. Supervise los fallos de firma, las tasas de duplicados, el retraso, los mensajes fallidos y los tipos de evento desconocidos. Un webhook autenticado demuestra el origen según el secreto configurado; no demuestra que el evento se haya asignado al trabajo interno correcto hasta que la correlación tenga éxito.

Diagnostique por familia de estado, no por la redacción que suponga

Empiece por el asunto del código de estado extendido: estado de la dirección, estado del buzón, estado del sistema de correo, estado de la red o del enrutamiento, estado del protocolo de entrega, estado del contenido o del formato del mensaje, o estado de seguridad y política. Luego use el código de detalle y el diagnóstico completo con la documentación vigente del receptor o del proveedor. Verifique la sintaxis del destinatario y el DNS del dominio en los fallos de dirección; la existencia del buzón y la evidencia de cuota en los fallos de buzón; MX, enrutamiento, TLS y la evidencia de red en los fallos de transporte; el tamaño, el MIME, la codificación y el contenido en los fallos del mensaje; y SPF, DKIM, DMARC, credenciales, política del remitente o reputación en los fallos de seguridad. Cambie una sola variable en cada nueva prueba controlada. No rote IP, dominios ni proveedores para eludir una decisión de política permanente. Conserve la respuesta original y revierta cualquier cambio de configuración que amplíe la autoridad del remitente o debilite la autenticación sin corregir la causa observada.

Mida la salud de los rebotes sin filtrar datos de los destinatarios

Haga seguimiento de la aceptación en el primer intento, los aplazamientos temporales, los fallos permanentes, la recuperación por reintento, los resultados desconocidos, las quejas, las supresiones y la antigüedad en la cola, por cohortes que respeten la privacidad. Entre las dimensiones útiles están el dominio del remitente, el dominio de destino con un nivel de agregación aprobado, la clase de mensaje, la revisión de la plantilla, el proveedor, la familia de estado y el tiempo. Evite direcciones completas, contenido de mensajes, bloques de diagnóstico o encabezados sin procesar en la analítica habitual. Separe la tasa de destinatarios no válidos de los fallos por política, autenticación, contenido, reputación e infraestructura transitoria; una única tasa de rebotes oculta causas sobre las que se puede actuar. Use denominadores basados en intentos por destinatario e informe los eventos tardíos dentro de su cohorte original. Defina las alertas a partir de referencias históricas y del riesgo de negocio, no de un porcentaje universal. Audite la aplicación de las supresiones y las excepciones manuales. Conserve solo la evidencia necesaria para las operaciones, la seguridad, las obligaciones legales y las disputas, y después elimínela o agréguela. Una tasa de rebotes baja no demuestra consentimiento, interacción ni llegada a la bandeja de entrada.

Cómo encaja SendHQ

SendHQ documenta el seguimiento de entregas y rebotes, así como las supresiones. Consulte la documentación actual para conocer el comportamiento admitido.

Preguntas frecuentes

Fuentes

• RFC 3464: formato de mensaje extensible para notificaciones de estado de entrega — RFC Editor
• RFC 3463: códigos de estado extendidos del sistema de correo — RFC Editor
• RFC 5321: protocolo simple de transferencia de correo (SMTP) — RFC Editor
• RFC 3834: recomendaciones para las respuestas automáticas al correo electrónico — RFC Editor