SMTP (Simple Mail Transfer Protocol) es el protocolo que hace posible el envío de correo electrónico. Cada vez que pulsas "Enviar", tu cliente de correo entrega el mensaje a un servidor SMTP, que lo transfiere al servidor de correo del destinatario consultando los registros MX del dominio. A diferencia de IMAP y POP3, que sirven para recibir correo, SMTP es exclusivamente para enviarlo. Sin un servidor SMTP configurado correctamente, el correo no sale. Con uno mal configurado, acaba en spam. Esta guía explica cómo funciona, qué puertos usar y cómo configurarlo en cualquier cliente.

Historia y evolución de SMTP

SMTP fue definido por Jon Postel en 1982 en la RFC 821, como parte del conjunto de protocolos que construyeron la arquitectura de correo electrónico de Internet. Su nombre — Simple Mail Transfer Protocol — refleja la filosofía de diseño de la época: un protocolo de texto plano, simple de implementar y depurar, que cualquier sistema podía soportar.

Esa simplicidad original era también su mayor debilidad: SMTP no tenía ningún mecanismo de autenticación. Cualquier servidor podía enviar correo diciendo ser cualquier remitente, lo que fue el caldo de cultivo para el spam y el phishing durante décadas. La respuesta llegó con las extensiones ESMTP (Extended SMTP, RFC 1869, 1995), que añadieron la capacidad de negociar funcionalidades adicionales entre cliente y servidor, incluyendo autenticación y cifrado.

Las versiones relevantes del protocolo hoy son:

  • RFC 5321 (2008): define SMTP en su forma actual, sustituyendo a la RFC 2821 de 2001, que a su vez sustituyó a la RFC 821 original.
  • RFC 6409 (2011): define el puerto 587 como el puerto estándar para message submission — el envío de mensajes desde clientes autenticados, separándolo del puerto 25 que se reserva para la transferencia entre servidores.
  • RFC 4954 (2007): define el mecanismo de autenticación SMTP AUTH, que exige que los clientes se identifiquen antes de poder enviar mensajes.

Cómo funciona SMTP: el protocolo en detalle

SMTP es un protocolo orientado a texto y a conexiones TCP. La comunicación entre cliente y servidor sigue un formato de comandos y respuestas numéricas — similar a HTTP — que hace que una sesión SMTP sea completamente legible por un humano.

El diálogo SMTP completo

Este es el aspecto de una sesión SMTP real, desde la conexión hasta la confirmación de entrega:

C: [conexión TCP al puerto 587]
S: 220 mail.sys4net.com ESMTP Postfix

C: EHLO cliente.tudominio.com
S: 250-mail.sys4net.com Hello cliente.tudominio.com
S: 250-SIZE 52428800
S: 250-AUTH PLAIN LOGIN
S: 250-STARTTLS
S: 250 8BITMIME

C: STARTTLS
S: 220 Ready to start TLS
[negociación TLS — a partir de aquí todo va cifrado]

C: EHLO cliente.tudominio.com
S: 250-mail.sys4net.com Hello

C: AUTH LOGIN
S: 334 VXNlcm5hbWU6          → "Username:" en base64
C: dHVAZG9taW5pby5jb20=      → "tu@dominio.com" en base64
S: 334 UGFzc3dvcmQ6          → "Password:" en base64
C: dHVfY29udHJhc2Vuw6E=      → contraseña en base64
S: 235 Authentication successful

C: MAIL FROM:<tu@tudominio.com>
S: 250 Ok

C: RCPT TO:<destinatario@otrodominio.com>
S: 250 Ok

C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: tu@tudominio.com
C: To: destinatario@otrodominio.com
C: Subject: Asunto del mensaje
C: 
C: Cuerpo del mensaje aquí.
C: .
S: 250 Ok: queued as A1B2C3D4

C: QUIT
S: 221 Bye

Algunas observaciones importantes sobre este diálogo:

  • El cliente se identifica con EHLO (Extended HELO) en lugar del antiguo HELO para indicar que soporta extensiones ESMTP. El servidor responde listando las extensiones que soporta.
  • STARTTLS se negocia antes de la autenticación. Esto es fundamental: las credenciales nunca deben enviarse sin cifrado previo.
  • La autenticación AUTH LOGIN envía usuario y contraseña en base64, que no es cifrado — es solo codificación. La seguridad real la aporta TLS, no base64.
  • El servidor confirma con el código 250 cada paso. El código 354 indica que puede empezar a enviar el cuerpo del mensaje. El mensaje termina con una línea que contiene solo un punto (.).
  • El código de respuesta final 250 Ok: queued as... confirma que el servidor aceptó el mensaje para entregar. Esto no significa que el destinatario lo haya recibido, solo que el servidor lo tiene en cola.

Qué pasa después: de servidor a servidor

Una vez que tu servidor SMTP acepta el mensaje, comienza la transferencia entre servidores (MTA to MTA). El servidor de origen:

  1. Consulta el registro MX del dominio del destinatario para encontrar qué servidor de correo gestiona ese dominio.
  2. Abre una conexión TCP al puerto 25 del servidor MX del destinatario.
  3. Entrega el mensaje usando el mismo protocolo SMTP, pero sin autenticación de usuario — la autenticación entre servidores se gestiona mediante reputación de IP y registros DNS (SPF, DKIM, DMARC).
  4. El servidor destinatario acepta el mensaje y lo deposita en el buzón del destinatario.

Si la entrega falla — porque el servidor destinatario no está disponible, porque la dirección no existe, o porque el mensaje fue rechazado por los filtros antispam — el servidor SMTP de origen genera un mensaje de error (bounce) y lo devuelve al remitente.

Los tres puertos SMTP y cuándo usar cada uno

La elección del puerto SMTP es una de las configuraciones que más confusión genera. Hay tres puertos en uso, con historia y propósito distintos:

PuertoNombreCifradoUsoRecomendado para
25SMTPSin cifrado (o STARTTLS opcional)Transferencia entre servidores MTASolo servidores — bloqueado por ISPs para usuarios
587SubmissionSTARTTLS (upgrade a TLS tras el saludo)Envío autenticado desde clientes✅ Usuarios y clientes de correo
465SMTPSSSL/TLS implícito desde el primer byteEnvío autenticado con TLS implícito✅ Alternativa válida al 587

Puerto 25: solo para servidores

El puerto 25 es el puerto original de SMTP, definido en 1982. Es el puerto que usan los servidores de correo para comunicarse entre sí (MTA a MTA) y no requiere autenticación de usuario — la legitimidad se verifica mediante registros DNS.

Los ISPs y proveedores de hosting bloquean el puerto 25 para conexiones salientes de usuarios finales desde hace años. El motivo es el spam: antes de que se implantaran estas restricciones, cualquier ordenador infectado con malware podía conectarse directamente al puerto 25 de cualquier servidor del mundo y enviar millones de correos de spam sin pasar por ningún servidor intermediario autenticado.

Si intentas configurar tu cliente de correo con el puerto 25, lo más probable es que tu ISP bloquee la conexión y no puedas enviar nada.

Puerto 587: el estándar para usuarios

El puerto 587 fue definido como puerto de message submission en la RFC 2476 (1998) y consolidado en la RFC 6409 (2011) con el objetivo explícito de separar el envío de usuarios autenticados del relay entre servidores.

Con el puerto 587 y STARTTLS, la conexión funciona así: el cliente se conecta sin cifrar, intercambia el saludo EHLO, negocia TLS con STARTTLS, y a partir de ese momento toda la comunicación — incluyendo las credenciales — va cifrada. Es el puerto recomendado para configurar en cualquier cliente de correo.

Puerto 465: TLS implícito

El puerto 465 tiene una historia curiosa: fue asignado originalmente a SMTPS en 1997, pero esa asignación fue revocada en 1998 y el número fue reasignado a otro servicio. Sin embargo, muchos servidores y clientes siguieron usándolo para SMTP con SSL implícito, creando una situación de facto que persiste hasta hoy. En 2018, la RFC 8314 rehabilitó formalmente el uso del puerto 465 para SMTP con TLS implícito.

La diferencia práctica con el 587: con el puerto 465, la conexión está cifrada desde el primer byte — no hay fase inicial sin cifrar. Esto es ligeramente más seguro en teoría, aunque en la práctica ambos puertos ofrecen el mismo nivel de seguridad si se usan correctamente.

Cuál elegir: si el servidor de tu proveedor soporta ambos, usa el 587 con STARTTLS. Es el estándar más universalmente soportado y el que recomienda la RFC vigente. Si un cliente o sistema legacy solo soporta TLS implícito, usa el 465.

SMTP y la autenticación: SPF, DKIM y DMARC

El mayor problema histórico de SMTP es que el protocolo en sí no verifica que el remitente del sobre (MAIL FROM) sea quien dice ser. Cualquier servidor puede enviar un correo afirmando ser ceo@apple.com y el protocolo SMTP no lo impedirá. Esta vulnerabilidad es la base del phishing y el spoofing de correo.

La solución llegó a través de tres registros DNS que trabajan en conjunto:

SPF (Sender Policy Framework)

SPF es un registro TXT en el DNS del dominio remitente que lista qué servidores están autorizados a enviar correo en nombre de ese dominio. Cuando el servidor destinatario recibe un mensaje, consulta el SPF del dominio del remitente y verifica que la IP del servidor que envió el mensaje está en esa lista.

Ejemplo de registro SPF:
v=spf1 ip4:185.34.12.8 include:_spf.sys4net.com ~all

Significado:
- ip4:185.34.12.8         → esta IP está autorizada a enviar
- include:_spf.sys4net.com → también los servidores incluidos en ese registro
- ~all                     → cualquier otro servidor → marcar como softfail

Si un servidor que no está en el SPF intenta enviar correo con tu dominio, los servidores destinatarios lo marcarán como sospechoso o lo rechazarán directamente.

DKIM (DomainKeys Identified Mail)

DKIM añade una firma digital a cada mensaje saliente. El servidor SMTP firma el mensaje con una clave privada, y el servidor destinatario verifica esa firma consultando la clave pública publicada en el DNS del dominio remitente.

La firma garantiza dos cosas: que el mensaje fue enviado desde un servidor que tiene acceso a la clave privada del dominio, y que el contenido del mensaje no fue alterado en tránsito. Si alguien intercepta el mensaje y modifica aunque sea un carácter, la firma DKIM deja de ser válida.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC es el mecanismo que une SPF y DKIM y define qué hacer cuando ambos fallan. Se publica también como registro TXT en el DNS y permite al propietario del dominio especificar una política de tres posibles acciones cuando un mensaje no pasa la verificación SPF o DKIM:

  • p=none: no hacer nada, solo reportar (modo monitorización).
  • p=quarantine: enviar a la carpeta de spam los mensajes que no pasen.
  • p=reject: rechazar directamente los mensajes que no pasen.

DMARC también define una dirección de correo a la que el servidor destinatario envía informes de autenticación, lo que permite al propietario del dominio ver quién está intentando enviar correo con su nombre.

Los tres — SPF, DKIM y DMARC — son imprescindibles para cualquier dominio de correo corporativo en 2026. Sin ellos, los mensajes tienen muchas más probabilidades de acabar en spam, y el dominio es vulnerable a que terceros lo usen para enviar phishing.

Errores SMTP comunes y cómo resolverlos

Los servidores SMTP comunican el resultado de cada operación mediante códigos de tres dígitos. El primer dígito indica si es una respuesta positiva (2xx), un error temporal (4xx) o un error permanente (5xx). Conocer los códigos más comunes ahorra mucho tiempo al depurar problemas de correo.

Errores 4xx: fallos temporales (el mensaje puede reintentarse)

CódigoSignificadoCausa habitual
421Service not availableEl servidor destinatario está sobrecargado o en mantenimiento. El cliente reintentará más tarde.
450Mailbox unavailableEl buzón del destinatario no está disponible temporalmente (lleno, bloqueado). Reintentable.
451Local error in processingError interno del servidor destinatario. Suele resolverse solo.
452Insufficient storageEl servidor destinatario no tiene espacio suficiente. Reintentable.

Errores 5xx: fallos permanentes (el mensaje no se entregará)

CódigoSignificadoCausa habitual y solución
500Syntax errorEl cliente envió un comando SMTP con sintaxis incorrecta.
530Authentication requiredEl servidor exige autenticación antes de aceptar mensajes. Verifica que las credenciales SMTP están configuradas correctamente en el cliente.
535Authentication failedUsuario o contraseña incorrectos. Verifica las credenciales. Si acabas de cambiar la contraseña, actualízala también en el cliente.
550Mailbox unavailable / Relay deniedLa dirección del destinatario no existe, el dominio no tiene registros MX, o el servidor rechaza mensajes de tu IP o dominio. Si es relay denied, tu servidor no está autorizado a enviar correo para ese dominio.
552Message too largeEl mensaje supera el tamaño máximo aceptado por el servidor destinatario. Reduce el tamaño de los adjuntos.
553Mailbox name invalidLa dirección del destinatario tiene un formato incorrecto.
554Transaction failed / Message rejectedEl mensaje fue rechazado por los filtros antispam del servidor destinatario. Revisa SPF, DKIM, DMARC y la reputación de la IP.

El problema más frecuente: correos que llegan al spam

En sys4net, una de las consultas de soporte más habituales es "mis correos llegan a la carpeta de spam del destinatario". Las causas son casi siempre las mismas, y todas tienen solución:

  • Falta de registro SPF o SPF incorrecto. El servidor destinatario no puede verificar que tu servidor está autorizado a enviar correo con tu dominio. Revisa que el registro SPF en el DNS de tu dominio incluye la IP de tu servidor de correo.
  • DKIM no configurado o con firma inválida. Sin firma DKIM, el servidor destinatario no puede verificar la integridad del mensaje ni la autenticidad del remitente. Activa DKIM en el panel de administración de tu servidor de correo.
  • Sin registro DMARC. Sin DMARC, los servidores destinatarios no saben qué política aplicar cuando SPF o DKIM fallan. Añade al menos un registro DMARC con p=none para empezar a monitorizar.
  • IP en listas negras (blacklists). Si la IP de tu servidor de correo está en una lista negra (RBL), la mayoría de servidores rechazarán o pondrán en spam tus mensajes. Comprueba la reputación de tu IP en MXToolbox o Spamhaus.
  • Sin registro PTR (DNS inverso). Muchos servidores verifican que la IP del servidor remitente tiene un registro PTR (resolución inversa de IP a nombre) que coincida con el nombre del servidor SMTP. Si no hay PTR o no coincide, el mensaje puede marcarse como sospechoso.

Cómo configurar SMTP en tu cliente de correo

Independientemente del cliente que uses — Outlook, Thunderbird, Apple Mail, Gmail app — los datos de configuración SMTP son siempre los mismos: servidor, puerto, tipo de cifrado y credenciales.

Configuración SMTP en sys4net

Servidor SMTP:   mail.tudominio.com
Puerto:          587
Seguridad:       STARTTLS
Usuario:         tu@tudominio.com
Contraseña:      la de tu cuenta de correo

Si el puerto 587 está bloqueado por tu red o ISP (poco habitual, pero ocurre en algunas redes corporativas), usa el puerto 465 con SSL/TLS como alternativa.

Configurar SMTP en Outlook

  1. Ve a Archivo → Configuración de la cuenta → Configuración de la cuenta.
  2. Selecciona tu cuenta y haz clic en "Cambiar".
  3. Haz clic en "Más configuración" → pestaña "Servidor de salida".
  4. Marca "Mi servidor de salida (SMTP) requiere autenticación" → "Usar la misma configuración que mi servidor de correo entrante".
  5. Ve a la pestaña "Avanzado" y configura: SMTP 587, cifrado STARTTLS.

Configurar SMTP en Thunderbird

  1. Ve a Configuración de la cuenta → Servidor de salida (SMTP).
  2. Selecciona el servidor o haz clic en "Añadir".
  3. Introduce el servidor, puerto 587, seguridad de conexión STARTTLS, método de autenticación "Contraseña normal".

Diagnóstico rápido: probar SMTP desde la línea de comandos

Si tienes dudas sobre si el servidor SMTP es accesible desde tu red, puedes probarlo directamente con telnet o openssl:

# Verificar que el puerto 587 está accesible
telnet mail.tudominio.com 587

# Si responde con "220 ...", el servidor es accesible
# Si no conecta, el puerto está bloqueado en tu red

# Probar la conexión con TLS (más completo)
openssl s_client -starttls smtp -connect mail.tudominio.com:587

# Para el puerto 465 con TLS implícito
openssl s_client -connect mail.tudominio.com:465

Datos de configuración completos: SMTP + IMAP/POP3

Para tener una cuenta de correo completamente operativa necesitas configurar tanto el servidor de salida (SMTP) como el de entrada (IMAP o POP3). Aquí están todos los datos juntos para una cuenta de correo corporativo en sys4net:

Correo saliente — SMTP
  Servidor:   mail.tudominio.com
  Puerto:     587
  Seguridad:  STARTTLS
  Auth:       Requerida (mismo usuario y contraseña)

Correo entrante — IMAP (recomendado)
  Servidor:   mail.tudominio.com
  Puerto:     993
  Seguridad:  SSL/TLS

Correo entrante — POP3 (alternativo)
  Servidor:   mail.tudominio.com
  Puerto:     995
  Seguridad:  SSL/TLS

Usuario:      tu@tudominio.com
Contraseña:   la de tu cuenta de correo

Preguntas frecuentes sobre SMTP

¿Qué es SMTP?

SMTP (Simple Mail Transfer Protocol) es el protocolo estándar para el envío de correo electrónico. Define cómo los clientes de correo entregan mensajes a los servidores SMTP y cómo estos los transfieren entre servidores hasta llegar al servidor de correo del destinatario. Fue definido originalmente en la RFC 821 en 1982; su versión actual está en la RFC 5321. A diferencia de IMAP y POP3, que sirven para recibir correo, SMTP es exclusivamente para enviarlo.

¿Qué puerto usa SMTP?

SMTP usa tres puertos: el 25 para comunicación entre servidores (bloqueado para usuarios por los ISPs), el 587 con STARTTLS para envío autenticado desde clientes (el recomendado), y el 465 con SSL/TLS implícito como alternativa. Para configurar tu cliente de correo, usa el puerto 587 con STARTTLS. Si está bloqueado en tu red, usa el 465 con SSL/TLS.

¿Cuál es la diferencia entre el puerto 465 y el 587 de SMTP?

El puerto 587 usa STARTTLS: la conexión empieza sin cifrar, se intercambia el saludo EHLO, y luego se negocia TLS antes de enviar las credenciales. El puerto 465 usa SSL/TLS implícito: la conexión está cifrada desde el primer byte. Ambos son seguros; el 587 es el estándar actual definido en la RFC 6409 y el más universalmente soportado. El 465 es válido como alternativa cuando la red o el cliente no admiten STARTTLS.

¿Por qué mis correos llegan al spam?

Las causas más habituales son: falta o error en el registro SPF del dominio, ausencia de firma DKIM, política DMARC no configurada, IP del servidor en listas negras, o ausencia de registro PTR (DNS inverso). Comprueba el estado de tu configuración DNS en MXToolbox introduciendo tu dominio. En sys4net configuramos SPF, DKIM y DMARC automáticamente en todos los planes de correo corporativo.

¿Qué significa el error SMTP 550?

El error 550 indica que el servidor destinatario rechazó el mensaje de forma permanente. Las causas más comunes son: la dirección del destinatario no existe (550 5.1.1 User unknown), el dominio no tiene registros MX válidos, la IP de tu servidor está en una lista negra, o el servidor destinatario rechaza mensajes de tu dominio por políticas de seguridad. Si el error es 550 relay denied, significa que tu servidor está intentando enviar correo para un dominio para el que no está autorizado.

¿Qué es un servidor SMTP relay?

Un SMTP relay (o smart host) es un servidor SMTP intermediario que acepta mensajes de clientes o servidores y los reenvía al servidor de destino final. Se usa cuando los servidores de origen no pueden conectarse directamente al puerto 25 del servidor destino (por ejemplo, servidores detrás de ISPs que bloquean el puerto 25) o cuando se quiere centralizar el envío a través de un servidor con buena reputación de IP. Servicios como SendGrid, Mailgun o Amazon SES son ejemplos de SMTP relays en la nube.

¿Por qué el puerto 25 está bloqueado por mi ISP?

Los ISPs bloquean el puerto 25 saliente para usuarios finales desde principios de los 2000 como medida para combatir el spam. Antes de estas restricciones, cualquier ordenador infectado con malware podía conectarse directamente al puerto 25 de cualquier servidor del mundo y enviar millones de correos de spam sin autenticación. El bloqueo del puerto 25 por los ISPs fue una de las medidas más efectivas para reducir el spam enviado desde redes de consumidores. Para enviar correo, usa el puerto 587 (con autenticación y cifrado), que es el puerto diseñado para eso.

¿SMTP autentica al remitente?

El protocolo SMTP básico no tiene autenticación de remitente — cualquier servidor puede afirmar ser cualquier dominio. La autenticación real se añade mediante extensiones: SMTP AUTH exige credenciales al cliente, y los registros DNS SPF, DKIM y DMARC permiten a los servidores destinatarios verificar que el servidor remitente está autorizado por el dominio que aparece en el correo. Sin estas extensiones, el correo electrónico es técnicamente falsificable.