término · protocolo de correo smtp

¿Qué es el protocolo de correo SMTP y cómo afecta al correo de una aplicación?

SMTP, o Simple Mail Transfer Protocol, es el protocolo estándar que usan los sistemas de correo para enviar, retransmitir y traspasar el correo saliente. Normalmente, una aplicación entrega un mensaje terminado a un servicio de envío autenticado; luego, los servidores de correo usan comandos SMTP y el enrutamiento por DNS para llevarlo hacia cada destinatario. Las respuestas SMTP indican si un salto concreto aceptó o rechazó a un destinatario, pero la aceptación no equivale a la llegada a la bandeja de entrada. Las aplicaciones siguen necesitando colas duraderas, reintentos seguros, identificadores de mensaje, autenticación y procesamiento de rebotes.

SMTP transfiere el correo entre sistemas responsables

SMTP es un protocolo de transferencia de almacenamiento y reenvío. Un cliente abre una sesión con un servidor, se identifica, presenta un remitente del sobre, propone uno o más destinatarios del sobre y transmite el contenido del mensaje cuando el servidor acepta recibirlo. El servidor puede aceptar algunos destinatarios y rechazar otros, así que el estado pertenece a un destinatario y a una transacción, no solo al mensaje en su conjunto. Una vez que un servidor acepta la responsabilidad, puede entregar localmente o retransmitir el mensaje hacia otro sistema seleccionado mediante los registros Mail Exchanger del DNS. Este diseño salto a salto es la razón por la que una aplicación no debe reducir el estado del correo a un único booleano de enviado. La aplicación, el servicio de envío, el relay, el servidor receptor y el sistema de filtrado del buzón conocen, cada uno, partes distintas del resultado. SMTP mueve el mensaje entre sistemas, mientras que los registros a nivel de producto y los eventos del proveedor hacen que ese movimiento sea comprensible para usuarios y operadores.

El envío y el relay son roles distintos del protocolo

El RFC 6409 separa el envío de mensajes (submission) del relay de mensajes. El envío es el primer traspaso desde un usuario o una aplicación autorizados a un Message Submission Agent, normalmente por el puerto 587. El relay es la transferencia entre Message Transfer Agents y usa convencionalmente el puerto 25. Los servicios de envío pueden exigir autenticación, validar o completar campos del mensaje y aplicar políticas de remitente, porque saben quién introduce correo nuevo. Los servidores de relay públicos deben interoperar con otros dominios y siguen reglas de confianza distintas. Por eso, el código de la aplicación debe conectarse al endpoint de envío documentado por el proveedor o usar su API HTTP, no abrir conexiones arbitrarias por el puerto 25 hacia los servidores de destino. Esta división también aclara las credenciales: un nombre de usuario o token SMTP autoriza el envío a un servicio concreto; no otorga autoridad sobre el dominio de destino. Mantenga las credenciales de envío en el servidor, limítelas a la carga de envío cuando el proveedor lo permita y rótelas sin incrustarlas en el contenido de los mensajes ni en software cliente.

El sobre SMTP es distinto de los encabezados visibles del mensaje

Una transacción SMTP lleva un sobre con `MAIL FROM` y uno o más comandos `RCPT TO`. El contenido transferido sigue, por separado, el formato de mensajes de Internet definido por el RFC 5322, con campos como From, To, Date, Subject y Message-ID, además de un cuerpo. Los estándares MIME amplían ese contenido para HTML, partes alternativas, adjuntos y datos no ASCII. El remitente del sobre es la dirección que se usa para los fallos de transporte y puede ser distinta del autor visible en From. Los destinatarios del sobre también pueden diferir de los campos To y Cc visibles, como ocurre con Bcc. No construya estas estructuras concatenando cadenas no confiables. Use una biblioteca de mensajes mantenida, valide las direcciones, bloquee la inyección de saltos de línea en los campos de encabezado y conserve un Message-ID estable. Al diagnosticar problemas, revise ambas capas: un campo From visible correcto no puede reparar una identidad de sobre no autorizada, y un sobre válido no hace que un MIME malformado se muestre correctamente.

Lea la transacción como una máquina de estados

Una sesión básica de Extended SMTP empieza con un saludo del servidor y luego `EHLO`, para que el servidor anuncie sus extensiones. En el envío, el cliente puede negociar TLS y autenticación. Después, una transacción de correo usa `MAIL FROM`, un `RCPT TO` por destino, `DATA`, el mensaje completo terminado según el encuadre de SMTP y `QUIT`. No tome el ejemplo como motivo para implementar manualmente el protocolo a nivel de conexión; las bibliotecas SMTP maduras manejan con más seguridad los finales de línea, la transparencia de puntos, la negociación de capacidades, la autenticación y el estado de TLS. Instrumente la biblioteca a nivel de categoría de comando y de código de respuesta, sin registrar credenciales ni cuerpos de mensaje completos. Registre qué destinatario falló, en qué etapa, y si el servidor había aceptado la responsabilidad después de los datos del mensaje. Ese límite determina si un reintento es apropiado, si es posible un duplicado y si el fallo llegará en una notificación de estado de entrega posterior en lugar de en una respuesta inmediata.

Clasifique los códigos de respuesta antes de decidir si reintentar

Las clases de respuesta SMTP indican qué hacer. Una respuesta 2xx indica que ese comando se completó correctamente. Una respuesta 4xx es una finalización negativa transitoria, así que un remitente con cola puede reintentar después de una espera. Una respuesta 5xx es una finalización negativa permanente para el comando intentado y normalmente requiere una corrección, una supresión o una investigación humana, en lugar de reintentos repetidos. Los códigos de estado extendidos agregan un diagnóstico estructurado `X.Y.Z` para condiciones de dirección, buzón, sistema, enrutamiento, protocolo, contenido o seguridad y política. Conserve tanto el código numérico como el texto del servidor, porque ambos pueden aportar valor diagnóstico, pero no exponga ampliamente respuestas sin procesar que contengan datos de destinatarios. Aplique backoff exponencial con jitter y una vida máxima en la cola a los fallos transitorios. Nunca reintente de forma tan agresiva que un problema temporal del destino se convierta en tráfico abusivo. Ante un fallo permanente de la dirección, detenga los envíos automáticos a ese destino y actualice el estado de supresión. Ante un fallo de política o de autenticación, corrija la identidad, el DNS, las credenciales o el contenido antes de otro intento.

Use un envío cifrado y autenticado

SMTP nació como un protocolo de transporte entre redes con supuestos de confianza distintos, así que el envío seguro depende de extensiones y de la política de despliegue. STARTTLS convierte una conexión SMTP en una conexión TLS, tras lo cual el cliente debe descartar las capacidades conocidas antes del handshake y volver a emitir `EHLO`. El RFC 8314 actualiza las recomendaciones de envío al considerar obsoletos el acceso y el envío en texto claro, y describe el TLS implícito para el envío. SMTP AUTH, estandarizado en el RFC 4954, permite que un servidor de envío autentique a un cliente mediante los mecanismos anunciados. Use el nombre de host, el puerto, el modo TLS y las instrucciones de autenticación vigentes del proveedor, en lugar de adivinar una combinación. Valide el certificado del servidor y no vuelva en silencio al texto claro cuando la carga de trabajo requiera un envío protegido. Guarde las contraseñas o tokens en un gestor de secretos, use credenciales separadas por entorno y deshabilite los mecanismos de autenticación obsoletos. TLS protege un salto de la conexión; no autentica al autor del mensaje ante cada receptor posterior ni reemplaza la alineación de identidades de SPF, DKIM y DMARC.

Diagnostique un fallo del correo de una aplicación salto a salto

Empiece por el registro de salida duradero de la aplicación: ¿el evento del producto estaba autorizado y solo un trabajo de la cola lo reclamó? Después revise el envío: resolución DNS, conexión TCP, negociación TLS, validación del certificado, autenticación, autorización del remitente del sobre, respuestas por destinatario y respuesta final a DATA. Si el servicio de envío aceptó el mensaje, deje de repetir la solicitud a ciegas y siga su identificador de mensaje y su flujo de eventos. Distinga un estado procesado por el proveedor de la aceptación por el servidor receptor. Un rebote posterior todavía puede informar un fallo permanente después de la aceptación inicial. Si el servidor receptor aceptó el mensaje, investigue los resultados de autenticación, la reputación, la política del destinatario, el contenido y la clasificación del buzón, en lugar de llamarlo un fallo de transporte SMTP. Compruebe las identidades del sobre y de los encabezados, y conserve las marcas de tiempo, los códigos de respuesta, la cantidad de intentos en la cola y los identificadores del proveedor. Use destinatarios controlados para las pruebas. Nunca pegue credenciales SMTP de producción ni mensajes completos de clientes en tickets, prompts, el historial de la terminal ni herramientas públicas de diagnóstico.

Separe la aceptación, la entrega y la llegada a la bandeja de entrada

La precisión del protocolo importa en las interfaces de producto. La aceptación por la aplicación significa que el sistema local registró una solicitud. La aceptación en el envío significa que el primer servicio de correo aceptó la responsabilidad de procesarla. La entrega al servidor receptor significa que el servidor SMTP de destino devolvió éxito en el traspaso. La llegada a la bandeja de entrada es una decisión posterior de política y clasificación dentro del entorno receptor. Un mensaje puede superar un estado y fallar o clasificarse de otra manera en el siguiente. SMTP aporta evidencia directa sobre la transacción en curso y puede producir notificaciones de estado de entrega posteriores, pero no expone la carpeta final del destinatario. Guarde estos estados de forma independiente, en lugar de etiquetar cada respuesta 250 como entrega en la bandeja de entrada. Un evento del proveedor que incluya la respuesta SMTP de éxito del destino puede respaldar un estado de entregado al servidor. Un rebote respalda la gestión de fallos o de supresión. Ninguno de los dos respalda una promesa sobre la visibilidad, la lectura o la interacción. Este modelo mantiene los estados veraces y evita reintentos inseguros una vez que la responsabilidad ya se transfirió.

Use la API documentada de SendHQ

Una aplicación puede comunicarse mediante SMTP a través de una biblioteca de proveedor o llamar a una API de correo electrónico HTTP cuyo proveedor gestiona el transporte de correo de Internet bajo esa interfaz. SendHQ proporciona una API de correo electrónico con alcance por espacio de trabajo con comprobaciones de dominios verificados, recursos de mensajes salientes y entrantes, eventos, supresiones, bandejas de entrada y límites de recursos por espacio de trabajo. Su API HTTP puede proporcionar solicitudes estructuradas, identificadores y eventos junto con el envío SMTP directo. No cambia el comportamiento del servidor de destino ni establece la aceptación SMTP, la llegada a la bandeja de entrada ni la interacción del destinatario.

Preguntas frecuentes

¿Qué significa SMTP?

SMTP significa Simple Mail Transfer Protocol (protocolo simple de transferencia de correo). Define cómo los clientes y servidores de correo envían y transfieren mensajes salientes mediante comandos, respuestas, sobres, datos del mensaje y extensiones para capacidades como la autenticación y TLS.

¿SMTP se usa para leer el correo de una bandeja de entrada?

No. SMTP sirve principalmente para enviar y transferir correo saliente. El acceso a la bandeja de entrada usa otras interfaces, como IMAP, POP, una API de buzón específica del proveedor o una API de correo para aplicaciones que expone los mensajes entrantes almacenados.

¿Cuál es la diferencia entre los puertos 25, 587 y 465?

El puerto 25 se usa convencionalmente para el relay entre servidores. El puerto 587 es el servicio estándar de envío de mensajes y suele negociar TLS. El puerto 465 está registrado para el envío sobre TLS implícito. Siga el endpoint y el modo de seguridad documentados por el proveedor, en lugar de cambiar de puerto a modo de prueba.

¿Un éxito SMTP demuestra que el correo llegó a la bandeja de entrada?

No. Una respuesta correcta solo demuestra que el servidor SMTP que respondió aceptó el comando correspondiente o la responsabilidad del mensaje. El sistema receptor todavía puede aplicar políticas posteriores, generar un fallo diferido o clasificar el correo aceptado fuera de la bandeja de entrada principal.

¿Debe una aplicación reintentar cada respuesta SMTP 4xx?

Un código 4xx indica un resultado negativo transitorio, pero los reintentos deben usar una cola duradera, backoff exponencial con jitter, una vida útil finita y límites de intentos que tengan en cuenta al destinatario. Investigue los fallos temporales repetidos en lugar de reintentar indefinidamente.

¿Una API HTTP de correo reemplaza a SMTP?

Puede reemplazar a SMTP en el código de la aplicación, pero el proveedor normalmente sigue usando SMTP para comunicarse con los sistemas de correo de los destinatarios. Una API agrega autenticación estructurada, payloads, delimitación de recursos, identificadores y manejo de eventos por encima de la capa de transporte.

Fuentes

Siga aprendiendo

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 mediante dominios verificados, envíos en cola, identificadores estables, reintentos controlados, eventos de entrega, supresión y aislamiento entre tenants.