Résultats de vérification d'email : valid, invalid, risky et unknown

Tout vérificateur d'email classe les adresses en quatre grands résultats : valid (valide : le serveur de messagerie a confirmé la boîte mail), invalid (invalide : rejetée, pas de serveur de messagerie ou syntaxe incorrecte), risky (risquée : joignable mais impossible à confirmer, généralement un catch-all) et unknown (inconnue : aucune réponse exploitable). Les mots changent d'un éditeur à l'autre. Les décisions qui se cachent derrière, non, et c'est ce que ce guide met en correspondance.

Si vous avez déjà transféré une liste d'un outil à un autre et constaté que les colonnes ne concordaient pas, voici pourquoi. Nous avons lu la documentation des résultats de huit services de vérification le 1er octobre 2026 et aligné leurs libellés les uns en face des autres.

Les quatre résultats derrière chaque libellé

Chaque statut répond en réalité à une seule question : qu'a dit le serveur de messagerie du destinataire, s'il a dit quelque chose ? La vérification consiste à ouvrir une conversation SMTP avec le serveur et à l'interroger sur la boîte mail à l'étape RCPT TO, sans envoyer de message. Nous avons détaillé le mécanisme dans comment vérifier un email sans l'envoyer.

Résultat	Ce qu'a fait le serveur	Cause typique
Valid	A accepté l'adresse, et rejeté une adresse inventée sur le même domaine	Une vraie boîte mail qui fonctionne
Invalid	A rejeté l'adresse, ou il n'y avait aucun serveur à interroger	Faute de frappe, boîte supprimée, domaine mort, syntaxe incorrecte
Risky	A accepté l'adresse, mais aussi une adresse inventée	Domaine catch-all, boîte pleine, fournisseur jetable (selon l'éditeur)
Unknown	N'a donné aucune réponse exploitable	Délai dépassé, greylisting, connexion refusée, système antispam

La distinction que l'on rate le plus souvent concerne les deux dernières lignes. Risky signifie que le vérificateur a obtenu une réponse, et que cette réponse ne voulait rien dire. Unknown signifie qu'il n'a obtenu aucune réponse. Le premier est une propriété du domaine et ne changera pas si vous revérifiez demain. Le second est une tentative ratée, et changera souvent.

Comment huit éditeurs nomment les mêmes résultats

Les quatre mêmes résultats apparaissent sous au moins cinq vocabulaires différents. Ce tableau met en correspondance les libellés de chaque éditeur, tirés de leur documentation d'API (sources sous le tableau).

Éditeur	Valid	Invalid	Catch-all	Unknown	Autres libellés de premier niveau
ZeroBounce	valid	invalid	catch-all	unknown	spamtrap, abuse, do_not_mail
NeverBounce	valid	invalid	catchall	unknown	disposable
Kickbox	deliverable	undeliverable	risky (avec l'indicateur accept_all)	unknown	aucun
Bouncer	deliverable	undeliverable	risky (motif low_deliverability)	unknown	aucun
Hunter	valid	invalid	accept_all	unknown	webmail, disposable
Clearout	valid	invalid	catch_all	unknown	indicateur safe_to_send : yes / risky / no / unknown
DeBounce	5 Valid	6 Invalid	4 Accept-All	7 Unknown	1 Syntax, 2 Spam Trap, 3 Disposable, 8 Role
EmailListVerify	ok	email_disabled, dead_server, invalid_mx, invalid_syntax	ok_for_all	unknown	antispam_system, smtp_protocol, disposable, spamtrap

Sources : codes de statut ZeroBounce, vérification unitaire NeverBounce, README du SDK Ruby officiel de Kickbox, terminologie Bouncer, référence de l'API Hunter, présentation de Clearout, codes de résultat DeBounce, et la spécification OpenAPI publiée par EmailListVerify sur api.emaillistverify.com/api-doc.

Là où les éditeurs divergent vraiment

La plupart des libellés se traduisent un pour un, mais trois catégories atterrissent dans des cases différentes selon l'outil. Si vous comparez les pourcentages récapitulatifs de deux vérificateurs sans le savoir, vous tirerez la mauvaise conclusion.

Les adresses jetables

Une adresse jetable, comme une adresse Mailinator, correspond généralement à une boîte mail qui fonctionne. Personne ne la lira.

• NeverBounce, Hunter, DeBounce et EmailListVerify lui attribuent un statut de premier niveau dédié.
• ZeroBounce la classe dans do_not_mail avec le sous-statut disposable.
• Bouncer la classe dans risky, motif low_quality.
• Kickbox la renvoie avec un indicateur disposable à côté du résultat principal.

Une liste nettoyée dans Bouncer affichera donc une part de risky plus élevée que la même liste dans NeverBounce, sans aucune différence dans les données sous-jacentes. Vous pouvez contrôler n'importe quel domaine vous-même avec le vérificateur d'emails jetables.

Les adresses de rôle

info@, sales@ et support@ sont de vraies boîtes mail : la plupart des outils renvoient donc le verdict sur la boîte mail et ajoutent un indicateur « rôle ». Deux font exception : DeBounce attribue aux comptes de rôle leur propre code (8, qu'il libelle « Maybe, Not recommended »), et ZeroBounce les place dans do_not_mail avec le sous-statut role_based. Faut-il leur envoyer des emails ? C'est une autre question, traitée dans faut-il écrire à info@ et sales@.

Les catch-all marqués valid

C'est le point à surveiller. Le statut valid de ZeroBounce comporte un sous-statut appelé accept_all, que sa documentation décrit comme des adresses qui « belong to domains on the ZeroBounce accept_all list » (appartiennent à des domaines de la liste accept_all de ZeroBounce). C'est distinct de son statut de premier niveau catch-all, qu'il décrit comme « impossible to validate without sending a real email and waiting for a bounce » (impossible à valider sans envoyer un vrai email et attendre un rebond). Si vous filtrez uniquement sur le statut de premier niveau, certaines adresses accept-all voyagent avec vos adresses valides. Lisez la colonne du sous-statut avant d'importer.

Hunter présente une version plus discrète du même problème. Son statut webmail couvre les adresses chez des fournisseurs comme Gmail et Outlook, et sa documentation indique que pour les adresses webmail et jetables « we provide an arbitrary score of 50 » (nous fournissons un score arbitraire de 50). webmail vous dit qui héberge la boîte mail, pas si elle existe.

Que faire de chaque résultat

Envoyez aux valid, supprimez les invalid, mettez de côté les risky et revérifiez les unknown. Voilà toute la règle, avec quelques nuances.

Résultat	Action	Pourquoi
Valid	Envoyer	Le serveur a confirmé la boîte mail
Invalid	Supprimer, et ajouter à la liste de suppression pour qu'elle ne soit jamais réimportée	Elle produira un hard bounce
Jetable (disposable)	Supprimer des listes marketing	Aucun humain ne la lira
Piège à spam (spam trap, s'il est signalé)	Supprimer	En toucher un abîme la réputation d'expéditeur bien plus qu'un rebond
Risky / catch-all	Envoyer à part, en petits lots, seulement si l'adresse provient d'une source fiable	Impossible à confirmer, pas forcément mauvaise
Unknown	Revérifier après 24 à 48 heures	Souvent un échec temporaire, comme le greylisting
Rôle	À vous de décider, selon le cas d'usage	Vraie boîte mail, risque de plainte plus élevé

Deux remarques sur ce tableau.

Un résultat valid a une date de péremption. La documentation de Clearout indique que sa garantie « safe to send » ne s'applique que si vous envoyez « within 24 hours of the verification time » (dans les 24 heures suivant la vérification), et ZeroBounce décrit les adresses valides comme ayant « a very low bounce rate of under 2% » (un taux de rebond très faible, inférieur à 2 %). Ce sont les affirmations des éditeurs eux-mêmes, non auditées de manière indépendante, mais elles s'accordent sur le point utile : un résultat valid décrit la boîte mail le jour où vous l'avez vérifiée. Voir à quelle fréquence revérifier votre liste.

Les catch-all ont besoin de leur propre règle. C'est souvent la plus grosse catégorie non valide d'une liste B2B, et la supprimer d'office revient à jeter de vraies personnes. Nous avons rédigé une grille de décision pour écrire aux adresses catch-all.

Unknown, c'est une nouvelle tentative, pas un verdict

Unknown signifie que la vérification n'a pas abouti : la bonne réaction est de la relancer, pas de trancher. Les sous-statuts publiés par les éditeurs rendent les causes explicites. ZeroBounce liste greylisted, timeout_exceeded, mail_server_did_not_respond, failed_smtp_connection et antispam_system. Bouncer liste timeout, unavailable_smtp, dns_error et unsupported. Kickbox liste no_connect, timeout et unavailable_smtp.

La plupart sont temporaires. Un serveur qui pratique le greylisting rejette la première tentative d'un expéditeur inconnu avec un code temporaire 4xx et accepte une tentative ultérieure. Un serveur surchargé dépasse le délai une fois et répond la fois suivante.

Il existe une cause d'unknown qui relève du vérificateur et non du destinataire : le réseau du vérificateur lui-même ne peut pas joindre le port 25. Nous l'avons mesuré sur notre propre infrastructure dans notre article sur le blocage du port 25 par les fournisseurs cloud. Un vérificateur dans cette situation devrait renvoyer unknown ou risky pour tout ce qu'il n'a pas pu vérifier. Un vérificateur qui renvoie valid à la place commet l'erreur décrite dans comment savoir si votre vérificateur d'email vous ment.

Correspondance des trois statuts de SimpleVerifier

Nous renvoyons trois statuts plutôt que quatre, et il vaut la peine d'être explicite sur la destination de chaque cas :

• valid : le serveur de messagerie du destinataire a confirmé la boîte mail.
• invalid : le serveur a rejeté la boîte mail, la syntaxe est incorrecte, le domaine n'a pas de serveur de messagerie, ou le domaine figure sur notre liste de 8 740 fournisseurs jetables.
• risky : le domaine fonctionne mais la boîte mail n'a pas pu être confirmée. Cela couvre les domaines catch-all et les serveurs qui n'ont pas répondu : les colonnes « risky » et « unknown » du tableau des éditeurs ci-dessus atterrissent donc toutes deux ici.

Les adresses de rôle sont signalées à côté du statut, sans le remplacer. Tout ce que nous n'avons pas pu confirmer est renvoyé en risky, jamais en valid. Les échecs passagers sont retentés au lieu d'être mis en cache comme verdict.

À retenir

Quand vous ouvrez un fichier de résultats, faites trois choses avant d'importer quoi que ce soit :

1. Traduisez les libellés en valid / invalid / risky / unknown à l'aide du tableau ci-dessus, pour ne pas comparer les catégories de deux éditeurs comme si elles correspondaient.
2. Lisez la colonne du sous-statut ou du motif, pas seulement le statut principal. Les catch-all cachés dans valid, comme les adresses jetables cachées dans risky, se trouvent là.
3. Relancez les unknown un jour plus tard avant de prendre la moindre décision à leur sujet.

Si vous voulez voir comment une adresse est classée avant de lancer un fichier entier, le vérificateur d'email unitaire gratuit affiche le statut et le motif.