5 conceptos erróneos de SMTP que confunden a los remitentes de email
SMTP existe desde 1982. Cualquiera pensaría que ya lo tendríamos todo resuelto a estas alturas. Y, sin embargo, algunos de los problemas de entrega de email más persistentes se remontan a un puñado de conceptos erróneos obstinados sobre lo que realmente hace SMTP.
El protocolo hace un solo trabajo – transportar emails entre servidores – y hace ese trabajo bien. Pero no autentica tu identidad, no garantiza la llegada a la bandeja de entrada, no cifra tu contenido por defecto ni gestiona los rebotes de la forma que suponen la mayoría de los remitentes. Entender dónde termina SMTP y dónde empieza todo lo demás es la diferencia entre una infraestructura de email limpia y una que siempre está en llamas.
¿Qué es SMTP realmente?
SMTP – Protocolo de transferencia de correo simple – es un protocolo de transporte. Mueve el email de un servidor a otro. Ese es todo su trabajoPiensa en SMTP como el repartidor que recoge un paquete y lo deja en el muelle de carga del edificio de tu destinatario. Lo que sucede después – si hay alguien en casa, si el paquete es marcado por seguridad, si llega al escritorio correcto – está completamente fuera del control del conductor.
SMTP rige el protocolo de enlace entre servidores: el saludo EHLO, los comandos MAIL FROM y RCPT TO, la transferencia del mensaje y la respuesta final 250 OK confirmando la aceptación. Una vez que llega ese 250, SMTP considera que ha terminado su trabajo. Si el mensaje llega a la bandeja de entrada, a la carpeta de spam o a ninguna parte es una cuestión diferente – y ahí es donde viven la mayoría de los conceptos erróneos. Si quieres un recorrido completo por todo el proceso de envíos SMTP, lo hemos cubierto en detalle.
Mito 1: La entrega de SMTP significa entrega en la bandeja de entrada
Probablemente este sea el malentendido más caro en el email. Una respuesta 250 OK de un servidor de recepción significa que ese servidor aceptó tu mensaje – no que lo entregó en la bandeja de entrada. El servidor de recepción es libre de hacer lo que quiera con el mensaje tras su aceptación: aplicarle un filtro al 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, gobernada por 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 toca directamente SMTP. Cuando estés intentando depurar una baja tasa de aperturas o una alta llegada a spam, no analices solo los logs de SMTP. Fíjate en tu reputación como remitente, en tu configuración de autenticación y en la salud de tu lista. Nuestra guía sobre los mitos comunes de la entregabilidad del email es un buen lugar para empezar a desenredar ambas cosas.
Consejo profesional: La confusión entre entrega y entregabilidad no es rara, es endémica. El informe Estado de la entregabilidad del email de 2025 de Mailgun incluyó una encuesta a más de 1100 remitentes y descubrió que casi el 88 % no podía definir correctamente qué evalúan las métricas de tasa de entrega. El informe profundiza en lo que realmente están haciendo (y no haciendo) los remitentes para llegar a la bandeja de entrada, desde la adopción de la autenticación hasta los hábitos de higiene de listas. Vale la pena leerlo si quieres comparar tu programa y establecer un nivel de referencia frente al sector.
Mito 2: SMTP gestiona la autenticación del remitente
SMTP se diseñó en una época en la que se confiaba más. El protocolo original no tiene ningún mecanismo para verificar que el remitente es quien dice ser – simplemente toma la dirección MAIL FROM al pie de la letra. Por eso la suplantación de email ha sido un problema durante décadas.
La autenticación se superpone a SMTP, no está integrada en él. SPF (convenio de remitentes), DKIM (DomainKeys Identified Mail) y DMARC (Domain-based Message Authentication, Reporting, and Conformance) operan de forma independiente al protocolo de enlace de SMTP. SMTP AUTH – 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 extra independiente, definido en el RFC 4954, no en la especificación central de SMTP.
Lo que esto significa en la práctica: un 250 OK de un servidor de recepción no sirve para confirmar que tus registros de autenticación estén en orden. Puedes transmitir con éxito un mensaje por SMTP y aun así ser marcado como correo no deseado o ser rechazado porque tu registro SPF esté dañado o tu firma DKIM no se pueda verificar. Arregla primero la autenticación – SMTP no lo hará por ti. Nuestra guía de autenticación de emails recorre la configuración de SPF, DKIM y DMARC desde cero.
Consejo profesional: Los requisitos de autenticación se están endureciendo en todos los ámbitos, y no solo en Gmail y Yahoo. En mayo de 2025, Microsoft comenzó a hacer cumplir los requisitos de SPF, DKIM y DMARC para los remitentes que llegan a las bandejas de entrada de Outlook, Hotmail y Live.com. Si realizas envíos de más de 5000 mensajes al día y no has auditado tus registros últimamente, ahora es el momento. El análisis de Mailgun sobre los requisitos de los remitentes de Microsoft para 2025 cubre exactamente qué cambió y qué debes hacer al respecto.
Mito 3: SMTP está cifrado por defecto
Por defecto, el SMTP clásico realiza los envíos de todo en texto sin formato. El encabezado del email, el contenido del mensaje, las credenciales… todo ello potencialmente visible para cualquiera que esté haciendo un seguimiento de la conexión. Esta no era una preocupación crítica en los inicios de internet; 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íos:
STARTTLS
STARTTLS es una extensión de protocolo que permite a un cliente pasar a un plan mejor una conexión SMTP de texto sin formato existente a una cifrada. Tiene asistencia en los puertos 25 y 587. La palabra clave es «pasar a un plan mejor» – si el servidor de recepción no tiene asistencia para STARTTLS, la conexión puede volver al texto sin formato. A veces esto se llama TLS oportunista, y es el enfoque dominante para un servidor de servidor a servidor.
SMTPS (TLS implícito)
SMTPS realiza aperturas de una conexión cifrada con TLS desde el principio, sin fase de texto sin formato. Se ejecuta en el puerto 465 (para el envío de cliente a servidor) y es de las opciones más segura cuando ambas partes tienen asistencia para ello. La conclusión práctica: aplica siempre una configuración en tus envíos para usar TLS y lograr confirmar que tu ESP lo aplica. Nuestra análisis profundo sobre los puertos SMTP cubre las implicaciones de seguridad de la elección de cada puerto. No des por sentado que porque tu mensaje fue aceptado, la conexión estaba cifrada.
Mito 4: El puerto 25 es el puerto correcto para realizar envíos
El puerto 25 es el puerto SMTP original, que data de 1982. También es el puerto con el que es más probable que te metas en problemas.
La mayoría de los proveedores de buzones de email y proveedores de alojamiento imponen un bloqueo al puerto saliente 25 en redes que no son de servidores específicamente porque es muy abusado por los spammers. Si estás creando aplicaciones que realizan envíos de email y estás enrutando a través del puerto 25, te encontrarás con errores de conexión en muchas redes, y tus mensajes no saldrán.
Los puertos que debes conocer:
Puerto 587: El estándar moderno para el envío de email autenticado (SMTP con STARTTLS). Úsalo para el envío de cliente a servidor en casi todos los casos.
Puerto 465: Obsoleto durante un período, pero ahora ampliamente utilizado para SMTPS (TLS implícito). Muchos ESP, incluido Mailgun, tienen asistencia para ello.
Puerto 2525: Una alternativa práctica cuando el 587 sufre un bloqueo. Mailgun ofrece asistencia para esto.
Puerto 25: Solo como servidor de servidor a servidor. No para envíos de clientes. A menudo bajo bloqueo.
Para un desglose histórico completo y una recomendación clara para tu configuración, consulta nuestra guía de puertos SMTP.
Mito 5: Ejecutar tu propio servidor SMTP es más barato y fácil
Este mito tiende a surgir cuando los equipos quieren reducir sus costos de ESP o mantener la infraestructura de email internamente. La lógica parece razonable a primera vista: ¿qué tan difícil 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 de por qué. Ejecutar tu propio servidor significa que eres responsable de todo lo que SMTP no maneja: calentamiento de IP, procesamiento de quejas y cada rebote, gestión de la lista de supresión, suscripción de bucles de retroalimentación con los principales proveedores de buzón de emails, mantenimiento de certificados TLS, monitorización de listas de bloqueo y mantenerse al día con los requisitos cambiantes del remitente de Gmail, Yahoo y Microsoft. Ese es un trabajo a tiempo completo, y es un trabajo en el que los ESP han pasado 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 compartida con malas reputaciones, y cada nueva dirección IP enfrenta grandes obstáculos en la llegada a la bandeja de entrada hasta que un período de calentamiento establezca un historial de envíos.
Para la mayoría de los equipos, el servidor SMTP gestiona la complejidad de la infraestructura y te brinda logs, analíticas y herramientas de entregabilidad que, de otro modo, tendrías que crear tú mismo. Y si estás evaluando si quedarte en SMTP o pasar a una integración de API, nuestra comparativa entre SMTP y API establece las ventajas y desventajas claramente.
En resumen: Cómo hacer bien el SMTP
SMTP no es el enemigo. Es un protocolo notablemente duradero que ha estado enrutando email durante más de 40 años, y entender lo que realmente hace es el primer paso para crear una configuración de envíos limpia.
La versión corta: SMTP mueve tu mensaje del punto A al punto B. Todo lo demás (llegada a la bandeja de entrada, autenticación, cifrado, gestión de rebotes) es tu responsabilidad aplicar en tu configuración por encima de él. La buena noticia es que la infraestructura de email moderna, desde los protocolos de autenticación hasta los servicios de servidor gestionados, hace que esa superposición de capas sea sencilla si sabes por dónde empezar.
Si estás solucionando un error de envíos específico, nuestra guía de códigos de error SMTP te servirá de ayuda para decodificar exactamente qué te está diciendo el servidor de recepción y cómo solucionarlo.
