Comment vérifier une adresse e-mail avant d’envoyer

Un e-mail qui rebondit vous apprend quelque chose que vous auriez souvent pu savoir avant d’envoyer : que l’adresse n’existe pas. Pour la prospection à froid, où les adresses proviennent de sites web, d’annuaires et de cartes de visite plutôt que de formulaires d’inscription, une partie de toute liste sera périmée.

Ce guide s’adresse à toute personne sur le point d’écrire à une liste qu’elle n’a pas constituée par inscription volontaire (opt-in) : équipes commerciales, fondateurs, agences. Nous (Outreach) expliquons les trois vérifications qui indiquent si une adresse peut recevoir des e-mails, les cas où ces vérifications cessent de fonctionner et la façon de lire les codes de rebond que vous obtenez lorsqu’un message échoue malgré tout.

La réponse courte d’emblée : vous pouvez généralement confirmer qu’une adresse existe sans lui envoyer d’e-mail, mais pas toujours, et savoir quand vous ne pouvez pas savoir est aussi utile que la réponse elle-même.

Pourquoi vérifier les adresses e-mail avant d’envoyer ?

Parce que les fournisseurs de messagerie demandent aux expéditeurs de retirer les adresses invalides, et que chaque rebond est un message qui n’a atteint personne. Les bonnes pratiques du Sender Hub de Yahoo disent : « Retirez rapidement de votre liste les destinataires invalides ». Les consignes pour les expéditeurs de messages de Google demandent de « désabonner automatiquement les destinataires dont l’adresse e-mail a rejeté vos messages plusieurs fois » et, si les messages renvoient un avis de non-distribution ou sont différés, de « réduire le volume d’envoi jusqu’à ce que le taux d’erreur SMTP diminue ».

En clair : les fournisseurs surveillent la façon dont vous traitez les mauvaises adresses. Vérifier avant d’envoyer, c’est moins de rebonds à gérer ensuite, et une image plus nette du nombre de vraies personnes que votre campagne a atteintes.

Quelles sont les étapes pour vérifier une adresse e-mail ?

Trois vérifications, dans l’ordre : l’adresse est-elle bien formée, son domaine a-t-il un serveur de messagerie, et ce serveur indique-t-il que la boîte aux lettres existe ? Chaque étape détecte des problèmes que la précédente ne peut pas détecter.

Un résultat positif à l’étape 3 est le signal le plus fort que vous puissiez obtenir sans envoyer. Mais, comme nous le verrons, certains serveurs donnent la même réponse pour toutes les adresses, réelles ou non.

Comment vérifier la syntaxe d’une adresse e-mail ?

Vérifiez qu’il y a exactement un @, une partie valide avant lui et un vrai domaine après lui, dans les limites de longueur de la norme SMTP. La RFC 5321 fixe à 64 octets « la longueur totale maximale d’un nom d’utilisateur ou d’une autre partie locale » (la partie avant le @), et la longueur maximale d’un domaine à 255 octets.

Les vérifications de syntaxe détectent l’évident : sales@@example.com, info@example, un espace final copié depuis une page web, ou une virgule saisie à la place d’un point. Elles sont peu coûteuses et instantanées, donc lancez-les toujours en premier. Elles ne peuvent pas vous dire si quelqu’un se trouve derrière l’adresse. jane.doe@example.com est parfaitement formée, que Jane travaille là ou non.

Comment fonctionne une recherche MX ?

Elle demande au DNS quel serveur reçoit le courrier du domaine ; s’il n’y en a pas, aucune adresse de ce domaine ne peut recevoir d’e-mail. L’enregistrement MX (mail exchanger, c’est-à-dire serveur d’échange de courrier) désigne le serveur qui accepte le courrier d’un domaine. Le consulter vous indique si le domaine est bel et bien configuré pour recevoir des e-mails.

Trois issues possibles, selon les normes :

• Enregistrements MX trouvés. Le domaine a un serveur de messagerie : passez à l’étape 3.
• Le domaine n’existe pas. La RFC 5321 indique : « Si une erreur de domaine inexistant est renvoyée, cette situation DOIT être signalée comme une erreur ». L’adresse est morte.
• Pas d’enregistrement MX, mais le domaine existe. La RFC 5321 indique que l’adresse « est traitée comme si elle était associée à un MX implicite » : le courrier est envoyé à l’enregistrement d’adresse du domaine lui-même. Un MX absent n’est donc pas automatiquement une impasse.

Il existe aussi un signal explicite « nous n’acceptons aucun courrier ». La RFC 7505 définit un « null MX », c’est-à-dire un enregistrement MX unique de priorité 0 avec un simple point (.) comme nom de serveur, qui « fera échouer immédiatement toutes les tentatives de remise du courrier à un domaine ». Si vous le voyez, arrêtez-vous : le domaine a déclaré qu’il ne reçoit pas d’e-mails.

Comment fonctionne une vérification SMTP de la boîte aux lettres sans envoyer d’e-mail ?

Le vérificateur se connecte au serveur de messagerie du domaine et amorce une remise, nomme le destinataire, lit la réponse du serveur, puis se déconnecte avant d’envoyer le moindre contenu de message. En termes SMTP : connexion, EHLO, MAIL FROM, RCPT TO:<address>, lecture du code de réponse, puis QUIT ; l’étape DATA, où irait le message lui-même, n’a jamais lieu.

La réponse à RCPT TO est ce qui compte. La RFC 5321 définit les codes :

Pourquoi ne pas simplement interroger directement le serveur avec la commande VRFY ? Parce que les serveurs ont le droit de la désactiver. La section 7.3 de la RFC 5321 autorise les sites à désactiver VRFY pour des raisons de sécurité, et précise qu’un serveur qui le fait « DOIT renvoyer une réponse 252 », c’est-à-dire une réponse qui ne veut dire ni oui ni non. C’est pourquoi les vérificateurs passent plutôt par la voie RCPT TO.

Lors de nos propres tests de septembre 2026, la méthode RCPT a correctement identifié les 6 adresses d’un petit ensemble connu : 3 adresses dont nous savions qu’elles avaient rebondi, 2 adresses fonctionnelles et 1 sur un domaine catch-all que nous avons correctement marquée comme impossible à confirmer.

Qu’est-ce qu’un domaine catch-all, et pourquoi ne peut-il pas être vérifié ?

Un domaine catch-all accepte le courrier pour n’importe quelle adresse, réelle ou inventée ; son serveur répond donc « 250 OK » pour chaque destinataire, et une vérification avant envoi n’apprend rien. Certaines entreprises configurent ainsi leur messagerie pour que les adresses mal orthographiées parviennent quand même à quelqu’un. D’autres utilisent des passerelles qui acceptent tout d’abord et trient ensuite.

On détecte un catch-all en interrogeant le serveur sur une adresse qui n’existe presque certainement pas, par exemple une longue chaîne aléatoire sur le même domaine. Si le serveur l’accepte aussi, chacun de ses « oui » ne signifie rien.

Est-ce fréquent ? Lors d’un test de septembre 2026, nous (Outreach) avons envoyé des vérifications RCPT avec des adresses inventées à 25 domaines de messagerie tirés de 200 contacts d’entreprises que nous avions collectés (principalement des sociétés coréennes). Environ 74 % des domaines ont répondu honnêtement et rejeté la fausse adresse ; environ 25 % l’ont acceptée, c’est-à-dire qu’ils étaient catch-all. Considérez cela comme un échantillon d’un seul marché, et non comme un taux universel. L’essentiel est que ce n’est pas rare.

Pour les adresses d’un domaine catch-all, le résultat honnête est « impossible à vérifier ». Envoyer est le seul moyen de le savoir, et c’est une question de jugement : une adresse publiée sur le site web de l’entreprise elle-même est un meilleur pari qu’une adresse devinée à partir d’un modèle de nom.

Pourquoi certains serveurs de messagerie refusent-ils les vérifications ?

Certains serveurs de messagerie limitent les personnes autorisées à les interroger sur les destinataires ; au lieu de répondre, ils temporisent, rejettent temporairement ou coupent la connexion. Les refus ressemblent généralement à ceci :

• Une réponse temporaire 4xx pour chaque destinataire, qui vous demande de réessayer plus tard.
• Une réponse 5xx qui renvoie à une politique ou à une réputation plutôt qu’à la boîte aux lettres, par exemple un code étendu 5.7.1, que la RFC 3463 décrit comme « Remise non autorisée, message refusé ».
• Aucune réponse du tout, ou une connexion coupée.

Aucune de ces réponses ne vous dit si la boîte aux lettres existe. Un bon vérificateur les signale comme « inconnu » et non comme « invalide » : marquer une vraie adresse comme morte parce que son serveur était prudent ferait perdre un bon contact.

Certains hébergeurs bloquent aussi les connexions sortantes sur le port 25, le port SMTP, ce qui signifie qu’un vérificateur qui y fonctionne ne peut joindre aucun serveur de messagerie. Là encore, la bonne réponse dans ce cas est « impossible à vérifier » et non « n’existe pas ».

Comment lire les codes de rebond après l’envoi ?

Regardez le premier chiffre du code d’état étendu : 5 signifie permanent, 4 signifie temporaire. Le chiffre du milieu indique ensuite de quel type de problème il s’agit. La RFC 3463 définit des codes de la forme class.subject.detail :

• 5.x.x — Échec permanent : « peu susceptible d’être résolu en renvoyant le message sous sa forme actuelle ».
• 4.x.x — Échec transitoire persistant : « un envoi ultérieur peut aboutir ».

Les codes que vous verrez le plus souvent lorsque le problème vient d’une adresse :

Cette dernière ligne compte. Un code 5.7.x signifie généralement que le serveur de réception vous a refusé, et non que la boîte aux lettres est introuvable. Vérifiez votre configuration SPF, DKIM et DMARC avant de supprimer le contact.

Comment vérifier gratuitement une seule adresse ?

Saisissez-la dans notre vérificateur d’adresses e-mail gratuit ; il effectue les vérifications de syntaxe, de MX et de boîte aux lettres, et vous donne l’une de trois réponses. Aucune inscription n’est nécessaire. Le vérificateur est disponible en anglais et en coréen ; saisissez l’adresse que vous voulez vérifier. Le résultat est l’un des suivants :

• Peut recevoir des e-mails : le serveur de messagerie a accepté le destinataire.
• N’existe pas : l’adresse n’est pas bien formée, le domaine n’a pas de serveur de messagerie, ou le serveur a indiqué qu’il n’existe pas de telle boîte aux lettres.
• Impossible à vérifier : le domaine est catch-all, le serveur a refusé la vérification, ou aucune vérification n’a été possible. L’outil vous indique quelle raison s’est appliquée.

Pour éviter que l’outil serve à des sondages en masse, il autorise un nombre limité de vérifications par jour. Pour une liste entière, vérifiez dans votre processus d’envoi plutôt qu’une adresse à la fois.

Que faire des adresses impossibles à vérifier ?

Gardez-les à part, envoyez-leur par lots plus petits et retirez celles qui rebondissent avec un code 5.x.x. Un ordre pratique :

1. Écartez tout ce qui échoue à la vérification de syntaxe ou n’a pas de serveur de messagerie.
2. Retirez les adresses dont le serveur a dit qu’elles n’existent pas.
3. Envoyez d’abord aux adresses confirmées.
4. Envoyez avec plus de prudence aux adresses « impossibles à vérifier », et retirez celles qui reviennent avec un rebond permanent, comme le conseillent Yahoo et Google.

N’oubliez pas non plus qu’une adresse valide ne signifie pas un destinataire consentant. Les plaintes pour spam jouent contre vous, que l’adresse existe ou non ; nous donnons les chiffres dans pourquoi les e-mails de prospection atterrissent dans les spams.

En bref

• Vérifiez en trois étapes : syntaxe → recherche MX → vérification SMTP de la boîte aux lettres (RCPT, sans envoyer de contenu).
• La partie avant le @ peut comporter au plus 64 caractères (RFC 5321) ; un null MX signifie que le domaine n’accepte aucun courrier (RFC 7505).
• Les domaines catch-all acceptent toutes les adresses (dans notre test sur 25 domaines, environ 25 % l’ont fait), donc certaines adresses ne peuvent être marquées que « impossibles à vérifier ».
• Dans les rebonds, 5.x.x est permanent et 4.x.x temporaire ; 5.1.1 signifie que la boîte aux lettres n’existe pas ; 5.7.x indique un problème de politique, et non une mauvaise adresse.
• Essayez une seule adresse avec notre vérificateur d’e-mails gratuit.