Vérifier une adresse n’envoie aucun message : la session SMTP s’arrête avant la commande DATA, celle qui transmet le contenu (RFC 5321, section 4.1.1.4). Cette mécanique, mal connue, explique la plupart des idées reçues sur la vérification d’emails, qu’on lui prête trop de pouvoirs ou des intrusions qu’elle ne commet pas.
Son effet le mieux établi porte sur le hard bounce : elle écarte les adresses inexistantes avant l’envoi. Elle ne touche ni aux plaintes spam ni à l’engagement. Les 9 idées reçues ci-dessous se règlent chacune par un seuil publié ou par le fonctionnement du protocole SMTP.
Vérification et validation : le périmètre en quelques lignes
La validation contrôle la forme d’une adresse : un « @ », un domaine, une syntaxe conforme à la RFC 5322. La vérification interroge ensuite le domaine, via son enregistrement MX, puis le serveur de messagerie lui-même et signale les adresses jetables. Le détail des étapes se trouve dans l’article sur la différence entre validation et vérification.
9 idées reçues sur la vérification d’emails, passées au crible
Une adresse vérifiée est-elle une adresse sans risque ?
Non. Un vérificateur range les adresses en catégories (valide, invalide, catch-all, risquée) parce qu’un « valide » ne couvre pas tous les cas. Les adresses jetables en sont un : la boîte existe et répond le jour du test, puis elle est abandonnée. Les services les repèrent grâce à des listes de domaines jetables, comparées dans l’article sur les adresses email jetables. Le piège à spam est le cas le plus sournois : tenu par un fournisseur de messagerie ou un organisme antispam, il accepte le courrier. Le test SMTP le voit donc comme une boîte ordinaire. La documentation d’Amazon SES précise que ces pièges peuvent être d’anciennes adresses valides, abandonnées après une longue période de rebonds.
Peut-on vérifier une boîte sans lui envoyer d’email ?
Oui. Une transaction SMTP compte 3 commandes : MAIL FROM annonce l’expéditeur, RCPT TO désigne le destinataire, DATA transmet le contenu du message (RFC 5321, section 3.3). Le serveur répond à RCPT TO avant que DATA n’existe ; un vérificateur s’arrête là et ferme la connexion. Le code 250 signifie « accepté », le 550 « boîte inconnue », un code en 4xx un refus temporaire à réessayer.
L’enregistrement MX indique où poser la question. La section 5.1 de la RFC 5321 prévoit qu’un domaine sans MX est traité comme s’il avait un MX implicite pointant vers son propre hôte. L’absence de MX reste donc un signal à croiser avec le reste. Ce mécanisme a une faille connue, développée plus bas : certains domaines répondent 250 à tout.
La vérification est-elle invasive ?
Le contenu reste hors de portée : aucun message n’est transmis ni lu, puisque la session s’arrête avant DATA. Reste la question du RGPD : une adresse nominative demeure une donnée personnelle. La CNIL fixe les règles au moment de la prospection. Elle exige un consentement préalable en B2C et un droit d’opposition en B2B. Elle recommande de les recueillir par une case décochée par défaut (la case précochée est interdite). Chaque sollicitation doit identifier l’organisation émettrice et offrir un refus simple (page de la CNIL sur la prospection par courrier électronique, mise à jour le 10 juin 2026).
Le catch-all prouve-t-il que l’adresse existe ?
Non. Un domaine catch-all accepte le courrier adressé à n’importe quel nom devant l’arobase : jean.dupont@ et azertyuiop@ obtiennent le même 250 à la commande RCPT TO.
Aucune méthode ne tranche à coup sûr : le sort du message, rangé dans une vraie boîte ou jeté, dépend de la configuration du domaine. Les services sérieux rangent ces adresses en risky (« accept-all » chez certains), ce qui exprime une incertitude réelle. Un lot test envoyé à ce segment, avec relevé du hard bounce avant d’étendre, vaut mieux qu’un tri à l’aveugle.
Un outil gratuit ou une simple syntaxe suffisent-ils ?
Non. « gmial.com » respecte toutes les règles de syntaxe. Le contrôle suivant, l’enregistrement MX, élimine les domaines inexistants sans arrêter un domaine réel où la boîte n’existe pas. Seule la conversation SMTP interroge l’adresse elle-même. Un outil gratuit se juge donc sur la profondeur de son contrôle : syntaxe et domaine d’un côté, SMTP avec détection du catch-all de l’autre. La validation seule ne dit rien de l’état de la boîte de réception.
Les adresses vérifiées sont-elles toujours actives ?
Non. « Valide » signifie accepté par le serveur au moment du test. Une boîte peut rester des mois sans lecteur. Elle peut aussi saturer et renvoyer des soft bounces. Amazon SES recommande d’ailleurs de cesser l’envoi aux destinataires qui n’ouvrent ni ne cliquent : un contact inactif ne rebondit pas, il pèse sur l’engagement.
Une vérification par an suffit-elle ?
Aucun chiffre universel ne fixe le rythme. Il dépend de la vitesse de renouvellement de la base et du coût d’un rebond (seuils plus bas). Pour les contacts qu’on n’a pas écrits depuis longtemps, SES conseille de n’en inclure qu’une petite part dans chaque envoi. La page sur la fréquence de vérification d’une liste d’emails en détaille le rythme. Un double opt-in et une vérification à la saisie coupent la source des fautes de frappe dès l’entrée ; le nettoyage de la liste existante complète ces deux garde-fous.
La vérification assure-t-elle la délivrabilité ?
Non, elle agit sur une seule ligne du bilan. Pour les plaintes spam, Gmail fixe la règle depuis le 1er février 2024 pour tous les expéditeurs :
« Maintenez les taux de spam indiqués dans Postmaster Tools en dessous de 0,10 % et évitez d’atteindre un taux de spam de 0,30 % ou plus. »
Cette consigne figure dans les consignes de Google pour les expéditeurs, qui demandent SPF ou DKIM à tous les expéditeurs et ajoutent DMARC au-delà de 5 000 messages par jour vers Gmail. Un destinataire parfaitement valide qui clique sur « signaler comme spam » pèse sur la réputation d’expéditeur sans qu’aucune vérification puisse l’empêcher ; la définition du spam et les erreurs de délivrabilité couvrent cette moitié du dossier.
Côté rebonds, la même page d’Amazon SES donne une échelle lisible : sous 2 % de rebonds définitifs pour de bons résultats, mise en revue du compte dès 5 %, suspension possible dès 10 %. Les rebonds temporaires, comme une boîte pleine, n’entrent pas dans ce calcul.
Tous les services de vérification se valent-ils ?
Non. Les services divergent sur le sort des adresses catch-all, sur la fraîcheur de leurs listes de domaines jetables et sur la finesse de leurs statuts. Un service qui ne renvoie que « valide » ou « invalide » masque la catégorie la plus incertaine, celle des catch-all. Le test le plus parlant tient en quelques minutes : soumettre quelques centaines d’adresses dont on connaît déjà le sort, puis comparer les statuts rendus. L’échantillon mêle des boîtes internes actives, des adresses inventées sur des domaines réels et un domaine catch-all identifié.
Ce qu’une liste vérifiée laisse hors champ
Le test ne mesure ni le contenu du message ni le consentement des destinataires. Il ne dit rien non plus de l’envie de lire. Un échantillon tiré du segment le plus ancien et passé dans Captain Verify avant la prochaine campagne fournit la part d’invalides de cette base, à rapprocher du seuil de 2 % de rebonds d’Amazon SES.
