Qu'est-ce qu'un domaine catch-all, et pourquoi les vérificateurs ne peuvent-ils pas le contrôler ?

Si vous avez déjà passé une liste B2B dans un vérificateur, vous avez vu des résultats qui ne sont ni valides ni invalides. Ils ressortent en catch-all, accept-all ou risky (risqué) — et c'est le résultat le plus mal compris de toute la vérification d'email.

Ce n'est pas de la paresse de la part du vérificateur. C'est le vérificateur qui reste exact sur une chose qu'il ne peut réellement pas déterminer.

Comment fonctionne normalement la vérification

Pour contrôler une boîte mail sans rien envoyer, un vérificateur ouvre une conversation SMTP avec le serveur de messagerie du destinataire et lui demande s'il accepterait du courrier pour cette adresse :

> MAIL FROM: <verify@example.com>
> RCPT TO: <someone@company.com>
< 250 OK                    ← la boîte mail existe

Si la boîte mail n'existe pas, un serveur correctement configuré la rejette :

< 550 5.1.1 User unknown    ← boîte mail inexistante

Cette différence — 250 contre 550 — constitue tout le mécanisme. Aucun message n'est jamais envoyé ; la conversation est abandonnée avant toute donnée.

Ce que fait différemment un domaine catch-all

Un domaine catch-all est configuré pour accepter le courrier destiné à toutes les adresses du domaine, que la boîte mail ait été créée ou non. Résultat :

> RCPT TO: <ceo@company.com>              < 250 OK
> RCPT TO: <asdkjh2981@company.com>       < 250 OK

Les deux sont acceptées. La seconde adresse n'existe évidemment pas, et le serveur a quand même dit oui.

C'est pourquoi une acceptation venant d'un domaine catch-all ne vous apprend rien. La bonne façon de le détecter est de tester d'abord une adresse volontairement absurde : si une chaîne aléatoire est acceptée, le domaine accepte tout, et aucun résultat pour aucune adresse de ce domaine n'est fiable.

Pourquoi les entreprises le configurent ainsi

C'est généralement délibéré et raisonnable :

• Elles préfèrent recevoir une faute de frappe que la perdre. Un email envoyé à jon@ au lieu de john@ arrive quand même.
• Les petites entreprises en hébergement mutualisé l'ont souvent activé par défaut.
• Les services évoluent. Plutôt que de maintenir des alias au gré des arrivées et des départs, tout est accepté puis trié ensuite.

Rien de tout cela n'est une erreur de configuration. Cela rend simplement toute vérification externe impossible.

Ce qu'un vérificateur devrait vous dire

Trois états, et celui du milieu fait un vrai travail :

Résultat	Signification
valid (valide)	Un serveur de messagerie a confirmé cette boîte mail précise
invalid (invalide)	Rejetée, pas de serveur de messagerie, syntaxe incorrecte ou adresse jetable
risky / catch-all (risqué)	Le domaine accepte tout, cette adresse ne peut donc pas être confirmée

Un outil qui renvoie valid sur un domaine catch-all vous parle de la configuration du domaine tout en vous laissant croire qu'il parle de la boîte mail. C'est l'échec qui mérite votre attention, parce qu'il ressemble à une bonne nouvelle jusqu'à l'arrivée des rebonds.

Que faire concrètement des adresses catch-all

Ne les supprimez pas simplement — sur les listes B2B, elles représentent souvent une part importante du fichier, et beaucoup sont parfaitement réelles.

Jugez-les selon leur provenance.

• Une adresse publiée sur le site web de l'entreprise elle-même est probablement réelle. Quelqu'un l'y a mise pour être contacté.
• Une adresse devinée à partir d'un format de nommage — prenom.nom@ — c'est pile ou face. Elle suit la convention, mais rien n'a confirmé la boîte mail.
• Une adresse issue d'une liste extraite par scraping ou achetée, sans provenance connue, mérite le moins de confiance.

Envoyez-leur des emails à part. Gardez les adresses confirmées valides dans vos envois principaux. Envoyez les adresses catch-all dans un lot plus petit et séparé : si le taux de rebond est élevé, les dégâts restent circonscrits au lieu de tirer vers le bas toute votre réputation d'expéditeur.

Servez-vous d'autres signaux. Une adresse catch-all associée à une personne nommée, à un profil LinkedIn correspondant et à une entreprise qui publie le même format ailleurs est un bien meilleur pari qu'une simple supposition.

En bref

Un résultat catch-all n'est pas un échec du vérificateur. C'est un vérificateur qui refuse de deviner.

Un outil qui ne renvoie jamais catch-all n'est pas plus précis qu'un outil qui le fait — il est simplement moins disposé à vous dire quand il ne sait pas, et c'est le plus coûteux des deux comportements.