20 déc. 2025·7 min
Checklist de validation de la syntaxe des e-mails conforme aux RFC pour les inscriptions
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.
Pourquoi la validation de la syntaxe des e-mails provoque tant de bugs
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 :
- Ce que les standards autorisent (règles de syntaxe)
- Ce que votre produit veut accepter (votre politique)
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.
Ce que signifie « conforme aux RFC » (et ce que cela ne signifie pas)
« 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é.
Syntaxe vs vérification de domaine vs existence de la boîte
Pensez la validation en couches :
- Syntaxe : l'adresse est-elle formatée correctement (caractères, séparateurs, règles de citation) ?
- Domaine : le domaine peut-il recevoir des e-mails (DNS, enregistrements MX) ?
- Existence de la boîte : cette boîte existe-t-elle vraiment ? C'est la couche la plus difficile, car beaucoup de serveurs ne la confirment pas.
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é.
Ce que « conforme aux RFC » signifie en pratique
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 :
- Absence de
@ou absence de partie locale ou de domaine - Caractères de contrôle, espaces invisibles ou sauts de ligne collés
- Labels de domaine commençant ou finissant par un tiret
- Unicode que vous ne supportez pas de bout en bout
- Entrées excessivement longues (fixez une longueur max pour éviter les abus)
Scé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.
Connaître les parties d'une adresse e-mail avant de valider
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.
- La partie locale est tout ce qui précède le
@. C'est là que se nichent les cas délicats : plus tags, points et parfois des chaînes entre guillemets. - La partie domaine est tout ce qui suit le
@. 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.
ASCII vs adresses internationalisées (vue d'ensemble)
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.
Limites de longueur à appliquer
Les limites de longueur aident à éviter les cas limites et protègent vos formulaires contre les abus. Limites communes en pratique :
- Longueur totale : 254 caractères
- Partie locale : 64 caractères
- Partie domaine : 253 caractères
- Chaque label de domaine : 63 caractères
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.
Plus addressing et points : cas courants à supporter
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.
Caractères de la partie locale : sous-ensemble sûr vs ensemble complet
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.
Points : ce que la syntaxe permet (et ce que font les fournisseurs)
Dans la forme non citée commune, les points sont autorisés dans la partie locale, mais pas n'importe où :
- Pas de point initial :
[email protected]est invalide - Pas de point final
- Pas de points consécutifs :
[email protected]est invalide
N'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)
Chaînes entre guillemets : le cas limite que la plupart des parseurs manquent
Protect your signup flow
Ajoutez un appel API unique pour bloquer les adresses invalides et les domaines jetables lors de l'inscription.
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 :
- Supporter complètement les chaînes entre guillemets (et les tester soigneusement), ou
- Les rejeter volontairement parce qu'elles sont rares et peuvent casser des systèmes en aval
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.com
Les chaînes entre guillemets n'affectent que la partie locale. Il faut toujours valider le domaine séparément.
Domaines et sous-domaines : quoi autoriser et quoi bloquer
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.
Ce qu'il faut autoriser (et pourquoi)
Pour la plupart des inscriptions grand public, ces règles fonctionnent bien :
- Plusieurs labels (sous-domaines) sont acceptables.
- Les labels peuvent contenir des lettres et des chiffres, et peuvent inclure des tirets à l'intérieur (pas au début ni à la fin).
- Les labels font de 1 à 63 caractères, et le domaine total n'est pas absurdemment long (beaucoup de systèmes plafonnent à 253).
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.
Ce qu'il faut bloquer (échecs courants qui « semblent valides »)
La position des points est là où se cachent les bugs. Ce sont des échecs sévères :
- Points consécutifs :
[email protected] - Point initial ou final :
[email protected],[email protected]. - Labels vides dus à un mauvais découpage :
[email protected] - Label commençant ou finissant par un tiret :
[email protected],[email protected] - Caractères invalides dans un label (les underscores sont une erreur courante) :
a@sub_domain.example
Erreurs d'analyse courantes qui créent des faux rejets
Make syntax rules predictable
Utilisez une vérification de syntaxe conforme aux RFC au lieu de deviner avec des motifs stricts ou permissifs.
La 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 :
- Nettoyer seulement les espaces ASCII, mais pas les tabs, les espaces insécables ou les sauts de ligne finaux
- Découper sur
@sans imposer « exactement un » - Accepter via une regex permissive, puis échouer plus tard avec une erreur vague
- Résultats différents entre environnements (web vs mobile vs backend)
- Ignorer les homographes Unicode (par exemple un « а » cyrillique qui ressemble à un « a » latin)
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.
Étape par étape : construire un validateur de syntaxe fiable
Un validateur de confiance n'est pas un motif astucieux. C'est un petit ensemble de règles appliquées dans le bon ordre.
1) Nettoyez l'entrée
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.
2) Parsez avec un parseur conscient des RFC (pas seulement une regex)
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 ? »
3) Appliquez les limites et les règles sur les labels de domaine
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.
4) Choisissez votre politique de sévérité et documentez-la
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.
5) Logguez les échecs avec des codes de raison
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é.
Cas de test à inclure dans votre suite de validation
Stop email regex bugs
Remplacez les regex fragiles par une validation conforme aux RFC, avec vérifications de domaine et MX.
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 » :
- `` (chaîne vide)
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.
Checklist rapide et prochaines étapes
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 :
- Exactement un
@, avec au moins un caractère de chaque côté - Pas d'espaces ni de caractères de contrôle (sauf si vous supportez volontairement les parties locales citées)
- Longueur dans les limites courantes (partie locale jusqu'à 64, adresse entière jusqu'à 254)
- Domaine bien formé (pas de points consécutifs, pas de labels vides, pas de tiret en début/fin de label)
- Les plus-tags et les sous-domaines sont autorisés par défaut
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.
FAQ
Why is validating email with a regex so error-prone?
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.
What’s the difference between syntax validation and acceptance policy?
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.
Does “RFC-compliant” mean an email is deliverable?
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.
What input cleanup should I do before validating an email?
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.
Should my signup form allow plus addressing (like [email protected])?
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.
Are subdomains like [email protected] valid?
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.
How should I handle multiple @ signs in an email input?
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.
Do I need to support quoted local parts like "john smith"@example.com?
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.
What length limits should I enforce for email addresses?
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.
How can I log validation failures so they’re actually useful?
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 ».