SMTP es el protocolo que usan los servidores para enviarse correo entre sí. Define cómo se entrega un mensaje de un servidor a otro, pero no comprueba nada: en el sobre puede ir escrito cualquier remitente. De ahí vienen SPF, DKIM y DMARC, que se inventaron para tapar ese hueco.
Dicho de otra forma: es el servicio de reparto del correo electrónico. Y como en el correo de papel, en el sobre puedes escribir el remite que te dé la gana — nadie lo comprueba al recogerlo.
Hace una cosa: mover mensajes. Establece la conversación entre el servidor que envía y el que recibe, y define las órdenes de esa conversación: quién manda, a quién, y aquí va el contenido.
No hace nada más. No comprueba identidades, no cifra por sí solo y no decide si un correo es legítimo. Se diseñó en los años ochenta, cuando los pocos servidores que había en la red se conocían entre ellos y nadie preveía que alguien fuera a mentir.
Ese es el detalle que explica todo lo demás del glosario: toda la autenticación del correo existe para tapar un hueco que SMTP dejó abierto. El registro SPF apareció para decir qué servidores pueden hablar en tu nombre, DKIM para firmar el mensaje y DMARC para atar los dos cabos. Ninguno forma parte de SMTP: son capas añadidas encima.
Aquí está la confusión que arrastra medio sector.
Cuando SMTP entrega un mensaje, primero mantiene una conversación con el servidor receptor: de quién es —la orden MAIL FROM— y para quién —la orden RCPT TO—. Eso es el sobre. Y después envía el contenido, que lleva dentro sus propias cabeceras: From:, To:, Subject:.
La dirección del sobre y la del «De» que ve tu cliente son dos cosas distintas y pueden no coincidir. SMTP lo permite sin problema.
Por eso el registro SPF verifica el sobre y DKIM firma la cabecera, y por eso DMARC tuvo que inventarse para comprobar que las dos apunten al mismo sitio.
| Puerto | Para qué | Cifrado |
|---|---|---|
| 25 | De servidor a servidor. El reparto entre proveedores | Opcional, se negocia |
| 587 | Envío desde tu programa o tu aplicación | STARTTLS: empieza en claro y se cifra después |
| 465 | Lo mismo que el 587 | Cifrado desde el primer byte |
| 2525 | Recambio cuando el alojamiento bloquea los otros dos | Depende del proveedor |
El 25 no es para ti. Es el que usan los servidores entre ellos para repartirse el correo del mundo. Casi todas las conexiones domésticas lo tienen bloqueado y muchos alojamientos también, precisamente porque es por donde se enviaba el spam masivo. Si intentas mandar correo autenticado por el 25, lo normal es que no salga.
Y el 2525 no existe oficialmente. No lo reconoce ningún organismo, pero casi todas las plataformas de envío lo admiten porque resuelve un problema muy real: hay alojamientos que bloquean el 587 y el 465 para evitar que sus clientes envíen spam. Cuando eso pasa, el 2525 suele ser la única salida. Si tu proveedor te lo ofrece, funciona igual que el 587.
La mayoría de las guías en español —incluidas algunas de las que mejor posicionan— siguen diciendo que el 465 está obsoleto, que «el 587 se introdujo como su sucesor» o que es un «puerto heredado». Eso fue cierto entre 1998 y 2018.
En 2018 la especificación que regula esto dio marcha atrás: volvió a registrar oficialmente el 465 para envío con cifrado desde el inicio, y recomienda usarlo por delante del 587.
El motivo es de seguridad. En el 587 la conexión empieza sin cifrar y se cifra después, con una orden. Alguien que esté en medio puede borrar esa orden de la respuesta del servidor, y si tu programa está configurado en modo «cífralo si se puede», seguirá adelante en claro con tu contraseña dentro. En el 465 eso no puede pasar: no hay ningún momento sin cifrar.
Los dos son seguros si están bien configurados, y el 587 sigue siendo el más compatible. Pero conviene saber que quien te diga que el 465 está obsoleto va siete años por detrás.
Hay guías que afirman lo contrario, y conviene aclararlo: el puerto que uses no cambia tu entregabilidad. Gmail no te trata mejor por enviar por el 465. El cifrado del puerto protege el trayecto entre tu aplicación y tu servidor de salida — un tramo que ocurre antes de que el correo salga siquiera a internet. Lo que decide si llegas a la bandeja pasa después, y depende de tu autenticación, de tu reputación y de tu lista.
El puerto puede impedir que envíes; no puede impedir que llegues.
Esa distinción es la que se cuenta mal. Si eliges un puerto bloqueado, el correo no sale y parece un problema de entregabilidad — pero no lo es: es un problema de conexión. Se ve enseguida porque el error es distinto: un puerto bloqueado da tiempo de espera agotado o conexión rechazada, y ahí no hay ningún mensaje que haya viajado a ninguna parte. Un problema de entregabilidad, en cambio, empieza cuando el correo sí ha salido.
Es la otra confusión habitual. SMTP solo sirve para sacar correo. Para leerlo están IMAP y POP3, que son protocolos distintos con puertos distintos.
Por eso al configurar una cuenta te piden dos servidores: el de salida, que es SMTP, y el de entrada, que es IMAP o POP.
Toda conversación SMTP se responde con números, y saber leerlos ahorra mucho tiempo:
| Código | Qué significa |
|---|---|
| 2xx | Aceptado. El 250 es el «recibido, todo bien» |
| 4xx | Fallo temporal. Buzón lleno, servidor saturado, retención preventiva. Se reintenta |
| 5xx | Fallo permanente. La dirección no existe, el dominio no está, te han rechazado. No se reintenta |
Esa diferencia entre el 4 y el 5 es la que separa un rebote blando de uno duro. Y cuando un servidor te rechaza por estar en una lista negra o por no cumplir sus requisitos de autenticación, te lo dice ahí, en el texto que acompaña al número.
Es de lo primero que miro cuando alguien me dice que sus correos «no salen»: el código de respuesta suele traer el diagnóstico escrito.
El 587 o el 465, nunca el 25. El 587 es el más compatible y el que ofrecen casi todas las plataformas. El 465 es el que recomienda la especificación desde 2018, porque cifra desde el primer byte y no deja ventana sin proteger. Los dos son seguros si exiges cifrado en la configuración.
Porque está pensado para la comunicación entre servidores, no para que tú envíes desde tu programa. La mayoría de proveedores de internet y de alojamientos lo bloquean, ya que fue durante años la vía del envío masivo de spam.
No es un puerto oficial: no lo reconoce ningún organismo. Pero casi todas las plataformas de envío lo admiten, y resuelve un caso muy concreto: alojamientos que bloquean el 587 y el 465 para impedir que sus clientes envíen spam. Si te encuentras con ese bloqueo, el 2525 suele ser la salida.
No. El cifrado del puerto protege el trayecto entre tu aplicación y tu servidor de salida; no influye en lo que decide Gmail o Microsoft cuando recibe el mensaje. Eso depende de la autenticación, de la reputación del dominio y de cómo tengas la lista.
No. SMTP envía y IMAP recibe. Por eso al configurar una cuenta de correo te piden dos servidores distintos: uno de salida y otro de entrada.
No, y ese es el origen de casi todo lo demás. El protocolo permite escribir cualquier remitente en el sobre. Para tapar ese hueco se crearon SPF, DKIM y DMARC, que son capas añadidas por encima de SMTP, no parte de él.
Si SMTP responde con un 250, tu correo ha salido bien. Lo que pase después —bandeja de entrada, spam o silencio— ya no lo decide el protocolo, sino tu autenticación y tu reputación. Ahí empieza el diagnóstico.
Nuria Palomo, la Dra. Spam
Experta en entregabilidad de email y reputación de dominio desde 2019.