← RFC Reference

El ciclo de vida de un correo electrónico

Desde el momento en que haces clic en "Enviar" hasta que un mensaje aparece en la bandeja de entrada de alguien — cada salto, cada protocolo, cada decisión en el camino.

Los Actores

La Arquitectura de Correo de Internet (RFC 5598) define los roles que participan en la entrega de correo. Entender estos roles es esencial porque el mismo software a menudo juega múltiples roles, y los límites entre ellos importan para entender cómo fluye el correo.

En la práctica, estos roles a menudo se colapsan. La infraestructura de Gmail es simultáneamente MSA, MTA, MX, MDA y MRA. Postfix puede actuar como tanto MSA como MTA. Pero los roles lógicos siguen siendo distintos, y entenderlos te ayuda a depurar problemas de entrega.

Etapa 1: Redacción (MUA)

El ciclo de vida comienza cuando un usuario redacta un mensaje en su cliente de correo, o cuando una aplicación genera un mensaje mediante programación (a través de una API o librería SMTP).

El MUA construye el mensaje según RFC 5322 (Formato de Mensaje de Internet):

Decisiones clave en esta etapa:

• El encabezado From: identifica al autor para el destinatario (y es lo que DMARC verifica para alineación).
• El Message-ID: se genera — un identificador único global para este mensaje específico.
• Se aplica codificación MIME: los adjuntos se codifican en Base64, el cuerpo se estructura como multiparte si es necesario.
• El MUA no añade encabezados Received:. Esos los añade cada servidor que maneja el mensaje.

Etapa 2: Envío (MUA → MSA)

El MUA se conecta al MSA (RFC 6409) para entregar el mensaje. Este es el paso de envío.

Lo que hace el MSA al recibir el mensaje:

• Autentica al remitente. El MUA debe proporcionar credenciales válidas (usuario/contraseña a través de AUTH). Esto evita que gente al azar use tu servidor de correo como relé abierto.
• Valida la envoltura. El MSA puede verificar que el dominio MAIL FROM coincida con el dominio del usuario autenticado.
• Añade un encabezado Received:. Esto registra el primer salto: quién envió el mensaje, cuándo y desde qué IP.
• Puede añadir o corregir encabezados. El MSA puede añadir un encabezado Date: si falta, generar un Message-ID: si el MUA no lo hizo, y añadir encabezados DKIM-Signature.
• Pone el mensaje en cola para entrega. El mensaje entra en la cola de salida del MTA.

La ruta de envío por API

Al usar un servicio de correo transaccional como Mailer To Go, tu aplicación típicamente envía a través de una API HTTP en lugar de SMTP. El servidor de API acepta el mensaje, construye la envoltura SMTP y los encabezados, aplica firma DKIM, e inyecta el mensaje en la cola del MTA. La llamada a la API reemplaza tanto el MUA como la transacción SMTP MUA-a-MSA, pero todo lo posterior permanece igual.

Etapa 3: Enrutamiento y Transferencia (MTA → MTA)

El MTA de envío ahora debe entregar el mensaje al dominio del destinatario. Esta es la fase de retransmisión, gobernada por RFC 5321 (SMTP).

Resolución DNS

El MTA busca los registros MX para el dominio del destinatario:

Intenta el MX de menor prioridad primero. Si ese servidor es inaccesible, retrocede al siguiente. Véase Enrutamiento de Correo y DNS para el algoritmo completo, incluyendo retroceso a registros A/AAAA y manejo de Null MX.

La transferencia

En esta etapa:

• STARTTLS encripta la conexión. Sin MTA-STS o DANE, el MTA de envío retrocederá a texto plano si la negociación TLS falla. Este es un riesgo de seguridad — un atacante activo puede despojar TLS de la conexión.
• No se usa autenticación (AUTH). SMTP servidor-a-servidor en el puerto 25 no requiere credenciales. El servidor receptor confía en la dirección IP, SPF, DKIM, y DMARC para verificar al remitente.
• Se añade otro encabezado Received:. Cada MTA prepone un encabezado Received:, construyendo una cadena que documenta el camino del mensaje.
• El mensaje puede pasar por múltiples MTAs. El enrutamiento interno dentro de organizaciones grandes, reglas de reenvío y listas de correo pueden añadir saltos adicionales.

Puesta en cola y reintentos

Si el MX receptor devuelve un error temporal 4xx (servidor ocupado, greylisting, límite de velocidad), el MTA de envío pone el mensaje en cola y reintenta más tarde. Los programas de reintento típicamente usan retroceso exponencial: 15 minutos, 30 minutos, 1 hora, 2 horas, etc. Si el mensaje no se puede entregar después del período de reintento (usualmente 4–5 días), el MTA genera un mensaje de rebote (DSN) y lo envía de vuelta al remitente de envoltura.

Etapa 4: Recepción (MX)

El MX receptor (el MTA que acepta correo entrante para el dominio del destinatario) es donde ocurre la mayoría del filtrado. Este es el guardián.

En el momento de la conexión, antes de que llegue contenido del mensaje:

• Verificación de reputación de IP. El MX receptor verifica la IP conectada contra su base de datos de reputación interna y listas de bloqueo externas.
• Verificación de DNS inverso. La IP debe tener un registro PTR válido que se resuelva de vuelta a la misma IP.
• Limitación de velocidad. Conexiones excesivas desde la misma IP pueden ser limitadas.

Durante la fase de envoltura:

• Validación de destinatario. ¿Existe el buzón? Si no: 550 5.1.1 User unknown.
• Verificación SPF. El dominio MAIL FROM se verifica contra su registro SPF para verificar que la IP de envío está autorizada.

Después de DATA (el mensaje completo se recibe):

• Verificación DKIM. La firma DKIM se valida contra la clave pública en DNS.
• Evaluación DMARC. Los resultados de SPF y DKIM se verifican para alineación DMARC con el encabezado From:.
• Filtrado de contenido. El mensaje pasa a través de filtros de spam: análisis de contenido, verificación de URL, clasificación Bayesiana, modelos de aprendizaje automático.
• Se añade encabezado Authentication-Results. El MX registra los resultados de todas las verificaciones de autenticación en un encabezado Authentication-Results.

Etapa 5: Entrega (MDA)

El Agente de Entrega de Correo toma el mensaje que pasó el filtrado y lo deposita en el buzón del destinatario. En muchos sistemas, el MDA está integrado en el servidor MX en lugar de ser un proceso separado.

Las responsabilidades del MDA:

• Selección de buzón. Determina cuál buzón (cuenta de usuario) recibe el mensaje basado en la dirección RCPT TO, alias y reglas de enrutamiento.
• Colocación de carpeta. Basado en el veredicto del filtro de spam y reglas definidas por el usuario, el mensaje va a la Bandeja de entrada, carpeta Spam/Correo no deseado, una etiqueta específica (Gmail), o una carpeta personalizada (reglas Sieve).
• Filtrado Sieve. Muchos sistemas de correo soportan Sieve (RFC 5228), un lenguaje para reglas de filtrado de correo definidas por el usuario. Las reglas pueden archivar mensajes en carpetas, reenviarlos, rechazarlos, o activar respuestas automáticas de vacaciones.
• Aplicación de cuota. Si el buzón está sobre cuota, el MDA puede rechazar el mensaje con 452 4.2.2 Mailbox full o 552 5.2.2 Mailbox full.
• Notificación. El MDA puede activar una notificación push a los dispositivos del usuario (alerta de correo nuevo).

En este punto, el mensaje está en reposo en el almacén de correo del destinatario. La transacción SMTP está completa. La responsabilidad del MTA de envío terminó cuando recibió el 250 OK del MX receptor.

Etapa 6: Recuperación (MRA → MUA)

El cliente de correo del destinatario recupera el mensaje del almacén de correo usando uno de tres protocolos:

IMAP (RFC 9051)

El protocolo dominante de acceso a correo. IMAP mantiene mensajes en el servidor y sincroniza estado (leído/no leído, banderas, carpetas) entre múltiples clientes. El cliente descarga encabezados de mensaje primero y obtiene cuerpos completos bajo demanda. Los cambios realizados en un cliente (marcar como leído, mover a una carpeta) se reflejan en todos los clientes.

POP3 (RFC 1939)

El protocolo más antiguo y simple. POP3 descarga mensajes al cliente y (por defecto) los borra del servidor. No sincroniza estado entre clientes. Largamente superado por IMAP, pero aún usado en algunos escenarios.

Acceso web y API

Las interfaces de correo web (Gmail, Outlook.com) y aplicaciones móviles acceden al almacén de correo a través de APIs propietarias o JMAP (RFC 8620), evitando IMAP/POP3 completamente. El mensaje nunca deja los servidores del proveedor — el cliente lo muestra a través de una solicitud web.

Dónde Salen Mal las Cosas: Modos de Fallo en Cada Etapa

Fallos de envío

La autenticación falla (contraseña incorrecta, token expirado), el MSA rechaza el mensaje (sobre límite de tamaño, violación de política), o la conexión expira. El usuario ve un error inmediatamente.

Fallos de enrutamiento

La resolución DNS falla (sin registros MX, timeout de DNS), todos los hosts MX son inaccesibles, o cada MX devuelve un error permanente. Después de agotar reintentos, el remitente recibe un rebote (DSN).

Rechazo en tiempo de recepción

El MX receptor rechaza el mensaje en tiempo SMTP: IP en lista de bloqueo (550), autenticación fallida (550 5.7.1), destinatario desconocido (550 5.1.1), o rechazo de contenido (554). El MTA de envío genera una notificación de rebote al remitente de envoltura.

Filtrado post-aceptación

El MX aceptó el mensaje (250 OK) pero el MDA lo enruta a la carpeta de spam basado en análisis de contenido y puntuación de reputación. El remitente no recibe un rebote — el mensaje fue técnicamente "entregado" — pero el destinatario nunca lo ve. Este es el problema más común y más difícil de diagnosticar en entregabilidad.

Buzón lleno

El buzón del destinatario está sobre cuota. Dependiendo de la implementación, esto es un rechazo en tiempo de RCPT TO o un rebote generado después de aceptación de DATA.

Los Encabezados Cuentan la Historia

Cada etapa del ciclo de vida añade encabezados al mensaje. Leer encabezados de abajo a arriba reconstruye el viaje:

Los encabezados Received: son las migas de pan. Cada uno registra el host de envío, el host receptor, el protocolo usado (ESMTP, ESMTPS para TLS, ESMTPSA para autenticado+TLS), un ID de cola, y una marca de tiempo. Véase Anatomía de Encabezados de Correo para una guía completa.

La Ruta de Correo Transaccional

Cuando una aplicación envía correo a través de un servicio como Mailer To Go, el ciclo de vida es ligeramente diferente:

1. La aplicación llama a la API. Tu app envía una solicitud POST con el contenido del mensaje, destinatarios y metadatos.
2. El servicio construye el mensaje. Construye la estructura MIME, añade encabezados requeridos (Date, Message-ID, List-Unsubscribe si aplica), y aplica firma DKIM con la clave de tu dominio.
3. El MTA del servicio envía el mensaje. El mensaje se envía desde la IP del servicio al MX del destinatario a través de SMTP en el puerto 25, con STARTTLS.
4. El resto es idéntico. La recepción del MX, verificaciones de autenticación, filtrado de contenido, entrega del MDA y recuperación del cliente todas proceden como se describe arriba.

La diferencia clave: tu aplicación nunca habla SMTP directamente. La API abstrae la capa de envío completa. Pero el mensaje aún atraviesa la misma infraestructura, se somete a las mismas verificaciones de autenticación, y es evaluado por los mismos filtros de spam.

Conclusiones Clave

• El correo tiene seis etapas distintas: redacción, envío, transferencia, recepción, entrega y recuperación. Cada etapa implica diferentes protocolos y diferentes actores.
• La envoltura y el mensaje son separados. MAIL FROM / RCPT TO (la envoltura) pueden diferir de los encabezados From: / To: (el mensaje). Esta distinción importa para autenticación, rebotes y Bcc.
• La mayoría del filtrado ocurre en recepción. El MX receptor es donde la autenticación, reputación y contenido se evalúan. Esta es la etapa que determina bandeja de entrada vs. spam.
• Un 250 OK significa aceptado, no entregado a la bandeja de entrada. El MX receptor puede aún enrutar el mensaje a spam, o el MDA puede rechazarlo más tarde (buzón lleno, reglas Sieve).
• Los encabezados Received: documentan el viaje. Léelos de abajo a arriba para rastrear el camino de un mensaje. Son la herramienta de depuración más útil para problemas de entrega.
• Cada salto añade latencia y riesgo. Más saltos significan más chances de fallo, retraso, o modificación de contenido (que puede romper firmas DKIM).

Lectura Adicional

Related RFCs