Enviar un correo parece trivial. Escribes, pones un destinatario, le das a enviar y listo. Pero entre ese clic y el momento en que el mensaje aparece (o no) en la bandeja del otro lado, pasan muchas cosas. Consultas DNS, autenticación del remitente, filtros antispam, evaluación de reputación — cualquiera de esos pasos puede fallar sin que nadie se entere.
Si administras un servidor de correo, estudias para el CCNA o simplemente quieres entender qué ocurre cuando un email “desaparece”, este recorrido por la cadena completa te va a servir.
Cómo viaja un correo electrónico
El camino de un correo tiene cuatro actores principales: el cliente de correo, el servidor SMTP de salida, el sistema DNS y el servidor receptor. Cada uno cumple una función distinta y falla de maneras distintas.
El cliente de correo (MUA)
El MUA (Mail User Agent) es lo que el usuario ve: Gmail en el navegador, Outlook en el escritorio, Thunderbird, Apple Mail o cualquier aplicación que permita redactar y leer mensajes. Su trabajo es conectarse al servidor SMTP del proveedor, autenticarse y entregar el mensaje para que comience su viaje.
El MUA no envía el correo directamente al destinatario. Lo entrega al servidor de salida del remitente, que es quien realmente inicia la transmisión SMTP hacia el exterior.
Servidor SMTP y MTA
SMTP (Simple Mail Transfer Protocol) es el protocolo que mueve correos entre servidores desde 1982. Fue definido originalmente en el RFC 821 y actualizado en el RFC 5321, que es la referencia vigente.
El MTA (Mail Transfer Agent) es el software que implementa SMTP en el servidor: Postfix, Exim, Sendmail, Microsoft Exchange. Cuando tu MUA le entrega un mensaje al MTA, este consulta DNS para averiguar a dónde enviarlo y establece una conexión SMTP con el servidor del destinatario.
Los puertos que debes conocer:
- Puerto 25: SMTP servidor a servidor. Es el puerto clásico para la transferencia entre MTAs. Muchos ISP residenciales lo bloquean para evitar spam desde equipos infectados.
- Puerto 587: SMTP con autenticación (submission). Es el que usa tu cliente de correo para enviar mensajes. Requiere autenticación y normalmente inicia cifrado con STARTTLS.
- Puerto 465: SMTP sobre TLS implícito (SMTPS). Fue deprecado, resucitado por el RFC 8314 en 2018 y hoy es una alternativa legítima al 587. La conexión arranca cifrada directamente, sin negociación previa.
Si quieres ver la lista completa de números de puerto TCP/UDP y cómo se asignan en la capa de transporte, ahí está el detalle.
Así se ve una sesión SMTP real
Para entender el protocolo, nada mejor que ver una conversación SMTP paso a paso. Puedes simularla con telnet o openssl contra el puerto 25 de un servidor:
$ telnet mail.ejemplo.com 25
220 mail.ejemplo.com ESMTP Postfix
EHLO miservidor.com
250-mail.ejemplo.com
250-STARTTLS
250-AUTH PLAIN LOGIN
250 OK
MAIL FROM:<admin@miservidor.com>
250 OK
RCPT TO:<contacto@ejemplo.com>
250 OK
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Prueba de entrega
From: admin@miservidor.com
To: contacto@ejemplo.com
Este es el cuerpo del mensaje.
.
250 OK: queued as 4F8B2C1A03
QUIT
221 Bye
Cada línea importa. Con EHLO, el servidor que envía se identifica y solicita las extensiones disponibles. MAIL FROM declara el remitente del sobre (envelope sender, que no necesariamente coincide con el “From:” visible). El destinatario se indica con RCPT TO, y DATA abre la transmisión del contenido, que termina con un punto solo en una línea.
Los códigos de respuesta siguen un patrón: 2xx significa éxito, 3xx que el servidor espera más datos, 4xx un error temporal (reintentar tiene sentido) y 5xx un error permanente (no insistir).
Cuando ves un 550 User not found, sabes que ese buzón no existe. Un 421 Too many connections te dice que el servidor receptor está limitando tu tráfico, probablemente por volumen o reputación.
DNS y registros MX
Cuando tu MTA necesita entregar un correo a contacto@ejemplo.com, lo primero que hace es buscar los registros MX del dominio ejemplo.com. Los registros MX (Mail Exchanger) indican qué servidores reciben correo para ese dominio y con qué prioridad. Si necesitas repasar los fundamentos del sistema de nombres, la guía sobre qué es DNS cubre desde la resolución básica hasta los tipos de registros.
$ nslookup -type=mx ejemplo.com
ejemplo.com MX preference = 10, mail exchanger = mx1.ejemplo.com
ejemplo.com MX preference = 20, mail exchanger = mx2.ejemplo.com
El número de preferencia determina el orden: el valor más bajo tiene prioridad. Si mx1 no responde, el MTA intenta con mx2. Es un mecanismo de redundancia básico pero efectivo.
¿Qué pasa si un dominio no tiene registros MX? El RFC 5321 permite usar el registro A o AAAA como fallback, pero en la práctica un dominio sin MX explícitos es sospechoso y muchos filtros lo penalizan.
Antes de llegar a esta cadena de consultas DNS, alguien tiene que conocer la dirección del destinatario. En entornos corporativos, herramientas como el buscador de correo electrónico de Snov.io permiten localizar emails profesionales asociados a un dominio. Pero encontrar la dirección es solo el primer paso: que el dominio tenga MX, que el buzón exista y que el servidor acepte el mensaje son comprobaciones que ocurren después, y cualquiera de ellas puede fallar.
Servidor receptor y MDA
El servidor receptor no acepta mensajes a ciegas. Antes de entregar nada al buzón, ejecuta una batería de comprobaciones: verifica que el destinatario exista, consulta listas negras de IP, revisa la autenticación del remitente (SPF, DKIM, DMARC), analiza el contenido con filtros antispam y evalúa la reputación del dominio e IP de origen.
Si el mensaje pasa todos los controles, entra en escena el MDA (Mail Delivery Agent), que es quien deposita el correo en el buzón del usuario. Ejemplos de MDA son Dovecot (que además sirve como servidor IMAP/POP3) y Procmail para filtrado local.
POP3 e IMAP: recuperar el correo
SMTP se encarga de mover mensajes entre servidores. Para que el usuario pueda leerlos desde su cliente, necesita otro protocolo. Aquí entran POP3 e IMAP.
POP3 (Post Office Protocol v3) descarga los mensajes del servidor al dispositivo local. En su configuración por defecto, los elimina del servidor tras la descarga. Funciona en el puerto 110 (sin cifrar) o puerto 995 (con TLS). Es simple, consume pocos recursos del servidor y tiene sentido cuando solo accedes al correo desde un único equipo, pero hoy eso ya casi no pasa.
IMAP (Internet Message Access Protocol) sincroniza el buzón entre el servidor y todos los clientes conectados. Los mensajes quedan en el servidor; si marcas uno como leído desde el móvil, aparece leído en el portátil. Usa el puerto 143 (sin cifrar) o puerto 993 (con TLS). Es el estándar actual para cualquier entorno con múltiples dispositivos.
La diferencia clave: con POP3, el servidor es un punto de paso temporal. Con IMAP, el servidor es el almacén central y los clientes son ventanas hacia él.
TLS: cifrado en tránsito
SMTP nació en los años 80 sin cifrado. Los mensajes viajaban en texto plano, legibles para cualquier equipo en la ruta. Hoy existen dos mecanismos para proteger la conexión.
STARTTLS es una extensión que permite “ascender” una conexión SMTP en texto plano a una conexión cifrada con TLS, sin cambiar de puerto. El cliente se conecta al puerto 25 o 587 en texto plano, envía el comando STARTTLS y, si el servidor lo soporta, ambos negocian el cifrado antes de transmitir datos sensibles.
El problema de STARTTLS es que la negociación ocurre después de establecer la conexión. Un atacante que logre interponerse en la comunicación (man-in-the-middle) podría eliminar la respuesta del servidor al comando STARTTLS y forzar que la conexión continúe sin cifrar. Esto se conoce como STARTTLS stripping.
TLS implícito (puerto 465 para SMTP, 993 para IMAP, 995 para POP3) inicia la conexión cifrada directamente. No hay fase en texto plano, así que no hay ventana para un ataque de stripping. El RFC 8314 de 2018 recomienda TLS implícito como la opción preferida para clientes de correo.
Conviene aclarar algo que genera confusión frecuente: TLS cifra la conexión entre dos puntos (tu cliente al servidor, o un servidor a otro servidor). No cifra el mensaje de extremo a extremo. Para eso existen soluciones como PGP o S/MIME, que utilizan criptografía asimétrica con pares de clave pública y privada.
Autenticación del remitente: SPF, DKIM y DMARC
Estos tres mecanismos intentan responder una pregunta que SMTP por diseño no resuelve: ¿quién envió realmente este correo? SMTP no tiene autenticación de origen incorporada. Cualquiera puede poner lo que quiera en el campo “From:”. SPF, DKIM y DMARC fueron creados para parchear esa debilidad.
SPF (Sender Policy Framework)
SPF permite que un dominio declare en DNS qué servidores tienen permiso para enviar correo en su nombre. Se publica como un registro TXT.
Un registro SPF real se ve así:
v=spf1 ip4:192.0.2.0/24 include:_spf.google.com include:sendgrid.net -all
Esto dice: “pueden enviar correo por mi dominio las IPs en el rango 192.0.2.0/24, los servidores que Google autoriza y los de SendGrid. Todo lo demás, rechazar.”
El mecanismo final importa mucho:
-all→ hard fail, rechazar lo que no coincida~all→ soft fail, marcar pero no rechazar necesariamente+all→ aceptar todo (básicamente anula el propósito de SPF, no lo uses)
Errores que aparecen constantemente: publicar dos registros SPF para el mismo dominio (el RFC dice que debe haber exactamente uno), exceder el límite de 10 búsquedas DNS (cada include y redirect cuenta) y olvidar incluir algún servicio que sí envía correo por tu dominio, como el CRM o la plataforma de newsletters.
SPF tiene una limitación estructural: evalúa el envelope sender (el MAIL FROM de la sesión SMTP), no el “From:” que ve el usuario en su cliente de correo. Eso significa que un atacante podría pasar SPF con su propio dominio y aún mostrar tu dirección en el “From:” visible. Para cerrar esa brecha existe DMARC.
DKIM (DomainKeys Identified Mail)
DKIM firma criptográficamente partes del mensaje. El servidor de envío aplica una firma con una clave privada, y publica la clave pública en DNS para que el receptor pueda verificarla. Este mecanismo se apoya en los mismos principios de criptografía de clave pública que protegen SSL/TLS, SSH e IPsec.
Un registro DKIM en DNS se ve así:
selector1._domainkey.ejemplo.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNA..."
El selector permite tener múltiples claves activas (por ejemplo, una por proveedor de envío). La verificación comprueba dos cosas: que la firma corresponda al dominio declarado y que el contenido firmado no se haya alterado en tránsito.
DKIM no cifra el contenido del correo. Lo que hace es asegurar que el mensaje no fue alterado en el camino y vincularlo a un dominio responsable.
¿Dónde falla? Si un servidor intermedio modifica el cuerpo del mensaje o ciertos encabezados firmados (algo que hacen algunas listas de correo y servicios de reenvío), la firma se rompe.
También fallan las implementaciones con claves demasiado cortas. El RFC 8301 exige al menos 1024 bits, pero esa longitud ya se considera un fallback de compatibilidad. Si estás configurando DKIM desde cero, usa 2048 bits: es el estándar práctico que recomiendan tanto Google como Microsoft.
DMARC (Domain-based Message Authentication, Reporting and Conformance)
DMARC conecta SPF y DKIM con el dominio que el usuario ve en el campo “From:”. Su concepto central es la alineación: para que DMARC pase, al menos SPF o DKIM deben validar correctamente Y el dominio autenticado debe coincidir (o ser subdominio, en modo relajado) con el dominio del “From:” visible.
Un registro DMARC:
_dmarc.ejemplo.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reportes@ejemplo.com; pct=100"
La política p= indica qué hacer con mensajes que fallen la alineación:
p=none→ solo monitorear, no actuar. Ideal para empezar.p=quarantine→ enviar a spam/cuarentena.p=reject→ rechazar el mensaje.
El camino recomendado es empezar con p=none durante semanas o meses, revisar los reportes agregados que llegan al correo configurado en rua=, identificar todos los servicios legítimos que envían en nombre de tu dominio, asegurar que todos tengan SPF y DKIM correctos, y solo entonces subir a quarantine o reject.
El error más peligroso con DMARC: poner p=reject sin haber auditado antes todos los flujos de correo legítimos. Hay empresas que bloquean sus propios correos transaccionales, newsletters o alertas de sistemas internos por una implementación precipitada.
Validación de direcciones de correo
Antes de enviar correo, tiene sentido verificar que la dirección del destinatario sea real. Esto reduce rebotes, protege la reputación de tu dominio e IP de envío y evita desperdiciar recursos.
Validación sintáctica
El nivel más básico: ¿tiene la dirección un formato válido? Parte local, arroba, dominio. ana@empresa.com pasa; ana@@empresa no. Parece obvio, pero la cantidad de formularios que aceptan basura porque nadie verificó lo que el usuario escribió es sorprendente.
Comprobación de dominio y MX
El siguiente nivel consulta DNS: ¿existe el dominio? ¿Tiene registros MX? Si empresa.com no resuelve o no tiene MX, ningún correo va a llegar ahí. Pero que un dominio tenga MX no significa que ana@empresa.com exista como buzón. Solo confirma que la infraestructura para recibir correo está configurada.
Verificación SMTP
En teoría, puedes conectarte al servidor receptor por SMTP y ejecutar RCPT TO:<ana@empresa.com> sin enviar un mensaje real. Si el servidor responde 250 OK, el buzón probablemente existe. Si responde 550, no existe.
En la práctica, muchos servidores ya no dan información útil por esta vía. Gmail, por ejemplo, acepta el RCPT TO para cualquier dirección y decide después internamente. Otros servidores bloquean las consultas repetidas o devuelven respuestas engañosas deliberadamente para evitar que programas automatizados validen listas masivas de direcciones.
La verificación SMTP es una señal útil, no una verdad absoluta.
Dominios catch-all
Un dominio configurado como catch-all acepta correo para cualquier dirección, exista o no el buzón. Si empresa.com es catch-all, tanto ana@empresa.com como xyzrandom@empresa.com recibirán respuesta positiva del servidor. Esto hace imposible distinguir direcciones reales de inventadas solo con verificación SMTP.
Tabla resumen de puertos y protocolos
| Protocolo | Puerto | Cifrado | Función |
|---|---|---|---|
| SMTP | 25 | STARTTLS (opcional) | Transferencia entre servidores |
| SMTP Submission | 587 | STARTTLS | Envío desde cliente autenticado |
| SMTPS | 465 | TLS implícito | Envío desde cliente (alternativa) |
| POP3 | 110 | Ninguno | Descarga de correo |
| POP3S | 995 | TLS implícito | Descarga de correo cifrada |
| IMAP | 143 | STARTTLS (opcional) | Sincronización de buzón |
| IMAPS | 993 | TLS implícito | Sincronización cifrada |
Conclusión
La cadena de entrega de un correo electrónico es más larga y más frágil de lo que parece desde la interfaz de Gmail. SMTP se encarga de mover el mensaje entre servidores, mientras DNS y los registros MX le indican a cuál entregarlo. En el camino, TLS protege la conexión contra interceptación. Del otro lado, SPF y DKIM permiten verificar que el remitente es quien dice ser, y DMARC ata todo con el dominio que el usuario ve en su bandeja.
Configurar mal cualquiera de estos eslabones tiene consecuencias reales: correos legítimos que caen en spam, dominios que pierden reputación, sistemas de autenticación que se rompen con un reenvío o proveedores de envío que nunca se incluyeron en el SPF. Si administras infraestructura de correo o te estás preparando para una certificación de redes, entender estos protocolos no es opcional. Son la base sobre la que funciona una de las aplicaciones más antiguas y más usadas de Internet.
