SincroDev El Viaje de un Email: De "Enviar" a la bandeja de entrada
Escribes un mensaje, pones el destinatario y presionas “Enviar”. El email desaparece de tu pantalla y, segundos después, aparece en la bandeja de entrada del otro lado del mundo. ¿Magia? No, es un sistema diseñado en los años 80 que sigue funcionando sorprendentemente bien.
Capa 1: Tu Cliente de Correo
Todo empieza en tu aplicación (Gmail, Outlook, Thunderbird):
- Compone el mensaje en formato MIME (permite texto, HTML, adjuntos)
- Añade cabeceras: From, To, Subject, Date, Message-ID
- Codifica adjuntos en Base64 (los binarios no viajan bien como texto)
- Se conecta a tu servidor SMTP para enviarlo
De: tu@tudominio.com
Para: amigo@otrodominio.com
Asunto: Hola!
┌─────────────────┐
Tu mensaje ───→│ Cliente Email │───→ SMTP
│ (Gmail/Outlook) │
└─────────────────┘Capa 2: Autenticación con tu Servidor
Antes de enviar, tu servidor necesita saber que eres tú:
- Conexión TLS al puerto 587 (o 465) de tu servidor SMTP
- Autenticación: usuario y contraseña (o OAuth2 en servicios modernos)
- El servidor verifica que puedes enviar desde esa dirección
Tu cliente Tu servidor SMTP
│ │
│ ─── EHLO [tu-pc] ──────────────────→│
│ ←── 250 OK, soporto AUTH, TLS ──────│
│ ─── AUTH LOGIN [credenciales] ─────→│
│ ←── 235 Autenticación exitosa ──────│
│ │
│ ✓ Listo para enviar │Capa 3: El Sobre Digital
Ahora tu cliente envía el email usando comandos SMTP:
MAIL FROM:<tu@tudominio.com> ← "El remitente es..."
RCPT TO:<amigo@otrodominio.com> ← "El destinatario es..."
DATA ← "Aquí viene el contenido"
From: Tu Nombre <tu@tudominio.com>
To: Amigo <amigo@otrodominio.com>
Subject: Hola!
Date: Sat, 7 Dec 2025 10:30:00 +0100
Content-Type: text/plain
Este es el cuerpo del mensaje.
. ← Un punto solo = fin del mensaje
QUITDato curioso: El “sobre” (MAIL FROM/RCPT TO) y las cabeceras (From/To) son independientes. Por eso existe el spoofing de emails.
Capa 4: Tu Servidor Procesa
Tu servidor SMTP recibe el mensaje y:
- Valida que el destinatario tiene formato correcto
- Agrega cabeceras de seguimiento (Received:)
- Encola el mensaje para envío
- Busca a dónde enviarlo → necesita consultar DNS
┌─────────────────────────────────────────────┐
│ Tu Servidor SMTP │
│ │
│ Recibido → Validado → Cola de salida │
│ │ │
│ ▼ │
│ "¿Dónde está │
│ otrodominio.com?" │
└─────────────────────────────────────────────┘Capa 5: DNS y Registros MX
Para encontrar el servidor de correo del destinatario, se consultan los registros MX (Mail eXchanger):
Consulta DNS: "¿Cuáles son los MX de otrodominio.com?"
Respuesta:
otrodominio.com. MX 10 mail1.otrodominio.com.
otrodominio.com. MX 20 mail2.otrodominio.com.
↑ ↑
Tipo Prioridad (menor = preferido)El número indica prioridad. Se intenta primero el 10, si falla, el 20.
Tu servidor DNS
│ │
│ ── MX query: otrodominio.com? ─────→│
│ ←── MX 10 mail1.otrodominio.com ────│
│ │
│ ── A query: mail1.otrodominio.com? →│
│ ←── A 203.0.113.50 ─────────────────│
│ │
▼
"Debo conectar a 203.0.113.50:25"Capa 6: Servidor a Servidor
Tu servidor SMTP se conecta al servidor destino:
Tu servidor SMTP Servidor destino
│ │
│ ─── Conexión TCP puerto 25 ────────→│
│ ←── 220 mail1.otrodominio.com ──────│
│ ─── EHLO tudominio.com ────────────→│
│ ←── 250 OK ─────────────────────────│
│ ─── MAIL FROM:<tu@tudominio.com> ──→│
│ ─── RCPT TO:<amigo@otrodominio.com>→│
│ ─── DATA + mensaje ────────────────→│
│ ←── 250 OK, queued as ABC123 ───────│
│ │
│ ✓ Mensaje entregado │Capa 7: Verificación Anti-Spam
El servidor destino no confía ciegamente. Hace verificaciones:
SPF (Sender Policy Framework)
“¿El servidor que envía está autorizado para ese dominio?”
Consulta DNS TXT para tudominio.com:
"v=spf1 include:_spf.google.com ~all"
→ Solo los servidores de Google pueden enviar desde @tudominio.comDKIM (DomainKeys Identified Mail)
“¿El mensaje fue firmado por el dominio remitente?”
Cabecera del email:
DKIM-Signature: v=1; a=rsa-sha256; d=tudominio.com; s=selector1;
h=from:to:subject:date; bh=abc123...; b=xyz789...
El servidor destino:
1. Obtiene la clave pública desde DNS (selector1._domainkey.tudominio.com)
2. Verifica la firma
3. ✓ El mensaje no fue alterado en tránsitoDMARC (Domain-based Message Authentication)
“¿Qué hacer si falla SPF o DKIM?”
_dmarc.tudominio.com TXT "v=DMARC1; p=reject; rua=mailto:reports@tudominio.com"
p=reject → Rechazar emails que fallen las verificaciones┌─────────────────────────────────────────────┐
│ Verificaciones Anti-Spam │
│ │
│ ┌─────┐ ┌──────┐ ┌───────┐ │
│ │ SPF │ + │ DKIM │ + │ DMARC │ = ✓ o ✗ │
│ └─────┘ └──────┘ └───────┘ │
│ │
│ + Filtros de spam (contenido, reputación) │
└─────────────────────────────────────────────┘Capa 8: Entrega al Buzón
Si todo está bien, el servidor destino:
- Determina el buzón local del usuario
- Aplica filtros del usuario (reglas, carpetas)
- Almacena el mensaje (formato Maildir o base de datos)
- Actualiza índices para búsqueda
Servidor destino
│
▼
┌─────────────────┐
│ MDA (Dovecot) │ ← Mail Delivery Agent
│ │
│ Filtros Sieve │ ← "Si viene de X, mover a carpeta Y"
│ │ │
│ ▼ │
│ /home/amigo/ │
│ Maildir/new/ │ ← Mensaje almacenado
└─────────────────┘Capa 9: El Destinatario Lee
Cuando tu amigo abre su cliente de correo:
- Se conecta vía IMAP (o POP3) a su servidor
- Sincroniza la bandeja de entrada
- Descarga el mensaje nuevo
- Renderiza el contenido (HTML, imágenes, adjuntos)
Cliente del destinatario Servidor IMAP
│ │
│ ─── LOGIN [credenciales] ───────→│
│ ─── SELECT INBOX ───────────────→│
│ ←── Tienes 1 mensaje nuevo ──────│
│ ─── FETCH 1 BODY[] ─────────────→│
│ ←── [Contenido del email] ───────│
│ │
▼
📧 "¡Tienes un email de tu@tudominio.com!"El Diagrama Completo
┌─────────────────┐
│ Tu Cliente │
│ (Gmail/etc) │
└────────┬────────┘
│ SMTP (587)
▼
┌─────────────────┐ ┌─────────────────┐
│ Tu Servidor │────→│ DNS │
│ SMTP │ │ "¿MX de dest?" │
└────────┬────────┘ └─────────────────┘
│ │
│ ←── MX records ──────┘
│
│ SMTP (25)
▼
┌─────────────────────────────────────────────┐
│ Servidor Destino │
│ │
│ ┌─────────┐ ┌─────────┐ ┌──────────┐ │
│ │ SMTP │ → │ Checks │ → │ MDA │ │
│ │ Recibe │ │SPF/DKIM │ │ Entrega │ │
│ └─────────┘ └─────────┘ └──────────┘ │
│ │ │
│ ┌──────▼─────┐ │
│ │ Buzón │ │
│ │ IMAP │ │
│ └──────┬─────┘ │
└─────────────────────────────────────┼───────┘
│
IMAP (993)
│
▼
┌─────────────────┐
│ Cliente destino │
│ 📧 Mensaje! │
└─────────────────┘¿Cuánto tiempo toma?
| Paso | Tiempo típico |
|---|---|
| Cliente → Tu SMTP | < 1 segundo |
| DNS (MX lookup) | 20-100ms |
| Tu SMTP → SMTP destino | 1-5 segundos |
| Verificaciones SPF/DKIM | < 1 segundo |
| Entrega al buzón | < 1 segundo |
| Sincronización IMAP | 1-30 segundos |
| Total | 3-60 segundos |
Puede tomar más si hay greylisting (retraso intencional anti-spam) o colas ocupadas.
¿Qué puede fallar?
| Error | Causa común |
|---|---|
| 550 User not found | El destinatario no existe |
| 553 Relay denied | Tu servidor no está autorizado |
| 421 Too many connections | Rate limiting |
| 550 SPF fail | Tu servidor no está en el registro SPF |
| Llega a Spam | Falla DKIM, mala reputación, contenido sospechoso |
Conclusión
Un simple email atraviesa:
- Tu cliente → compone y codifica
- Tu servidor SMTP → autentica y encola
- DNS → encuentra el servidor destino (MX)
- Internet → viaja entre servidores
- SMTP destino → recibe y verifica (SPF/DKIM/DMARC)
- MDA → entrega al buzón
- IMAP → el destinatario lo descarga
Un protocolo de más de 40 años (SMTP, 1982) que sigue moviendo más de 300 mil millones de emails al día. No está mal para tecnología de los 80.
Este post es parte de la serie “El Viaje de la Información”, donde exploramos qué sucede realmente cuando interactuamos con nuestros sistemas.
P.D. ¿Qué es el spoofing de emails?
¿Recuerdas que mencionamos que el “sobre” (MAIL FROM) y las cabeceras (From:) son independientes? Ahí está el problema.
El protocolo SMTP original (1982) fue diseñado para una época de confianza. No verifica que quien dice ser el remitente realmente lo sea. Es como enviar una carta postal escribiendo cualquier nombre en el remitente.
MAIL FROM:<ceo@empresa.com> ← El sobre dice "CEO"
...
From: CEO Empresa <ceo@empresa.com> ← La cabecera dice "CEO"
Pero el email lo envió cualquier servidor random.Esto es email spoofing: falsificar la dirección del remitente para que parezca que el email viene de alguien más (tu banco, tu jefe, un servicio conocido).
Por eso existen SPF, DKIM y DMARC: son parches que se añadieron décadas después para verificar que el remitente es quien dice ser. Si un dominio tiene estos registros bien configurados, los emails falsificados serán rechazados o irán a spam.
Moraleja: si recibes un email sospechoso “del banco” pidiéndote datos, recuerda que el From: puede mentir. Verifica siempre el dominio real y los indicadores de autenticación de tu cliente de correo.