Qu'est-ce que la vérification d'e-mails ? Guide pour développeurs

Quand un utilisateur saisit une adresse e-mail dans votre formulaire d'inscription, que savez-vous réellement d'elle ? Si vous ne contrôlez que la syntaxe — est-ce que ça ressemble à une adresse ? — vous n'en savez presque rien. La vérification d'e-mails, c'est le processus qui établit si une adresse est réelle, joignable et digne d'être contactée.

Ce guide explique ce que la vérification contrôle vraiment, comment fonctionne chaque couche, et où elle doit s'insérer dans votre stack.

Ce que la vérification d'e-mails n'est pas

La validation de syntaxe n'est pas de la vérification. Contrôler qu'une adresse correspond à /^[^\s@]+@[^\s@]+\.[^\s@]+$/ vous dit seulement que la chaîne contient un @ et un point. Cela n'attrape pas :

test@mailinator.com — adresse jetable, supprimée en 10 minutes
noreply@example.com — adresse de rôle que personne ne lit
user@nonexistent-domain.com — domaine sans serveur de messagerie
ghost@real-company.com — adresse dont la boîte a été supprimée

Un pipeline de vérification complet a cinq couches distinctes. Chacune élimine une classe différente de mauvaises adresses.

Couche 1 : validation de la syntaxe

Le premier contrôle normalise et valide le format de l'adresse selon la RFC 5321 et la RFC 5322. Au-delà de l'expression régulière de base, il attrape des cas limites comme :

Les points doublés (user..name@domain.com)
Un point en début ou en fin de partie locale
Les caractères interdits dans la partie locale
Les adresses trop longues (limite RFC : 254 caractères au total, 64 dans la partie locale)

La plupart des adresses n'échouent ici qu'à cause d'une faute de frappe, et cette étape se termine en quelques microsecondes.

Couche 2 : domaine et enregistrements MX

Une syntaxe valide ne signifie pas que le domaine existe ou accepte du courrier. La deuxième couche effectue des requêtes DNS :

Requête MX — le domaine a-t-il des enregistrements de messagerie pointant vers un serveur SMTP ?
Repli sur l'enregistrement A — s'il n'y a pas de MX, le domaine se résout-il tout de même ?
Existence du domaine — le domaine est-il enregistré et non expiré ?

Un domaine comme emai.com (faute de frappe courante pour email.com) passe la validation de syntaxe mais n'a aucun enregistrement MX — et n'en aura jamais. Ce contrôle élimine des catégories entières de fautes de frappe et de domaines récemment expirés.

# Contrôle manuel : consulter les enregistrements MX d'un domaine
dig MX gmail.com
# ;; ANSWER SECTION:
# gmail.com. 3600 IN MX 5 gmail-smtp-in.l.google.com.

Couche 3 : vérification SMTP

Le contrôle le plus précieux est un dialogue SMTP avec le serveur de messagerie. Le vérificateur se connecte au serveur MX, engage une conversation et demande si la boîte existe — sans envoyer le moindre e-mail.

L'échange ressemble à ceci :

→ EHLO verifier.mailbeam.dev
← 250-smtp.gmail.com Hello
→ MAIL FROM:<probe@mailbeam.dev>
← 250 2.1.0 OK
→ RCPT TO:<user@gmail.com>
← 250 2.1.5 OK        ← la boîte existe

Si le serveur répond 550 ou 551 à la commande RCPT TO, la boîte n'existe pas. Le vérificateur envoie alors un RSET pour interrompre avant tout envoi de message.

Cela attrape les adresses qui passent la syntaxe et le MX mais n'ont aucune boîte réelle — fréquent après un départ de salarié, une fermeture de compte ou la création en masse de faux comptes.

Les limites du SMTP

Certains serveurs ne jouent pas le jeu. Ils répondent 250 OK à toutes les adresses, quelles qu'elles soient (comportement catch-all), pour ne pas révéler quelles boîtes existent. D'autres limitent le débit des sondages de vérification. C'est là que la quatrième couche compte.

Couche 4 : noter les cas ambigus

Quand le SMTP donne un résultat ambigu — typiquement un domaine catch-all — il vous faut autre chose qu'un oui ou un non. Certains services appliquent un modèle d'apprentissage entraîné sur des données d'envoi historiques. Mailbeam utilise plutôt un score additif : un ensemble fixe de signaux avec des poids et des plafonds publiés, où une adresse catch-all ne peut jamais dépasser 70 parce qu'aucun sondage ne peut la confirmer.

L'arbitrage est délibéré. Un barème ne battra pas un bon modèle en prédiction sur des adresses réellement ambiguës, mais chaque point est traçable jusqu'à un contrôle : quand le nombre surprend, il est possible de savoir pourquoi. La sortie va de 0 à 100 plutôt que d'être binaire, ce qui vous laisse appliquer des seuils différents selon le cas d'usage :

const result = await verifyEmail(email);

if (result.catchAll) {
  // Adresse d'entreprise — accepter en forte confiance, signaler en moyenne, rejeter en faible
  if (result.score >= 70) return "accept";
  if (result.score >= 40) return "flag_for_review";
  return "reject";
}

Couche 5 : les métadonnées

Au-delà de la délivrabilité, les API de vérification remontent des métadonnées utiles :

disposable — est-ce un domaine de messagerie temporaire connu (Mailinator, 10MinuteMail, etc.) ?
role — est-ce une adresse de rôle comme info@, noreply@, admin@ ?
suggestion — l'utilisateur voulait-il probablement écrire gmail.com plutôt que gmai.com ?
free — est-ce un fournisseur gratuit (Gmail, Outlook) ?

Ces indicateurs vous permettent d'appliquer des règles différentes selon le type d'adresse — accepter par exemple les adresses de rôle pour des contacts de facturation, mais les rejeter pour des listes marketing.

Quand utiliser la vérification d'e-mails

À l'inscription (temps réel)

Le point d'intégration le plus rentable. Vérifiez l'adresse avant la création du compte, pendant que l'utilisateur est encore sur le formulaire.

// Server Action Next.js
async function createAccount(formData: FormData) {
  const email = formData.get("email") as string;

  const result = await verifyEmail(email);
  if (!result.valid) {
    return { error: result.suggestion
      ? `Vouliez-vous dire ${result.suggestion} ?`
      : "Cette adresse e-mail ne semble pas valide." };
  }
  if (result.disposable) {
    return { error: "Les adresses e-mail temporaires ne sont pas autorisées." };
  }

  // suite de la création du compte
}

La vérification en temps réel exige une API sous 100 ms — au-delà, vous bloquez visiblement l'envoi du formulaire.

Avant un envoi en masse

Avant d'importer un CSV ou d'écrire à une liste froide, lancez un traitement de vérification par lot. Cela protège votre réputation d'expéditeur avant que le mal ne soit fait.

const auth = { Authorization: `Bearer ${process.env.MAILBEAM_KEY}` };

// Envoi de la liste ; la réponse est un identifiant de traitement, pas les résultats.
const job = await fetch("https://api.mailbeam.dev/v1/verify/batch", {
  method: "POST",
  headers: { ...auth, "Content-Type": "application/json" },
  body: JSON.stringify({ emails }),
}).then((r) => r.json());

// Attendez le webhook batch.completed, ou interrogez /v1/jobs/:id jusqu'à la fin.
const { results } = await fetch(
  `https://api.mailbeam.dev/v1/jobs/${job.job_id}/results?format=json`,
  { headers: auth }
).then((r) => r.json());

const deliverable = results
  .filter((r) => r.status === "deliverable" && r.score >= 60)
  .map((r) => r.email);

Nettoyage périodique des listes

Les adresses e-mail se dégradent d'environ 20 à 30 % par an. Une adresse valide il y a 18 mois peut rebondir aujourd'hui. Un nettoyage tous les 6 mois maintient le taux de bounce sous contrôle sans toucher au frontend.

Que faire du résultat

Une erreur courante consiste à traiter la vérification comme une barrière binaire. Le bon schéma est un traitement par paliers :

Résultat	Action
`valid: true, score >= 70`	Accepter immédiatement
`valid: true, score 40–69`	Accepter, mais surveiller l'engagement
`valid: true, score < 40, catchAll: true`	Accepter sur les parcours à forte intention ; rejeter en prospection à froid
`valid: false, suggestion`	Afficher la suggestion à l'utilisateur
`disposable: true`	Bloquer avec un message
`valid: false, sans suggestion`	Afficher une erreur de validation générique

En résumé

La vérification d'e-mails est un pipeline, pas un contrôle unique :

Syntaxe — le format est-il valide ?
DNS/MX — le domaine accepte-t-il du courrier ?
SMTP — la boîte précise existe-t-elle ?
Score — pour un domaine catch-all, quelle confiance reste-t-il ?
Métadonnées — est-ce une adresse jetable, de rôle, ou une faute de frappe ?

Exécuter les cinq couches — via une API ou en construisant votre propre pipeline — est ce qui sépare une vraie adresse d'une adresse qui en a l'air.