RFC 6532 – Encabezados de Correo Electrónico Internacionalizados

Proposed Standard Core SMTP & Message Format Obsoletes RFC 5322 Published March 2026

ELI5: Antes de este RFC, si querías escribir un nombre como "Müller" o una línea de asunto en japonés en un encabezado de correo electrónico, tenías que codificarlo en un lío ilegible como `=?UTF-8?B?...?=`. RFC 6532 dice "simplemente usa UTF-8 directamente". La línea From puede decir `田太郎 ` en texto plano, y el Subject puede estar en cualquier idioma sin trucos de codificación. El correo electrónico se ve igual en la red que en la pantalla.

Por Qué Existe Este RFC

El formato original de mensaje de correo electrónico (RFC 5322) restringe los campos de encabezado a caracteres US-ASCII. Para incluir texto no ASCII en encabezados como Asunto, nombres de remitentes o comentarios de direcciones, los remitentes tenían que usar RFC 2047 palabras codificadas — un esquema engorroso que codifica en Base64 o Q el texto y lo envuelve en marcadores =?charset?encoding?...?=.

Este sistema funciona pero produce encabezados ilegibles en su forma sin procesar, difíciles de implementar correctamente y limitados en dónde pueden aparecer. Por ejemplo, las palabras codificadas de RFC 2047 no pueden usarse dentro de la parte local de una dirección de correo electrónico.

RFC 6532 actualiza RFC 5322 para permitir UTF-8 directamente en encabezados de correo electrónico. Combinado con RFC 6531 (SMTPUTF8 para el sobre SMTP), esto permite correo electrónico completamente internacionalizado donde direcciones, nombres de remitentes, asuntos y otros encabezados pueden usar escrituras nativas sin trucos de codificación.

Cómo Funciona

El mensaje se transmite vía SMTP con la extensión SMTPUTF8 (RFC 6531), señalando que el mensaje usa contenido internacionalizado.
Los campos de encabezado pueden contener octetos UTF-8 sin procesar en cualquier lugar donde RFC 5322 permita texto.
Las direcciones de correo electrónico en encabezados (From, To, Cc, Reply-To) pueden contener caracteres UTF-8 en la parte local y en la parte del dominio.
El Content-Type para el bloque de encabezado del mensaje es implícitamente message/global (definido en RFC 6532) en lugar del tradicional message/rfc822.
Los clientes de correo que reciben y soportan RFC 6532 muestran los encabezados nativamente. Los clientes que no lo hacen pueden mostrar bytes UTF-8 sin procesar o no analizar los encabezados.

Ejemplos de Encabezados

Encabezados codificados tradicionales de RFC 2047 frente a encabezados de RFC 6532:

# Forma antigua: palabras codificadas de RFC 2047 (ilegibles en el cable) From: =?UTF-8?B?w4ltaWxpZSBEdXBvbnQ=?= <emilie@example.fr> Subject: =?UTF-8?B?5Lya6K2w44Gu56K66KqN?= To: =?UTF-8?B?5bGx55Sw5aSq6YOO?= <taro@example.jp> # Forma nueva: RFC 6532 con UTF-8 sin procesar (legible para humanos) From: Émilie Dupont <émilie@exemple.fr> Subject: 会議の確認 To: 田太郎 <田太郎@例.jp>

Un mensaje completamente internacionalizado:

From: 田太郎 <田太郎@例.jp> To: Émilie Dupont <émilie@exemple.fr> Subject: 会議の確認 Date: Wed, 11 Mar 2026 19:00:00 +0900 Message-ID: <20260311.001@例.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 来週の会議を確認します。

Detalles Técnicos Clave

message/global frente a message/rfc822

RFC 6532 introduce un nuevo tipo MIME: message/global. Esto es funcionalmente idéntico a message/rfc822 pero señala que el mensaje puede contener UTF-8 en encabezados. Cuando un mensaje se transmite con SMTPUTF8, los mensajes adjuntos y reenviados deben usar message/global en lugar de message/rfc822:

Tipo MIME	Codificación de Encabezados	Uso
`message/rfc822`	Solo ASCII (RFC 2047 para no-ASCII)	Correo electrónico tradicional
`message/global`	UTF-8 permitido nativamente	Correo electrónico internacionalizado

Dónde Se Permite UTF-8

RFC 6532 permite UTF-8 en todas las posiciones de campos de encabezado donde RFC 5322 permite texto:

Nombres de remitente: From: 田太郎 <taro@example.jp>
Partes locales de direcciones: To: <田太郎@example.jp>
Nombres de dominio: Cc: <user@例.jp>
Campos sin estructura: Subject: 会議の確認
Comentarios: From: user@example.com (山田太郎)

Consideraciones de Firma DKIM

Las firmas DKIM cubren encabezados específicos. Cuando esos encabezados contienen UTF-8 sin procesar, el proceso de firma y verificación debe manejar los bytes correctamente. La etiqueta DKIM h= enumera los encabezados a firmar, y la canonicalización se aplica a los bytes UTF-8 sin procesar. Tanto el remitente como el verificador deben procesar la misma secuencia de bytes para que las firmas coincidan.

Compatibilidad Hacia Atrás

Los mensajes de RFC 6532 no son compatibles hacia atrás con sistemas de correo que solo entienden RFC 5322. Un servidor o cliente que recibe un mensaje message/global pero no soporta RFC 6532 puede:

Mostrar bytes UTF-8 sin procesar (que la mayoría de los clientes modernos manejan razonablemente)
No analizar encabezados de dirección que contienen caracteres no ASCII
Romper la verificación DKIM si la implementación no maneja encabezados UTF-8

Errores Comunes

Usar encabezados de RFC 6532 sin SMTPUTF8 en el sobre. Si la sesión SMTP no usó el parámetro SMTPUTF8, el mensaje debe usar palabras codificadas de RFC 2047 para contenido de encabezado no ASCII. Los encabezados de RFC 6532 solo son válidos cuando se envían vía RFC 6531.
Mezclar RFC 2047 y UTF-8 sin procesar en el mismo encabezado. Elige un enfoque por mensaje. Si envías vía SMTPUTF8, usa UTF-8 sin procesar. Si no, usa RFC 2047 en todo. Mezclarlos crea ambigüedad en el análisis.
Usar message/rfc822 para adjuntos internacionalizados. Al reenviar o adjuntar un mensaje que contiene encabezados UTF-8, usa message/global como tipo MIME, no message/rfc822.
Ignorar la normalización Unicode. El mismo carácter visual puede tener múltiples representaciones de bytes en Unicode. Usa normalización NFC consistentemente para direcciones de correo electrónico y contenido de encabezados para evitar fallos en coincidencia y verificación.
Asumir que todos los clientes de correo renderizan UTF-8 correctamente. Aunque los clientes modernos manejan UTF-8 bien, algunos clientes antiguos o integrados pueden no hacerlo. Para correo electrónico transaccional crítico, considera si tu audiencia incluye usuarios en sistemas heredados.
Romper DKIM modificando encabezados UTF-8 en tránsito. Algunos sistemas de procesamiento de correo normalizan o vuelven a codificar texto UTF-8. Cualquier modificación a un encabezado firmado por DKIM, incluso cambiar la forma de normalización Unicode, invalida la firma.

Impacto en la Entregabilidad

Mejor visualización para receptores internacionales. Los nombres de remitentes y asuntos en escrituras nativas se ven profesionales y confiables. La basura de palabras codificadas en encabezados puede confundir a los receptores y desencadenar sospecha.
DKIM debe manejar UTF-8 correctamente. Si tu implementación de DKIM firma encabezados UTF-8 y el verificador los procesa de manera diferente (normalización diferente, codificación diferente), la firma falla. Esto impacta directamente en la alineación DMARC y la entregabilidad.
Soporte creciente de proveedores. Gmail, Outlook.com y otros proveedores principales soportan encabezados de RFC 6532. Los mensajes con encabezados UTF-8 limpios se muestran correctamente por estos proveedores.
Requerido para direcciones completamente internacionalizadas. No puedes tener una dirección de correo electrónico internacionalizada sin encabezados de RFC 6532. A medida que crece la adopción de EAI, soportar este RFC se vuelve esencial para llegar a usuarios globales.
La estrategia de alternativa importa. Para máxima entregabilidad, genera tanto una versión message/global (para servidores con capacidad SMTPUTF8) como una versión degradada de RFC 2047 (para otros). Tu infraestructura de envío debe elegir según las capacidades del receptor.