Les emails catch-all expliqués : ce que les domaines accept-all cachent à la vérification

Tôt ou tard, chaque expéditeur B2B se heurte à la même énigme. La liste est passée par la vérification, les adresses sont revenues correctes, et la campagne a quand même rebondi. Très souvent, la cause est un domaine catch-all : un serveur de messagerie d’entreprise qui dit oui à toutes les adresses, si bien que le contrôle censé protéger votre réputation d’expéditeur n’avait rien de réel à signaler.

Ce guide explique ce que signifie catch-all, pourquoi la vérification ne peut pas voir au-delà, comment BounceIntel détecte et note ces adresses, et les règles qui décident lesquelles méritent un envoi.

Ce que signifie catch-all (accept-all)

Un domaine catch-all, aussi appelé accept-all, est un domaine dont le serveur de messagerie accepte les messages pour n’importe quelle adresse de ce domaine. jane.doe@, j.doe@, sales-team@ et xq7k2@ reçoivent tous le même accueil, qu’une boîte portant ce nom existe ou non.

Les entreprises le configurent pour des raisons qui semblent raisonnables :

• Ne pas perdre de courrier. Un client qui écorche le nom d’un employé atteint quand même quelqu’un, car les adresses inconnues arrivent dans une boîte partagée.
• Le départ des salariés. Le courrier adressé aux personnes parties continue d’arriver quelque part au lieu de revenir en erreur chez les clients.
• Les passerelles de sécurité. Certains services de filtrage placés devant les boîtes d’une entreprise acceptent tout d’abord et font le tri ensuite.
• Une ancienne configuration que personne n’a regardée depuis des années.

Les configurations catch-all sont courantes sur les domaines d’entreprise et rares chez les grands fournisseurs grand public, c’est pourquoi le problème apparaît surtout dans les listes B2B.

Pourquoi SMTP dit toujours « oui »

La vraie vérification d’email repose sur une seule question posée via SMTP. Le vérificateur se connecte au serveur de messagerie du domaine, indique l’adresse avec RCPT TO et lit la réponse. Un serveur normal cherche la boîte, puis l’accepte ou la refuse comme inconnue. Pour la séquence complète, voir comment fonctionne la vérification d’email.

Un serveur catch-all saute cette recherche, ou la repousse à plus tard. Il répond 250, accepté, pour chaque destinataire. Ce qui arrive ensuite à un vrai message dépend de la configuration :

• Il est livré dans une boîte partagée que quelqu’un lira peut-être.
• Il est accepté puis renvoyé en erreur, quelques minutes ou quelques heures plus tard, sous la forme d’un message de rebond distinct, bien après la fin de la conversation du vérificateur.
• Il est supprimé sans bruit.

Le deuxième cas est le plus dangereux. Un rebond qui arrive tard compte quand même contre vous auprès de votre service d’emailing, et il indique toujours aux fournisseurs de messagerie que vous écrivez à des adresses qui n’existent pas. Votre rapport de vérification était propre, et votre réputation a payé quand même.

Comment les vérificateurs le détectent

Puisque le serveur dit oui à l’adresse réelle, le vérificateur l’interroge sur une adresse qui n’existe certainement pas. BounceIntel le fait sur la même connexion SMTP que pour l’adresse soumise : il envoie un second RCPT TO pour une partie locale aléatoire de 15 caractères sur le même domaine. Aucun message n’est envoyé, ni dans un cas ni dans l’autre.

• Si l’adresse aléatoire est refusée, le serveur vérifie réellement les boîtes, et son acceptation de votre adresse a un sens.
• Si l’adresse aléatoire est acceptée, le domaine est catch-all, et l’acceptation de votre adresse ne dit rien sur cette boîte.

Pour quelques fournisseurs de messagerie dont les serveurs ont un comportement bien à eux, la sonde est ignorée et des règles propres au fournisseur s’appliquent à la place.

Dans la réponse de l’API, un catch-all détecté ressemble à ceci. C’est un résultat réel pour un nom inventé sur notre propre domaine, qui accepte le courrier pour n’importe quelle adresse :

{
  "input": "[email protected]",
  "is_reachable": "risky",
  "smtp": {
    "can_connect_smtp": true,
    "is_deliverable": true,
    "is_catch_all": true,
    "is_disabled": false,
    "has_full_inbox": false
  },
  "score": {
    "reason_codes": ["catch_all", "catch_all_high_risk"],
    "catch_all": {
      "severity": "high",
      "confidence": 55,
      "factors": ["catch_all:corporate_domain", "website:present", "auth_records:present"]
    }
  },
  "bounce_risk": { "action": "verify_manually" }
}

Remarquez smtp.is_deliverable: true. Le serveur a bien accepté l’adresse, et c’est justement la réponse qu’on ne peut pas prendre au pied de la lettre.

Pourquoi « valide » est un mensonge ici

Beaucoup d’outils de vérification présentent une adresse catch-all acceptée comme valide ou délivrable, parce que techniquement le serveur a dit oui. Mais le serveur dit la même chose d’un vrai salarié et d’un nom que vous avez inventé il y a trente secondes. Une étiquette qui donne la même réponse aux deux n’est pas une information. C’est une supposition déguisée en résultat.

Les dégâts sont prévisibles. Une liste passe la vérification, le taux de rebond grimpe malgré tout, et c’est le vérificateur qui est accusé. C’est pire encore avec les listes construites par déduction, quand quelqu’un a généré [email protected] pour chaque nom trouvé sur un site ou acheté un fichier de ce genre d’adresses. Sur un domaine catch-all, chaque supposition « se vérifie », et la liste paraît parfaite jusqu’au moment de l’envoi.

BounceIntel ne classe jamais une adresse catch-all comme sûre. is_reachable vaut risky, score.safe_to_send vaut false, et le code de raison catch_all explique pourquoi, afin qu’aucune partie de votre code ne la confonde avec une boîte confirmée.

Noter les catch-all et send_with_caution

Qualifier toutes les adresses catch-all de risquées est honnête, mais peu utile à lui seul : en B2B, une grande partie d’une liste parfaitement saine peut se trouver sur des domaines catch-all. BounceIntel évalue donc chaque adresse selon les indices qui l’entourent et le résume dans score.catch_all, sous la forme d’une severity (low, medium ou high), d’une valeur de confidence et des factors qui les justifient.

Le point de départ dépend du domaine. Un domaine d’entreprise commence en gravité élevée ; un fournisseur grand public gratuit commence en gravité faible. Les indices la font ensuite évoluer :

La gravité est reprise sous forme de code de raison exploitable dans votre code : catch_all_low_confidence, catch_all_medium_confidence ou catch_all_high_risk. La recommandation de bounce_risk.action suit ensuite le risque global de l’adresse. Une adresse catch-all appuyée par de bons indices revient en général avec send_with_caution, une adresse avec peu d’indices avec verify_manually, et une adresse qui cumule d’autres mauvais signaux, comme une adresse générique sur un domaine sans site web, avec do_not_send.

send_with_caution veut dire exactement cela. L’adresse est probablement bonne, et elle doit quand même partir d’une manière qui limite les dégâts si elle ne l’est pas.

Règles B2B : garder ou exclure

La vérification vous fournit les indices. Ce que vous faites d’une adresse catch-all relève d’une politique, et il vaut la peine de l’écrire pour que toute l’équipe l’applique de la même façon. Voici les règles que nous recommandons.

Gardez l’adresse, et envoyez-lui dans un segment à part, quand :

• elle provient d’un formulaire rempli par la personne elle-même, idéalement avec double opt-in, ou d’une vraie conversation ;
• le contact a ouvert, cliqué ou répondu ces derniers mois ;
• sa gravité est low ou medium, ou elle suit un format de nom déjà vérifié dans cette entreprise ;
• elle appartient à une personne nommée, sur un domaine qui a un site web et SPF ou DMARC en place.

Excluez-la quand :

• c’est une adresse générique comme info@ ou sales@ dans une liste froide, où les codes catch_all et role_account apparaissent ensemble ;
• elle a été devinée, collectée par scraping ou achetée, quoi qu’en dise un vérificateur ;
• sa gravité est high et vous n’avez aucun historique d’engagement avec elle ;
• elle a déjà fait un hard bounce, ne serait-ce qu’une fois. Ne réessayez jamais un hard bounce.

Quand vous envoyez à des adresses catch-all :

1. Placez-les dans un segment séparé de vos adresses confirmées, pour qu’un problème reste circonscrit.
2. Commencez par un petit lot et regardez le taux de rebond avant d’envoyer le reste.
3. Arrêtez-vous et analysez si les rebonds augmentent, au lieu d’envoyer tout le segment.
4. Retirez immédiatement chaque hard bounce, de toutes les listes.
5. Vérifiez à nouveau le segment avant la campagne suivante, car les indices de format sur lesquels repose le score s’accumulent à chaque vérification.

Testez vous-même une adresse catch-all

Dans votre code, lisez smtp.is_catch_all dans la réponse de POST /v1/check_email, ou dans chaque ligne d’un job en masse, et orientez vos décisions selon score.catch_all.severity et bounce_risk.action. La documentation de l’API décrit chaque champ, et la vérification en masse montre comment faire passer une liste entière par les mêmes contrôles.