RFC 5322 – Formato de Mensaje de Internet

Current Standard Core SMTP & Message Format Obsoletes RFC 2822 Published March 2026

ELI5: Si [RFC 5321](5321) (SMTP) es el camión postal que entrega tu carta, RFC 5322 es el formato de la carta en sí — donde escribes la dirección de remitente, la dirección del destinatario, la fecha, la línea de asunto, y luego el mensaje actual debajo. Cada correo electrónico que abres en tu bandeja de entrada está estructurado de acuerdo con esta especificación.

Por qué existe este RFC

RFC 5322 define la sintaxis de un mensaje de correo electrónico — el texto que fluye a través de SMTP durante la fase DATA. Su predecesor, RFC 822 (1982), fue uno de los primeros estándares de internet. RFC 5322 actualizó el formato con reglas de sintaxis más estrictas, manejo más claro de sintaxis obsoleta, y alineación con prácticas modernas.

Este RFC trata puramente del formato del mensaje — no dice nada sobre cómo se transporta el mensaje (eso es RFC 5321) o cómo funcionan los adjuntos (eso es RFC 2045 y la familia MIME). Define los campos de encabezado, el cuerpo y las reglas para direcciones, fechas e identificación de mensajes.

Cómo funciona

Un mensaje de correo electrónico se divide en dos partes separadas por una línea en blanco:

Sección de encabezado: Una secuencia de campos de encabezado, cada uno como Nombre: valor, terminada por CRLF.
Cuerpo: El contenido del mensaje, que es simplemente texto no estructurado (MIME añade estructura encima).

Estructura del mensaje

# Sección de encabezado From: Alice Smith <alice@example.com> To: Bob Jones <bob@example.net>, Carol White <carol@example.org> Cc: Dave <dave@example.com> Subject: Quarterly Report Date: Wed, 11 Mar 2026 15:30:00 -0500 Message-ID: <unique-id-12345@example.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" # Línea en blanco separa encabezados del cuerpo Hi Bob and Carol, Please find the quarterly report attached.

Campos de encabezado obligatorios

RFC 5322 requiere que todo mensaje DEBE contener estos campos:

Campo	Descripción	Ejemplo
`From:`	El autor o autores del mensaje	`From: Alice <alice@example.com>`
`Date:`	Cuándo se compuso el mensaje	`Date: Wed, 11 Mar 2026 15:30:00 -0500`

Además, todo mensaje DEBERÍA contener un campo Message-ID — un identificador único global. Los mensajes sin un Message-ID causan problemas con el enhebrado, deduplicación y firma DKIM.

Campos de encabezado comunes

Campo	Propósito
`To:`	Destinatarios principales
`Cc:`	Destinatarios con copia de carbón
`Bcc:`	Copia de carbón ciega (eliminada antes de la entrega)
`Subject:`	Tema del mensaje
`Reply-To:`	Dirección para respuestas (anula From:)
`Sender:`	Remitente real cuando From: contiene múltiples autores o difiere del agente transmisor
`In-Reply-To:`	Message-ID del mensaje al que se está respondiendo
`References:`	Cadena de Message-IDs para enhebrado
`Message-ID:`	Identificador único global para este mensaje
`Return-Path:`	Añadido por el sistema de entrega final de MAIL FROM
`Received:`	Encabezado de rastreo añadido por cada servidor que maneja el mensaje

Detalles técnicos clave

Formatos de dirección

RFC 5322 define dos formatos de dirección válidos:

Addr-spec: alice@example.com — solo el buzón.
Name-addr: Alice Smith <alice@example.com> — un nombre visible más dirección entre ángulos.

Los nombres visibles que contienen caracteres especiales deben entrecomillarse: "O'Brien, Alice" <alice@example.com>. La parte local (antes de la @) es sensible a mayúsculas según la especificación pero tratada como insensible a mayúsculas por prácticamente todos los sistemas de correo en la práctica.

Formato de fecha

El formato de fecha es específico e inflexible:

Date: Thu, 11 Mar 2026 15:30:00 -0500

El formato es: day-of-week, DD Mon YYYY HH:MM:SS zone. El día de la semana es opcional pero convencional. La zona horaria debe ser un desplazamiento numérico (-0500), no un nombre como "EST". Aunque la especificación tolera abreviaturas antiguas de zona horaria como sintaxis obsoleta, no se recomienda generarlas.

Formato de Message-ID

Un Message-ID debe ser único globalmente y sigue la forma:

Message-ID: <unique-part@domain>

La mejor práctica es usar un UUID o una parte única basada en marca de tiempo combinada con tu dominio de envío: <20260311153000.a1b2c3@mail.example.com>.

Plegado de encabezado

Los valores de encabezado largos pueden ser "plegados" insertando un CRLF seguido de al menos un espacio o tabulación (espacio en blanco). Así es como las listas largas de destinatarios o líneas de asunto se mantienen dentro del límite de 998 caracteres por línea:

To: Alice <alice@example.com>, Bob <bob@example.com>, Carol <carol@example.com>

Los analizadores deben "desplegar" estos al unir líneas donde la continuación comienza con espacio en blanco.

Encabezados de rastreo

Cada servidor de correo que maneja un mensaje antepone un encabezado Received:. Estos forman un rastro de arriba a abajo — el encabezado Received: superior fue añadido por último. El encabezado Return-Path: es añadido solo por el sistema de entrega final y contiene el remitente del sobre de MAIL FROM.

Errores comunes

Encabezado Date faltante o malformado. Algunos filtros de spam penalizan mensajes sin un encabezado Date apropiado o con una fecha muy en el futuro o pasado. Siempre genéralo en el momento del envío.
Message-ID faltante. Sin un Message-ID único, las respuestas no se enhebrarán correctamente, las firmas DKIM pueden no cubrir el campo y algunos filtros de spam marcan el mensaje.
Entrecomillado de dirección incorrecto. Los nombres visibles con comas, puntos o caracteres especiales deben entrecomillarse. O'Brien, Alice <alice@example.com> es inválido — debe ser "O'Brien, Alice" <alice@example.com>.
Usar BCC incorrectamente. El encabezado BCC debe ser eliminado antes de la transmisión. Si incluyes destinatarios BCC en el encabezado que se entrega, has anulado el propósito de la copia ciega.
Exceder la longitud de línea. Las líneas de encabezado y cuerpo no deben exceder 998 caracteres. Usa plegado de encabezado para encabezados largos y codificación MIME apropiada para contenido de cuerpo largo.
Confundir From y Sender. El encabezado Sender: es requerido solo cuando la entidad transmisora real difiere del autor From:. No añadas un encabezado Sender redundante que coincida con From — es innecesario y puede confundir filtros.
Formato de zona horaria incorrecto. Usar EST en lugar de -0500 es sintaxis obsoleta. Siempre usa desplazamientos numéricos.

Impacto en la entregabilidad

La firma DKIM depende de encabezados. DKIM (RFC 6376) firma campos de encabezado específicos. Los encabezados faltantes o malformados significan que la firma puede no cubrir lo que esperas, o el mensaje puede fallar en la verificación.
Las verificaciones de alineación DMARC comprueban el encabezado From. DMARC (RFC 7489) compara el dominio en el encabezado From: contra resultados de SPF y DKIM. Un encabezado From no coincidente o faltante significa fallo automático de DMARC.
Enhebrado y experiencia del usuario. Los encabezados Message-ID, In-Reply-To y References adecuados aseguran que tus mensajes se enhebren correctamente en los clientes de correo de los destinatarios. El enhebrado roto hace que tus mensajes se vean poco profesionales.
Heurísticas de filtros de spam. Los filtros comprueban el cumplimiento de RFC 5322. Los encabezados requeridos faltantes, fechas malformadas y formato no estándar son todas señales negativas que aumentan tu puntuación de spam.
Suplantación de nombre visible. Los proveedores de buzones de correo cada vez más muestran advertencias cuando la dirección From se ve sospechosa. Usar un encabezado From limpio y consistente con un nombre visible reconocible mejora las tasas de apertura y confianza.