Escritos

¿Qué es SMTP? Cómo viaja un correo por internet (guía de MX, SPF, DKIM y DMARC)

¿Qué ocurre en los milisegundos posteriores a que tu backend dispara un correo de restablecimiento de contraseña? Desde los relays SMTP y las consultas DNS MX hasta la trinidad criptográfica (SPF, DKIM, DMARC) que mantiene tus correos transaccionales fuera de la carpeta de spam.

Furkan Özay18 de octubre de 2026 · 4 min de lectura
czCZAY.DEV // EDITORIALES
AĞ & PROTOKOLLER

#Ağ & Protokoller · 4 MIN DE LECTURA

FURKAN ÖZAYVOL. 2026 // #2003

Enviar un correo desde una aplicación web parece algo sin esfuerzo: llamas a resend.emails.send() o a nodemailer.sendMail() y dos segundos después un código de verificación aparece en la bandeja de entrada del usuario.

Sin embargo, detrás de esa única llamada a la API hay una arquitectura de relays distribuida de hace 40 años que involucra handshakes TCP, enrutamiento DNS y firmas criptográficas. Si no entiendes cómo funciona, tus correos de restablecimiento de contraseña en producción acabarán inevitablemente bloqueados en silencio o enterrados en la carpeta de spam.

· · ·

1. ¿Qué es SMTP (Simple Mail Transfer Protocol)?

Estandarizado por primera vez en 1982 (RFC 821 / RFC 5321), SMTP es el mensajero postal de internet.

Lo fundamental: SMTP es un protocolo solo de envío y retransmisión (push): ¡no se usa para leer los correos de tu bandeja de entrada!

  • SMTP (puertos 587 TLS, 465 SSL, 25 Relay): Envía el correo saliente desde el cliente o backend del remitente al servidor de correo, y lo retransmite desde el servidor de correo del remitente al servidor de correo del destinatario.
  • IMAP (puerto 993): Sincroniza y lee los correos almacenados en el servidor de correo receptor desde varios dispositivos (móvil, portátil).
  • POP3 (puerto 995): Protocolo heredado que descarga el correo a un único dispositivo y normalmente lo elimina del servidor.
· · ·

2. El viaje de un correo paso a paso

Cuando [email protected] envía un correo a [email protected], ocurren cuatro pasos:

text
[1. Backend API] ──(SMTP Auth :587)──▶ [2. Outgoing MTA (SES / Resend / Postfix)]
                                                       │
                                        (DNS Query: "What is gmail.com's MX record?")
                                                       │
                                                       ▼
[4. User's Inbox] ◀──(IMAP :993)── [3. Gmail Inbound MX Server (Port :25 + TLS)]
  1. Envío (MSA): Tu backend en Node.js/Go/PHP se conecta a tu servidor de correo saliente por el puerto 587 (STARTTLS) y entrega el mensaje.
  2. Consulta DNS MX: Tu servidor de correo pregunta al DNS: "¿Dónde entrego el correo de gmail.com?" El DNS responde con los registros MX (Mail Exchange) (por ejemplo, gmail-smtp-in.l.google.com, prioridad 5).
  3. Relay de servidor a servidor (MTA): Tu servidor de correo abre una conexión con el servidor MX de Gmail y mantiene una conversación SMTP (EHLO, MAIL FROM, RCPT TO, DATA).
  4. Entrega en la bandeja (MDA / IMAP): Si Gmail verifica la autenticidad del remitente, coloca el mensaje en el buzón del usuario, donde su móvil lo lee mediante IMAP.
· · ·

3. ¿Por qué los correos acaban en spam? (SPF, DKIM y DMARC)

Como la especificación original de SMTP de 1982 tenía cero verificación del remitente integrada, cualquiera podía levantar un servidor y declarar MAIL FROM: <[email protected]>. Para frenar la suplantación, los proveedores de correo modernos (Gmail, Outlook) exigen estrictamente tres registros DNS de seguridad:

1. SPF (Sender Policy Framework)

Un registro DNS TXT que enumera qué direcciones IP y proveedores de correo están autorizados oficialmente para enviar correos en nombre de tu dominio.

2. DKIM (DomainKeys Identified Mail)

Adjunta una firma digital criptográfica (cabecera DKIM-Signature) a cada correo saliente usando tu clave privada. El servidor receptor obtiene tu clave pública del DNS (selector._domainkey.czay.dev) para verificar que el correo te pertenece y que no fue alterado en tránsito.

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

Indica al servidor receptor qué hacer si un correo no supera las comprobaciones de SPF y DKIM (p=none, p=quarantine -> enviar a spam, o p=reject -> bloquear por completo).

Advertencia: Regla de producción: nunca envíes correo transaccional directamente desde el flujo de tu app

Un handshake SMTP tarda entre 300 ms y 1500 ms. ¡Nunca hagas await sendEmail() de forma síncrona dentro de una solicitud HTTP de registro de usuario o de pago! Envía siempre los trabajos de correo a una cola asíncrona en segundo plano (BullMQ / RabbitMQ) para que tu API responda en 10 ms.

Hoja de ruta y herramienta interactivas

Sigue leyendo