Catch all email : qu'est-ce que c'est, comment fonctionnent les adresses catch-all, pourquoi les vérificateurs ne peuvent pas les confirmer et comment leur écrire sans risque

Catch all email : un domaine qui accepte toutes les adresses, les libellés des vérificateurs et comment écrire sans risque
REVIEWER:

Publish date: 28 oct. 2026

Un catch all email est une adresse hébergée sur un domaine dont le serveur de messagerie accepte tous les messages, quoi qu'on écrive avant le @. Le serveur ne dit jamais si la boîte existe : le vérificateur renvoie donc « catch-all » au lieu de valide ou invalide. Les contrôles de Spona placent 14,25 % de 40 000 adresses dans cette catégorie.

Ce guide se place du côté de l'expéditeur B2B. Il montre ce que fait le serveur pendant un contrôle de vérification, pourquoi les entreprises le configurent ainsi et comment chaque vérificateur nomme le résultat. Il montre aussi ce qui s'est passé quand un client a envoyé 1 200 e-mails à des adresses catch-all. La configuration d'une boîte catch-all n'a droit qu'à une réponse, dans la FAQ.

The Extractor
The Refiner
The Verifier
The Exporter

Get thousands of leads in 4 minutes.

Stop stitching tools together.
Start with verified sales data, delivered in minutes.

SCALE SALES NOW

No contracts · No setup · No onboarding

Catch all email, définition : une boîte mail catch all pour toutes les adresses

Deux publics emploient le terme, et ils ne parlent pas de la même chose.

Pour un administrateur de messagerie, un catch-all est une boîte aux lettres. Proton le décrit comme l'option permettant de « recevoir tout le courrier envoyé à leur domaine », y compris aux adresses que personne n'a créées. Chez Namecheap, tout e-mail envoyé à votre domaine « qui n'est pas encore configuré comme compte e-mail ou comme alias » y atterrit.

Les vraies boîtes gardent leur propre courrier. Proton précise qu'un message adressé à une adresse existante « ne sera pas distribué à l'adresse catch-all ».

Pour un expéditeur, un catch-all est un résultat de vérification. NeverBounce le résume en une ligne : l'accept-all « est un réglage du serveur de messagerie du destinataire, pas un verdict sur l'adresse elle-même ». L'adresse contrôlée peut appartenir à une vraie personne, contenir une faute de frappe ou viser quelqu'un parti il y a deux ans. Le serveur ne vous a rien appris, ni dans un sens ni dans l'autre.

Les graphies varient : catchall email, catch-all email, accept-all email. Les vérificateurs disent aussi « accept all », et les hébergeurs « wildcard ». Tous décrivent le même comportement du serveur.

Une erreur de lecture cause l'essentiel des dégâts. On entend catch-all et on pense « adresse morte ». Le statut dit que le domaine accepte tout. Il ne dit rien sur la présence de la personne.

Comment un domaine catch-all répond au contrôle SMTP d'un vérificateur

Pour contrôler une adresse, un vérificateur entame une remise et s'arrête avant l'envoi du moindre message. Il se connecte au serveur de messagerie du domaine, désigne un destinataire et lit la réponse. La RFC 5321, la norme SMTP, définit ces réponses : quand le serveur accepte le destinataire, il « renvoie une réponse “250 OK” ». Quand le destinataire est « connu pour ne pas être une adresse livrable », il répond 550.

Sur un domaine normal, cette réponse tranche la question. Un 250 signifie que la boîte existe. Un 550 signifie qu'elle n'existe pas.

Un domaine catch-all répond 250 à tout. Le vérificateur ne peut pas distinguer une vraie boîte d'une boîte inventée : il lance donc une seconde sonde.

La méthode de Hunter consiste à demander au serveur s'il acceptera du courrier pour une adresse « qui n'existe pas, à coup sûr ». Si la réponse est oui, tout le domaine est marqué accept-all. Chaque adresse du domaine hérite alors de ce libellé.

Contrôle SMTP d'un domaine normal et d'un domaine catch-all : le serveur catch-all répond 250 OK même à une adresse inventée

La norme avait prévu le cas : un serveur « NE DOIT PAS renvoyer de code 250 » à une commande de vérification s'il n'a pas réellement vérifié l'adresse. S'il ne le peut pas, c'est le code 252 qui « DEVRAIT être renvoyé ». Cette règle vise la commande VRFY. Un serveur catch-all répond à l'étape du destinataire, où un 250 signifie qu'il prendra le message, pas que quelqu'un lit la boîte.

Une autre clause comptera plus loin. Un serveur qui a accepté un message puis ne peut pas le remettre « DOIT construire une notification de “courrier non distribuable” » et la renvoyer. Le oui donné à la porte peut devenir un non après l'envoi.

Pourquoi les entreprises configurent une adresse catch-all

Les pages d'aide des hébergeurs qui proposent la fonction avancent deux raisons. Une migration de messagerie peut en ajouter une troisième.

Les fautes de frappe : l'exemple de one.com est celui d'un expéditeur qui tape « daivd@domain.com » au lieu de david@. Sans catch-all, le serveur refuse le message. Avec, il arrive dans une boîte que quelqu'un consulte.

Les départs de salariés : Google Workspace permet à un administrateur d'acheminer les messages envoyés à des « adresses e-mail inexistantes ou incorrectes » vers une boîte catch-all. L'option de routage porte le libellé « All inactive and unrecognized accounts ». Le courrier entrant d'un ancien salarié continue ainsi d'arriver dans l'entreprise. C'est une règle de routage posée par un administrateur, pas un réglage par défaut : un domaine hébergé chez Google n'est catch-all que si quelqu'un l'a activé.

Les migrations : avec Directory-Based Edge Blocking, Microsoft 365 permet au contraire à un locataire de « rejeter les messages destinés à des destinataires non valides en bordure du réseau de service ». La réponse est « 550 5.4.1 Recipient address rejected: Access denied ». Microsoft demande aux administrateurs de ne laisser un domaine en « Internal relay » que le temps que l'annuaire contienne tous les destinataires valides. D'ici là, la bordure du réseau peut accepter des destinataires inconnus, et la sonde d'un vérificateur peut y lire un catch-all.

Le spam en est le prix. L'avertissement de one.com à qui active la fonction : « la plupart des e-mails que vous attraperez seront du spam ».

Vérification d'un catch-all email : ce que renvoie chaque vérificateur

En vérification d'e-mails, « catch-all » signifie que le vérificateur a trouvé un serveur de messagerie qui accepte n'importe quel destinataire : il n'a donc pas pu tester votre adresse.

Tous les vérificateurs se heurtent au même mur. ZeroBounce écrit que les e-mails catch-all « sont impossibles à valider sans leur écrire » puis attendre de voir s'ils génèrent un bounce. MailerCheck va dans le même sens : « il n'y a aucun moyen de savoir s'ils sont valides ou invalides ». Ce qui change, c'est le libellé, et ce que l'éditeur fait ensuite.

VérificateurLibelléCe que signifie le libelléCe qu'ajoute l'éditeur
NeverBounce« Accept all » (« Unverifiable »), code 3 sur 5Un réglage du serveur valable pour tout le domaine, pas un verdict sur l'adresseEnvoyer par petits lots et retirer ce qui revient en bounce
Hunter« Accept all »Le domaine a « pour politique de déclarer valide tout e-mail du domaine »Un score de confiance, plus la mention « L'utilisation de ce type peut entraîner des bounces. »
ZeroBounce« Catch-all »Impossible à valider sans envoyer d'e-mail et attendre un bounce« Certains e-mails catch-all sont valides et sûrs, d'autres non. »
MillionVerifier« Catch-All », ou « Risky » après un ping approfondiUn contrôle approfondi fait passer « jusqu'à 40 % » en « Valid » ou « Invalid » ; les autres restent « Risky »Aucun crédit facturé pour les résultats « Catch-All » ou « Unknown » non résolus
MailerCheck« catch-all » (statut API)« Unverifiable » : aucun moyen de distinguer le valide de l'invalideUn délai de grâce courant de 3 à 6 mois sans engagement avant suppression

Les libellés proviennent des pages d'aide et des pages produit de chaque éditeur. Les prix des contrôles approfondis figurent dans le guide sur le nettoyage de liste email, pas ici.

« Unknown » est un autre résultat. NeverBounce le définit comme un serveur qui n'a pas donné « de réponse définitive à temps », souvent à cause du greylisting ou d'une passerelle de sécurité. Un serveur catch-all a répondu ; un serveur en « Unknown » n'a pas répondu.

Revérifiez un « Unknown » le lendemain : il peut se résoudre. Revérifiez un catch-all : vous obtiendrez un nouveau 250.

Part des e-mails catch-all : les 40 000 contrôles B2B de Spona

Spona a contrôlé 10 000 adresses candidates uniques dans chacun des quatre pays étudiés, avant tout envoi. Ce sont des données Spona, et la part revenue en catch-all va de 12 % au Royaume-Uni à 16 % en Allemagne.

PaysAdresses contrôléesPart catch-allAdresses catch-all
États-Unis10 00014,0 %1 400
Royaume-Uni10 00012,0 %1 200
Allemagne10 00016,0 %1 600
France10 00015,0 %1 500
Ensemble40 00014,25 %5 700

La part est calculée sur l'ensemble des adresses candidates uniques contrôlées. Une adresse est soit validée, soit catch-all, soit rejetée pour un autre motif, jamais deux à la fois. Spona n'a pas mesuré de répartition par fonction ou par secteur, et ces quatre pays sont les seuls qu'elle a mesurés. Sur les quatre pays, environ une adresse contrôlée sur sept est revenue sans verdict.

D'autres parts publiées décrivent d'autres populations. ZeroBounce a constaté que « plus de 9 % » de tous les e-mails qu'il a contrôlés étaient catch-all, sur plus de 11 milliards d'adresses traitées. Le chiffre de MailerCheck est de 8,6 % de tout ce qu'il a vérifié, mais par liste client, la médiane grimpe à 15,25 %. Hunter compte des domaines plutôt que des adresses : « 38 % des domaines e-mail » d'un échantillon de 2 572 adresses étaient accept-all.

Aucun de ces chiffres ne se compare au tableau de Spona. Chacun compte autre chose, sur une autre liste. Ils partagent la direction : une minorité non négligeable de la liste que vous contrôlez, quelle qu'elle soit.

Les e-mails catch-all sont-ils risqués en cold email ? Ce qu'a vu un client

Oui, et le risque se mesure. Le benchmark en direct de Spona fixe la référence et exclut par principe les adresses catch-all : « Le hard bounce correspond aux échecs de remise définitifs divisés par les envois tentés vers le sous-ensemble vérifié, hors adresses catch-all ». Sur 20 000 envois de ce type, le taux de hard bounce était de 1,525 %.

Un client a malgré tout écrit à des adresses catch-all et a communiqué le résultat. Sur environ trois mois, ses 1 200 envois ont produit 86 hard bounces, que Spona a enregistrés comme une cohorte distincte. Cela fait 7,17 %. Ce type de retour garde son propre dénominateur d'envois et n'entre jamais dans le benchmark.

Mis côte à côte, le taux de cette cohorte représente environ 4,7 fois celui du benchmark.

Taux de hard bounce sur 20 000 envois vérifiés et sur les 1 200 envois catch-all d'un client, en cohortes distinctes

Deux précautions accompagnent cet écart. Les 7,17 % viennent des 1 200 envois d'un seul client : ce n'est pas un taux du secteur, et il ne prédit pas le vôtre. Les deux cohortes diffèrent aussi par autre chose que le libellé catch-all ; l'écart compare donc des résultats, il ne mesure pas une cause.

Hunter a mené son propre test : une campagne vers 100 adresses accept-all et 100 adresses valides. Résultat : « Le taux de bounce était de 27 % » pour le groupe accept-all, contre 1 % pour le groupe témoin. Autre liste, autre expéditeur, même direction.

Le mécanisme, c'est la clause de la RFC 5321 citée plus haut. Un serveur catch-all accepte chaque message à la porte, puis tente de le remettre en interne. Quand aucune boîte ne correspond, il doit renvoyer l'avis de non-distribution. D'où l'avertissement de ZeroBounce : les « adresses e-mail catch-all inexistantes finiront en bounce » et nuiront à votre réputation d'expéditeur.

Hunter énumère les trois issues possibles d'un message envoyé à un domaine accept-all : « remis, redirigé vers une boîte catch-all, ou bounce plus tard ». Vous ne savez laquelle qu'après l'envoi.

Reste à situer le seuil. Twilio écrit qu'un taux de bounce « supérieur à 2 % » signale qu'il est temps d'agir, et que les programmes sains restent sous 1 %. Un segment catch-all qui génère autant de bounces que cette cohorte, glissé dans une campagne vérifiée, tire le taux de toute la campagne vers ce seuil.

Vérifier une adresse catch-all au-delà du contrôle SMTP

Aucun outil ne peut confirmer une boîte derrière un serveur catch-all. Le serveur ne le dira pas, et rien d'autre ne peut parler à sa place. Les meilleurs outils font une estimation, de trois façons.

Les scores de confiance : Hunter attache un score à ses résultats « Accept all », fondé sur « le nombre et la fraîcheur des sources » où il a trouvé l'adresse. Sa consigne : traiter un score de « 85-100 % » comme valide, même si l'adresse reste un peu plus susceptible de revenir en bounce. Un score est une probabilité tirée d'indices trouvés sur le web, pas une réponse du serveur.

Les sondes approfondies : MillionVerifier indique qu'un ping approfondi fait passer « jusqu'à 40 % » des e-mails catch-all en « Valid » ou « Invalid », les autres restant « Risky ». C'est le chiffre de l'éditeur pour sa propre méthode, sur ses propres listes. Traitez chaque taux de récupération de la même façon tant que vous ne l'avez pas testé sur les vôtres.

Les indices hors du serveur de messagerie : un nom qui suit le format d'adresse de l'entreprise, un profil chez cet employeur, une mention récente sur le site de l'entreprise. Chacun augmente la probabilité que la boîte existe. Le guide sur la validation des données B2B décrit cette chaîne de traitement, et rien de tout cela ne change la réponse du serveur.

Le seul test qui fonctionne est celui qui vous coûte. Envoyer un message et guetter le bounce reste la seule méthode, comme le dit ZeroBounce. Pourtant, l'absence de bounce peut simplement signifier une boîte catch-all, que Hunter juge peu susceptible d'être lue. Hunter note que la méthode soulève des « questions éthiques » : vous spammez d'autres entreprises pour savoir, et chaque bounce s'inscrit dans l'historique de votre domaine.

Écrire à une adresse catch-all sans risque : six étapes

  1. Gardez un segment à part. Les adresses catch-all ne figurent jamais dans la même liste que les adresses vérifiées. La checklist d'hygiène des données les maintient dans leur propre segment à chaque envoi.
  2. Plafonnez leur part. Hunter recommande de limiter les adresses accept-all à une petite part de vos campagnes, soit 2 % à 5 % des envois. À ce niveau, un segment aussi exposé aux bounces que la cohorte client ajouterait au plus quelques dixièmes de point.
  3. Classez selon les indices. Écrivez d'abord aux adresses qui ont un score de confiance élevé, un format de nom cohérent ou une mention publique récente. Gardez les simples suppositions pour la fin, ou laissez-les de côté.
  4. Envoyez par petits lots et surveillez. NeverBounce conseille d'envoyer « par petits lots » et de suivre les messages qui reviennent en bounce. Si votre fournisseur exige un taux de bounce « inférieur à 4 % », NeverBounce recommande d'envoyer de façon sélective plutôt que de les supprimer.
  5. Arrêtez au premier bounce d'un domaine. Un hard bounce sur un domaine catch-all vous indique que son tri a échoué pour ce nom. Placez aussitôt l'adresse en liste d'exclusion, et suspendez le reste du domaine jusqu'à ce que vous ayez un meilleur nom.
  6. Exploitez l'identité sur un autre canal. Un statut catch-all ne dit rien de la personne : le nom, l'entreprise et la fonction peuvent donc encore servir. Un appel ou un message LinkedIn ne revient pas en bounce. Un second contact dans l'entreprise peut aider, mais sur le même domaine, son adresse est catch-all elle aussi.

Côté RGPD, l'article 5.1.d du règlement, dans le texte que publie la CNIL, exige des données personnelles « exactes et, si nécessaire, tenues à jour ». Il demande aussi de prendre toutes les mesures raisonnables pour que les données inexactes, au regard des finalités du traitement, soient « effacées ou rectifiées sans tarder ».

Comment Spona traite les adresses catch-all, et ses limites

Spona trouve des leads à partir de la description de votre client idéal dans un chat, vérifie chaque adresse et livre une liste notée en 4 minutes environ. Les adresses catch-all passent par le même contrôle SMTP que les autres. La suite obéit à six règles.

ÉtapeRègle de SponaCe que vous voyez
1Classer les catch-all à part après la validation SMTPStatut e-mail « catch-all », avec la date et la méthode de vérification
2Exclure les catch-all de la livraison par défaut des e-mails vérifiésUn nombre d'e-mails vérifiés qui ne compte que les enregistrements validés non catch-all
3Conserver l'identité et la source indépendamment du statut de l'e-mailPersonne nommée, entreprise, fonction et provenance, qui peuvent rester utiles sur d'autres canaux
4Ne proposer les enregistrements catch-all que dans un export séparé, demandé explicitementUn fichier et un statut catch-all distincts ; aucune affirmation de boîte vérifiée ni de taux de bounce
5Revérifier les résultats incertains après un intervalle documentéLe statut et l'horodatage du dernier contrôle ne changent qu'avec de nouveaux éléments
6Enregistrer à part les envois catch-all signalés par les clientsUn dénominateur d'envois distinct et un décompte final des hard bounces

Là où Spona est utile : vous payez au lead, et une adresse catch-all ne compte jamais dans le nombre d'e-mails vérifiés. Un lead Standard Search limité à l'e-mail coûte 3 à 7 crédits. Aux prix des crédits des différents plans, cela représente 0,024 $ à 0,07 $.

Chaque nouvelle session de recherche entraîne aussi un coût unique de 1 000 crédits.

Pour les enregistrements catch-all, c'est la règle 3 qui sert. Spona conserve la fiche de la personne, et l'enrichissement peut y ajouter un numéro de mobile pour 35 crédits. Cela représente 0,28 $ à 0,35 $, et la conversation passe au téléphone. Chaque recherche commence par un échantillon gratuit, et le plan Free inclut 3 000 crédits attribués une seule fois.

Ses limites : Spona ne peut pas non plus confirmer une boîte catch-all ; par conception, son export catch-all n'affirme rien sur la boîte ni sur le taux de bounce. Spona ne vend ni outil de résolution ni score de confiance pour ces enregistrements, ce que font Hunter et MillionVerifier.

Le tableau par pays ne couvre que les États-Unis, le Royaume-Uni, l'Allemagne et la France, sans répartition par fonction ou par secteur. La cohorte de 1 200 envois est le retour d'un seul client, enregistré parce que ce client l'a transmis. Spona n'envoie pas vos e-mails : elle ne voit donc les bounces catch-all que lorsqu'un client les signale.

The Extractor
The Refiner
The Verifier
The Exporter

Get thousands of leads in 4 minutes.

Stop stitching tools together.
Start with verified sales data, delivered in minutes.

SCALE SALES NOW

No contracts · No setup · No onboarding

FAQ : catch all email

Comment configurer une adresse catch-all (attrape-tout) ?

Dans les paramètres d'administration de votre hébergeur de messagerie, pas dans un client mail. Proton la propose sur « toute offre payante Proton », sous Settings, All settings, Organization, Domain names, puis Set catch-all. Google Workspace passe par une règle de routage « All inactive and unrecognized accounts », dont l'application « peut prendre jusqu'à 24 heures ». Microsoft 365 fonctionne à l'inverse et rejette les destinataires inconnus en bordure du réseau.

Qu'est-ce qu'un domaine catch-all ?

Un domaine catch-all est un domaine dont le serveur de messagerie accepte le courrier pour n'importe quelle adresse, y compris les adresses qui n'existent pas. Les vérificateurs le détectent en sondant une adresse inventée : un 250 sur celle-ci suffit à marquer le domaine. Toutes les adresses du domaine portent alors le statut catch-all : ce statut décrit donc le domaine, pas la personne.

Un email catch-all est-il invalide ?

Non. Invalide signifie que le serveur a refusé l'adresse avec un 550. Catch-all signifie que le serveur l'a acceptée, comme tout le reste : l'adresse peut très bien appartenir à une vraie personne. Dans les contrôles de Spona, validée, catch-all et autre rejet sont des catégories distinctes, et chaque adresse n'entre que dans une seule.

Les e-mails catch-all reviennent-ils en bounce ?

Certains, oui, après que le serveur les a acceptés : il prend le message, ne trouve aucune boîte correspondante et renvoie un avis de non-distribution. Les 1 200 envois catch-all d'un client sont revenus avec 86 hard bounces. Dans le test de Hunter, 100 adresses accept-all ont eu un taux de bounce de 27 %. Aucun de ces chiffres ne prédit le résultat de votre liste.

Faut-il retirer les e-mails catch-all de votre liste ?

Pas automatiquement. Pour Hunter, les adresses accept-all « ne devraient pas être écartées automatiquement », mais personne ne devrait non plus les traiter comme pleinement valides. Gardez-les dans leur propre segment, écrivez par petits lots à celles qui s'appuient sur les meilleurs indices, et basculez les autres vers le téléphone ou LinkedIn. MailerCheck décrit un délai de grâce courant de 3 à 6 mois sans ouverture ni clic avant suppression.

Share this article

GET FREE LEADSSparkle

Similar Topics For You

see all texts