5 errores de concepto sobre SMTP que confunden a los remitentes de email

SMTP existe desde 1982. Cualquiera podría pensar que a estas alturas ya no habría ninguna duda al respecto. Sin embargo, algunos de los problemas más persistentes relacionados con la entrega de emails se deben a un puñado de falsas creencias difíciles de erradicar sobre qué hace realmente el SMTP.

Este protocolo tiene una única función (transportar emails entre servidores) y la cumple muy bien. Pero no autentica tu identidad, garantiza la llegada a la bandeja de entrada, cifra tu contenido por defecto ni gestiona los rebotes de la forma en que la mayoría de los remitentes creen. Entender hasta dónde llega el alcance de SMTP y dónde empieza todo lo demás es la diferencia entre una infraestructura de email clara y otra que hace aguas constantemente.

El SMTP, o Simple Mail Transfer Protocol (Protocolo simple de transferencia de correo), es un protocolo de transporte. Mueve el email de un servidor a otro. Esa es su única función. Imagina que SMTP es el repartidor que recoge el paquete y lo deja en la zona de carga del edificio de tu destinatario. Lo que suceda después (si hay alguien presente que lo recoja o no, si pasa o acaba retenido en el control de seguridad, o si llega o no al escritorio correcto) queda completamente fuera del control del repartidor.
SMTP rige el protocolo de enlace entre servidores: el comando EHLO (que inicia la conversación de la sesión SMTP), los comandos MAIL FROM y RCPT TO (que establecen la dirección de retorno y el destinatario del mensaje), la transferencia del mensaje y la respuesta final «250 OK» (que confirma la aceptación). Una vez que recibe el código de estado 250, SMTP considera que su trabajo ha terminado. Que el mensaje acabe en la bandeja de entrada, en la carpeta de spam o en ninguna parte es otra cuestión; y ahí es donde surgen la mayoría de las ideas equivocadas. Si quieres un recorrido completo por todo el proceso de envíos SMTP, aquí te lo explicamos en detalle.

Probablemente, este sea el malentendido más caro en el mundo del email. Cuando un servidor de recepción responde «250 OK», esto significa que el servidor ha aceptado tu mensaje, no que lo haya entregado en la bandeja de entrada. El servidor de recepción es libre de hacer lo que quiera con el mensaje una vez lo haya aceptado: puede filtrarlo como spam, ponerlo en cuarentena o descartarlo en silencio.

SMTP opera en la capa de transporte. La llegada a la bandeja de entrada es una cuestión de entregabilidad, que se rige por aspectos como la reputación como remitente, las señales de autenticación, el historial de interacción y las señales de contenido, ninguno de los cuales incumbe directamente a SMTP. Cuando estés intentando depurar una baja tasa de apertura o una elevada llegada a la carpeta de spam, no te limites a analizar los logs de SMTP. Fíjate en tu reputación como remitente, tu configuración de autenticación y la salud de tus listas. Nuestra guía sobre los mitos más comunes de la entregabilidad del email es un buen lugar para empezar a desentrañar estos conceptos.

SMTP se diseñó en una época en la que se desconfiaba menos. El protocolo original no cuenta con ningún mecanismo para verificar que el remitente es quien dice ser; simplemente toma la dirección MAIL FROM tal cual. Por eso, la suplantación de email lleva décadas siendo un problema.

La autenticación se asienta sobre el protocolo SMTP, no está integrada en él. Los protocolos de autenticación, como SPF (Marco de directivas de remitente), DKIM (DomainKeys Identified Mail) y DMARC (Autenticación, informes y conformidad de mensajes basada en dominios) operan de forma independiente del protocolo de enlace de SMTP. La extensión del protocolo SMTP SMTP AUTH (es decir, el mecanismo que requiere un nombre de usuario y una contraseña antes de que tu cliente de email entregue un mensaje) también es un complemento independiente, definido en el estándar oficial de Internet RFC 4954, no en la especificación central de SMTP.
¿Qué significa esto en la práctica? Recibir una respuesta «250 OK» de un servidor de recepción no sirve para confirmar que tus registros de autenticación estén en orden. Puedes transmitir correctamente un mensaje por SMTP y que aun así se marque como correo no deseado o se rechace porque tu registro SPF esté dañado o tu firma DKIM no se pueda verificar. Antes de nada, debes solucionar cualquier problema con la autenticación, SMTP no va a hacerlo por ti. Nuestra guía de autenticación de emails explica la configuración de SPF, DKIM y DMARC desde cero.

De forma predeterminada, el SMTP clásico envía todo en texto sin formato. El encabezado de los emails, el contenido de los mensajes, las credenciales… Y cualquiera que esté haciendo un seguimiento de la conexión puede, potencialmente, ver todo esto. Esta no era una preocupación crítica en los inicios de internet; sin embargo, hoy en día es un problema grave.
El cifrado llegó más tarde, como una capa separada. Dos opciones cubren la mayoría de los escenarios de envío:

STARTTLS
STARTTLS es una extensión de protocolo que permite a un cliente mejorar una conexión SMTP de texto plano existente, al convertirla en una cifrada. Es compatible con los puertos 25 y 587. La palabra clave es \»mejorar\», porque si el servidor de recepción no es compatible con STARTTLS, la conexión puede volver al texto plano. A veces, a esto se le denomina TLS oportunista (o cifrado oportunista) y es el enfoque dominante para la transmisión de servidor a servidor.

SMTPS (TLS implícito)
SMTPS abre una conexión cifrada con TLS desde el principio, sin fase en texto plano. Se ejecuta en el puerto 465 (para el envío de cliente a servidor) y es la opción más segura cuando ambas partes son compatibles. ¿Cuál es la principal conclusión? Configura tus envíos de modo que siempre usen TLS y confirma que tu ESP lo aplica. Nuestro análisis en detalle sobre los puertos SMTP explica las implicaciones de seguridad que conlleva la elección de cada puerto. No des por sentado que si tu mensaje se ha aceptado, la conexión estaba cifrada.

El puerto 25 es el puerto SMTP original, que data de 1982. También es el puerto con más posibilidades de darte problemas.
La mayoría de los ISP y proveedores de alojamiento bloquean el puerto saliente 25 en redes sin servidor central, precisamente porque los spammers hacen un mal uso del mismo. Si creas una aplicación que envía emails y la enrutas a través del puerto 25, vas a encontrarte con errores de conexión en muchas redes y tus mensajes no saldrán.
Qué puertos debes conocer:

Puerto 587: El estándar moderno para el envío autenticado de emails (SMTP con STARTTLS). Úsalo para el envío cliente-servidor en casi todos los casos.
Puerto 465: Obsoleto durante un período, pero ahora se utiliza ampliamente para SMTPS (TLS implícito). Muchos ESP, incluido Mailgun, son compatibles con este puerto.
Puerto 2525: Una alternativa práctica cuando el 587 está bloqueado. Mailgun es compatible.
Puerto 25: Solo para transmisión servidor-servidor. No apto para envíos desde clientes. A menudo bloqueado.

Para un desglose histórico completo y recomendaciones claras para tu configuración, consulta nuestra guía de puertos SMTP.

Este mito tiende a surgir cuando los equipos quieren reducir los costes de ESP o gestionar la infraestructura de email internamente. La lógica parece razonable a primera vista: ¿cómo de complicado puede ser un servidor SMTP?

En la práctica, mantener tu propia infraestructura SMTP es una de las formas más rápidas de degradar tu entregabilidad sin darte cuenta del motivo. Ejecutar tu propio servidor significa que eres responsable de todos los aspectos que SMTP no gestiona,como el calentamiento de IP, el procesamiento de rebotes y quejas, la gestión de listas de supresión, el registro de bucles de retroalimentación con los principales proveedores de servicios de email, el mantenimiento de certificados TLS y el seguimiento de las listas de bloqueo, además de mantenerte al día sobre los requisitos en continua evolución para los remitentes de Gmail, Yahoo y Microsoft. Es un trabajo a tiempo completo y los ESP llevan años creando herramientas para ello.

Más allá de los gastos generales de operaciones, los servidores autogestionados a menudo se encuentran en bloques de IP compartidas con una mala reputación, y las direcciones IP nuevas se enfrentan a grandes obstáculos a la hora de llegar a las bandejas de entrada hasta que pasan el período de calentamiento y se establece un historial de envíos.

Para la mayoría de los equipos, los servidores SMTP gestionan la complejidad de la infraestructura y te brindan registros, analíticas y herramientas de entregabilidad que, de otro modo, tendrías que crear por tu cuenta. Por último, si estás pensando si quedarte en SMTP o pasar a una integración de la API, nuestra comparativa entre SMTP y API establece claramente las ventajas y desventajas.

SMTP no es el enemigo. Es un protocolo muy duradero que lleva enrutando email más de cuarenta años, y entender qué hace es el primer paso para crear una configuración de envíos clara.

En resumen: SMTP mueve tu mensaje del punto A al punto B. La gestión de todo lo demás (llegada a la bandeja de entrada, autenticación, cifrado, gestión de rebotes) es tu responsabilidad y un aspecto adicional. La buena noticia es que la infraestructura de email moderna, desde los protocolos de autenticación hasta los servicios de servidores gestionados, hace que esa superposición de capas sea sencilla si sabes por dónde empezar.

Si estás intentando solucionar un error de envío específico, nuestra guía de códigos de error SMTP te servirá de ayuda para descifrar qué te está diciendo exactamente el servidor de recepción y cómo solucionarlo.

Author: The Sinch Mailgun team The Sinch Mailgun team shares news, best practices, and strategies to take your products and apps to the next level using email. Subscribe to our newsletter to get all the articles in your inbox!