Comment vérifier si une adresse email est valide sans rien envoyer

Vous pouvez déterminer si une adresse email existe sans rien lui envoyer. La méthode n'a rien d'une astuce : c'est la conversation de livraison ordinaire du courrier, interrompue une étape avant la livraison.

Voici les quatre vérifications, dans l'ordre où elles doivent s'exécuter, et ce que chacune peut réellement prouver.

1. La syntaxe

L'adresse respecte-t-elle les règles d'une adresse email ? Cette étape repère les fautes de frappe, les @ manquants et les caractères invalides.

Elle est gratuite et instantanée, et elle ne prouve presque rien. asdkjhaslkdjh@gmail.com a une syntaxe parfaitement valide et n'est certainement pas une vraie boîte mail. Un outil qui s'arrête là n'est qu'un correcteur orthographique.

2. Le domaine et les enregistrements MX

Tout domaine qui reçoit du courrier publie des enregistrements MX dans le DNS, qui désignent les serveurs acceptant le courrier pour lui. Si un domaine n'en a aucun, il ne peut pas recevoir d'email et toutes ses adresses sont mortes.

Vous pouvez le vérifier à la main :

$ dig +short MX gmail.com
5 gmail-smtp-in.l.google.com.
10 alt1.gmail-smtp-in.l.google.com.

Pas d'enregistrement MX et pas d'enregistrement A de repli : le domaine ne peut pas recevoir de courrier. La RFC 5321 prévoit qu'un expéditeur se rabat sur l'enregistrement A du domaine en l'absence de MX ; un MX manquant est donc un signal fort, pas une preuve. Un null MX (MX 0 .), lui, est définitif : le domaine a déclaré qu'il n'accepte aucun courrier. Dans tous les cas, c'est la vérification la moins coûteuse qui soit, et elle repère les domaines mal orthographiés ou abandonnés.

3. Adresses jetables et adresses de rôle

Deux choses à savoir avant d'envoyer quoi que ce soit :

Les domaines jetables (Mailinator, Guerrilla Mail et des milliers d'autres) sont des boîtes de réception à usage unique. Techniquement, la boîte existe, mais la personne derrière ne verra jamais le message.

Les adresses de rôle (info@, sales@, admin@) sont lues par plusieurs personnes ou par personne, attirent les plaintes pour spam et sont parfois recyclées en pièges à spam (spam traps).

Ni l'une ni l'autre n'est un échec bloquant. Ce sont des décisions à prendre délibérément, plutôt qu'à découvrir après coup.

4. La vérification SMTP de la boîte mail

C'est elle qui répond vraiment à la question.

Vous vous connectez au serveur de messagerie du domaine et entamez la conversation que vous auriez si vous livriez un message, puis vous vous arrêtez avant d'envoyer quoi que ce soit :

$ telnet gmail-smtp-in.l.google.com 25

> HELO yourdomain.com
< 250 mx.google.com at your service

> MAIL FROM: <you@yourdomain.com>
< 250 2.1.0 OK

> RCPT TO: <someone@gmail.com>
< 250 2.1.5 OK                    ← la boîte mail existe

Si la boîte n'existe pas :

> RCPT TO: <definitely-not-real-xyz9987661@gmail.com>
< 550-5.1.1 The email account that you tried to reach does not exist

Puis QUIT. Aucun message n'est envoyé, et rien n'apparaît dans la boîte de réception de qui que ce soit. La commande DATA, celle qui transmet réellement un message, n'est jamais émise.

Cette différence entre 250 et 550, c'est toute la vérification d'email.

Pourquoi vous ne pouvez probablement pas le faire vous-même

Lancez cette commande telnet depuis votre ordinateur portable et elle restera très probablement bloquée. Presque tous les fournisseurs d'accès à Internet grand public et les fournisseurs cloud bloquent le port 25 sortant pour lutter contre le spam. Nous l'avons mesuré chez deux grands hébergeurs :

Hébergeur	Port 25 sortant
Railway	Bloqué
DigitalOcean	Bloqué

C'est la seule raison pour laquelle la vérification d'email existe en tant que service payant. La vérification elle-même est simple ; le plus difficile, c'est d'être sur un réseau autorisé à la faire, depuis une IP à la réputation propre et avec un DNS inverse cohérent.

C'est aussi bon à savoir à cause de la façon dont certains outils gèrent la situation. Si la vérification SMTP d'un outil échoue et que le code se rabat sur le statut valid (valide), alors toutes les adresses d'un domaine actif passent et rien n'a réellement été vérifié. Nous connaissons ce défaut de près : notre propre moteur le faisait jusqu'à ce que nous le découvrions.

Ce à quoi on ne peut pas répondre

Deux cas mettent la méthode complètement en échec :

Les domaines catch-all acceptent toutes les adresses du domaine, réelles ou non. L'acceptation ne prouve rien, donc rien ne peut être confirmé. Nous en parlons ici.

Les fournisseurs qui ne répondent pas clairement. Yahoo et iCloud refusent souvent de confirmer ou d'infirmer l'existence d'une boîte à l'étape RCPT, si bien que le test n'est pas concluant. Outlook.com et Microsoft 365, à l'inverse, rejettent les destinataires inconnus pendant la conversation.

Un outil de vérification honnête classe ces deux cas en risky (risqué). Un outil qui les classe en valid devine, en espérant que vous ne vérifierez jamais.

En résumé

1. Syntaxe : repère les fautes de frappe, prouve peu de choses
2. Enregistrements MX : indiquent si un domaine peut recevoir du courrier
3. Indicateurs jetable et rôle : des décisions, pas des échecs
4. Vérification SMTP de la boîte : la vraie réponse, quand le réseau le permet

Tout ce qui ne peut pas être établi doit ressortir en risky. Les outils qui valent leur prix sont ceux qui acceptent de vous dire quand ils ne savent pas.