376.000 millones de correos electrónicos circularon cada día en el mundo en 2025, según el informe Email Statistics Report 2024-2028 del Radicati Group. Cada uno de ellos pasa por el mismo diálogo de texto, prácticamente sin cambios desde 1982. SMTP (Simple Mail Transfer Protocol) es el protocolo que transporta un correo desde el software del remitente hasta el servidor del destinatario, apoyándose en una serie de comandos cortos intercambiados a través de una conexión TCP. No se ocupa ni de la recepción ni del almacenamiento del mensaje, dos tareas que corresponden a otros protocolos.
Lo que SMTP hace realmente se limita a tres gestos: abrir una conexión hacia el servidor correcto, transmitir el sobre que indica quién envía y a quién, y luego entregar el contenido del mensaje. El resto de la cadena se apoya en capas añadidas después, mucho después de la publicación del protocolo original. Autenticación y cifrado forman la primera capa; filtrado antispam y clasificación en la bandeja de entrada, la segunda.
El papel de SMTP en el envío de un correo
Un correo atraviesa cuatro etapas antes de llegar a una bandeja de entrada y SMTP solo cubre dos. El MUA, el software de correo que usa el remitente para redactar su mensaje (Outlook, Gmail, Thunderbird), transmite el mensaje a un MSA, el servidor que acepta el envío tras verificar la identidad del remitente. El MSA pasa entonces el relevo a un MTA, que retransmite el mensaje de servidor en servidor hasta llegar al que aloja la bandeja del destinatario. Este último servidor entrega finalmente el mensaje a un MDA, encargado de depositarlo en la bandeja correspondiente. SMTP dirige los dos eslabones centrales: el envío por parte del MSA y la retransmisión por parte del MTA. Un mismo software de servidor (Postfix, Exim, Microsoft Exchange) asume con frecuencia ambos roles a la vez, lo que difumina la distinción en la práctica diaria pero no la hace desaparecer en el intercambio de comandos en sí.
RFC 5321 y RFC 5322: el sobre y el mensaje
«The objective of the Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently.» RFC 5321, IETF, 2008.
Dos normas distintas rigen un correo electrónico y la confusión entre ambas explica buena parte de los malentendidos sobre deliverability. La RFC 5321 regula SMTP en sí: define los comandos, los códigos de respuesta y las reglas de transporte del sobre. La RFC 5322, publicada el mismo mes de octubre de 2008, rige un objeto distinto: el formato del mensaje transportado, con sus cabeceras From, To, Subject, Date y Message-ID. Esta separación se remonta al primer antecesor del protocolo, la RFC 821, publicada en agosto de 1982 por Jonathan Postel en el Information Sciences Institute de la Universidad del Sur de California. Fue sustituida por la RFC 2821 en 2001, a su vez reemplazada por la actual RFC 5321 en 2008. Desde entonces nada ha exigido una reescritura completa del transporte en sí, solo extensiones sucesivas injertadas sobre el mismo esqueleto de comandos.
La consecuencia práctica se resume en un punto técnico a menudo ignorado: la dirección declarada en el comando MAIL FROM (el sobre, llamado 5321.From) y la dirección mostrada en el campo From del mensaje (la cabecera, llamada 5322.From) no tienen ninguna obligación de coincidir. Un servicio de gestión de listas de distribución, una herramienta de seguimiento de campañas o un mecanismo de forwarding modifican legítimamente una sin tocar la otra. Es precisamente esa diferencia la que SPF verifica del lado del sobre. DKIM y DMARC se centran más bien en la cabecera visible para el destinatario, lo que explica por qué los tres mecanismos se complementan sin duplicarse.
El diálogo SMTP, comando por comando
Abre una sesión en texto plano en el puerto de envío de un servidor de correo y el diálogo se parece a un intercambio de cortesías coreografiado con mucha precisión. El servidor responde primero con un código 220, señal de que acepta la conexión. El cliente envía EHLO seguido de su propio nombre de dominio, lo que anuncia su capacidad para hablar la versión extendida del protocolo (ESMTP) y activa a cambio la lista de extensiones disponibles, SIZE para el tamaño máximo del mensaje o AUTH para la autenticación, por ejemplo. Llega después MAIL FROM, que declara al remitente del sobre; luego RCPT TO, repetido tantas veces como destinatarios haya. El comando DATA abre entonces la ventana de transmisión del contenido propiamente dicho, que termina con una línea compuesta por un único punto. El cliente cierra cortésmente con QUIT.
Cada etapa devuelve un código numérico de tres cifras que actúa como veredicto. Un código que empieza por 2 significa éxito (250 para un comando aceptado). Un código en 3 invita a continuar, como el 354 que autoriza el inicio del bloque DATA. Un código en 4 indica un fallo temporal, a reintentar más tarde. Un código en 5 cierra la puerta definitivamente, sin posibilidad de reenvío para ese mensaje. Esta escala se resume en cuatro familias, no más. No ha cambiado desde la primera especificación del protocolo, a pesar de que el volumen de correos intercambiados se ha multiplicado por varios cientos desde 1982.
Envío y retransmisión: el trayecto en dos etapas
El envío y la retransmisión responden a lógicas opuestas. El envío pasa por un MSA que exige autenticación (usuario y contraseña o token) antes de aceptar cualquier mensaje: sin ella, cualquiera podría suplantar una dirección de origen. La retransmisión entre MTA, por su parte, tradicionalmente no requiere ningún tipo de autenticación. Ese vacío histórico lo llenan a posteriori SPF, DKIM y DMARC, décadas después de la redacción del protocolo original.
Encontrar el servidor SMTP de tu correo
El nombre del servidor SMTP que hay que introducir en un cliente de correo depende del proveedor de correo utilizado, no de un estándar universal. Gmail, Outlook, OVH o un hosting compartido publican cada uno sus propias direcciones de servidor, con variantes según se trate de una dirección profesional o de una cuenta de particular, y a veces según el país de facturación de la cuenta. Este parámetro rara vez se encuentra en el mismo sitio de una interfaz a otra, lo que lleva a muchos usuarios a buscarlo cada vez que cambian de cliente de correo. Cómo encontrar el servidor SMTP de tu correo recopila estas direcciones proveedor por proveedor, con el procedimiento para localizarlas cuando no están documentadas.
Elegir el puerto SMTP
SMTP se apoya históricamente en cuatro puertos: el 25 para la retransmisión entre servidores, el 587 para el envío autenticado, el 465 para una conexión cifrada desde el inicio y el 2525 como alternativa cuando un proveedor de acceso bloquea los anteriores. El puerto 25 en particular sigue cerrado por defecto en la mayoría de conexiones residenciales y en numerosas redes empresariales, para limitar el envío de spam desde equipos comprometidos sin que su propietario lo sepa. La elección del puerto correcto depende, por tanto, tanto del software utilizado como de la red desde la que realmente se envía. Cómo determinar el puerto SMTP correcto detalla los casos de uso de cada uno según el contexto de envío.
Pasar por un relé SMTP
Un envío gestionado desde un servidor propio expone a un problema de sender reputation: basta una sola dirección mal configurada para hundir la deliverability de todo el dominio. La mayoría de empresas confían por eso el envío a un relé SMTP externo (Twilio SendGrid, Brevo, Amazon SES), que comparte una IP pool ya calentada y gestiona el IP warmup por ellas. La elección entre IP dedicada e IP compartida depende sobre todo del volumen enviado cada mes. El funcionamiento de un relé SMTP detalla estos compromisos.
Autenticación SMTP: AUTH, STARTTLS, SPF, DKIM, DMARC, BIMI
El protocolo original no preveía ni cifrado ni verificación de identidad. El comando AUTH, añadido más tarde, exige credenciales antes de aceptar un envío. STARTTLS permite después pasar una conexión en texto plano a una conexión cifrada durante la sesión, en lugar de abrir un canal cifrado desde el principio. Una decisión de diseño que sigue siendo oportunista en lugar de obligatoria en buena parte del parque mundial de servidores. Sobre esta capa de transporte se superpone un tríptico que se ha generalizado para la deliverability. SPF verifica que el servidor emisor está autorizado a enviar en nombre de ese dominio. DKIM firma criptográficamente el contenido y DMARC decide la suerte de un mensaje que falla en ambos, hasta llegar al DMARC reject, que directamente rechaza el correo no conforme. El detalle de SPF, DKIM, DMARC y BIMI explica cómo se articulan estas capas, y BIMI añade al final de la cadena la visualización de un logo verificado en algunos clientes de correo. El Postmaster Tools de Gmail permite observar el efecto real de estos ajustes sobre la reputación de un dominio.
Lo que SMTP no hace
SMTP se detiene en la entrega del mensaje en el servidor del destinatario. Nunca consulta una bandeja de entrada y no almacena nada por sí mismo. La lectura, la clasificación y la sincronización entre dispositivos corresponden a IMAP y POP3, dos protocolos que entran en juego después de que SMTP haya terminado su trabajo.
Códigos de respuesta y fallos de envío
Un código 550 devuelto en un comando RCPT TO indica un hard bounce: la dirección no existe o el servidor rechaza el mensaje de forma definitiva. Un código 421 o 450 corresponde a un soft bounce, un fallo temporal (buzón lleno, servidor no disponible, límite de envío alcanzado o filtro temporal activo) que el MTA remitente reintentará automáticamente según su propio calendario de deferrals. Las versiones recientes del protocolo suelen acompañar este código de un Enhanced Status Code de tres grupos de cifras, 5.1.1 para una dirección inexistente, por ejemplo, que precisa la causa sin cambiar la naturaleza del veredicto. Persiste una trampa en los dominios configurados como catchall: el servidor devuelve un 250 para cualquier dirección local, incluida una que nunca ha existido, lo que hace que ese código de éxito sea engañoso para quien quiera juzgar la validez real de una dirección. La lista completa de los códigos de respuesta SMTP y el detalle de los mecanismos de hard bounce y soft bounce ayudan a diagnosticar con precisión una campaña que se degrada. Una dirección inválida que acumula hard bounces daña la sender reputation de la IP emisora incluso antes de que entre en juego cualquier problema de autenticación. Comprobar la lista antes del envío sigue siendo la única forma de saber dónde está realmente el daño.
Límites y evolución del protocolo
SMTP fue diseñado para texto ASCII y direcciones en caracteres latinos, una decisión que de hecho excluía los alfabetos no latinos de las direcciones de correo. La extensión SMTPUTF8 corrige este punto al permitir direcciones en unicode, pero su adopción sigue siendo marginal fuera de algunos mercados asiáticos. Otras dos evoluciones buscan proteger el transporte entre servidores, ahí donde STARTTLS sigue siendo opcional: MTA-STS (Mail Transfer Agent Strict Transport Security) impone el cifrado mediante una política publicada en DNS y HTTPS, mientras que DANE se apoya directamente en DNSSEC para autenticar el certificado del servidor destinatario. Menos del 1% de los dominios del top 1 millón publican una política MTA-STS, una tasa que se ha más que duplicado entre 2024 y 2026 sin superar nunca ese umbral (Uriports, 2026). La paradoja radica en el peso de los grandes proveedores sobre el tráfico real: en los Países Bajos, un estudio de Zivver de septiembre de 2025 mide que el 19,1% del volumen de correos ya pasa por una conexión protegida con MTA-STS, impulsado casi enteramente por Gmail y Hotmail. DANE sigue siendo una curiosidad técnica: su adopción depende de DNSSEC, una pieza que la mayoría de los hostings todavía no han desplegado, lo que bloquea el mecanismo incluso antes de que pueda configurarse en el lado del cliente. El protocolo avanza por los márgenes, nunca mediante un reemplazo completo.
