Utilisez cette checklist de validation de la syntaxe des e-mails conforme aux RFC pour attraper des cas limites (chaînes citées, plus addressing, sous-domaines) avant le lancement.
Utilisez un parseur dédié quand c'est possible. Les regex manquent souvent des cas limites comme les parties locales entre guillemets, les plus-tags et les domaines à plusieurs labels, donc elles rejettent soit des utilisateurs réels soit acceptent des entrées cassées.
La syntaxe répond à la question « Est-ce que ceci est écrit au format d'adresse e-mail valide ? ». La politique répond à « Est-ce que nous voulons l'accepter dans notre produit ? ». Séparez-les pour ne pas bloquer par erreur des adresses valides en cherchant à réduire les inscriptions à risque.
Non. « Conforme aux RFC » signifie surtout que la chaîne peut être parsée comme une adresse e-mail selon les règles de RFC 5322. Cela ne prouve pas que le domaine existe, qu'il a des enregistrements MX ou que la boîte peut recevoir du courrier.
Commencez par supprimer les espaces en tête et en fin, puis rejetez les caractères de contrôle comme les tabulations et les sauts de ligne. N'effectuez pas de « normalisation » qui supprime des caractères internes, car cela peut changer l'adresse saisie par l'utilisateur.
Par défaut, autorisez-le. [email protected] est un format normal et largement utilisé : le bloquer crée des frictions inutiles pour l'inscription sans améliorer la sécurité à lui seul.
Oui. Les sous-domaines sont courants et un domaine peut comporter plusieurs points comme sub.example.co.uk. Un validateur qui suppose « un seul point » rejettera beaucoup d'adresses réelles.
Appliquez la règle « exactement un @ », avec au moins un caractère de chaque côté. Ne découpez pas sur le premier @ en ignorant les suivants, et n'acceptez pas les saisies contenant plusieurs @ tels quelles.
Décidez-en de manière volontaire. Elles sont valides selon la norme, mais rares et souvent mal gérées par les systèmes en aval qui supposent un format plus simple. Si vous les rejetez, faites-en un choix de politique et affichez un message clair.
Ils aident à éviter les saisies abusives et les cas limites. Limites pratiques courantes : 254 caractères au total, 64 pour la partie locale, 253 pour le domaine, et 63 par label de domaine.
Utilisez des codes de raison qui correspondent à des échecs spécifiques, comme CONTROL_CHAR, PARSE_FAIL, LENGTH ou DOMAIN_LABEL. Cela rend les tickets support et le débogage beaucoup plus actionnables qu'un simple « e-mail invalide ».
Les adresses e-mail semblent simples jusqu'à ce qu'on tente de les valider. Beaucoup de bugs en production viennent du fait qu'on traite un e-mail comme « quelques lettres, un @ et un point », puis qu'on se repose sur une regex rapide. Les adresses réelles autorisent plus de variations que ce que la plupart des formulaires attendent, et de petits choix d'analyse peuvent transformer une adresse valide en erreur « invalide ».
Une confusion courante consiste à mélanger deux questions différentes :
Si vous voulez réduire les inscriptions risquées, vous pouvez bloquer certains motifs. Si votre objectif est d'éviter de rejeter de vrais utilisateurs, commencez par bien faire la syntaxe, puis appliquez votre politique par-dessus. Séparer ces couches, c'est la différence entre un validateur auquel on peut faire confiance et un validateur qui fait fuir silencieusement des inscriptions.
Rejeter des e-mails valides casse des choses réelles. Quelqu'un saisit une adresse parfaitement valide avec plus addressing ou un sous-domaine, votre formulaire indique « invalide » et il part. Vous perdez l'inscription et vous ne collectez même pas assez de données pour comprendre le problème.
Accepter des e-mails invalides casse d'autres choses. Les adresses invalides augmentent les rebonds, ce qui peut nuire à votre réputation d'expéditeur et à la délivrabilité. Elles attirent aussi des inscriptions de faible qualité et de la fraude quand des attaquants remplissent vos formulaires avec des déchets.
La plupart des échecs en production tiennent à quelques motifs : des regex trop strictes (ou trop laxistes), un découpage incorrect autour du @, un nettoyage ou une « normalisation » trop agressive, et le mélange des vérifications de syntaxe avec des vérifications de délivrabilité.
Exemple : quelqu'un s'inscrit avec [email protected]. Un validateur simpliste le rejette car il attend un seul point dans le domaine. L'adresse peut être parfaitement valide, mais l'utilisateur n'atteint jamais la confirmation.
Ce billet se concentre sur la syntaxe : si une adresse est écrite dans un format valide. Il ne prouve pas que la boîte existe ou que le domaine peut recevoir du courrier. Ces vérifications appartiennent aux couches suivantes.
« Conforme aux RFC » concerne principalement la syntaxe : cette chaîne peut-elle être parsée comme une adresse e-mail selon les règles de la RFC 5322 ? C'est utile, mais ce n'est que la première barrière. Une adresse syntaxiquement valide peut rester non livrable, dangereuse ou de faible qualité.
Pensez la validation en couches :
Un pipeline pratique ressemble à : parser la syntaxe, vérifier les bases du domaine, puis appliquer votre politique (bloquer les domaines jetables connus, les pièges à spam et autres signaux de risque). La syntaxe seule ne doit jamais prétendre garantir la délivrabilité.
Pour les formulaires d'inscription, « conforme aux RFC » signifie généralement accepter les formats réels courants (plus tags, sous-domaines, TLD plus longs) et éviter de rejeter des adresses valides juste parce qu'elles paraissent peu familières.
Certaines équipes resserrent volontairement les règles. C'est raisonnable si c'est un choix de politique délibéré, documenté et testé. Par exemple, vous pourriez toujours rejeter :
@ ou absence de partie locale ou de domaineScénario : [email protected] peut être syntaxiquement valide. Si le domaine n'a pas d'enregistrements MX, vous le détectez dans la couche domaine. S'il s'agit d'un fournisseur jetable connu, c'est de la politique.
La plupart des bugs de validation viennent d'un validateur qui devine. Avant d'attraper une regex, clarifiez la structure : une partie locale, un seul @, et une partie domaine.
@. C'est là que se nichent les cas délicats : plus tags, points et parfois des chaînes entre guillemets.@. Elle suit les règles des labels de domaine et peut être internationalisée.Garder ces pièces séparées rend la logique plus simple à raisonner et beaucoup plus facile à tester.
Les adresses réelles peuvent inclure des caractères non ASCII dans la partie locale (EAI) et des domaines non ASCII (IDN). Décidez en amont de ce que vous supportez.
Si vous n'acceptez que l'ASCII, rejetez les caractères non ASCII tôt avec un message clair. Si vous acceptez les IDN, vous validerez habituellement le domaine en forme compatible ASCII (punycode) en interne.
Les limites de longueur aident à éviter les cas limites et protègent vos formulaires contre les abus. Limites communes en pratique :
Faites un nettoyage basique avant l'analyse : supprimez les espaces en début et fin, et rejetez les adresses contenant des espaces internes à moins que vous ne supportiez volontairement les parties locales entre guillemets. Ne mettez pas la partie locale en minuscules (elle peut être sensible à la casse), mais mettre le domaine en minuscules est généralement sans risque.
Le plus addressing consiste à ajouter une étiquette après un signe plus, comme [email protected]. Les gens l'utilisent pour filtrer le courrier et suivre les inscriptions, donc le rejeter ajoute de la friction sans bénéfice.
Traitez + comme un caractère normal dans la partie locale (hors chaînes entre guillemets). Même si certains fournisseurs ignorent l'étiquette pour la livraison, c'est quand même partie de l'adresse telle qu'elle a été saisie.
Beaucoup d'équipes acceptent un « sous-ensemble sûr » dans la partie locale (lettres, chiffres et quelques séparateurs comme ., _, -, +). Cela couvre la plupart des adresses réelles et simplifie l'implémentation.
Les règles RFC autorisent plus de ponctuation, mais élargir l'ensemble accepté n'a de sens que si vous pouvez le faire correctement et garder des tests solides.
Dans la forme non citée commune, les points sont autorisés dans la partie locale, mais pas n'importe où :
[email protected] est invalide[email protected] est invalideN'intégrez pas des comportements spécifiques aux fournisseurs dans la syntaxe. Certains fournisseurs traitent firstlast et first.last comme la même boîte, mais ce n'est pas une règle de syntaxe.
Quelques cas rapides à tester :
[email protected] (plus tag)[email protected] (point)[email protected] (point initial)[email protected] (double point)[email protected] (plus tag avec sous-domaine)Les chaînes entre guillemets existent parce que les règles e-mail devaient couvrir d'anciens systèmes et des noms de boîtes inhabituels. Elles apparaissent dans la partie locale quand l'adresse a besoin de caractères autrement interdits ou ambigus.
Une partie locale citée est entourée de guillemets doubles, comme "john smith"@example.com. À l'intérieur des guillemets, les espaces sont permis. Si vous avez besoin d'un guillemet double littéral ou d'un antislash à l'intérieur, il doit être échappé par un antislash.
La partie déroutante est que les règles changent à l'intérieur des guillemets. Deux points consécutifs sont normalement invalides dans une partie locale non citée, mais ils sont autorisés à l'intérieur d'une chaîne citée. Cela signifie que "a..b"@example.com peut être valide alors que [email protected] doit être rejeté.
Pour les inscriptions, vous avez un vrai choix :
Les deux choix sont défendables. Ce qui cause des bugs, c'est les rejeter accidentellement avec une regex sur laquelle vous ne vouliez pas compter.
Cas de test syntaxiquement valides :
"john smith"@example.com"a..b"@example.com"john\"smith"@example.com"back\\slash"@example.com"weird()[],:;\u003c\u003e@\"@example.comLes chaînes entre guillemets n'affectent que la partie locale. Il faut toujours valider le domaine séparément.
Beaucoup de validateurs se trompent sur le domaine. Les sous-domaines sont normaux et fréquents. [email protected] ne devrait pas surprendre votre parser.
Une approche simple est de valider le domaine comme des labels séparés par des points, puis d'appliquer quelques règles faciles.
Pour la plupart des inscriptions grand public, ces règles fonctionnent bien :
Exiger « au moins un point » est souvent un bon filtre contre les fautes de frappe pour les adresses publiques, mais c'est une décision de politique si vous supportez des domaines internes.
La position des points est là où se cachent les bugs. Ce sont des échecs sévères :
[email protected][email protected], [email protected].[email protected][email protected], [email protected]a@sub_domain.exampleLa plupart des « e-mail invalide » viennent de validateurs qui font des suppositions au lieu de suivre des règles cohérentes.
L'espace blanc en est un gros. Le copier/coller peut ajouter des espaces en tête, en fin, des tabs, des espaces insécables ou un saut de ligne caché. Si vous validez avant de nettoyer, vous rejetez une adresse valide. Si vous « normalisez » trop (par exemple en supprimant tous les espaces internes), vous pouvez modifier la signification de l'adresse.
Un autre piège est de découper autour du @ naïvement. Il vous faut une règle claire : exactement un séparateur @, avec au moins un caractère de chaque côté. N'acceptez pas des choses en découpant sur le premier @ et en ignorant les autres, et ne plantez pas ou ne générez pas d'erreurs confuses en découpant par tous les @.
Certaines bibliothèques supportent partiellement des fonctionnalités RFC comme les commentaires (par exemple john.smith(comment)@example.com). Le support partiel peut être pire qu'un rejet cohérent parce qu'il crée des incompatibilités entre frontend et backend.
Signaux d'alerte à surveiller :
@ sans imposer « exactement un »Les homographes Unicode sont délicats. Même si vous supportez les adresses internationalisées, il est utile de logger les cas suspects et d'afficher un message clair quand quelque chose semble louche.
Un validateur de confiance n'est pas un motif astucieux. C'est un petit ensemble de règles appliquées dans le bon ordre.
Supprimez les espaces en tête et en fin, puis rejetez les caractères de contrôle (tabs, sauts de ligne, octets nuls). Décidez comment vous traitez les espaces Unicode non standards. Soyez explicite sur le support ou non du non-ASCII.
L'approche uniquement regex rejette souvent des adresses valides ou accepte des éléments cassés. Utilisez un parseur qui comprend la partie locale vs le domaine, et qui sait gérer les chaînes entre guillemets si vous choisissez de les supporter.
Gardez l'analyse séparée de la politique. L'analyse répond à « est-ce syntaxiquement valide ? », la politique répond à « voulons-nous l'autoriser dans notre produit ? »
Après l'analyse, appliquez des limites strictes et des vérifications de sanity basiques du domaine (longueurs, pas de labels vides, pas de tirets en début/fin, sous-domaines autorisés si bien formés). Cela attrape des entrées qui peuvent techniquement parser mais poseront problème plus tard.
Décidez volontairement des cas limites comme les parties locales entre guillemets. Si vous les bloquez, dites-le et affichez un message clair. Si vous les autorisez, ajoutez des tests pour les caractères échappés et les espaces.
Surtout, gardez les mêmes règles sur web, mobile et backend pour éviter des erreurs incohérentes visibles par les utilisateurs.
Quand le support demande pourquoi un e-mail a été rejeté, « invalide » ne suffit pas. Logger un petit ensemble de codes de raison (par exemple : CONTROL_CHAR, PARSE_FAIL, LENGTH, DOMAIN_LABEL) rend les pics d'erreur plus faciles à diagnostiquer et vous aide à trouver des problèmes comme un clavier iOS insérant un saut de ligne caché.
Un validateur n'est aussi bon que les tests qui verrouillent son comportement. Gardez un petit ensemble « doit passer » basé sur de vraies inscriptions, un ensemble « doit échouer » pour les rejets universels, et un ensemble de cas limites pour piéger le parseur.
Exemples « doit passer » :
Exemples « doit échouer » :
plainaddress (manque le @)alex@ (manque le domaine)@example.com (manque la partie locale)[email protected] (double point dans la partie locale)Si vous décidez de supporter les chaînes entre guillemets, ajoutez des tests explicites comme "john..doe"@example.com et "john\"doe"@example.com. Si vous décidez de ne pas les supporter, gardez quand même ces tests mais marquez-les comme rejets par politique pour que le choix reste visible.
Ne vous arrêtez pas au simple pass/fail. Stockez des codes de raison attendus pour que les échecs soient actionnables.
{ "input": "[email protected]", "expected": "fail", "reason": "LOCALPART_DOT_SEQUENCE" }
Exécutez la même suite partout où vous validez : web, mobile, backend et tout flux d'auth tierce partie. C'est là que les incohérences apparaissent généralement.
Si vous voulez moins de bugs d'inscription et moins de tickets « pourquoi cet e-mail ne marche pas ? », gardez vos règles de syntaxe courtes et cohérentes. Un seuil pratique ressemble à ceci :
@, avec au moins un caractère de chaque côtéDécidez une fois et documentez : acceptez-vous les parties locales citées comme "john smith"@example.com ? Elles sont valides selon RFC 5322, mais rares dans les inscriptions et souvent mal gérées en aval.
Après la syntaxe, ajoutez les vérifications que la syntaxe ne couvre pas : vérifiez que le domaine existe, contrôlez les enregistrements MX, et filtrez les fournisseurs jetables et les pièges à spam connus. Si vous préférez ne pas maintenir ces couches vous-même, Verimail (verimail.co) est une API de validation d'e-mails qui exécute des contrôles de syntaxe, vérification de domaine, recherche MX et correspondance de listes noires/jetables, pour que vous puissiez garder une logique d'inscription cohérente sans tout empiler dans une seule regex.