Emails catch-all : détecter le domaine et lire le statut accept_all

CaptainVerify a vérifié plus de 126 millions d’adresses email en 2025. Environ 2,5 % du volume relève d’un domaine catch-all. Rapportée aux seules adresses hébergées sur un domaine d’entreprise, hors messageries grand public qui pèsent près des trois quarts du total vérifié, la proportion approche les 11 %, soit près d’une adresse professionnelle sur 9. Cette mesure porte sur des adresses. Les taux bien plus élevés que l’on croise ailleurs comptent des domaines, ce qui est une autre unité : un seul domaine en catch-all peut ne porter qu’une poignée d’adresses dans votre base comme en porter des centaines. Sur un fichier B2B de 50 000 contacts, cela fait de l’ordre de 5 500 lignes dont la validité reste indécidable avant l’envoi.

Le domaine qui héberge ces adresses se repère en quelques secondes avec une commande SMTP. Les 2 niveaux se traitent séparément : la détection du domaine relève d’un test technique reproductible, la décision d’envoyer relève de vos seuils de rebond.

Qu’est-ce qu’une adresse catch-all ?

Un catch-all est une règle de routage posée au niveau du domaine : le serveur de réception accepte les messages adressés à n’importe quelle boîte du domaine, déclarée ou non.

La règle vit dans la configuration du domaine receveur, derrière son enregistrement MX. Aucune boîte ne porte l’étiquette en propre. L’expression « adresse catch-all » circule par raccourci et désigne toute adresse dont le domaine applique ce mode de repli.

Un exemple rend la mécanique évidente. Le domaine exemple.com déclare david@exemple.com et active un catch-all. Un correspondant tape daivd@exemple.com, 2 lettres inversées. Sur un domaine standard, le serveur refuse cette adresse au moment du RCPT TO et renvoie une erreur permanente à l’expéditeur, l’un des codes de réponse SMTP qu’il faut savoir lire. Sur exemple.com, le message entre, atterrit dans la boîte de repli et la faute de frappe passe inaperçue.

Catch-all, alias, redirection et sous-adressage : ne pas confondre

Un alias déclare une adresse supplémentaire qui pointe vers une boîte existante. Une redirection prend une adresse déclarée et fait suivre son courrier vers une autre destination. Le sous-adressage ajoute un suffixe après un signe plus, du type david+presse@exemple.com, que le serveur ramène à la boîte de base. Ces 3 mécanismes portent sur des adresses connues du serveur, qui refuse tout ce qui sort de sa liste. Le catch-all agit après cette liste, sur les parties locales qu’aucune règle ne déclare.

À quoi sert l’adresse catch-all ?

Un catch-all récupère le courrier envoyé à une adresse mal orthographiée et prive un attaquant de la réponse qui lui dirait quelles adresses existent sur le domaine.

Le premier usage est trivial. Les fautes de frappe abondent sur les noms composés, les boîtes de collaborateurs partis restent adressées pendant des mois et le catch-all rattrape ce courrier.

Le second usage est défensif. Un serveur qui répond 550 sur les adresses inconnues fournit un oracle gratuit : l’attaquant soumet une liste de prénoms et garde celles que le serveur accepte. Le domaine en catch-all répond 250 à tout le monde et ne trie plus rien pour lui.

Le revers arrive dans la boîte de repli. Un domaine qui accepte tout attire les campagnes de dictionnaire, ces envois massifs qui tentent contact@, admin@, sav@, rh@ et quelques centaines de prénoms jusqu’à ce que quelque chose reste. Le tri retombe alors sur l’équipe qui relève la boîte, avec le travail de nettoyage de liste que cela suppose côté expéditeur.

Comment détecter un domaine catch-all

Un domaine catch-all se détecte en soumettant au serveur une adresse tirée au hasard : si le serveur accepte une adresse improbable, il accepte tout le reste.

Le test SMTP étape par étape : MX, EHLO, MAIL FROM, RCPT TO

1. Résoudre les enregistrements MX du domaine et retenir celui dont la valeur de préférence est la plus basse, soit le MX primaire. En l’absence de MX, le courrier retombe sur l’enregistrement A du domaine.
2. Ouvrir une connexion sur le port 25 vers ce serveur et saluer avec EHLO suivi d’un nom d’hôte qui résout en DNS.
3. Annoncer MAIL FROM avec une enveloppe vide ou une adresse de test réellement joignable.
4. Envoyer RCPT TO sur l’adresse à vérifier, puis noter le code de retour ainsi que le texte qui l’accompagne.
5. Envoyer RCPT TO sur une adresse aléatoire du même domaine, du type k7v29xq4m@exemple.com.
6. Fermer la session avec QUIT, sans jamais passer à la commande DATA.

Le signal se lit sur l’adresse aléatoire, la première acceptation servant seulement à vérifier que la session se comporte normalement. Prévoyez un RSET entre les deux commandes RCPT TO, car un serveur coupe souvent la session après un mauvais destinataire. Couper avant DATA évite de livrer un message et ne laisse dans les journaux distants que la trace d’une ouverture de session. L’IP qui sonde doit disposer d’un enregistrement PTR valide, faute de quoi un refus de politique se lit à tort comme une adresse invalide.

250 OK contre 550 : lire la réponse du serveur

La RFC 5321 d’octobre 2008 fixe la règle dans sa section 3.3 : le serveur répond 550 au RCPT TO quand le destinataire n’est pas distribuable, avec un message du type « no such user ». La RFC 3463 de janvier 2003 précise le code étendu associé dans sa section 3.2 : 5.1.1 signale une adresse de destination invalide et un échec définitif. Un 250 renvoyé sur l’adresse aléatoire établit que le domaine accepte tout au RCPT TO. La réserve compte : certaines passerelles antispam placées en frontal acceptent elles aussi n’importe quel destinataire à ce stade sans appliquer de catch-all. Le rejet différé décrit plus bas produit la même réponse. Ces codes portent sur l’enveloppe, la forme de l’adresse relève quant à elle de la syntaxe d’une adresse email définie par les RFC.

Ce qui fausse le test : MX mutualisé, greylisting, tarpitting et rejet différé

Le MX mutualisé arrive en tête des faux signaux. Des centaines de milliers de domaines pointent vers les mêmes serveurs de messagerie chez les grands hébergeurs. La politique de destinataires se règle domaine par domaine derrière ce MX commun, le nom du serveur ne dit donc rien du mode de repli.

Le greylisting produit un autre bruit. Le serveur répond une erreur temporaire en 4xx au premier contact et attend une nouvelle tentative pour se prononcer. CaptainVerify attend jusqu’à 30 minutes et relance la vérification avant de conclure. Les adresses qui restent muettes après cette relance passent en statut inconnu et sont recréditées. Le tarpitting relève de la même famille : le serveur ralentit délibérément ses réponses pour décourager les sondes.

Le rejet différé complique encore la lecture. Le serveur accepte le destinataire au RCPT TO, puis génère un rebond une fois le message avalé. Le test voit un 250 franc alors que l’envoi réel produira une erreur permanente quelques minutes plus tard.

Que signifie le statut accept_all dans un rapport de vérification

Le statut accept_all, nommé ok4all dans les rapports CaptainVerify, indique que le domaine accepte toutes les adresses et que la vérification s’arrête donc au niveau du domaine.

La documentation CaptainVerify range ok4all dans la famille des adresses risquées et annonce l’effet sans détour : le taux de rebond monte et le taux d’ouverture baisse. Le rapport dit donc 2 choses en une ligne. Le domaine est qualifié, la personne derrière l’adresse reste à confirmer par l’envoi.

Peut-on vérifier une adresse sur un domaine catch-all ?

Le protocole ne tranche pas, puisque le serveur renvoie la même réponse à toutes les adresses du domaine. Ce qui reste possible, c’est d’estimer une probabilité et de trier le segment en conséquence.

Regardez d’abord ce qui se cache derrière l’enregistrement MX du domaine. Quand il pointe vers une passerelle de sécurité, du type Proofpoint, Mimecast, Barracuda ou Microsoft Defender pour Office 365, c’est la passerelle qui répond pour le compte du domaine, avant même d’interroger la boîte réelle. Le statut accept_all traduit alors une architecture de filtrage plutôt qu’une règle de repli décidée par l’entreprise. Le cas est fréquent sur les grands comptes.

Vient ensuite la forme de l’adresse. Sur un domaine dont les boîtes suivent une convention visible, prenom.nom par exemple, une adresse qui respecte cette convention porte une probabilité de validité bien plus haute qu’une chaîne arbitraire. Comparez vos lignes entre elles : celles qui sortent du moule partent en segment de test, les autres passent en priorité.

Un vérificateur ajoute enfin ses propres signaux : l’ancienneté du domaine, la réputation du fournisseur de messagerie, la taille de l’organisation et l’historique observé sur des envois précédents. Le résultat donne un indice de confiance qui sert à ordonner un segment avant l’envoi.

Créer ou désactiver un catch-all selon l’hébergeur

La bascule se règle dans la console d’administration du domaine : mode du domaine accepté sous Microsoft 365, règle de routage sous Google Workspace, adresse par défaut sous cPanel.

Google Workspace

Google Workspace ne propose aucune fonction catch-all native. Google publie en revanche une page d’aide dédiée à la boîte de collecte et nomme le type de compte visé Unrecognized ou Catch-all. La configuration passe par une règle de routage, sous Apps puis Gmail puis Routing, avec l’action Change envelope recipient appliquée aux comptes inactifs et non reconnus. Le courrier adressé à une boîte inconnue part alors vers une adresse de collecte désignée. Pour revenir en arrière, supprimez cette règle de routage : le domaine recommence aussitôt à refuser les destinataires qu’il ne connaît pas.

Microsoft 365

Le comportement dépend du mode du domaine accepté, sous Mail flow puis Accepted domains. En mode Authoritative, le domaine rejette les destinataires inconnus et active le Directory-Based Edge Blocking, qui coupe le message à la frontière du service. Le mode Internal relay fait suivre le courrier des destinataires inconnus vers un autre serveur et produit de fait un comportement de repli.

cPanel

La fonction se nomme Default Address. Elle propose de renvoyer une erreur à l’expéditeur pendant la session SMTP, ce qui est le comportement par défaut et l’exact contraire du catch-all, de router le courrier des adresses inconnues vers une boîte existante ou de le jeter silencieusement. La documentation cPanel étiquette elle-même cette seconde option Not Recommended, pour une raison de fond : l’expéditeur n’apprend jamais que son message a disparu.

Par quoi remplacer un catch-all

La sortie passe par des adresses déclarées plutôt que par une règle de repli. Créez des alias sur les fautes de frappe les plus fréquentes de vos noms de domaine et gardez une boîte générique de contact réellement relevée. Le sous-adressage prend le relais pour tracer vos formulaires sans multiplier les boîtes. Le domaine retrouve une liste de destinataires nette. Vos correspondants récupèrent une erreur immédiate quand ils se trompent.

Catch-all avec ou sans bounce

2 configurations distinctes se cachent derrière cette question. Le catch-all accepte le destinataire inconnu au RCPT TO et livre le message dans une boîte de repli, sans rebond d’aucune sorte. Le rejet différé accepte lui aussi au RCPT TO, puis fabrique un rapport de non-remise après avoir avalé le message.

Ce second mode a un coût pour tout le monde. Quand l’enveloppe d’origine est falsifiée, ce qui est la norme en spam, le rapport de non-remise part vers un tiers innocent dont l’adresse a servi de leurre. Le phénomène porte un nom, le backscatter. Il alimente les listes de blocage. Le comprendre aide aussi à trier vos propres retours, entre hard bounce et soft bounce.

Devriez-vous inclure les adresses catch-all dans vos campagnes ?

Envoyer sur des adresses catch-all fait monter le taux de rebond et baisser le taux d’ouverture, 2 courbes que les routeurs surveillent pour décider de la suite. C’est par là que la réputation d’expéditeur se dégrade, message après message.

Le risque réel : seuil de rebond, taux de plainte, réputation d’expéditeur et pièges à spam

Les seuils de rebond viennent des plateformes d’envoi. Amazon SES place son compteur sous revue au-delà de 5 % de rebond et peut suspendre les envois à 10 %. La documentation Microsoft pour Dynamics 365 Customer Insights, mise à jour en août 2026, distingue deux niveaux : un taux de rebond acceptable ne dépasse pas 2 % dans la plupart des cas. Le produit lui-même tolère jusqu’à 8 % avant de réagir. Les 2 % relèvent donc de la bonne pratique, les 8 % du seuil réellement appliqué. Reprenons le fichier de 50 000 contacts et ses quelque 5 500 lignes en catch-all. Si la moitié rebondit, le compteur dépasse les 5 % avant même d’avoir compté le reste de la base, au-dessus de la barre qui déclenche la revue de compte. Les seuils de rebond appliqués par les plateformes d’envoi varient ensuite d’un acteur à l’autre.

Les seuils de plainte viennent des messageries et se comptent à part. Les règles Google pour les expéditeurs, applicables depuis le 1er février 2024, demandent un taux de plainte sous 0,10 % et fixent une limite à ne jamais atteindre à 0,30 %, pour tout expéditeur de plus de 5 000 messages par jour vers Gmail. Le Sender Hub de Yahoo demande de rester sous 0,3 %. Ces 2 acteurs publient des seuils de plainte, aucun seuil de rebond.

Reste le sujet des pièges à spam. Spamhaus a documenté le cycle en février 2022 : une adresse abandonnée rebondit en erreur permanente pendant souvent 12 mois ou plus, puis le domaine la rallume en piège. Une base laissée sans nettoyage depuis 2 ans contient donc, statistiquement, des adresses qui ont changé de nature entre-temps.

Réduire l’incertitude avant l’envoi

La vérification préalable de la liste fait le premier tri. Elle sort les invalides, isole les ok4all dans leur propre segment et laisse une base sur laquelle le rebond redevient prévisible. Regardez ensuite l’origine de la collecte : une liste bâtie en simple opt-in ou en double opt-in produit nettement moins de rebonds qu’un fichier acheté. Regardez enfin l’ancienneté, puisque le cycle décrit par Spamhaus court sur toutes les adresses dormantes. Ce panorama des outils de vérification d’emails détaille les approches disponibles.

Valider par l’engagement après le premier envoi

Le segment ok4all se traite comme un test. Envoyez d’abord sur 5 à 10 % du segment. Mesurez le rebond et l’ouverture, puis comparez ces 2 valeurs à celles du reste de la campagne. Un écart faible autorise à monter le pourcentage au prochain envoi. Un écart net indique un segment à laisser de côté ou à retravailler.

Après 2 envois sans ouverture ni clic, une adresse en catch-all a fait la preuve de son inutilité et sort de la liste. Avant votre prochaine campagne, isolez les lignes ok4all d’un échantillon de votre base et comparez leur taux de rebond à celui du reste : le verdict tombe en une heure et il vaut toutes les estimations.

Questions fréquentes

Un domaine catch-all est-il détectable ?

Oui, en quelques secondes. Une commande RCPT TO sur une adresse aléatoire du domaine suffit : une réponse 250 sur une adresse improbable révèle le mode de repli. La validité de chaque adresse individuelle, elle, reste indécidable par ce test.

Quelle part d’une base B2B est concernée ?

Sur plus de 126 millions d’adresses vérifiées par CaptainVerify en 2025, environ 2,5 % sont ressorties en catch-all. Le périmètre des seuls domaines d’entreprise porte cette proportion à près de 11 %. Une base B2B de 100 000 contacts contient donc de l’ordre de 11 000 lignes de ce type, à isoler avant l’envoi.

Le catch-all protège-t-il du spam ?

Il augmente le spam reçu, puisque toute adresse inventée sur le domaine trouve une boîte. Son bénéfice se situe ailleurs : le serveur ne répond plus 550 sur les adresses inconnues et prive l’attaquant de l’oracle qui lui permettrait d’énumérer les adresses valides.

Faut-il supprimer les adresses catch-all de sa liste ?

La suppression pure se justifie quand votre plateforme d’envoi applique un seuil de rebond bas, à l’image des 5 % qui déclenchent une revue de compte chez Amazon SES. Sur une IP dédiée que vous pilotez, un segment séparé et un envoi par lots restent une option raisonnable.

Que faire d’un statut inconnu dans un rapport ?

Il signale un serveur resté muet malgré la relance automatique effectuée dans les 30 minutes. CaptainVerify recrédite ces vérifications. Une nouvelle passe plus tard tranche dans la grande majorité des cas.