Comment savoir si votre vérificateur d'email vous ment
La vérification d'email a un problème inhabituel : vous ne pouvez pas facilement savoir si elle a fonctionné.
Si un vérificateur vous dit qu'une adresse est valide et que vous lui envoyez un email, vous l'apprenez des semaines plus tard par votre taux de rebond. À ce stade, les dégâts — réputation d'expéditeur, délivrabilité, domaine grillé — sont déjà faits. Tous les outils du secteur affichent « 99 % de précision », et presque personne ne vérifie.
Voici un test qui prend environ une minute, et ce que nous avons découvert en le passant sur notre propre produit.
Le test
Inventez une adresse qui ne peut absolument pas exister, chez un fournisseur dont vous savez qu'il rejette les boîtes mail inconnues :
definitely-not-real-xyz9987661@gmail.com
Gmail rejette les destinataires inconnus au niveau SMTP avec une réponse 550. Ce n'est pas une supposition sur le comportement de Gmail — c'est observable, et c'est tout le mécanisme sur lequel repose la vérification.
Il n'y a donc qu'une seule bonne réponse : invalid (invalide).
Soumettez cette adresse à votre vérificateur. Si elle revient valide, l'outil n'a pas contrôlé la boîte mail. Il a regardé le domaine, vu gmail.com, et supposé.
Nous avons échoué à notre propre test
Nous avons construit ce produit. Quand nous avons passé cette adresse dans notre propre moteur, il a renvoyé :
definitely-not-real-xyz9987661@gmail.com → valid ("Verified")
Pas « risky ». Pas « unknown ». Verified (vérifiée).
Deux éléments de notre propre code en étaient la cause, et tous deux méritent d'être compris, car ce sont des erreurs faciles à commettre.
Le raccourci fournisseur. Le moteur contenait une liste des grands fournisseurs — Gmail, Yahoo, Outlook, iCloud, etc. — et renvoyait valid pour toute adresse correctement formée chez l'un d'eux, sans jamais ouvrir de connexion SMTP. Le raisonnement était que ces domaines acceptent forcément le courrier. C'est vrai du domaine, et cela ne dit rien de la boîte mail. Sur une liste grand public typique, ce seul raccourci valide d'office une grande partie de chaque fichier importé.
Le repli en cas d'échec. Lorsque le contrôle SMTP s'exécutait et échouait pour une raison quelconque — délai dépassé, port bloqué, connexion refusée — le code retombait sur valid par défaut, selon la logique qu'une syntaxe valide plus un serveur de messagerie valide signifient probablement une adresse réelle.
Le second compte plus qu'il n'y paraît, à cause de l'endroit où la vérification s'exécute généralement.
La plupart des hébergeurs cloud bloquent le port dont la vérification a besoin
Contrôler une boîte mail implique de se connecter au serveur de messagerie du destinataire sur le port 25. Presque tous les grands fournisseurs cloud bloquent par défaut le port 25 sortant pour freiner le spam. Nous l'avons mesuré chez deux d'entre eux :
| Hébergeur | Port 25 sortant |
|---|---|
| Railway | Bloqué |
| DigitalOcean | Bloqué |
Mettez ces deux faits ensemble. Si un vérificateur tourne sur une infrastructure qui bloque le port 25, et que son code répond valid par défaut quand le contrôle SMTP échoue, alors toutes les adresses d'un domaine actif reviennent valides — et l'outil n'a rien vérifié du tout tout en affichant une confiance totale.
Ce n'est pas un scénario d'échec théorique. C'est ce que faisait notre propre code jusqu'à ce que nous le corrigions.
À quoi ressemble un résultat honnête
La solution n'est pas un sondage plus astucieux. C'est d'accepter de dire « je ne sais pas ».
Un vérificateur devrait renvoyer trois états, et celui du milieu est le plus important :
- valid (valide) — un serveur de messagerie a confirmé que cette boîte mail existe
- invalid (invalide) — un serveur de messagerie l'a rejetée, le domaine n'a pas de serveur de messagerie, la syntaxe est incorrecte ou c'est une adresse jetable
- risky (risqué) — le contrôle n'a pas pu aboutir
Risky est la réponse honnête pour les cas réellement ambigus, et il y en a plusieurs :
Les domaines catch-all acceptent toutes les adresses du domaine, réelles ou non : anything@theirdomain.com reçoit donc une acceptation. La vérification ne peut pas y distinguer une vraie boîte mail d'une faute de frappe. Tout outil qui répond valid sur un domaine catch-all décrit la configuration du domaine, pas la boîte mail.
Les fournisseurs qui masquent l'état des boîtes mail. Certains grands fournisseurs grand public, dont Yahoo et iCloud, refusent de donner une réponse claire pour les destinataires inconnus à l'étape RCPT : un sondage chez eux est donc souvent non concluant. Microsoft ne fait pas partie de ce groupe : Outlook.com comme Microsoft 365 rejettent les destinataires inconnus pendant la conversation SMTP.
Les connexions bloquées ou refusées, comme expliqué ci-dessus.
Notre moteur renvoie désormais invalid pour cette adresse Gmail inventée, avec le motif Mailbox not found. Tout ce qu'il ne peut pas confirmer passe en risky, et jamais en valid.
Comment tester celui que vous utilisez
Préparez un petit fichier avec des adresses dont vous connaissez déjà la réponse :
- Une adresse inventée sur
gmail.com— doit être invalid - Votre propre adresse réelle — doit être valid
- Une chaîne sans
@— doit être invalid - Une adresse sur un domaine jetable comme
mailinator.com— devrait être invalid - Une adresse sur un domaine sans aucun serveur de messagerie — doit être invalid
- Une adresse générique comme
info@dans une vraie entreprise — devrait être signalée risky ou comme adresse générique (role-based)
Six lignes. Tout vérificateur qui mérite d'être payé obtient les six bonnes réponses, et c'est la première qui démasque les suppositions.
Si votre fournisseur renvoie valid sur la ligne 1, vous n'achetez pas de la vérification. Vous achetez un contrôleur de syntaxe au ton assuré — et vous découvrirez la différence par votre taux de rebond.
Pourquoi nous avons publié ceci
Il aurait été facile de corriger le bug discrètement. Nous l'avons documenté parce que le test est plus utile que la promesse : vous ne devriez pas nous croire sur parole quant à notre précision, pas plus que n'importe qui d'autre.
Passez les six lignes sur notre outil. Passez-les sur celui que vous utilisez aujourd'hui. Les résultats vous en diront plus que n'importe quel pourcentage de précision sur une page tarifaire.
Questions fréquentes
Comment tester la précision d'un vérificateur d'email ?
Inventez une adresse qui ne peut pas exister chez un grand fournisseur, par exemple une longue chaîne aléatoire sur gmail.com, et soumettez-la. Gmail rejette les boîtes mail inconnues au niveau SMTP : un vérificateur précis répond donc invalid. S'il répond valid, l'outil devine à partir du domaine au lieu de contrôler la boîte mail.
Pourquoi les vérificateurs d'email déclarent-ils valides des adresses inventées ?
Généralement pour l'une de ces trois raisons : l'outil fait confiance aux domaines connus et saute le contrôle de la boîte mail, sa propre connexion SMTP a échoué et il répond valid par défaut au lieu de unknown, ou le domaine est catch-all et accepte réellement toutes les adresses. Seule la troisième est honnête.
Que signifie réellement un résultat risky ?
Cela signifie que le vérificateur n'a pu confirmer la boîte mail ni dans un sens ni dans l'autre. Cela arrive sur les domaines catch-all, chez les fournisseurs qui masquent l'état des boîtes mail, et lorsque le serveur de vérification ne peut pas joindre le port 25. Risky est la bonne réponse dans ces cas, et bien plus utile qu'une supposition déguisée en vérification.
Une garantie de précision de 99 % veut-elle dire quelque chose ?
Pas à elle seule. Les promesses de précision sont rarement définies, rarement auditées, et généralement mesurées sur des listes qui excluent les cas difficiles. Une seule adresse inventée chez un fournisseur dont vous savez qu'il rejette les boîtes mail inconnues vous en apprend plus que le chiffre marketing.
Vérifiez un nombre illimité d’adresses pour 29,99 USD/mois
Vérification SMTP réelle de la boîte aux lettres. Sans crédits ni frais par e-mail.
Commencer