Arrêtez de valider les emails avec regex

Arrêtez de valider les emails avec regex : voici ce qu’il faut faire à la place

ByDigiLop

Presque toutes les bases de code que j’ai touchées contiennent une version de cette ligne :

const ok = /^[^@]+@[^@]+\.[^@]+$/.test(email);

Cela ressemble à une validation par e-mail. Ce n’est pas le cas. Voici ce qui manque réellement à cette expression régulière et une manière plus honnête de vérifier une adresse avant de lui faire confiance.

1. Regex vérifie uniquement formepas la réalité

a@a.a passe la plupart des expressions régulières. Il en va de même test@mailinator.com (une adresse jetable) et ceo@yourcompany.com tapé comme ceo@yourcompnay.com. Votre regex dit « valide » pour les trois. Votre entonnoir d’inscription, votre e-mail transactionnel et votre taux de délivrabilité ne sont pas d’accord.

La grammaire complète de la RFC 5322 pour une adresse valide est notoirement monstrueuse, et même la version correcte ne vous dit rien sur l’arrivée réelle du courrier.

2. Les quatre contrôles qui comptent vraiment

Au lieu d’une seule expression régulière, pensez en couches, en commençant par le moins cher :

  1. Syntaxe – un sain sous-ensemble, pas la RFC complète. Attrapez les déchets évidents.
  2. Jetable/détection de rôle — le domaine est-il jetable (mailinator.com, 10minutemail) ou une boîte de réception de rôle (admin@, support@) ? Ceux-ci détruisent vos mesures d’engagement.
  3. Suggestions de fautes de frappe — gmial.com à gmail.com, yaho.com à yahoo.com. L’un des correctifs avec le retour sur investissement le plus élevé pour la conversion d’inscription.
  4. MX / délivrabilité — le domaine publie-t-il réellement des serveurs de messagerie (enregistrements MX) ? S’il n’y a pas de MX, rien de ce que vous envoyez ne pourra jamais atterrir.

Cette dernière étape est l’étape que les gens sautent, car elle nécessite une recherche DNS plutôt qu’un test de chaîne.

3. Faire la vérification MX

Dans Node, vous pouvez le faire vous-même :

import { promises as dns } from 'node:dns';

async function hasMx(domain) {
  try {
    const records = await dns.resolveMx(domain);
    return records.length > 0;
  } catch {
    return false;
  }
}

C’est l’idée centrale. Dans un navigateur ou une fonction Edge, vous n’avez pas de DNS brut, vous atteindrez donc un petit point de terminaison qui effectue la recherche pour vous.

4. Une version hébergée, si vous ne souhaitez pas la construire

J’en avais assez de réimplémenter ces quatre couches, alors je les ai placées derrière un seul appel GET gratuit. Partager au cas où cela vous sauverait l’après-midi même :

GET https://verify-api.cchkjjdobby.workers.dev/email?email=test@mailinator.com

{
  "domain": "mailinator.com",
  "is_disposable": true,
  "has_mx": true,
  "status": "disposable",
  "deliverable": false
}

CORS est activé et fonctionne sur Cloudflare Workers sans appels externes payants, le niveau gratuit est donc véritablement gratuit. Il existe également une interface utilisateur sans inscription si vous souhaitez simplement coller une adresse et voir les couches : https://tools-site.cchkjjdobby.workers.dev

Limites honnêtes

Un contrôle MX confirme le domaine peut recevoir du courrier — il ne peut pas garantir un boîte de réception existe sans envoyer quelque chose. Et vous ne devriez jamais bloquer une inscription en raison d’une faute de frappe ; suggérez, ne rejetez pas.

C’est le compromis : les chèques en couches bon marché détectent la plupart des mauvaises adresses avant qu’elles ne vous coûtent cher, et vous acceptez que le dernier kilomètre (cette boîte aux lettres exacte existe-t-elle) nécessite un envoi réel.

Que fait votre pile pour cela aujourd’hui : lancer la vôtre ou payer pour un SaaS de validation ? Curieux de savoir quel est le point de rupture où les gens décident de payer.

Articles similaires