landing · servicio de relay SMTP

¿Qué debería evaluar un equipo de producto al elegir un servicio de relay SMTP?

Evalúe un servicio de relay SMTP como un sistema controlado de envío de mensajes y de operación, no simplemente como un nombre de host y un puerto. Verifique el TLS obligatorio, los puertos de envío admitidos, los controles de SMTP AUTH, el aislamiento de credenciales, la verificación de dominios remitentes, la durabilidad de las colas, el comportamiento documentado ante respuestas 4xx y 5xx, las cuotas, los límites de tamaño de los mensajes, los eventos de estado de entrega, la gestión de rebotes y quejas, el alcance de las supresiones, el aislamiento entre inquilinos, la observabilidad y la posibilidad de exportar. Pruebe exactamente los clientes y las redes que se van a conectar. Una respuesta 250 del relay transfiere la responsabilidad del tratamiento posterior; no demuestra la entrega al servidor receptor ni la llegada a la bandeja de entrada.

Distinga el envío (submission) del relay entre servidores

Los equipos de producto suelen usar «relay SMTP» para referirse a un servicio autenticado que acepta mensajes salientes de una aplicación y los transfiere hacia los servidores de correo de los destinatarios. Los estándares distinguen esa función de envío (submission) del relay entre servidores de correo. RFC 6409 reserva el puerto 587 para el envío de mensajes y permite que los servidores de envío apliquen reglas de autenticación, de política y de corrección de mensajes distintas de las del relay en el puerto 25. Pregunte a cada proveedor qué interfaz está contratando: envío autenticado para aplicaciones, relay entrante entre servidores o ambos. Registre el nombre de host, los puertos, los modos de cifrado, los mecanismos de autenticación, las reglas de remitente y las extensiones SMTP admitidas. Un servicio que funciona para un cliente de escritorio puede no servir para una cola de gran volumen, mientras que un relay entre servidores puede rechazar la autenticación de una aplicación. Pruebe la función exacta en lugar de suponer que todos los endpoints SMTP se comportan igual.

Exija un envío protegido y una autenticación segura

No envíe credenciales ni contenido de mensajes por una conexión sin protección. RFC 8314 considera obsoleto el envío en texto claro, recomienda TLS 1.2 o posterior para el tráfico de envío y prefiere TLS implícito cuando esté disponible. RFC 4954 define SMTP AUTH y exige que los servidores ofrezcan una configuración que no permita mecanismos de contraseña en texto claro sin TLS o una protección equivalente. Durante la evaluación, confirme la validación de certificados, las versiones de TLS admitidas, los puertos de TLS implícito y STARTTLS, el comportamiento ante degradaciones y si la autenticación se rechaza antes del cifrado. Guarde las credenciales del relay en un almacén de secretos del lado del servidor, cree principals separados para cada entorno y aplicación, y rótelas sin tiempo de inactividad. Determine si los permisos pueden restringir los dominios remitentes o las clases de mensajes. Una única credencial compartida entre los inquilinos de producción hace que la revocación, la atribución y la contención de incidentes sean innecesariamente amplias.

Compruebe la compatibilidad de clientes y redes

Haga un inventario de todos los remitentes antes de elegir un relay: bibliotecas de aplicaciones, workers de colas, dispositivos de monitoreo, software de negocio, equipos multifunción y sistemas heredados. Algunos admiten el puerto 587 con STARTTLS, otros requieren TLS implícito y otros no pueden validar certificados modernos ni autenticarse de forma segura. Esa limitación es un motivo para aislar o sustituir el cliente, no para debilitar la cuenta del relay de forma global. Pruebe la resolución DNS, IPv4 e IPv6, las reglas del firewall saliente, los tiempos de espera de conexión, el comportamiento de los proxies, la negociación TLS, AUTH, las extensiones EHLO, los límites de tamaño de los mensajes y las direcciones internacionalizadas si son necesarias. Los entornos en la nube pueden restringir el puerto 25, así que los puertos de envío alternativos de un proveedor importan en la operación. Ejecute la prueba de compatibilidad desde cada red de producción y no desde el portátil de un desarrollador. Documente una configuración admitida y bloquee el paso a texto claro o a un nombre de host no aprobado.

Comprenda la aceptación, las colas y los reintentos

Las respuestas SMTP forman parte del contrato de la aplicación. Una respuesta 2xx indica que ese comando se completó con éxito; tras la aceptación final del mensaje, el relay asume la responsabilidad de la entrega o de una notificación de fallo posterior según las reglas de SMTP. Una respuesta 4xx es transitoria y puede justificar un reintento, mientras que una respuesta 5xx es permanente para el comando intentado y normalmente requiere una corrección en lugar de una repetición. Pregunte cuánto tiempo mantiene el servicio los mensajes en cola, qué fallos reintenta, cuál es su calendario de backoff, cuándo genera una notificación de estado de entrega y si el correo en cola sobrevive a un fallo regional. Su aplicación sigue necesitando un identificador de trabajo estable, reintentos de conexión acotados y protección frente a resultados ambiguos. Si la conexión se corta después de DATA, crear a ciegas un trabajo nuevo puede duplicar el correo. Guarde el identificador de mensaje del relay cuando esté disponible y concilie antes de volver a enviar.

Mida la capacidad con las unidades correctas

Los límites del relay pueden aplicarse a destinatarios por día móvil, mensajes por segundo, conexiones simultáneas, destinatarios por transacción, bytes por mensaje, tamaño de los adjuntos tras la codificación y profundidad de la cola almacenada. Un plan que anuncia un gran total mensual puede, aun así, limitar un pico de lanzamiento o una conmutación por error. Solicite los límites actuales de cada cuenta y región, y luego modele el tráfico normal, pico, de reintentos y de conmutación por error completa por destinatario, no solo por sesiones SMTP. Determine si el relay devuelve una respuesta transitoria cuando aplica limitación y si su cliente la respeta sin abrir conexiones excesivas. Pruebe la contrapresión por debajo del techo aprobado y configure alertas sobre la cuota restante, la saturación de conexiones, la antigüedad de la cola y las respuestas de limitación. No aumente la concurrencia hasta que el proveedor y el ecosistema receptor puedan soportar el tráfico. La capacidad también es un límite frente al abuso, así que evalúe los controles por credencial y por inquilino, no solo un máximo único para toda la cuenta.

Verifique la autenticación del remitente y la incorporación de dominios

Un relay debería ofrecer un flujo de incorporación de dominios exacto y revisable. Confirme cómo verifica la propiedad, genera los selectores DKIM, configura el dominio MAIL FROM del sobre e informa del estado de la autenticación. SPF autoriza identidades SMTP y debe integrarse en un registro válido existente en lugar de publicarse como un segundo registro SPF seleccionable. DKIM asocia un dominio de firma con una firma criptográfica. DMARC evalúa si un identificador SPF o DKIM validado está alineado con el dominio From visible y permite que el propietario del dominio publique una política y reciba informes. Pregunte quién controla las claves de firma, la rotación de selectores, la alineación del return path y los cambios de DNS durante la migración. Envíe mensajes controlados e inspeccione los encabezados recibidos antes de pasar a producción. Un panel que muestra «verificado» no demuestra que todos los flujos legítimos estén alineados, y la autenticación no garantiza la llegada a la bandeja de entrada.

Exija eventos de resultado utilizables y correlación

El envío SMTP por sí solo proporciona respuestas a los comandos, mientras que la operación de un producto necesita los resultados posteriores. Evalúe si el servicio expone eventos de entrega al servidor receptor, rebote, queja, rechazo, demora y supresión mediante webhooks autenticados, colas o API. Determine los identificadores de evento, el comportamiento de reintentos, las garantías de orden, la retención, la verificación de firmas y si los datos del destinatario pueden ocultarse. RFC 3461 define una extensión SMTP para solicitar notificaciones de estado de entrega en determinadas condiciones, pero los sistemas de eventos de los proveedores pueden ofrecer datos operativos más estructurados. Asocie el ID de trabajo de su aplicación con el ID de mensaje del relay en el momento de la aceptación y luego incorpore los eventos de forma idempotente. Trate la aceptación, la entrega a un servidor de correo del destinatario, la queja, el rebote y la llegada a la bandeja de entrada como conceptos distintos. Las observaciones de aperturas y clics requieren una revisión de privacidad aparte y no deberían sobrescribir la verdad del transporte.

Evalúe los límites de supresión y de reputación

Un relay de producción debe hacer operativamente posible la respuesta ante rebotes y quejas. Pregunte si mantiene listas de supresión a nivel de todo el proveedor, de cuenta, de subcuenta, de dominio o de inquilino; qué tipos de evento agregan entradas; si se puede consultar una dirección antes del envío; y cómo se autorizan las eliminaciones. Los rebotes permanentes y las quejas deberían detener los intentos rutinarios futuros, mientras que las demoras temporales necesitan una política aparte. En una cuenta compartida, determine si la queja de un inquilino puede suprimir a un destinatario legítimo de otro inquilino o afectar a la reputación de toda la cuenta. Revise las opciones de IP dedicada frente a compartida solo en relación con el volumen real, las necesidades de aislamiento, la responsabilidad del calentamiento y la respuesta ante incidentes. Ninguna elección de red compensa el correo inesperado, los datos de destinatarios deficientes o las quejas ignoradas. Exija paneles y alertas para los cambios en rebotes y quejas, pero conserve sus propios eventos normalizados para que una migración no borre el historial operativo.

Pruebe la separación entre inquilinos, la observabilidad y la recuperación ante fallos

Cree dos inquilinos de prueba y demuestre que cada credencial solo puede enviar desde sus dominios aprobados, ver solo sus mensajes y consumir solo sus propios límites. Intente una dirección From no autorizada, una credencial revocada, un mensaje demasiado grande, un destinatario no válido, la superación del límite de frecuencia, un fallo de TLS, un tiempo de espera de red, un envío duplicado, un destinatario rebotado, una queja, una entrega demorada y un webhook repetido. Verifique que los registros contengan un ID de mensaje estable, el inquilino, la clase de respuesta depurada, el número de intentos y los tiempos, sin copiar credenciales ni cuerpos de mensajes. Pida al proveedor el historial de estado, la comunicación de incidentes, el comportamiento de conmutación por error regional, la residencia de los datos, la retención, los formatos de exportación y la escalada del soporte. Una promesa de nivel de servicio solo es útil cuando la aplicación puede detectar su incumplimiento y recuperarse. Haga un ejercicio de conmutación por error con mensajes en cola y demuestre que la configuración alternativa tiene dominios verificados, credenciales, cuotas, eventos y estado de supresión.

Compare el relay SMTP con una API de correo

El envío SMTP es valioso cuando el software existente ya se comunica mediante SMTP o cuando importa una interfaz de transporte de correo independiente del proveedor. Una API de correo electrónico HTTPS puede proporcionar validación estructurada, identificadores de recursos, semántica de lotes y recursos de eventos directos que son más fáciles de controlar para una aplicación nueva. Los equipos que requieren compatibilidad con SMTP heredado deben seleccionar un relay documentado o crear un adaptador estrictamente controlado. Los equipos que crean nuevos flujos de trabajo de producto pueden comparar una capa de API en autorización, colas, eventos, límites de tenant, costo de migración y propiedad operativa en lugar de asumir que SMTP es automáticamente más portable.

Haga una evaluación del relay con puntuación

Construya una matriz de requisitos antes de solicitar propuestas. Pondere la seguridad del envío, la compatibilidad de los clientes, la incorporación de dominios, la alineación de la autenticación, la durabilidad de las colas, la semántica de reintentos, las cuotas, la completitud de los eventos, la verificación de webhooks, el alcance de las supresiones, el aislamiento entre inquilinos, la observabilidad, el tratamiento de los datos, el diseño regional, el soporte, la posibilidad de exportar y el costo operativo total. Marque los fallos eliminatorios por separado de las preferencias: el paso a texto claro, la ausencia de una vía para rebotes o quejas, eventos no verificables, credenciales compartidas, la falta de comprobaciones de propiedad del dominio o límites inferiores a la demanda pico no deberían compensarse con un precio bajo. Ejecute el mismo conjunto de pruebas controladas contra cada finalista y conserve las transcripciones sin secretos. Puntúe el comportamiento documentado actual, no las promesas de la hoja de ruta. Antes de migrar, ensaye el envío doble a bajo volumen, los cambios de DNS, la conciliación de eventos, la transferencia de supresiones, la rotación de credenciales, la reversión y la revocación final del relay antiguo.

Preguntas frecuentes

¿Cuál es la diferencia entre el envío (submission) SMTP y el relay?

El envío acepta correo saliente de un cliente autenticado, normalmente por el puerto 587 y con una política específica de envío. El relay describe la transferencia entre servidores de correo, habitualmente por el puerto 25, con reglas de confianza y de enrutamiento distintas.

¿Un relay SMTP debe exigir TLS?

Sí, para el envío desde aplicaciones. Exija TLS con validación de certificados y rechace el uso de credenciales o el envío de mensajes cuando no esté disponible el nivel de confidencialidad configurado. Pruebe tanto el puerto admitido como el comportamiento ante degradaciones.

¿Un 250 de SMTP significa que el destinatario recibió el mensaje?

No. Significa que el servidor asumió la responsabilidad del comando SMTP o del mensaje completados. Las notificaciones de estado de entrega o los eventos posteriores del proveedor describen la entrega al servidor receptor, el rebote, la queja, la demora o el rechazo.

¿Cómo debería una aplicación reintentar los fallos SMTP?

Reintente los fallos transitorios 4xx y de red con backoff acotado y una identidad de trabajo estable. Corrija los fallos 5xx antes de otro intento y concilie los fallos ambiguos posteriores a DATA para evitar mensajes duplicados.

¿Los relays SMTP gestionan DKIM, SPF y DMARC?

Las capacidades varían. Confirme quién firma con DKIM, qué dominio MAIL FROM se usa, qué mecanismo SPF se requiere y si SPF o DKIM están alineados con el dominio From visible para DMARC.

¿Cuándo es preferible una API de correo a un relay SMTP?

Una API puede ser preferible para aplicaciones nuevas que necesitan validación estructurada, identificadores de recursos, autorización explícita por inquilino, resultados por lote y recursos de eventos. SMTP sigue siendo útil para el software existente compatible con SMTP.

Fuentes

Siga aprendiendo

Protocolo de correo SMTP: cómo circula el correo de una aplicaciónAprenda cómo el envío (submission) SMTP, el relay, los sobres, los códigos de respuesta, TLS, los reintentos y el contenido del mensaje dan forma al flujo de correo de una aplicación.Guía de implementación de una API de correo electrónico para equipos de productoDiseñe una integración segura con una API de correo con dominios verificados, envíos en cola, identificadores estables, reintentos controlados, eventos de entrega, supresión y aislamiento entre inquilinos.