Domaines catch-all : ce qu'ils sont et comment les traiter

La vérification d'e-mails classique fonctionne en posant une question au serveur de messagerie : « cette boîte existe-t-elle ? » La plupart des serveurs répondent honnêtement. Les domaines catch-all, non : ils disent oui à toutes les adresses, que quelqu'un les lise ou pas.

Ce guide explique ce qu'est une configuration catch-all, pourquoi elle est courante, comment la détecter, et comment décider intelligemment du sort d'une adresse catch-all sans se rabattre sur un rejet systématique.

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

Un domaine catch-all est configuré avec une règle de boîte joker : tout message envoyé à n'importe quelle adresse du domaine est accepté et remis dans une boîte désignée, au lieu d'être renvoyé comme non distribuable.

Par exemple, si acme.com est configuré en catch-all :

• john.smith@acme.com — remis (probablement réel)
• xq87zk@acme.com — remis aussi (presque certainement faux)
• ceo@acme.com — remis (probablement réel)
• asdfjkl@acme.com — remis (probablement pas réel)

Le domaine les accepte toutes. La vérification SMTP renvoie 250 OK pour chaque adresse de ce domaine.

Pourquoi une organisation configure-t-elle un catch-all ?

Les raisons légitimes ne manquent pas.

Alias de redirection : une entreprise peut vouloir que info@, sales@, hello@, contact@ — et toute variante qu'on pourrait deviner — arrivent dans la même boîte. Plutôt que de créer chaque alias un par un, l'administrateur pose une règle catch-all.

Ne rien perdre : si un client a jane.smith@company.com dans ses contacts et écrit à jsmith@company.com, le catch-all garantit que le message arrive. Pour une équipe en contact avec la clientèle, cela évite des demandes perdues.

Confidentialité : un salarié peut utiliser un alias unique par service (newsletter-amazon@company.com, newsletter-linkedin@company.com) sans créer chaque adresse dans le système de messagerie.

Migration : après un changement de nom de domaine ou un rachat, le catch-all sur l'ancien domaine récupère le courrier adressé aux anciennes adresses pendant la transition.

Ce sont des configurations réelles et fréquentes. Le catch-all n'a rien de suspect en soi : c'est une fonction standard des serveurs de messagerie, utilisée par une part non négligeable des domaines professionnels.

Pourquoi le catch-all met la vérification SMTP en défaut

Une vérification SMTP classique se déroule ainsi :

ou bien :

Sur un domaine catch-all, chaque RCPT TO reçoit un 250 OK. La technique de l'adresse sonde — envoyer une adresse volontairement aléatoire pour observer le comportement du domaine — est la façon de détecter le catch-all :

Si une adresse aléatoire obtient un 250 OK, alors le 250 OK d'une adresse d'apparence réelle ne veut plus rien dire : le SMTP seul ne permet plus de distinguer le distribuable du non distribuable.

Quelle est la proportion de domaines catch-all ?

Les données du secteur situent la part des domaines professionnels configurés en catch-all autour de 10 à 20 %. Le taux est plus élevé sur certains segments :

• Grandes entreprises (les équipes informatiques préfèrent un contrôle centralisé)
• Services professionnels (cabinets d'avocats, cabinets de conseil)
• Entreprises anciennes, avec une infrastructure héritée
• Domaines B2B en général, par rapport au B2C

Chez les fournisseurs grand public (Gmail, Outlook, Yahoo), la configuration catch-all n'est pas possible : ils rejettent toujours les adresses invalides par un 550. Le catch-all est donc avant tout un sujet B2B.

Le problème d'un traitement binaire

L'approche naïve consiste à rejeter tous les domaines catch-all, avec ce raisonnement : si je ne peux pas vérifier l'adresse, je ne devrais pas l'accepter.

Le problème, c'est que vous rejetteriez une part considérable de vos prospects B2B légitimes. Un outil commercial qui refuse cmo@acme.com parce que acme.com est en catch-all est tout simplement inutilisable pour de la prospection professionnelle.

Le bon modèle est probabiliste : accepter les adresses catch-all qui portent des signaux de légitimité, et rejeter celles qui ont l'air générées automatiquement.

Le score d'une adresse catch-all

Certains services de vérification notent les adresses catch-all avec un modèle d'apprentissage automatique entraîné sur un historique d'envois. Mailbeam ne le fait pas, et il vaut la peine de dire pourquoi : nous n'avons pas de corpus d'envois pour entraîner un modèle, et un indice de confiance produit par un modèle que vous ne pouvez pas inspecter est difficile à exploiter quand il se trompe.

Ce que Mailbeam renvoie à la place est un score additif construit sur un jeu fixe de signaux, aux poids et plafonds publiés :

• Syntaxe, route de messagerie, résultat de la sonde, adresse jetable, adresse fonctionnelle, catch-all
• Une adresse catch-all est plafonnée à 70, parce qu'aucune sonde ne peut la confirmer
• Le champ reason vaut catch_all_unverifiable, et status revient à risky plutôt qu'à deliverable

Chaque point remonte à une vérification précise, si bien qu'un score surprenant reste explicable. Le compromis est assumé : un barème ne battra pas un bon modèle en prédiction sur les adresses ambiguës. Il vous dira ce qu'il sait et où il s'est arrêté, ce dont vous avez besoin pour fixer votre propre seuil.

Mettre en place un traitement par paliers

// Pas encore de SDK : voici le wrapper de 12 lignes de /docs/quickstart.
import { verifyEmail } from "./lib/mailbeam";

async function verifyEmailForUseCase(
  email: string,
  useCase: "signup" | "cold_outreach" | "lead_import"
) {
  const result = await verifyEmail(email);

  // Pas de catch-all : cas simple
  if (!result.catchAll) {
    return { accept: result.valid && result.score >= 50 };
  }

  // Catch-all : des seuils de score selon le cas d'usage
  const thresholds = {
    signup:        40,   // permissif — l'utilisateur est là et motivé
    cold_outreach: 70,   // strict — un bounce à froid coûte cher
    lead_import:   55,   // équilibré
  };

  const threshold = thresholds[useCase];
  return { accept: result.score >= threshold, catchAll: true };
}

Chaque contexte appelle un seuil différent :

Quoi faire dans l'interface

Quand vous détectez une adresse catch-all, plusieurs options s'offrent à vous.

Option 1 : accepter en silence. Retenez un seuil permissif et acceptez sans rien dire. Adapté aux inscriptions B2B, où vous ne voulez pas ajouter de friction pour les utilisateurs en entreprise.

Option 2 : accepter avec une note. Affichez un message non bloquant : « Nous n'avons pas pu vérifier complètement cette adresse — vérifiez qu'elle est correcte avant de continuer. » Utile sur un formulaire de captation de leads.

Option 3 : demander une confirmation. Envoyez un e-mail de confirmation et exigez un clic avant d'activer le compte. C'est la norme pour les inscriptions à forte valeur.

La mauvaise approche consiste à afficher une erreur disant que l'adresse est invalide : elle ne l'est pas. Elle est invérifiable par SMTP standard, ce qui est tout autre chose.

Le catch-all en vérification par lots

En nettoyant une liste, vous rencontrerez des paquets d'adresses catch-all. La bonne approche :

const auth = { Authorization: `Bearer ${process.env.MAILBEAM_KEY}` };

// Envoie la liste ; la réponse est un identifiant de tâche, pas les résultats.
const job = await fetch("https://api.mailbeam.dev/v1/verify/batch", {
  method: "POST",
  headers: { ...auth, "Content-Type": "application/json" },
  body: JSON.stringify({ emails }),
}).then((r) => r.json());

// Attends le webhook batch.completed, ou interroge /v1/jobs/:id jusqu'à la fin.
const { results } = await fetch(
  `https://api.mailbeam.dev/v1/jobs/${job.job_id}/results?format=json`,
  { headers: auth }
).then((r) => r.json());

for (const result of results) {
  // Un domaine catch-all accepte tout, donc le verdict revient en "risky"
  // plutôt qu'en oui ou non franc. Segmente selon le score.
  if (result.status === "risky" && result.reason === "catch_all") {
    if (result.score >= 70)      keepInList(result.email);
    else if (result.score >= 40) flagForReview(result.email);
    else                         suppress(result.email);
  } else if (result.status === "undeliverable") {
    suppress(result.email);
  }
}

Ne supprimez pas les adresses catch-all en bloc. Segmentez-les par score et décidez segment par segment.

En résumé

Les domaines catch-all sont une fonction normale de l'infrastructure de messagerie professionnelle, pas une anomalie. Ils concernent 10 à 20 % des domaines B2B. La vérification SMTP classique est aveugle à leur égard : toute adresse d'un domaine catch-all obtient une réponse positive.

La bonne réponse n'est pas le rejet en bloc, c'est le score probabiliste :

• Détecter le catch-all par une adresse sonde
• Noter l'adresse à partir des signaux du domaine et de la partie locale
• Appliquer des seuils adaptés à votre cas d'usage
• Accepter les adresses à forte confiance, signaler les moyennes, rejeter les faibles

Cette approche préserve la qualité de vos listes sans écarter une part importante de vos utilisateurs B2B légitimes.

Prochaines étapes

• Qu'est-ce que la vérification d'e-mails ?
• API de vérification des domaines catch-all
• Référence de l'API — POST /v1/verify
• Tarifs et offre gratuite de Mailbeam