Les adresses e-mail internationalisées peuvent échouer à l'inscription à cause des IDN, de la normalisation Unicode et des lacunes SMTPUTF8. Découvrez des étapes de validation sûres.
Une regex ne peut juger que la forme du texte, pas si le domaine peut recevoir du courrier ni si votre chaîne d'envoi peut livrer à cette adresse. Les regex ont aussi tendance à être soit trop strictes, bloquant des domaines internationalisés valides, soit trop permissives, acceptant des entrées qui rebondiront ou échoueront ensuite.
Si votre audience est mondiale, autoriser l'Unicode dans la partie domaine est généralement sûr car il peut être converti en forme ASCII pour les vérifications DNS. L'Unicode dans la partie locale est une décision plus lourde : toute votre chaîne d'envoi doit supporter SMTPUTF8, sinon vous risquez des inscriptions qui ne recevront jamais les vérifications ou réinitialisations.
Conservez ce que l'utilisateur a tapé pour l'affichage, mais convertissez le domaine en sa forme ASCII avant d'effectuer des recherches DNS ou MX. Conserver la forme ASCII en parallèle avec l'original aide à dédupliquer et évite les divergences entre bibliothèques traitant les IDN différemment.
Normalisez tôt, idéalement avant de valider, comparer ou vérifier l'unicité, afin que des entrées visuellement identiques ne créent pas de comptes séparés. NFC est un choix pratique : il réduit les problèmes de « même apparence mais octets différents » sans réécrire agressivement les caractères comme le ferait une normalisation de compatibilité.
Mettez le domaine en minuscules : les noms de domaine sont en pratique insensibles à la casse, et cela évite des doublons. Évitez de mettre la partie locale en minuscules par défaut : certains systèmes la considèrent comme sensible à la casse et cela peut aussi surprendre avec des règles de casse non ASCII.
Stockez à la fois la saisie originale et une forme canonique utilisée pour les comparaisons, les recherches et les contraintes d'unicité. La forme canonique est généralement triée des espaces entourants, normalisée en NFC, avec le domaine en minuscules et converti en ASCII si nécessaire, tandis que la forme d'affichage reste conviviale.
Faites d'abord une vérification de syntaxe, puis vérifiez que le domaine se résout et recherchez les enregistrements MX en utilisant la version ASCII du domaine. Cela permet de repérer les fautes de frappe et les domaines morts tôt, mais cela ne prouve pas qu'une boîte existe, donc combinez-le avec une confirmation de possession par e-mail.
C'est souvent la voie d'envoi qui rejette le message, pas votre application qui l'a accepté. Une cause fréquente est l'absence de support SMTPUTF8 quelque part entre votre application, votre fournisseur d'e-mails et les relais en aval, ce qui casse la livraison pour des local-parts Unicode même si l'adresse est valide.
Supprimez les espaces visibles autour de la saisie, mais soyez prudent avec le « nettoyage » qui supprimerait des caractères Unicode significatifs. Il est utile de détecter et d'avertir pour des caractères invisibles comme les zero-width spaces afin que l'utilisateur corrige l'entrée plutôt que d'être bloqué silencieusement.
Utilisez-le pour remplacer une logique de validation fragile et incohérente par un appel API unique qui vérifie la syntaxe selon les RFC, valide le domaine, recherche les MX et signale les entrées à risque comme les domaines jetables. C'est particulièrement utile si vous voulez des décisions rapides et cohérentes à l'inscription sans construire et maintenir votre propre pipeline multi-étapes.
Une adresse e-mail peut sembler normale et pourtant échouer dès qu'elle arrive dans un vrai système. La raison principale est que ce que les gens voient comme un caractère peut être stocké sous des octets différents, traité différemment par des bibliothèques ou rejeté par des serveurs de mail anciens.
Un exemple courant est quelque chose comme søren@exämple.com. Ça peut être une adresse légitime, mais elle touche plusieurs points fragiles à la fois : Unicode dans la partie locale, un nom de domaine internationalisé, et une infrastructure de mail qui peut ou non le supporter.
Les erreurs apparaissent aussi loin de votre formulaire d'inscription. Vous pouvez accepter l'adresse, puis échouer à envoyer une réinitialisation de mot de passe parce que votre fournisseur d'e-mail (ou un relais intermédiaire) ne supporte pas SMTPUTF8. Ou votre regex l'accepte, mais votre étape de « mettre en minuscules et couper les espaces » la transforme en quelque chose de différent de ce que l'utilisateur voulait.
Les rejets silencieux coûtent cher : les gens abandonnent l'inscription, réessaient avec une autre adresse, ou ouvrent des tickets support difficiles à reproduire. Si vous avez une audience globale, rejeter des adresses internationalisées peut aussi donner l'impression que vous ne supportez pas leur langue.
Les acceptations erronées coûtent différemment. Les mauvaises adresses entraînent des rebonds, une délivrabilité réduite et des listes encombrées. Certaines saisies apparemment valides sont délibérément malveillantes : domaines jetables, comptes de rôle utilisés pour l'abus, ou pièges à spam qui abîment la réputation d'envoi.
L'objectif n'est pas « tout accepter » ni « tout bloquer ». C'est d'accepter de vrais utilisateurs tout en stoppant les entrées manifestement mauvaises, en utilisant des contrôles qui correspondent à la façon dont le courrier fonctionne réellement : séparer affichage et stockage, vérifier l'atteignabilité du domaine (pas seulement la présence d'un @), et éviter des transformations agressives qui réécrivent silencieusement ce que l'utilisateur a tapé.
Une adresse e-mail a deux parties séparées par @ : la partie locale (avant @) et le domaine (après @). Les adresses e-mail internationalisées peuvent inclure des caractères Unicode dans l'une ou l'autre partie, et le support réel varie selon le côté qui utilise l'Unicode.
Le cas le plus courant est un nom de domaine internationalisé (IDN). L'utilisateur voit un domaine écrit dans son alphabet, comme maria@bücher.example ou li@例子.公司. En coulisses, beaucoup de systèmes convertissent ce domaine en une forme ASCII (souvent appelée punycode) pour que les recherches DNS et les vérifications MX fonctionnent de manière fiable.
Le cas plus délicat est l'Unicode dans la partie locale, comme jó[email protected] ou ユーザー@domain.com. Cela relève de l'Email Address Internationalization (EAI) et s'achemine généralement via SMTPUTF8. Même si l'adresse est valide selon les normes modernes, certains serveurs de mail, bibliothèques anciennes et outils en aval la rejettent encore. Vous pouvez donc l'accepter à l'inscription et échouer plus tard quand vous essayez d'envoyer.
Une façon pragmatique de penser au support aujourd'hui :
C'est pourquoi une simple regex oui/non ne suffit pas. Une regex peut rejeter des utilisateurs légitimes (par exemple en bloquant tout non-ASCII), ou accepter des adresses que vous ne pourrez pas livrer.
Une meilleure validation traite chaque côté séparément. Pour le domaine, normalisez et convertissez en ASCII pour les vérifications DNS. Pour la partie locale, il faut une décision de politique : supportez-vous SMTPUTF8 totalement, l'autorisez-vous avec un avertissement, ou la bloquez-vous parce que votre stack e-mail ne peut pas la délivrer de façon fiable ?
Un IDN (Internationalized Domain Name) est un domaine utilisant des caractères non-ASCII, comme des accents ou des scripts non latins. Les gens voient et tapent la forme Unicode, mais le DNS est construit autour de l'ASCII. Ce décalage est souvent la source des bugs en production.
Pour rechercher des enregistrements MX, vérifier un domaine ou même faire une vérification DNS basique, vous devez généralement la forme ASCII du domaine. Cette conversion suit les règles IDNA et produit du punycode, qui commence souvent par xn--. Ainsi, un utilisateur peut saisir un domaine qui lui semble normal, mais vos logs, votre base ou votre fournisseur en amont peuvent montrer une version xn--... à la place.
Le punycode apparaît dans des endroits où vous devez vous y attendre et le gérer :
Deux erreurs communes :
Il y a aussi un angle sécurité. Les scripts mixtes et les caractères confusibles peuvent servir à créer des domaines visuellement ressemblants à une marque de confiance. Vous ne devriez généralement pas bloquer tous les IDN pour cette raison, mais il est raisonnable de les considérer comme plus risqués dans des contextes sensibles comme les paiements, les réinitialisations de mot de passe ou les accès admin.
Une approche pragmatique est d'accepter ce que l'utilisateur tape, puis de normaliser en interne :
Unicode permet de taper des noms et mots de nombreuses langues, mais cela signifie aussi qu'un même « caractère » peut être représenté de plusieurs façons. Si vous comparez les chaînes octet à octet, ou stockez une forme puis en recevez une autre, vous pouvez avoir des doublons, des connexions échouées et des erreurs déroutantes « e-mail déjà utilisé ».
Un exemple simple concerne les caractères accentués. La lettre « é » peut être un seul point de code (U+00E9), ou deux points de code : « e » (U+0065) plus un accent combinant (U+0301). Ils paraissent identiques à une personne, mais votre base de données peut les traiter comme différents.
La normalisation convertit le texte en une forme cohérente.
Pour la gestion des e-mails, NFC est souvent le choix le plus sûr pour les comparaisons « rendre égal ».
Les règles de casse diffèrent entre les deux côtés d'une adresse :
@) : il est sûr de la traiter comme insensible à la casse. La mise en minuscules est standard.@) : techniquement sensible à la casse, même si beaucoup de fournisseurs l'ignorent. La mettre en minuscules peut fusionner deux adresses distinctes sur certains systèmes.Approche pratique : mettez en minuscules et normalisez le domaine ; gardez la partie locale telle que l'utilisateur l'a saisie, tout en stockant une forme canonique pour les comparaisons.
Normalisez aux moments où la cohérence compte :
Même avec un bon service de validation, votre application a besoin d'une politique claire de normalisation et de casse pour éviter que des utilisateurs légitimes soient bloqués par des différences de caractères invisibles.
La plupart des bugs liés aux adresses e-mail internationalisées se produisent aux jonctions, où un système fait une hypothèse différente de la suivante. L'adresse semble correcte pour un utilisateur, mais quelque chose dans la chaîne la change, la rejette ou traite deux valeurs visuellement identiques comme différentes.
Un échec courant commence dans le formulaire d'inscription. Les règles côté client n'autorisent souvent que A-Z, 0-9 et quelques symboles. Les claviers mobiles insèrent une ponctuation intelligente, et l'autocomplétion ajoute un espace final invisible. La mise en minuscules automatique peut aussi se comporter de façon étrange en dehors de l'ASCII de base.
Côté backend, de petites étapes de nettoyage peuvent être destructrices. Couper les espaces est utile, mais supprimer les caractères « non imprimables » peut effacer des signes Unicode valides. Les limites de longueur posent aussi problème : les domaines internationalisés peuvent s'allonger une fois convertis en punycode, et vous pouvez atteindre une limite inattendue.
Les bases de données ajoutent leurs propres pièges. Les règles de collation et de comparaison décident si deux chaînes sont égales. Si un système stocke une forme composée et qu'un autre envoie plus tard une forme décomposée, les vérifications d'unicité peuvent échouer. Cela peut créer des comptes dupliqués ou bloquer un utilisateur parce que votre requête « existe déjà » ne correspond pas à ce qui a été stocké.
Les problèmes apparaissent le plus souvent dans :
L'envoi sortant est là où cela devient inévitable. Si votre serveur mail ou un relais aval ne supporte pas SMTPUTF8, il peut refuser d'envoyer vers une boîte avec des caractères non-ASCII dans la partie locale. Les utilisateurs peuvent s'inscrire, mais ne jamais recevoir d'e-mail de vérification.
Une chaîne d'échec réaliste ressemble à ceci : un utilisateur s'enregistre avec un domaine Unicode, votre appli le stocke, votre CRM le normalise différemment, et votre fournisseur d'e-mail refuse SMTPUTF8. Vous vous retrouvez avec un utilisateur, deux chaînes qui ne correspondent pas et un e-mail de bienvenue qui n'arrive jamais.
Un workflow sûr commence par séparer deux objectifs : ne pas bloquer de vrais utilisateurs à l'inscription, et stocker quelque chose que vous pouvez comparer, envoyer et dépanner plus tard.
Préservez la saisie de l'utilisateur. Conservez l'adresse exactement comme tapée, puis supprimez seulement les espaces entourants évidents. Évitez les modifications « utiles » comme changer la casse, enlever des accents, supprimer des points ou retirer les plus-tags. Ces changements peuvent silencieusement transformer une adresse en une autre.
Faites une vraie vérification de syntaxe. Traitez-la comme « est-ce structurellement possible », pas « le mail va-t-il définitivement arriver ». Les règles modernes sont plus larges que la plupart des regex, surtout quand des caractères internationaux sont impliqués.
Décidez de la normalisation et de l'unicité. Stockez l'adresse brute plus une forme canonique (souvent NFC) pour les contrôles d'égalité. Si l'e-mail est une clé unique dans votre système, précisez si des entrées visuellement identiques mais encodées différemment doivent compter pour le même compte.
Traitez correctement le domaine. Normalisez le domaine et convertissez-le en ASCII (punycode) avant tout travail DNS. Puis vérifiez le domaine et recherchez les enregistrements MX (et éventuellement un fallback A/AAAA si votre politique l'autorise).
Définissez une politique pour les local-parts Unicode. Si votre fournisseur sortant ne peut pas délivrer SMTPUTF8 de façon fiable, acceptez l'inscription seulement si vous avez un plan de secours (vérification in-app, méthode de contact alternative, ou un avertissement clair avant de promettre la livraison d'e-mails).
Conservez un petit ensemble de logs sur les résultats de validation pour que le support puisse dépanner les cas limites sans deviner.
On dit souvent « validation d'e-mail » quand on veut dire « mon message atteindra-t-il une vraie personne ». C'est la délivrabilité, et vous ne pouvez pas la prouver complètement à l'inscription. Avec les adresses internationalisées, il est encore plus facile de confondre « ça paraît valide » avec « ça marchera partout ».
La validation peut néanmoins fournir de bons signaux avant de stocker une adresse ou d'envoyer :
Mais la validation ne garantit pas que la boîte existe ou acceptera votre message. Beaucoup de fournisseurs bloquent le probing de boîte, acceptent le mail pour des utilisateurs inconnus puis renvoient un bounce, ou changent de politique sans prévenir.
Une approche plus sûre est en deux étapes :
Pour les résultats « à risque », les blocages durs créent souvent des faux négatifs. La friction légère fonctionne généralement mieux : autorisez l'inscription, exigez la confirmation avant les actions sensibles, ou demandez un signal supplémentaire seulement quand le risque est élevé.
La façon la plus rapide de perdre de vraies inscriptions est de traiter tout ce qui est hors ASCII comme invalide. Beaucoup de fournisseurs légitimes supportent des domaines internationalisés, et certains utilisateurs en dépendent réellement.
Beaucoup de code en production suppose encore que e-mail = A-Z, 0-9, points et une courte liste de symboles. Cela casse pour les domaines IDN et garantit des rejets pour des produits globaux.
Mettre le domaine en minuscules va, mais mettre la partie locale en minuscules peut être risqué.
La normalisation aide, mais la faire aveuglément peut surprendre les utilisateurs. Normalisez intentionnellement, conservez l'entrée originale et testez le comportement des systèmes en aval.
Transformations « utiles » qui échouent souvent :
Votre backend peut avoir besoin du punycode pour les vérifications DNS, mais votre UI devrait en général afficher le domaine dans l'écriture de l'utilisateur. Afficher xn--... dans des confirmations ou messages d'erreur paraît souvent suspect, même si l'adresse est correcte.
Même si une adresse est valide selon la spécification, tous les serveurs mail ne supportent pas SMTPUTF8. Si vous acceptez des local-parts Unicode, préparez-vous à des différences de délivrabilité selon les fournisseurs.
Le copier-coller introduit des espaces insécables, des caractères zéro-largeur et des espaces superflus autour du @. Les utilisateurs ne voient pas ces problèmes, mais votre validation síera.
Exemple : un utilisateur colle name@пример.рф avec un espace final. Si vous validez avant de trim, vous le rejetez. Si vous sur-nettoyez, vous pouvez modifier la partie locale.
Les adresses e-mail internationalisées peuvent fonctionner de bout en bout, mais seulement si chaque couche s'accorde sur ce qu'elle acceptera, stockera et enverra. Avant la mise en production, exécutez des vérifications qui correspondent au comportement réel en production, pas seulement des tests unitaires.
Assurez-vous que les logs et outils admin peuvent afficher la version conviviale sans la transformer en mojibake ou casser les exports. Confirmez aussi que chaque système qui touche l'adresse peut la gérer : événements analytics, synchronisation CRM, payloads webhook, exports CSV et ingestion dans un entrepôt de données. Beaucoup d'échecs se produisent à l'export, pas à l'entrée.
Un test concret : faites passer la même adresse par inscription, connexion, réinitialisation de mot de passe et tout flux de fusion de compte. Si elle passe l'inscription mais échoue ensuite, vous avez une divergence dans la normalisation, le stockage ou les comparaisons.
Un utilisateur s'inscrit avec marta@bücher.example. Cela paraît normal car le domaine est écrit en Unicode. Votre système doit traiter le domaine comme un IDN.
Côté domaine, conservez l'affichage convivial mais validez la forme DNS-safe. Convertissez bücher.example en punycode (xn--bcher-kva.example) avant d'effectuer des recherches MX. Si vous ne vérifiez que la forme Unicode, certaines bibliothèques DNS échoueront ou se comporteront de manière incohérente.
Maintenant la partie subtile : la même adresse peut être tapée de différentes manières qui paraissent identiques. Supposons que l'utilisateur entre márta@bücher.example, mais le « á » peut être composé en un seul caractère ou en « a » plus un accent combinant. Si vous ne stockez que l'entrée brute, un utilisateur peut se retrouver avec deux comptes qui semblent identiques dans votre UI.
La normalisation corrige cela. Normalisez en NFC avant de comparer, stocker, limiter le taux ou dédupliquer, et appliquez les mêmes étapes partout où l'adresse est manipulée.
La partie locale (tout avant @) est l'endroit où vous devez avoir une politique claire. SMTPUTF8 autorise des local-parts Unicode, mais pas tous les fournisseurs les supportent de bout en bout. Une politique pratique pour beaucoup de produits :
Si vous voulez un endroit unique pour exécuter des vérifications de syntaxe, de domaine et MX (et filtrer les domaines jetables), une API de validation d'e-mails comme Verimail (verimail.co) peut fournir ces signaux sans s'appuyer sur une regex fragile.
Étapes suivantes pour rester sûr sans rejeter de vrais utilisateurs :