9. SMTP (Simple Mail Transfer Protocol)

El Simple Mail Transfer Protocol (SMTP) define cómo los servidores intercambian correos electrónicos siguiendo las reglas establecidas en la RFC 5321. Fue diseñado para transporte server-to-server y luego adoptado por clientes que envían mensajes a servidores de salida (submission).

A diferencia de los protocolos de acceso (POP3, IMAP), SMTP no almacena mensajes para lectura: su finalidad exclusiva es entregar el correo al siguiente salto de la cadena hasta alcanzar el buzón del destinatario.

9.1 Encargado del envío de correos

Un flujo SMTP típico inicia cuando el cliente (MUA) entrega un mensaje al servidor de envío (MSA). Este servidor aplica políticas de autenticación y reenviá el correo al agente de transferencia (MTA), que a su vez consulta DNS para resolver registros MX y conectarse con el dominio destino. Si el servidor remoto acepta el mensaje, queda en cola para ser distribuido al buzón del usuario.

Cuando el destino no está disponible, el MTA conserva el mensaje y reintenta periódicamente hasta que se cumpla el tiempo de expiración, enviando un bounce al remitente si la entrega fracasa.

9.2 Funcionamiento entre servidores (relaying)

Los MTAs actúan como relevo (relay): reciben mensajes de dominios autorizados y los reenvían según las rutas definidas por los registros MX. Para evitar que cualquiera use un servidor como botón de spam, las organizaciones configuran listas de redes permitidas, autenticación obligatoria o filtros que chequean SPF, DKIM y DMARC antes de aceptar la entrega.

El relaying puede ser interno (entre MTAs de la misma empresa) o externo (de un proveedor de correo hacia Internet). En ambos casos SMTP garantiza la interoperabilidad gracias a su gramática de comandos y códigos de estado.

9.3 Comandos principales

SMTP utiliza comandos en texto plano seguidos de respuestas numéricas. Los más habituales son:

  • HELO / EHLO: el cliente se identifica ante el servidor y anuncia extensiones soportadas.
  • MAIL FROM: indica la dirección de envelope del remitente.
  • RCPT TO: especifica cada destinatario (permite varios).
  • DATA: señala el inicio del cuerpo del mensaje, finalizando con una línea que contiene solo un punto.
  • RSET: reinicia la transacción sin cerrar la conexión.
  • QUIT: termina la sesión de manera ordenada.

Extensiones como STARTTLS, AUTH LOGIN o AUTH PLAIN se negocian mediante EHLO y permiten cifrar y autenticar el canal antes de aceptar comandos sensibles.

9.4 Puertos y opciones de cifrado

Los servicios SMTP operan sobre distintos puertos según la etapa y el nivel de seguridad requerido:

Puerto Uso Cifrado
25/TCP Relaying entre MTAs públicos. Opcional mediante STARTTLS.
465/TCP Submission con TLS implícito (SMTPS), heredado de implementaciones tempranas. Cifrado desde el inicio.
587/TCP Submission moderno para clientes autenticados. STARTTLS obligatorio en la mayoría de proveedores.

Separar el puerto de relaying del de submission permite aplicar políticas y filtros distintos a usuarios finales y a MTAs externos.

9.5 Ejemplo práctico de sesión

Es posible probar la entrega de un mensaje sencillo usando telnet o openssl s_client para SSL/TLS: 

telnet smtp.ejemplo.com 25
220 smtp.ejemplo.com ESMTP Service Ready
EHLO laboratorio.local
250-smtp.ejemplo.com greets laboratorio.local
250-STARTTLS
250 AUTH LOGIN
STARTTLS
220 Ready to start TLS
(se negocia TLS)
EHLO laboratorio.local
MAIL FROM:<demo@laboratorio.local>
250 OK
RCPT TO:<soporte@ejemplo.com>
250 Accepted
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Prueba SMTP

Hola equipo,
Mensaje de verificación.
.
250 Message queued
QUIT
221 Bye

Este flujo confirma que el servidor acepta STARTTLS, autenticación y que la cola de salida funciona correctamente.

9.6 Diagnóstico con PowerShell

Para validar rápidamente un servidor corporativo se puede emplear Send-MailMessage o una combinación de clases .NET: 

$cred = Get-Credential # usuario autorizado
Send-MailMessage -From "alertas@laboratorio.local" `
  -To "soporte@laboratorio.local" `
  -Subject "Prueba SMTP 587" `
  -Body "Mensaje automático enviado desde PowerShell." `
  -SmtpServer "smtp.laboratorio.local" `
  -Port 587 -UseSsl -Credential $cred

El comando reporta errores de autenticación o TLS de manera inmediata, lo que ayuda a identificar configuraciones incorrectas antes de involucrar a los usuarios.

9.7 Automatización con Python

La biblioteca smtplib simplifica el envío de notificaciones o reportes automatizados: 

import smtplib
from email.message import EmailMessage

mensaje = EmailMessage()
mensaje["Subject"] = "Reporte diario"
mensaje["From"] = "robot@laboratorio.local"
mensaje["To"] = "soporte@laboratorio.local"
mensaje.set_content("Adjunto el resumen de procesos.")

with smtplib.SMTP("smtp.laboratorio.local", 587) as servidor:
    servidor.starttls()
    servidor.login("robot@laboratorio.local", "ClaveSecreta!")
    servidor.send_message(mensaje)
    print("Correo enviado")

Es recomendable almacenar las credenciales en un gestor seguro y rotarlas periódicamente si el script se ejecuta desde pipelines o servidores de integración continua.

9.8 Buenas prácticas y cierre

Para mantener SMTP confiable se debe implementar autenticación, cifrado y filtros anti-spam, monitorear las colas de entrega, habilitar registros detallados y configurar correctamente SPF, DKIM y DMARC para proteger la reputación del dominio. Documentar el uso de puertos 25, 465 y 587 ayuda a resolver incidencias rápidas cuando un firewall bloquea el tráfico.

Con estas medidas, SMTP continúa siendo la columna vertebral del correo electrónico, mientras que los protocolos de acceso (POP3, IMAP) se encargan de la lectura que veremos en los temas siguientes.

Retornar