Pourquoi la validation d'e-mails par regex échoue

Chaque base de code en possède une : une expression régulière, copiée depuis Stack Overflow, qui « valide » les adresses e-mail. Elle a l'air d'un contrôle, mais elle répond à une question que presque personne ne pose vraiment. Une regex peut vous dire qu'une chaîne a la forme d'une adresse e-mail. Elle ne peut pas vous dire que l'adresse existe, qu'elle accepte le courrier, ou qu'elle ne provoquera pas de rebond dur lors de votre prochaine campagne — et ce sont là les seules choses qui comptent.

La réponse en bref#

Une regex valide la syntaxe, pas la délivrabilité. definitely-fake@gmail.com est une adresse e-mail parfaitement valide selon toutes les regex jamais écrites, et elle rebondira à l'instant où vous lui enverrez un message. Pire, les regex vers lesquelles les gens se tournent, soit rejettent de vraies adresses (trop strictes), soit acceptent des absurdités (trop laxistes), et celle qui est techniquement correcte fait des milliers de caractères et ne peut toujours pas confirmer l'existence d'une boîte aux lettres. Utilisez un simple contrôle de syntaxe pour attraper les fautes de frappe au niveau du champ, puis vérifiez la délivrabilité avec un contrôle DNS et SMTP — car c'est un problème de réseau, pas de recherche de motif.

La regex que vous avez déjà vue, et ce qu'elle laisse passer#

Voici l'archétype — une variante de celle-ci vit dans la plupart des projets :

const re = /^[^@\s]+@[^@\s]+\.[^@\s]+$/;
re.test("definitely-fake@gmail.com"); // true  ← will hard-bounce
re.test("typo@gmial.com");            // true  ← typo'd domain, bounces
re.test("info@company-that-folded.com"); // true  ← dead domain

Les trois passent. Les trois sont non délivrables. La regex a parfaitement fait son travail et ne vous a rien appris d'utile, parce que syntaxe et délivrabilité sont deux questions différentes. Toute adresse qu'une regex peut voir est une chaîne ; qu'un humain y lise son courrier est un fait à propos d'Internet, pas à propos de la chaîne.

L'engrenage de la RFC 5322#

« Très bien, se dit-on, je vais utiliser une regex correcte. » La grammaire formelle d'une adresse e-mail est définie par la RFC 5322, et une regex qui l'implémente réellement est tristement monstrueuse — des milliers de caractères, et elle autorise des choses dont vous ne voudriez jamais, comme des parties locales entre guillemets contenant des espaces ("a b"@example.com) et des commentaires à l'intérieur de l'adresse.

Deux problèmes en découlent. D'abord, la regex stricte accepte plus que ce que vous voulez, pas moins — elle valide au regard d'une spécification de 2008, pas au regard des « adresses auxquelles de vrais serveurs de messagerie livreront ». Ensuite, même une correspondance RFC 5322 impeccable ne peut toujours pas vous dire si le domaine dispose d'un serveur de messagerie ou si la boîte aux lettres existe. Vous avez déployé des efforts considérables pour répondre à la question facile avec plus de précision, tandis que la question difficile — le courrier arrivera-t-il ? — reste totalement intacte.

Les trois choses qu'une regex ne peut fondamentalement pas faire#

Aucun motif, si astucieux soit-il, ne peut traverser le réseau. Une regex ne peut pas :

• Vérifier que le domaine peut recevoir du courrier. user@company-that-folded.com est une syntaxe valide sur un domaine sans enregistrement MX. Seule une résolution DNS révèle le domaine mort.
• Confirmer que la boîte aux lettres existe. noreply-9f2x@gmail.com est une syntaxe valide pour un compte qui n'a jamais été créé. Seule une conversation SMTP avec Gmail peut vous dire qu'il n'existe pas.
• Détecter un domaine catch-all. Un serveur catch-all accepte toutes les adresses, si bien que même un contrôle SMTP en direct ne peut pas confirmer une boîte aux lettres précise — et une regex n'a aucune idée que le domaine se comporte ainsi.

Ce ne sont pas des lacunes d'une regex particulière ; elles sont hors de ce que toute regex peut faire, parce que ce sont des questions à propos de serveurs, pas de chaînes.

Ce qu'il faut vraiment faire : valider par couches#

La délivrabilité est un enchaînement de contrôles de plus en plus coûteux, et la syntaxe n'est que la première étape, la moins chère (le tableau complet est dans comment fonctionne la vérification d'e-mails) :

1. Syntaxe — un simple contrôle au niveau du champ pour attraper les fautes de frappe évidentes. C'est la seule couche à laquelle une regex appartienne.
2. Domaine et MX — une résolution DNS pour confirmer que le domaine peut, tout simplement, recevoir du courrier. Voir les guides Node.js et Python pour du code fonctionnel.
3. Sonde SMTP de la boîte aux lettres — la conversation de livraison qui confirme réellement la boîte aux lettres, plus la détection des catch-all. Cela requiert un serveur de messagerie doté d'une réputation d'IP propre et d'une limitation de débit soignée, ce qui explique pourquoi la plupart des équipes se tournent vers une API de vérification plutôt que de la construire.

Le contrôle de syntaxe qui vaut la peine d'être conservé#

Pour la couche 1, ne bricolez pas votre propre RFC 5322. La démarche pragmatique, c'est le champ e-mail HTML5 dans le navigateur (qui applique gratuitement le motif du standard vivant du WHATWG) et un contrôle court et permissif côté serveur :

// Pragmatic: rejects fat-finger errors, accepts the addresses real
// mail servers actually deliver to. Not a deliverability check.
const SYNTAX = /^[^\s@"]+(?:\.[^\s@"]+)*@[^\s@.]+(?:\.[^\s@.]+)+$/;

SYNTAX.test("jane@example.com"); // true
SYNTAX.test("not-an-email");     // false
SYNTAX.test("a@@b.com");         // false

Servez-vous-en pour donner un retour instantané au clavier — rien de plus. Traitez un succès comme un « à vérifier correctement », jamais comme un « valide ».

Parcourir le reste du chemin#

Une fois la syntaxe validée, la véritable vérification est un travail de réseau. Vous pouvez construire vous-même les couches DNS et SMTP — les guides par langage ci-dessus montrent jusqu'où vous pouvez aller — mais confirmer des boîtes aux lettres actives à grande échelle se heurte au port 25 bloqué sur la plupart des hébergeurs, à la réputation d'IP et au greylisting, là où une API managée prend tout son sens. Le point de terminaison POST /verify de Qualisend exécute tout l'enchaînement et renvoie un verdict à quatre issues (deliverable | risky | undeliverable | unknown) assorti d'un code de motif, pour que votre code réagisse selon que la boîte aux lettres existe, et non selon que la chaîne contient un @.

Foire aux questions#

Existe-t-il une regex correcte pour valider les e-mails ?#

Pas au sens où les gens l'entendent. Une regex qui implémente la RFC 5322 existe, mais elle fait des milliers de caractères, accepte des formes exotiques dont vous ne voudriez jamais, et ne peut toujours pas confirmer que l'adresse est délivrable. En pratique, un motif court et permissif (ou le champ HTML5 type="email") pour attraper les fautes de frappe est la juste dose de regex — le reste est un problème de DNS et de SMTP.

Pourquoi ma regex rejette-t-elle des adresses e-mail valides ?#

Parce que les motifs stricts encodent des hypothèses fausses — que les domaines de premier niveau font 2 à 3 lettres (c'est faux : .email, .io, .marketing), que les signes plus ou les points ne sont pas autorisés dans la partie locale (ils le sont), ou que les nouveaux gTLD n'existent pas. Une regex trop stricte est une cause fréquente d'inscriptions perdues. Restez permissif sur la syntaxe et vérifiez la délivrabilité séparément.

La validation HTML5 des e-mails vérifie-t-elle si l'adresse est réelle ?#

Non. La validation type="email" du navigateur est un contrôle de syntaxe — une version plus conviviale et normalisée de la même recherche de motif. Elle attrape les @ manquants et les malformations évidentes au niveau du champ, mais elle ne contacte jamais le serveur de messagerie ; elle ne peut donc pas vous dire si le domaine ou la boîte aux lettres existe.

Que devrais-je utiliser à la place d'une regex pour valider les e-mails ?#

Procédez par couches : un contrôle de syntaxe permissif pour un retour instantané, une résolution DNS/MX pour écarter les domaines morts, et une sonde SMTP de la boîte aux lettres pour confirmer la délivrance. Construisez vous-même les deux premières ; utilisez une API de vérification pour la couche SMTP, car la réaliser de façon fiable exige une réputation d'IP d'envoi et une limitation de débit qu'une regex ne pourrait jamais fournir.

Vous voulez voir la différence entre « syntaxe valide » et « livrera réellement » ? Le forfait gratuit inclut 100 crédits de vérification qui exécutent tout l'enchaînement — syntaxe, DNS et sonde SMTP de la boîte aux lettres — pour que vous puissiez voir une adresse approuvée par une regex revenir undeliverable. La référence de l'API propose des exemples à copier-coller dans sept langages.