Vérifier une adresse e-mail sans envoyer d’e-mail : la méthode et ses limites

On peut savoir si une adresse e-mail existe sans envoyer le moindre message. La vérification enchaîne trois contrôles : la syntaxe de l’adresse, le domaine et ses serveurs de messagerie, puis un dialogue avec le serveur qui s’arrête juste avant l’envoi. Le serveur indique alors s’il accepterait cette boîte, ou non.

La réponse est fiable pour beaucoup de domaines, pas pour tous. Certains serveurs acceptent toutes les adresses, d’autres ne répondent pas du premier coup. Voici comment fonctionne chaque contrôle, et comment lire les résultats.

Les trois niveaux de vérification

Niveau 1 : la syntaxe

Une adresse e-mail a une forme précise : une partie locale, un @, puis un domaine. Les règles sont fixées par les standards de l’Internet : la RFC 5322 pour le format des messages, la RFC 5321 pour leur transport. Cette dernière limite par exemple la partie locale à 64 octets et le nom de domaine à 255.

Les erreurs les plus fréquentes dans un fichier de prospection :

• Les restes de copier-coller : un espace, un mailto:, une virgule, ou le point final d’une phrase collé à l’adresse.
• Les fautes de frappe dans le domaine : gmial.com au lieu de gmail.com, une extension oubliée ou tronquée.
• Les caractères accentués : les adresses internationalisées existent (RFC 6531), mais beaucoup de systèmes ne les acceptent pas. Dans un fichier B2B français, un « é » dans une adresse est plus souvent une faute de saisie qu’un vrai choix.

Une adresse de rôle (contact@, info@) n’est pas une erreur : c’est souvent la bonne adresse pour une petite entreprise.

Niveau 2 : le domaine et ses serveurs MX

Pour recevoir des e-mails, un domaine publie dans le DNS des enregistrements MX, qui désignent ses serveurs de messagerie. Ce contrôle répond à trois questions :

• Le domaine existe-t-il ? Un domaine expiré, fréquent après la fermeture d’une entreprise ou un changement de nom, rend toutes ses adresses invalides.
• Reçoit-il des e-mails ? Sans enregistrement MX, la norme prévoit de se rabattre sur l’adresse du domaine lui-même (RFC 5321, section 5.1). À l’inverse, un « MX nul » (RFC 7505) déclare explicitement que le domaine n’accepte aucun e-mail.
• Vers quels serveurs ? Leur nom indique souvent l’hébergeur de la messagerie, utile pour interpréter la suite.

Pour un seul domaine, la commande nslookup avec l’option -type=mx affiche ses serveurs MX. Ce contrôle ne dit rien d’une boîte précise : contact@ peut avoir été supprimée sur un domaine parfaitement actif.

Niveau 3 : le dialogue SMTP, arrêté avant l’envoi

C’est le contrôle décisif. L’envoi d’un e-mail suit un dialogue normalisé entre serveurs, le protocole SMTP. La vérification en joue le début, puis s’arrête avant de transmettre quoi que ce soit :

1. Connexion au serveur MX du domaine.
2. Présentation (EHLO) : le vérificateur s’identifie.
3. Expéditeur (MAIL FROM) : il déclare une adresse d’envoi.
4. Destinataire (RCPT TO) : il annonce l’adresse à vérifier, et le serveur répond par un code.
5. Fin (QUIT) : il se déconnecte sans passer à l’étape DATA, celle qui transmet le contenu du message.

L’étape DATA n’ayant jamais lieu, aucun message n’est transmis : rien n’arrive dans la boîte vérifiée. Tout se joue sur la réponse à l’étape 4 :

La commande VRFY, prévue par la norme pour vérifier une adresse, existe toujours. Mais de nombreux serveurs la désactivent pour empêcher la collecte d’adresses, un choix que la RFC 5321 autorise. D’où le recours à RCPT TO.

Pourquoi ne pas le faire vous-même à grande échelle

Techniquement, rien de secret. En pratique, c’est une mauvaise idée depuis votre propre connexion :

• beaucoup de fournisseurs d’accès bloquent le port 25 en sortie sur les connexions grand public ;
• les serveurs de messagerie limitent ou bloquent les adresses IP qui enchaînent les vérifications ;
• une IP repérée peut finir sur une liste de blocage, et vos vrais e-mails en pâtissent si elle sert aussi à l’envoi.

Un service de vérification répartit la charge, respecte les limites des serveurs et interprète les réponses ambiguës. C’est son métier.

Pourquoi certaines réponses restent incertaines

Les domaines catch-all

Un serveur catch-all accepte toutes les adresses de son domaine, qu’elles existent ou non : il répond 250 à tout. Pour le détecter, on teste d’abord une adresse inventée, qui n’a aucune chance d’exister. Si le serveur l’accepte, il accepte tout, et l’adresse réelle ne peut pas être confirmée. Le message sera peut-être distribué, peut-être rejeté plus tard, peut-être rangé à part.

Le greylisting

Certains serveurs refusent temporairement (code 4xx) un expéditeur qu’ils ne connaissent pas encore, en comptant sur le fait qu’un vrai serveur d’envoi réessaiera plus tard (RFC 6647). Une vérification unique tombe sur ce refus et ne peut pas conclure. C’est le cas typique d’une adresse « inconnue » qui devient valide à la seconde tentative.

Les protections contre la collecte d’adresses

Pour empêcher qu’on devine leurs adresses, certains serveurs ralentissent volontairement leurs réponses, limitent le nombre de destinataires testés ou répondent de la même façon à toutes les adresses après quelques essais. Le résultat devient ininterprétable.

L’acceptation suivie d’un rebond

Enfin, un serveur peut accepter l’adresse pendant le dialogue, puis rejeter le message plus tard, par exemple quand la distribution finale passe par un autre système interne. Une adresse « valide » réduit le risque de rebond, sans l’annuler.

Les quatre verdicts et ce qu’il faut en faire

Pour les adresses catch-all, privilégiez celles qui sont publiées sur le site de l’entreprise (contact@, une adresse nominative affichée) plutôt qu’une adresse devinée : la publication est un indice d’existence.

Quand revérifier une adresse

Une vérification est une photo, pas une garantie permanente. Les boîtes ferment quand un salarié part ou qu’une entreprise change de domaine. Quelques repères :

• Avant chaque campagne, si la dernière vérification date de plusieurs semaines. C’est une règle de prudence, pas une norme.
• Pour les adresses inconnues, quelques heures ou quelques jours plus tard : le greylisting et les pannes passagères se résolvent souvent d’eux-mêmes.
• Après chaque rebond définitif : retirez l’adresse, et revérifiez les autres adresses du domaine si plusieurs d’entre elles rebondissent.

Une règle empirique courante veut que les rebonds définitifs restent sous 2 % d’une campagne. Des rebonds nombreux signalent aux messageries une liste mal tenue, et pèsent sur la réputation du domaine d’envoi. Côté plaintes, les seuils sont officiels : Google demande de garder le taux de spam mesuré dans Postmaster Tools sous 0,3 %, et Yahoo publie des exigences comparables.

La vérification répond aussi à une obligation légale : le RGPD exige que les données personnelles soient exactes et, si nécessaire, tenues à jour (article 5). Retirer les adresses mortes fait partie de ce travail.

Les méthodes à éviter

• Envoyer un e-mail « test » : c’est un envoi, avec les rebonds qui vont avec.
• Détourner la procédure « mot de passe oublié » d’un webmail pour savoir si un compte existe : c’est un usage abusif du service, à proscrire.
• Deviner des dizaines de combinaisons prénom.nom et garder celle qui passe : le résultat ne vaut rien sur un domaine catch-all, et cette collecte à l’aveugle se concilie mal avec le principe de minimisation du RGPD.
• Se fier à l’ouverture d’un e-mail : de nombreuses messageries bloquent ou préchargent les pixels de suivi, qui ne prouvent donc pas grand-chose.

Ce que fait Glintscout

Dans Glintscout, la vérification suit la recherche des entreprises et de leurs e-mails, par exemple après une recherche Google Maps. Elle contacte le serveur de messagerie sans envoyer d’e-mail et donne à chaque adresse l’un des quatre verdicts : valide, invalide, catch-all ou inconnue. Une seconde vérification facultative revérifie les adresses inconnues, et seules les adresses valides arrivent dans le CSV. Le prix s’affiche avant de lancer la vérification, et les crédits du travail non livré vous reviennent : le détail est sur la page Tarifs.

La vérification n’est qu’une étape d’une méthode plus large, décrite dans notre guide pour créer un fichier de prospection B2B par ville et par secteur et dans celui pour extraire les entreprises de Google Maps avec leurs e-mails.

FAQ

La personne est-elle prévenue quand on vérifie son adresse ?

Non. Aucun message n’est transmis et rien n’arrive dans sa boîte. Le serveur de messagerie peut toutefois garder une trace de la connexion dans ses journaux, que son administrateur peut consulter.

Une adresse « valide » peut-elle quand même rebondir ?

Oui, c’est possible : la boîte peut fermer après la vérification, ou le serveur peut accepter pendant le dialogue puis rejeter le message. Envoyer peu après la vérification limite ce risque.

Pourquoi une adresse est-elle « inconnue » ?

Le serveur n’a pas donné de réponse exploitable : délai dépassé, refus temporaire lié au greylisting, protection contre la collecte ou panne. Une nouvelle vérification quelques heures plus tard permet souvent de trancher.

Faut-il écrire aux adresses catch-all ?

Pas dans vos envois principaux. Si le segment compte pour vous, testez un petit lot, surveillez les rebonds et ne continuez que si le résultat est propre. Commencez par les adresses catch-all publiées sur le site de l’entreprise.

Vérifier une adresse e-mail est-il compatible avec le RGPD ?

La vérification est un traitement de données dès que l’adresse identifie une personne. Elle sert le principe d’exactitude du RGPD, mais ne rend pas la prospection licite à elle seule : les règles de la prospection B2B par e-mail s’appliquent toujours.