RFC 6531 – Extensión SMTP para Correo Electrónico Internacionalizado

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

ELI5: Las direcciones de correo electrónico tradicionales solo pueden usar letras inglesas, números y algunos símbolos. Eso significa que miles de millones de personas en todo el mundo no pueden tener direcciones de correo electrónico en su propio sistema de escritura — sin caracteres chinos, sin árabe, sin cirílico. SMTPUTF8 soluciona esto extendiendo SMTP para manejar Unicode completo, para que alguien pueda tener una dirección como `émilie@exemple.fr` o una dirección en hindi, japonés, o cualquier otro sistema de escritura.

Por qué existe este RFC

El correo electrónico fue diseñado en la era del ASCII. La especificación SMTP original (RFC 5321) restringe las direcciones de correo electrónico y los comandos de envío a caracteres ASCII de 7 bits. Esto funciona bien para el inglés, pero excluye la mayoría de los idiomas del mundo. Una dirección de correo electrónico como 田太郎@例.jp era simplemente imposible.

RFC 6531 define la extensión SMTPUTF8, que permite la codificación UTF-8 en el envío SMTP — específicamente en MAIL FROM, RCPT TO y el dominio EHLO. Esto forma parte de un conjunto de RFC conocidos colectivamente como Internacionalización de Direcciones de Correo (EAI), que también incluye RFC 6532 para encabezados de mensajes internacionalizados.

Esta extensión abre el correo electrónico a todos los sistemas de escritura admitidos por Unicode, lo cual es esencial para la adopción mundial del correo electrónico.

Cómo funciona

El cliente envía EHLO y confirma que el servidor anuncia SMTPUTF8 en su lista de capacidades.
Al enviar un mensaje que utiliza direcciones no ASCII (en el envío, encabezados o ambos), el cliente agrega el parámetro SMTPUTF8 al comando MAIL FROM.
Las direcciones MAIL FROM y RCPT TO ahora pueden contener caracteres UTF-8.
Los encabezados del mensaje también pueden contener UTF-8 (según RFC 6532), reemplazando los antiguos workarounds de palabras codificadas de RFC 2047.
Si el servidor del siguiente salto no admite SMTPUTF8, el servidor que envía debe degradar el mensaje o rechazarlo — no puede eliminar silenciosamente los caracteres internacionales.

Ejemplo SMTP

Envío de un mensaje con direcciones internacionalizadas:

S: 220 mx.example.com ESMTP C: EHLO sender.example.net S: 250-mx.example.com S: 250-SMTPUTF8 S: 250-8BITMIME S: 250-STARTTLS S: 250 SIZE 52428800 # Se requiere parámetro SMTPUTF8 cuando se usan direcciones internacionales C: MAIL FROM:<émilie@exemple.fr> SMTPUTF8 S: 250 2.1.0 OK C: RCPT TO:<田太郎@例.jp> S: 250 2.1.5 OK C: DATA S: 354 Start mail input C: From: Émilie Dupont <émilie@exemple.fr> C: To: 田太郎 <田太郎@例.jp> C: Subject: Meeting confirmation C: Date: Wed, 11 Mar 2026 10:00:00 +0100 C: MIME-Version: 1.0 C: Content-Type: text/plain; charset=UTF-8 C: C: Confirming our meeting for next week. C: . S: 250 2.0.0 OK, queued

Detalles técnicos clave

El parámetro SMTPUTF8

La palabra clave SMTPUTF8 en MAIL FROM señala que este mensaje utiliza contenido internacionalizado. Debe estar presente siempre que alguno de los siguientes contenga caracteres no ASCII:

La dirección MAIL FROM
Cualquier dirección RCPT TO
Los encabezados del mensaje (From, To, Cc, Reply-To, etc.)

Si el parámetro SMTPUTF8 no se declara y el envío contiene caracteres no ASCII, el servidor debe rechazar el comando.

Nombres de dominio: IDN y UTF-8

Los nombres de dominio internacionalizados (IDN) han existido durante años utilizando codificación Punycode (por ejemplo, xn--e1afmapc.xn--p1ai para пример.рф). SMTPUTF8 permite la forma UTF-8 de nombres de dominio directamente en SMTP, aunque Punycode (etiquetas A) sigue siendo válido. Para búsquedas de DNS, el dominio aún debe convertirse a su forma de etiqueta A.

Degradación y respaldo

El mayor desafío con SMTPUTF8 es la interoperabilidad con servidores que no lo admiten. Al retransmitir un mensaje a un servidor que no es SMTPUTF8:

Si el mensaje puede degradarse (por ejemplo, solo el nombre para mostrar contiene no ASCII, las direcciones en sí son ASCII), el servidor puede realizar una conversión de degradación.
Si las direcciones de envío en sí contienen caracteres no ASCII, la degradación es imposible — el mensaje no puede entregarse a ese servidor. El servidor que envía debe generar un rechazo.

Interacción con autenticación

Los mecanismos de autenticación de correo electrónico necesitan actualizaciones para direcciones internacionalizadas:

SPF: Utiliza el dominio de MAIL FROM. Si el dominio es internacionalizado, debe convertirse a forma de etiqueta A para la búsqueda de DNS.
DKIM: Firma y verifica encabezados. Con SMTPUTF8, los encabezados pueden contener UTF-8 sin procesar, por lo que la implementación de DKIM debe manejar esto correctamente.
DMARC: Las comprobaciones de alineación de dominio deben tener en cuenta tanto las formas UTF-8 como las de etiqueta A del mismo dominio.

Errores comunes

Omitir el parámetro SMTPUTF8. Si su mensaje contiene algún no ASCII en direcciones o encabezados, debe incluir SMTPUTF8 en el comando MAIL FROM. Olvidarlo hace que el servidor rechace las direcciones.
Asumir soporte universal de SMTPUTF8. La adopción está creciendo pero no es universal. A partir de 2025, proveedores principales como Gmail y Outlook admiten SMTPUTF8, pero muchos servidores más pequeños no. Su infraestructura de envío debe manejar el respaldo correctamente.
No convertir dominios para búsquedas de DNS. Incluso con SMTPUTF8, las consultas de DNS requieren la forma de etiqueta A (Punycode) de dominios internacionalizados. Puede usar UTF-8 en el envío SMTP, pero las búsquedas de MX/A/AAAA deben usar la codificación compatible con ASCII.
Almacenar direcciones internacionalizadas sin normalización. Unicode tiene múltiples representaciones para el mismo carácter (por ejemplo, formas compuestas frente a descompuestas). Use normalización NFC para direcciones de correo electrónico para asegurar una coincidencia y deduplicación consistentes.
Eliminar silenciosamente caracteres no ASCII. Si su sistema no puede manejar direcciones internacionalizadas, debe rechazarlas limpiamente — nunca modifique silenciosamente las direcciones eliminando caracteres. Eso cambia el destinatario.
Olvidar direcciones de rechazo. Si la dirección del remitente es internacionalizada y el mensaje se rechaza, el rechazo también debe enviarse mediante SMTPUTF8. Si la ruta de rechazo no admite SMTPUTF8, el rechazo se pierde.

Impacto en la entregabilidad

Llegar a una audiencia mundial. El soporte de SMTPUTF8 señala que su infraestructura de envío es moderna e inclusiva. A medida que las direcciones internacionalizadas se vuelven más comunes, admitirlas se convierte en una expectativa básica.
Complejidad del manejo de rechazos. Los mensajes a direcciones internacionalizadas pueden rechazarse de manera diferente si los servidores intermedios no admiten SMTPUTF8. Su procesamiento de rechazos debe manejar tanto direcciones ASCII como UTF-8.
Alineación de autenticación. SPF, DKIM y DMARC deben funcionar correctamente con dominios internacionalizados. Las discrepancias entre representaciones UTF-8 y de etiqueta A pueden causar fallos de autenticación espurios.
El soporte de proveedores principales es sólido. Gmail, Microsoft 365 y otras plataformas principales aceptan mensajes de SMTPUTF8. El soporte para enviar desde direcciones internacionalizadas se está expandiendo rápidamente.
Preparación para el futuro. La proporción de direcciones de correo electrónico que utilizan caracteres no ASCII solo crecerá. Invertir en soporte de SMTPUTF8 ahora previene brechas de entregabilidad a medida que aumenta la adopción global.