RFC 6531 – Extension SMTP pour le courrier électronique internationalisé

Norme proposée SMTP principal & Format de message Obsoletes RFC 5321 Published March 2026

ELI5: Les adresses e-mail traditionnelles ne peuvent utiliser que des lettres anglaises, des chiffres et quelques symboles. Cela signifie que des milliards de personnes dans le monde ne peuvent pas avoir d'adresses e-mail dans leur propre script — pas de caractères chinois, pas d'arabe, pas de cyrillique. SMTPUTF8 résout ce problème en étendant SMTP pour gérer l'Unicode complet, afin que quelqu'un puisse avoir une adresse comme `émilie@exemple.fr` ou une adresse en hindi, japonais ou tout autre système d'écriture.

Pourquoi cette RFC existe

Le courrier électronique a été conçu à l'époque de l'ASCII. La spécification SMTP originale (RFC 5321) limite les adresses e-mail et les commandes d'enveloppe aux caractères ASCII 7 bits. Cela fonctionne bien pour l'anglais, mais exclut la majorité des langues du monde. Une adresse e-mail comme 田太郎@例.jp était simplement impossible.

RFC 6531 définit l'extension SMTPUTF8, qui permet l'encodage UTF-8 dans l'enveloppe SMTP — spécifiquement dans MAIL FROM, RCPT TO, et le domaine EHLO. Cela fait partie d'une suite de RFC collectivement connue sous le nom d'Internationalisation des adresses e-mail (EAI), qui inclut également RFC 6532 pour les en-têtes de messages internationalisés.

Cette extension ouvre le courrier électronique à tous les systèmes d'écriture supportés par Unicode, ce qui est essentiel pour l'adoption mondiale du courrier électronique.

Comment cela fonctionne

Le client envoie EHLO et confirme que le serveur annonce SMTPUTF8 dans sa liste de capacités.
Lors de l'envoi d'un message qui utilise des adresses non-ASCII (dans l'enveloppe, les en-têtes, ou les deux), le client ajoute le paramètre SMTPUTF8 à la commande MAIL FROM.
Les adresses MAIL FROM et RCPT TO peuvent désormais contenir des caractères UTF-8.
Les en-têtes du message peuvent également contenir UTF-8 (conformément à RFC 6532), remplaçant les anciennes contournements de mots codés RFC 2047.
Si le serveur suivant ne supporte pas SMTPUTF8, le serveur d'envoi doit soit rétrograder le message, soit le rejeter — il ne peut pas supprimer silencieusement les caractères internationaux.

Exemple SMTP

Envoi d'un message avec des adresses internationalisées :

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 # Paramètre SMTPUTF8 requis lors de l'utilisation d'adresses internationales 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

Détails techniques clés

Le paramètre SMTPUTF8

Le mot-clé SMTPUTF8 sur MAIL FROM signale que ce message utilise du contenu internationalisé. Il doit être présent chaque fois que l'un des éléments suivants contient des caractères non-ASCII :

L'adresse MAIL FROM
Toute adresse RCPT TO
Les en-têtes du message (From, To, Cc, Reply-To, etc.)

Si le paramètre SMTPUTF8 n'est pas déclaré et que l'enveloppe contient des caractères non-ASCII, le serveur doit rejeter la commande.

Noms de domaine : IDN et UTF-8

Les noms de domaine internationalisés (IDN) existent depuis des années en utilisant l'encodage Punycode (par exemple, xn--e1afmapc.xn--p1ai pour пример.рф). SMTPUTF8 permet la forme UTF-8 des noms de domaine directement dans SMTP, bien que Punycode (A-labels) reste valide. Pour les recherches DNS, le domaine doit toujours être converti en sa forme A-label.

Rétrogradation et secours

Le plus grand défi avec SMTPUTF8 est l'interopérabilité avec les serveurs qui ne le supportent pas. Lors du relais d'un message vers un serveur non-SMTPUTF8 :

Si le message peut être rétrogradé (par exemple, seul le nom d'affichage contient des caractères non-ASCII, les adresses elles-mêmes sont ASCII), le serveur peut effectuer une conversion de rétrogradation.
Si les adresses d'enveloppe elles-mêmes contiennent des caractères non-ASCII, la rétrogradation est impossible — le message ne peut pas être livré à ce serveur. Le serveur d'envoi doit générer un rebond.

Interaction avec l'authentification

Les mécanismes d'authentification e-mail ont besoin de mises à jour pour les adresses internationalisées :

SPF : Utilise le domaine de MAIL FROM. Si le domaine est internationalisé, il doit être converti en forme A-label pour la recherche DNS.
DKIM : Signe et vérifie les en-têtes. Avec SMTPUTF8, les en-têtes peuvent contenir UTF-8 brut, donc l'implémentation DKIM doit gérer cela correctement.
DMARC : Les vérifications d'alignement de domaine doivent tenir compte des formes UTF-8 et A-label du même domaine.

Erreurs courantes

Omission du paramètre SMTPUTF8. Si votre message contient un quelconque non-ASCII dans les adresses ou les en-têtes, vous devez inclure SMTPUTF8 sur la commande MAIL FROM. L'oublier provoque le rejet des adresses par le serveur.
Supposer un support SMTPUTF8 universel. L'adoption est croissante mais non universelle. Dès 2025, les grands fournisseurs comme Gmail et Outlook supportent SMTPUTF8, mais de nombreux petits serveurs ne le font pas. Votre infrastructure d'envoi doit gérer le secours gracieusement.
Ne pas convertir les domaines pour les recherches DNS. Même avec SMTPUTF8, les requêtes DNS nécessitent la forme A-label (Punycode) des domaines internationalisés. Vous pouvez utiliser UTF-8 dans l'enveloppe SMTP, mais les recherches MX/A/AAAA doivent utiliser l'encodage compatible ASCII.
Stocker les adresses internationalisées sans normalisation. Unicode a plusieurs représentations pour le même caractère (par exemple, formes composées ou décomposées). Utilisez la normalisation NFC pour les adresses e-mail pour assurer une correspondance et une déduplication cohérentes.
Supprimer silencieusement les caractères non-ASCII. Si votre système ne peut pas gérer les adresses internationalisées, il doit les rejeter clairement — ne modifiez jamais silencieusement les adresses en supprimant des caractères. Cela change le destinataire.
Oublier les adresses de rebond. Si l'adresse de l'expéditeur est internationalisée et que le message rebondit, le rebond doit également être envoyé via SMTPUTF8. Si le chemin de rebond ne supporte pas SMTPUTF8, le rebond est perdu.

Impact sur la délivrabilité

Atteindre un public mondial. Le support de SMTPUTF8 signale que votre infrastructure d'envoi est moderne et inclusive. À mesure que les adresses internationalisées deviennent plus courantes, les supporter devient une attente de base.
Complexité du traitement des rebonds. Les messages vers des adresses internationalisées peuvent rebondir différemment si les serveurs intermédiaires ne supportent pas SMTPUTF8. Votre traitement des rebonds doit gérer les adresses ASCII et UTF-8.
Alignement de l'authentification. SPF, DKIM et DMARC doivent tous fonctionner correctement avec les domaines internationalisés. Les désalignements entre les représentations UTF-8 et A-label peuvent causer des échecs d'authentification sporadiques.
Le support des grands fournisseurs est fort. Gmail, Microsoft 365 et autres grandes plateformes acceptent les messages SMTPUTF8. Le support de l'envoi à partir d'adresses internationalisées se développe rapidement.
Planification future. La proportion d'adresses e-mail utilisant des caractères non-ASCII ne fera que croître. Investir dans le support SMTPUTF8 maintenant prévient les lacunes de délivrabilité à mesure que l'adoption mondiale augmente.