Comment fonctionne la vérification des e-mails : les 8 étapes

La réponse en bref#

La vérification des e-mails fait passer une adresse par un pipeline de contrôles de plus en plus coûteux, qui s'arrête dès que l'un d'eux est décisif. Les contrôles peu coûteux et instantanés se déroulent en local — l'adresse a-t-elle seulement la forme d'un e-mail, son domaine accepte-t-il le courrier — et seules les adresses qui survivent à ces contrôles atteignent l'étape lente, tributaire du réseau, qui consiste à demander réellement au serveur de messagerie si la boîte aux lettres existe. Qualisend exécute huit étapes distinctes, et cet article les détaille une par une : ce que chacune peut prouver, ce qu'elle ne peut pas, et quel verdict elle produit.

L'ordre a son importance, car chaque étape est un filtre. Il ne sert à rien d'ouvrir une connexion SMTP pour vérifier une boîte aux lettres sur un domaine dépourvu de serveur de messagerie, ni d'interroger le DNS de ce domaine si l'adresse ne comporte pas d'@. On élimine d'abord à peu de frais ; la question coûteuse vient en dernier.

Étape 1 — La syntaxe#

Le premier contrôle vérifie si la chaîne est une adresse e-mail structurellement valide : un seul @, une partie locale cohérente, un domaine qui ressemble à un domaine. Cela intercepte les erreurs de saisie — virgules en trop, espaces, TLD manquant, deux signes @ — et c'est instantané et gratuit, car ce contrôle ne quitte jamais le processus.

La validation de la syntaxe est nécessaire, mais faible à elle seule. definitely-not-real@some-made-up-domain.com a une syntaxe parfaitement valide et est totalement non distribuable. Quiconque « vérifie » avec une expression régulière et s'arrête là contrôle l'orthographe, pas la distribuabilité. Un échec à cette étape renvoie undeliverable avec le motif invalid_email.

Étape 2 — Le domaine et les enregistrements MX#

Ensuite, le vérificateur interroge le DNS pour savoir si le domaine peut recevoir du courrier : se résout-il, et publie-t-il des enregistrements MX (ou un enregistrement A exploitable en repli) pointant vers un serveur de messagerie ? Un domaine sans route de courrier ne peut accepter de messages pour personne ; cette étape élimine donc des domaines entièrement morts en une seule requête — noms d'entreprise mal orthographiés, domaines expirés et TLD inventés.

Un domaine qui échoue ici renvoie undeliverable avec le motif invalid_domain. Un domaine qui réussit dispose d'une route pour le courrier ; il n'a pas encore prouvé que votre boîte aux lettres précise existe. Cela reste à quatre étapes de distance.

Étape 3 — Les domaines jetables#

Certains domaines n'existent que pour distribuer des boîtes de réception éphémères — ces adresses valables dix minutes que l'on utilise pour récupérer un code de réduction avant de ne jamais y revenir. Qualisend compare le domaine à une liste tenue à jour de fournisseurs jetables. Une correspondance ne signifie pas que l'adresse n'acceptera pas de courrier aujourd'hui ; elle signifie que l'adresse sera sans valeur demain, elle est donc signalée et pénalisée dans le score plutôt que considérée comme fiable.

Une adresse jetable est signalée comme risky avec le motif low_quality et un sous-indicateur disposable. La question connexe de savoir s'il faut lui envoyer du courrier ou non est une décision distincte — traitée dans les adresses de rôle, jetables et gratuites.

Étape 4 — Les comptes de rôle#

Une adresse de rôle est une boîte aux lettres partagée — info@, support@, billing@ — lue par une équipe ou un système de tickets plutôt que par une personne. Ces adresses sont généralement réelles et distribuables, mais elles se comportent mal en marketing : aucun individu ne les possède, elles faussent les indicateurs d'engagement et elles attirent les plaintes pour spam. Le vérificateur les détecte donc (sans tenir compte de la casse, en ignorant tout suffixe +tag) et les signale au lieu de les traiter comme une boîte de réception personnelle.

Une adresse de rôle reste deliverable mais porte un sous-indicateur role, afin que vous puissiez décider si elle a sa place dans un envoi donné. Là encore, le choix d'envoyer ou de supprimer fait l'objet de son propre guide.

Étape 5 — La détection des fautes de frappe#

Avant de dépenser un aller-retour réseau, le vérificateur vérifie si le domaine ressemble de très près à un fournisseur courant — gmial.com pour gmail.com, hotmial.com pour hotmail.com — à l'aide de la distance d'édition de Damerau-Levenshtein (l'algorithme qui compte les insertions, suppressions, substitutions et transpositions). Lorsqu'il repère une faute de frappe probable, il propose une suggestion « vouliez-vous dire », bien plus utile qu'un simple rejet : à l'inscription, elle vous permet d'offrir la correction en temps réel et de sauver l'abonné plutôt que de le perdre.

La détection des fautes de frappe est une suggestion, pas un verdict à elle seule — mais c'est l'une des étapes au plus fort effet de levier, car intercepter la faute de frappe dès la saisie évite d'un seul coup un rebond définitif et un contact perdu.

Étape 6 — Le sondage SMTP de la boîte aux lettres#

Tout ce qui précède est local et instantané. Voici l'étape qui coûte réellement quelque chose : le vérificateur ouvre une connexion vers le serveur de messagerie du domaine et entame la conversation de distribution — HELO, MAIL FROM, RCPT TO:<address> — puis lit la réponse du serveur sans jamais envoyer de message. La réponse à RCPT TO est ce qui se rapproche le plus d'une vraie réponse sur l'existence de la boîte aux lettres :

• 250/251 → le serveur accepte le destinataire → deliverable, accepted_email
• classe 550 → rejet permanent, utilisateur inexistant → undeliverable, rejected_email
• 4xx → un report temporaire, généralement du greylisting → nouvelle tentative, puis unknown s'il persiste
• toute autre réponse, ou un délai dépassé → unknown

Cette étape lit aussi le texte et les codes de la réponse pour deux conditions particulières : un message 452/552 ou « over quota » signifie que la boîte aux lettres existe mais est pleine (risky), et un message « disabled/suspended » signifie que le compte est mort (undeliverable). La grammaire complète de ces réponses a sa propre référence : les codes de réponse SMTP expliqués.

Étape 7 — La détection des domaines fourre-tout#

Un 250 SMTP n'a de sens que si le serveur aurait répondu non à une adresse inexistante. En même temps que votre adresse, le vérificateur sonde donc une boîte aux lettres délibérément absurde sur le même domaine. Si le serveur l'accepte elle aussi, le domaine est fourre-tout (catch-all) — il accepte tout — et le 250 obtenu pour votre adresse ne prouve rien. Cette adresse est signalée comme risky avec le motif low_deliverability et un indicateur catch-all, jamais arrondie au statut deliverable.

C'est l'étape la plus déformée du secteur, et c'est pourquoi elle dispose de son propre article pilier. Le résumé honnête : une boîte aux lettres derrière un domaine fourre-tout est inconfirmable, et aucun score n'y change rien.

Étape 8 — La notation et le verdict#

L'étape finale agrège chaque signal — le verdict SMTP, les sous-indicateurs, la réputation du domaine, le fait que la boîte aux lettres soit chez un fournisseur gratuit — en un statut unique (deliverable | risky | undeliverable | unknown), un code de motif et un score de confiance de 0 à 100. Le statut vous indique quoi faire ; le motif et les sous-indicateurs vous disent pourquoi ; le score ordonne les adresses au sein d'un même statut. Point crucial : chaque verdict est livré avec ses preuves — le fournisseur MX, le détail du sondage — de sorte que le chiffre est auditable plutôt qu'une boîte noire.

Ce que les huit étapes ne peuvent toujours pas vous dire#

Un pipeline aussi minutieux peut donner l'impression qu'il devrait produire un oui ou un non net pour chaque adresse. Ce n'est pas le cas, et il vaut la peine d'énoncer clairement ces limites honnêtes :

• Un domaine fourre-tout plafonne la certitude à « risky ». Lorsque l'étape 7 détecte un serveur qui accepte tout, le 250 de l'étape 6 n'a aucune valeur informative — la boîte aux lettres est inconfirmable, quel que soit le nombre d'étapes exécutées. Aucun vérificateur ne résout cela sans envoyer de message, et tout outil qui prétend le contraire ne fait que deviner.
• Un serveur pratiquant le greylisting ou la limitation de débit peut imposer un unknown. Si l'étape 6 n'obtient jamais qu'un report 4xx dans le temps imparti, le verdict honnête est unknown — réessayer plus tard — et non un valide ou invalide fabriqué de toutes pièces.
• La vérification est un instantané. Une adresse confirmée distribuable aujourd'hui peut se dégrader demain, quand quelqu'un quitte un poste ou abandonne une boîte de réception. C'est pourquoi il importe de nettoyer à nouveau avant les envois majeurs, et pourquoi un taux de rebond qui grimpe est un signal qu'il faut vérifier de nouveau.
• L'engagement est la seule chose que la vérification ne peut pas mesurer. Une adresse distribuable qui n'ouvre jamais rien est un handicap de distribuabilité que le pipeline ne peut pas voir. La vérification vous dit qu'une adresse peut recevoir du courrier, pas que son titulaire veut le vôtre.

Aucune de ces limites n'est un défaut du pipeline — ce sont les frontières de ce que toute vérification peut savoir. L'outil dont il faut se méfier est celui qui feint que ces frontières n'existent pas.

Pourquoi le vérificateur gratuit s'arrête à l'étape 5#

Notre vérificateur d'e-mails gratuit exécute les étapes 1 à 5 — les étapes locales — et s'arrête délibérément avant le sondage SMTP. Ce n'est pas une version bridée du produit ; c'est une frontière honnête. Les étapes 1 à 5 peuvent écarter une adresse (mauvaise syntaxe, aucune route de courrier, jetable, faute de frappe évidente), mais elles ne peuvent pas confirmer une boîte aux lettres ni détecter un domaine fourre-tout, car cela exige d'ouvrir une véritable conversation SMTP depuis une IP réputée. Tout outil gratuit dans le navigateur qui prétend confirmer des boîtes aux lettres actives soit n'exécute pas l'étape 6, soit n'est pas honnête à ce sujet. Le compromis entre version complète et version gratuite a sa propre analyse.

Foire aux questions#

La vérification d'un e-mail lui envoie-t-elle un message ?#

Non. Le sondage SMTP de l'étape 6 déroule la conversation de distribution jusqu'au point où le serveur accepte ou rejette le destinataire, puis se déconnecte sans émettre la commande DATA qui transmettrait un message. Le titulaire de la boîte aux lettres ne voit rien. Envoyer un vrai e-mail « de test » pour vérifier la validité est précisément la mauvaise pratique qu'une vérification correcte évite.

Pourquoi la vérification ne peut-elle pas simplement être instantanée ?#

Les étapes 1 à 5 sont instantanées parce qu'elles sont locales. L'étape 6 nécessite une conversation réseau avec un serveur de messagerie tiers que vous ne contrôlez pas — un serveur susceptible de vous faire du greylisting, de vous limiter en débit ou de répondre lentement à dessein. Cet aller-retour est le prix d'une vraie réponse, ce qui explique pourquoi les traitements en masse s'exécutent de manière asynchrone plutôt que de bloquer sur chaque adresse.

Quelle est la différence entre le statut et le score ?#

Le statut (deliverable | risky | undeliverable | unknown) est la décision ; le score (0 à 100) ordonne les adresses au sein d'un même statut afin que vous puissiez les prioriser. Une adresse distribuable chez un fournisseur gratuit obtient un score différent d'une adresse sur un domaine d'entreprise, mais les deux sont distribuables. Servez-vous du statut pour décider, du score pour trier.

Quelles étapes l'API expose-t-elle ?#

Toutes. Un résultat de vérification renvoie le statut final et le motif, ainsi que les sous-indicateurs (catch-all, disposable, role, free, full-mailbox) et la suggestion « vouliez-vous dire », de sorte que votre propre code puisse agir sur les preuves plutôt que sur le seul verdict. Consultez la documentation développeur, et — si vous choisissez entre plusieurs fournisseurs — la comparaison des API de vérification d'e-mails.