Qu’est-ce qu’un email catch-all ?
Un domaine configuré en catch-all (ou “fourre-tout”) accepte tous les emails qui lui sont envoyés, quelle que soit la boîte locale ciblée. Concrètement, si vous envoyez un message à n'[email protected], le serveur de messagerie l’acceptera — même si cette adresse n’existe pas réellement.
Cette configuration est légale et souvent intentionnelle : certaines entreprises l’utilisent pour s’assurer de ne manquer aucun email entrant en cas de faute de frappe, ou pour récupérer des emails envoyés à d’anciens collaborateurs.
Le problème pour vous : quand votre outil de vérification SMTP “pinge” l’adresse pour savoir si elle existe, le serveur répond systématiquement “oui”. Vous ne pouvez donc pas distinguer une vraie adresse d’une fausse par la méthode classique.
Comment identifier un domaine catch-all ?
La détection nécessite une approche spécifique. Au lieu de vérifier une adresse réelle, on teste une adresse manifestement aléatoire sur le même domaine :
- Générer une adresse impossible :
[email protected] - Envoyer une commande SMTP
RCPT TO - Si le serveur répond
250 OK→ le domaine est catch-all - Si le serveur répond
550 Unknown user→ le domaine n’est pas catch-all
L’API Syvel effectue cette détection automatiquement lors de l’analyse d’une adresse. Le signal catch-all est intégré dans le risk_score retourné — une adresse sur un domaine catch-all verra son score de risque augmenté, reflétant l’incertitude sur sa délivrabilité réelle.
Faut-il envoyer vos campagnes sur des adresses catch-all ?
La réponse courte : cela dépend du contexte, mais dans la plupart des cas, c’est risqué.
Cas 1 : Formulaire d’inscription en ligne
Ne validez pas les adresses catch-all. Rien ne garantit que l’adresse saisie existe réellement. Si vous acceptez [email protected], vous ajoutez un contact qui ne recevra jamais votre email, ou pire, dont la boîte n’existe pas et génèrera un hard bounce différé.
Recommandation : marquez ces adresses comme risquées et demandez une confirmation par double opt-in avant de les activer.
Cas 2 : Base B2B achetée ou enrichie
Dans le contexte du cold email B2B, les adresses catch-all sont très fréquentes (jusqu’à 25-30% d’une base). Les filtrer complètement réduirait drastiquement votre reach.
Recommandation : segmentez-les dans une campagne séparée, avec un volume d’envoi réduit et une surveillance accrue de vos métriques. Si le taux d’ouverture est similaire à vos autres contacts, les adresses sont probablement valides.
Cas 3 : Campagne transactionnelle ou de réactivation
Évitez absolument les catch-all dans ce contexte. Si l’adresse n’existe pas, un rebond différé (le serveur accepte, puis supprime l’email) n’est pas comptabilisé comme bounce immédiat mais dégrade quand même votre réputation sur le long terme.
Les risques concrets d’envoyer sur des catch-all
| Risque | Impact | Niveau |
|---|---|---|
| Hard bounce différé | Dégradation du Sender Score | Élevé |
| Spam trap secondaire | Blacklistage par les FAI | Critique |
| Faux taux d’ouverture | Décisions marketing biaisées | Modéré |
| Perte de crédibilité CRM | Données contact corrompues | Modéré |
Les spam traps sont particulièrement dangereux dans ce contexte : certains FAI configurent des domaines catch-all précisément pour attraper les expéditeurs qui n’ont pas vérifié leurs listes.
Comment Syvel gère les catch-all
L’API Syvel utilise une sonde SMTP en arrière-plan (avec randomisation de la requête pour éviter la détection) pour identifier les domaines catch-all. Le signal est intégré dans le risk_score global de la réponse :
{ "is_risky": true, "risk_score": 62, "reason": "safe", "deliverability_score": 35, "mx_provider_label": null}Ici, reason: "safe" indique qu’aucun signal de domaine jetable confirmé n’a été détecté, mais le risk_score élevé (62, proche du seuil de 65) et le deliverability_score faible (35) reflètent l’incertitude liée au catch-all. is_risky devient true si le score dépasse votre seuil de projet.
Vous pouvez ajuster ce seuil par projet dans votre dashboard pour être plus ou moins tolérant selon votre cas d’usage.
En pratique : quelle stratégie adopter ?
- Formulaires web → Bloquer ou demander un double opt-in pour les catch-all (
risk_score > 50) - Cold email B2B → Envoyer avec prudence, dans un sous-ensemble dédié, volume limité
- Base marketing existante → Identifier les catch-all avant votre prochain envoi et les segmenter
- Transactionnel → Filtrer tous les catch-all, prioriser la délivrabilité
L’outil le plus puissant reste la validation en temps réel à la saisie, avant même que l’adresse n’entre dans votre CRM. C’est le principe de l’API Syvel : intercepter les adresses problématiques au moment de la soumission du formulaire, pas après.
Conclusion
Un email catch-all n’est ni toujours bon ni toujours mauvais. C’est un signal d’incertitude qui doit déclencher une stratégie adaptée à votre contexte. L’ignorer, c’est prendre le risque de dégrader votre réputation d’expéditeur sur le long terme — un actif qui se construit sur des mois et se détruit en quelques campagnes mal ciblées.
Intégrez la détection catch-all dans votre workflow de validation pour prendre des décisions basées sur les données plutôt que sur l’intuition. Découvrez aussi pourquoi le double opt-in ne suffit plus à protéger votre base et comment le fingerprinting MX détecte les nouveaux domaines suspects. Vous pouvez tester la détection catch-all directement sur notre checker d’email.