Adresse catch-all : fonctionnement, risques et alternatives

Le catch-all e-mail dirige les messages pour les destinataires inconnus du domaine vers une destination précise. Pour ghost@yourdomain.com, un serveur peut refuser ce destinataire avec 550 sans forcément fermer la connexion. Un catch-all peut répondre 250 OK au destinataire ; ce n'est pas encore l'acceptation définitive du contenu après DATA.

En 2026, récupérer une faute de frappe reste utile, mais volume, réputation et données personnelles demandent des contrôles. Les effets dépendent de l'usage et de la configuration.

Ce guide explique SMTP, cinq domaines de risque, l'authentification du transfert et les choix de configuration.

Qu'est-ce que le catch-all ?

Le catch-all e-mail, également nommé accept-all ou règle générique, affecte les destinataires inconnus d'un domaine valide à une route de repli. Au lieu d'un refus 550 pour une adresse inexistante, le serveur peut admettre le destinataire puis remettre le message s'il passe les autres contrôles.

Les interfaces utilisent accept-all et catch-all pour ce comportement : les destinataires sans correspondance à RCPT TO ont une destination de repli. Dans TrekMail, examinez Domaines → Routage, nommé Connexion dans les anciennes interfaces, → Boîte catch-all et choisissez un destinataire autorisé. Vérifiez l'application du changement et le parcours réel, sans supposer un effet instantané.

Entre la fin des années 1990 et 2026, le trafic automatisé a modifié les besoins de contrôle. Un catch-all peut masquer les adresses existantes lors d'une sonde, mais les destinataires fictifs peuvent aussi accroître traitement et stockage.

Pourquoi activer le catch-all et que vérifier ?

Deux motivations courantes sont récupérer des contacts mal adressés et éviter des licences supplémentaires. Comparez-les aux alias explicites, aux besoins réels en boîtes et à la charge de réception.

Récupérer les fautes de frappe

Une entreprise peut craindre de perdre un contact à cause de suport@ au lieu de support@. Le catch-all peut le récupérer, tout en recevant du trafic inventé. Désignez un responsable et une procédure permettant de retrouver le courrier utile parmi les indésirables.

Pour les erreurs connues, créez des alias précis. Avec support@, ajoutez par exemple suport@ vers la même boîte. Cela limite les destinataires arbitraires, sans remplacer les filtres et contrôles.

Le coût des licences

Une référence historique Google Workspace et Microsoft 365 situe les licences à $6-30 par utilisateur et par mois. support@, billing@, jobs@ et marketing@ avec quatre licences indépendantes pourraient coûter jusqu'à $120/mois dans cet exemple. Alias, boîtes partagées et licences existantes peuvent avoir d'autres conditions : le catch-all n'est pas obligatoire.

Comparez coût complet, droits et contrôles. Le stockage mutualisé peut changer le calcul sans supprimer seul les risques. Consultez les offres TrekMail et leurs conditions actuelles.

Le fonctionnement en SMTP

À RCPT TO, l'émetteur indique le destinataire avant de transmettre le contenu. Le serveur peut l'admettre ou le refuser, puis appliquer d'autres contrôles. La sécurité dépend aussi de l'authentification, des filtres, du routage et de l'acceptation définitive.

Le refus d'un destinataire inconnu

S: EHLO mail.sender.com
S: MAIL FROM: <sender@sender.com>
S: RCPT TO: <ghost@yourdomain.com>
R: 550 5.1.1 User unknown
(connection closed - zero bytes of message body transferred)

Le destinataire ghost n'existe pas et le serveur répond 550. L'exemple simplifie l'échange : la connexion n'est pas obligatoirement fermée et des commandes SMTP ont déjà circulé. Aucun contenu n'est accepté pour ce destinataire, mais la transaction peut comprendre d'autres destinataires valides.

Le parcours catch-all

S: EHLO mail.sender.com
S: MAIL FROM: <sender@sender.com>
S: RCPT TO: <ghost@yourdomain.com>
R: 250 OK
(full message body, headers, attachments transferred)
→ routed to catchall-bucket@yourdomain.com

La route admet le destinataire inconnu. L'acceptation définitive du contenu vient ensuite et peut dépendre de filtres pendant DATA. Une fois le message accepté, le serveur doit gérer remise, stockage et erreurs sans notifier des identités falsifiées.

À grande échelle, refuser les destinataires inconnus peut économiser analyses et stockage. Le catch-all peut accroître la charge, sans obliger à accepter tout contenu avant filtrage. Vérifiez limites et étapes de filtrage avec le fournisseur.

Les 5 risques opérationnels

Admettre des destinataires inventés élargit la réception et peut augmenter les indésirables. C'est un changement du serveur, pas une promesse liée à la propagation DNS. Examinez les domaines suivants avant activation.

Risque 1 : sondes d'annuaire et volume

Les attaques de collecte d'adresses essaient des millions de noms : admin, david, invoice, hr, webmaster, noreply. Elles cherchent à distinguer destinataires admis et refusés.

Une réponse 550 peut révéler une adresse inexistante, sans obliger l'attaquant à s'arrêter. Le catch-all complique la distinction entre adresses créées et inventées. Passer de 50 messages quotidiens à 50,000 est néanmoins un scénario de charge qui peut consommer quotas et filtres et masquer le courrier légitime.

Risque 2 : backscatter et réputation d'envoi

Le backscatter survient lors de notifications ultérieures à une identité d'enveloppe falsifiée. Exemple :

1. Un attaquant envoie à random-gibberish@yourdomain.com sur un domaine avec catch-all.
2. Il falsifie MAIL FROM, reflété à la remise dans Return-Path, en désignant une victime : victim@gmail.com. Un en-tête fourni par l'attaquant ne fixe pas de manière fiable l'identité d'enveloppe.
3. Le serveur accepte définitivement le message après avoir admis le destinataire.
4. Un filtre ultérieur détecte un indésirable et signale un échec interne.
5. Si le serveur produit un NDR vers l'expéditeur d'enveloppe, reflété dans Return-Path, il l'adresse à victim@gmail.com.
6. La victime reçoit une notification non sollicitée pour un message qu'elle n'a pas envoyé.

Ce trafic peut nuire à la réputation et contribuer à des listes comme ips.backscatterer.org. Refusez pendant SMTP lorsque pertinent ou utilisez une quarantaine sûre sans réponse aux identités falsifiées. Consultez l'analyse de la réputation du domaine.

Risque 3 : responsabilité du routage

Un message pour partnerships@company.com peut finir dans la boîte commune. Sans responsable, il peut rester plusieurs jours sans être lu. Définissez propriétaire, accès et revue selon l'urgence du trafic.

Les alias explicites permettent de choisir qui reçoit chaque adresse. Vérifiez le destinataire de partnerships@ et documentez la responsabilité ; l'alias ne garantit pas seul une réponse.

Risque 4 : assistance des prestataires de services gérés

Pour les agences gérant 50+ domaines, prévoyez des réponses à des incidents comme :

• “La boîte est pleine et lente” : examiner quota, stockage et volume.
• “Je reçois trop de spam” : examiner filtres et destinataires admis.
• “Je ne trouve pas le message du client” : il peut être, par exemple, à la page 400 de la boîte commune.
• “Mes envois arrivent dans le spam” : examiner authentification, réputation et notifications indues.

Dans une comparaison entre catch-all et alias, 30-40% d'incidents en moins peuvent servir d'objectif indicatif de planification, pas de résultat mesuré ou promis. Mesurez volume réel et temps de revue avant et après le changement.

Risque 5 : minimisation et protection des données

L'article 5(1)(c) du GDPR impose la minimisation selon la finalité applicable. Un catch-all peut recueillir des informations inutiles, mais l'analyse dépend de l'objectif, de la base juridique, des accès et de la conservation. Définissez quelles données sont reçues et comment elles sont traitées.

Retrouver des données parmi 500,000 messages peut compliquer une demande d'effacement. Si doctor@yourclinic.com dirige des informations de santé vers une boîte commune, examinez rôles, autorisations, flux et garanties HIPAA lorsque pertinentes. L'accès de techniciens ne constitue pas à lui seul une violation : il faut évaluer le traitement réel.

SPF, DKIM et DMARC avec catch-all

Le catch-all ne casse pas directement ces protocoles. Les résultats dépendent des expéditeurs, des identités, des signatures et des modifications lors du transfert. Séparer authentification, réputation et routage aide au diagnostic.

Lors du transfert, examinez IP intermédiaire et identités réelles. Les rapports DMARC concernent le domaine From initial, pas toujours celui du relais. Google Postmaster Tools fournit des données agrégées éligibles pour Gmail personnel, pas un journal complet du catch-all ou de chaque échec d'authentification.

Le problème du transfert

Tout transférer vers Gmail personnel peut sembler commode, mais nécessite contrôle des expéditeurs, des filtres, de l'authentification et des accès. Un destinataire inconnu ne doit pas créer un transfert indiscriminé.

Pourquoi l'authentification peut échouer

Le destinataire voit une connexion depuis votre IP intermédiaire, tandis que From: peut conserver bank@chase.com. SPF évalue l'identité SMTP, pas cet en-tête seul. Examinez enveloppe et signatures :

1. SPF : avec MAIL FROM du domaine initial, l'IP intermédiaire doit être autorisée par ce domaine.
2. DKIM : un pied de page, sujet ou fichier joint modifié peut invalider une signature si les parties signées sont touchées ; d'autres causes existent.
3. DMARC : SPF ou DKIM réussi et aligné suffit. Si aucun ne satisfait ce critère, le destinataire applique les politiques pertinentes.

Le résultat peut être refus, retard, quarantaine, spam ou autre action, pas toujours une suppression silencieuse. Pour p=reject, consultez résultat réel, journaux et notifications. Le guide de diagnostic et configuration du transfert détaille les contrôles.

SRS et ARC si vous devez transférer

Pour une migration ou un ancien flux, examinez deux mécanismes : SRS réécrit l'enveloppe et ARC transmet des résultats antérieurs signés. Le besoin dépend du parcours ; un DKIM initial valide et aligné peut satisfaire DMARC sans les deux.

SRS (Sender Rewriting Scheme)

SRS réécrit l'expéditeur d'enveloppe pour évaluer SPF sur le domaine employé par le relais, éventuellement votre domaine. Son SPF doit autoriser l'IP réelle du transfert.

Avant SRS
Envelope From: alice@example.com

Après SRS
Envelope From: SRS0=HASH=TT=example.com=alice@your-forwarder.com

Le destinataire évalue SPF pour your-forwarder.com. Vérifiez autorisation de l'IP et résultat effectif de l'évaluation.

SRS ne résout pas seul l'alignement DMARC. From: conserve alice@example.com, tandis que l'enveloppe utilise your-forwarder.com, sans alignement entre ces domaines. Un DKIM initial valide et aligné peut satisfaire DMARC ; modifier les parties signées peut l'empêcher. Consultez le transfert avec SRS.

ARC (Authenticated Received Chain)

ARC permet aux intermédiaires de transmettre des résultats d'authentification antérieurs dans des en-têtes signés. Une déclaration n'établit pas automatiquement la confiance : chaîne et identité du scelleur doivent être vérifiées.

Le destinataire peut prendre en compte une chaîne ARC valide d'un intermédiaire auquel il fait confiance. RFC 8617 définit ce mécanisme ; la remise dépend toujours des politiques du destinataire.

Validité cryptographique, confiance dans le scelleur et réputation d'envoi sont liées mais distinctes. Recevoir des milliers de messages ne prouve pas seul qu'un intermédiaire soit indigne de confiance. Évitez backscatter et transfert abusif et vérifiez les décisions réelles sans promettre la remise grâce à ARC.

Configurer le catch-all avec des contrôles

Pour récupérer des erreurs, migrer ou préserver une compatibilité, définissez périmètre, responsables et filtres. Ces trois stratégies donnent des critères, pas une isolation ou une sécurité automatiques.

Stratégie A : destination de révision séparée

Utilisez une réception contrôlée avec droits et revue adaptés. Une boîte de quarantaine n'est pas seule une sandbox de sécurité.

1. Créez catchall-quarantine@yourdomain.com avec accès limité, sans Send As, transfert ni réponse automatique.
2. Dirigez uniquement les destinataires inconnus du domaine autorisé vers cette boîte.
3. Dans Microsoft 365, attribuer SCL 9 demande de classer le message comme spam hautement probable ; la politique détermine indésirables, quarantaine et notifications. Ne l'appliquez pas aveuglément à tout le catch-all : vérifiez l'effet avec l'administrateur.
4. Une revue hebdomadaire peut servir de base ; adaptez-la au trafic et à l'urgence sans ignorer de messages légitimes en attente.

Dans TrekMail, vérifiez destination dédiée et vues disponibles. Une vue filtrée n'isole ni stockage ni permissions : examinez accès, filtres, quota et recherche des messages mal adressés.

Stratégie B : Microsoft 365, DBEB et Internal Relay

Pour les domaines faisant autorité, DBEB (Directory-Based Edge Blocking) peut refuser les destinataires inconnus selon l'annuaire. Vérifiez la configuration et la présence de toutes les adresses valides.

Internal Relay Mode désactive DBEB sans créer seul un catch-all. Annuaire, connecteurs, routage et prévention des boucles doivent correspondre à la topologie. Ne changez pas le type du domaine uniquement pour admettre des inconnus : un administrateur autorisé doit examiner le schéma et la charge.

Stratégie C : motifs limités dans Postfix

Les motifs partiels nécessitent un type de table compatible, comme PCRE ou regexp, vérifié et correctement ancré. Dans une table hash ordinaire, l'exemple suivant est littéral, pas un motif générique fonctionnel :

# /etc/postfix/virtual
sales-*@yourdomain.com    sales-bucket@yourdomain.com

Un motif réel vérifié pourrait couvrir sales-q1@, sales-webinar@ et sales-2026@ sans admettre admin@ ou hr@. La table hash montrée ne le fait pas automatiquement. Contrôlez ancrage, domaine, expansion des alias et boucles avant une autre mise en œuvre.

Alias et routage explicite comme alternative

Les alias explicites définissent adresses et responsables et limitent les destinataires arbitraires. Ils peuvent couvrir de nombreux besoins sans catch-all, mais n'éliminent pas spam, échecs d'authentification ou obligations de protection des données.

Alias, boîtes et catch-all : critères de décision

Incluez filtrage, stockage, assistance et suivi de réputation dans la comparaison. Leur effet dépend du trafic et du service. Pour choisir alias ou boîte, consultez la définition, la configuration et les usages des alias e-mail.

Quelles adresses créer ?

Listez les adresses réellement utilisées. Ces cinq exemples ne constituent pas un maximum suffisant pour toute entreprise :

• hello@ ou info@ : demandes générales vers le responsable désigné.
• support@ : assistance vers helpdesk ou boîte partagée.
• billing@ : factures et paiements vers les finances.
• jobs@ ou careers@ : recrutement vers les RH ou une intégration ATS autorisée.
• noreply@ : envoi transactionnel ; définissez le traitement des réponses légitimes sans les supprimer aveuglément.

Cinq alias peuvent couvrir cet exemple, mais d'autres besoins nécessitent davantage. Pour helo@ au lieu de hello@, un refus 550 peut permettre à l'émetteur de corriger, sans garantir qu'il le fasse. Évitez de laisser du courrier utile trois semaines sans revue dans une boîte commune.

Le modèle TrekMail pour catch-all

Vérifiez quelles offres TrekMail permettent catch-all, leurs destinations, limites et tarifs actuels. Le modèle de facturation peut faciliter des adresses explicites sans rendre catch-all nécessaire ni supprimer ses risques.

Exemple de licences utilisateur

À une référence historique de $6-30/mois par boîte, support@, billing@ et jobs@ avec trois nouvelles licences pourraient ajouter jusqu'à $90/mois. Vérifiez prix et solutions d'alias ou de ressources partagées avant de modifier les routes pour économiser.

Comparer l'offre TrekMail

Examinez stockage mutualisé par compte, domaines, boîtes et limites. À titre historique, Starter à $3.50/mois mentionne 50 domaines et Pro à $10/mois en mentionne 100. Vérifiez conditions actuelles et coût des adresses supplémentaires sans supposer capacité illimitée ou gratuité universelle.

Pour une migration ou une compatibilité, configurez une destination séparée avec accès et filtres adaptés. Des boîtes distinctes ne garantissent pas l'isolation de la capacité ou des ressources partagées. Consultez la documentation de la boîte catch-all TrekMail et vérifiez la configuration actuelle.

Examinez deux possibilités selon l'offre actuelle : transfert d'une boîte vers plusieurs destinations avec copie locale facultative et destination catch-all externe lorsqu'elle est permise. Pro et Agency sont cités pour cette seconde option, mais droits, routes et conditions doivent être vérifiés. Un domaine parqué nécessite aussi réception et authentification contrôlées. Consultez le routage d'un domaine sans boîte locale.

Pour comparer, consultez un éventuel essai gratuit de 14 jours et ses exigences actuelles, dont la carte lorsque nécessaire. Dans le modèle Nano avec SMTP externe, configurez ce service pour tous les envois et réponses.

Questions fréquentes

Ces questions aident à évaluer ou retirer un catch-all et à préparer les vérifications nécessaires.

Qu'est-ce que le catch-all e-mail ?

C'est une règle du serveur qui affecte les destinataires inconnus du domaine à un repli. Au lieu de refuser le destinataire avec 550, elle peut l'admettre puis appliquer filtres et acceptation définitive du message. Accept-all et routage générique sont des noms d'interface : vérifiez le fonctionnement concret.

Le catch-all est-il sûr ?

Cela dépend de finalité, filtres, accès, volume, conservation et destination. Il peut accroître la charge ou les notifications indues sans provoquer seul échec d'authentification ou violation réglementaire. Utilisez une destination contrôlée et une revue adaptée à l'urgence, sans appliquer aveuglément un score maximal ou ignorer du courrier légitime.

Peut-il affecter la délivrabilité sortante ?

Indirectement, si des notifications sont envoyées à des identités falsifiées ou du trafic abusif est transféré. Pour l'authentification, examinez enveloppe, signatures et From initial ; les rapports ne concernent pas toujours le relais. Enquêtez sur les résultats concrets plutôt que de supposer une dégradation inévitable.

Quelle différence entre catch-all et alias ?

Un alias définit une adresse et sa route. Le catch-all admet des destinataires inconnus du domaine selon les politiques et les dirige vers un repli. Cinq alias peuvent couvrir un exemple simple ; les besoins réels déterminent combien en créer.

Peut-on l'utiliser avec Google Workspace ou Microsoft 365 ?

Vérifiez fonctions actuelles et permissions. Dans Google Workspace, préparez une règle entrante dans Gmail → Routage, pour destinataires inactifs ou inconnus, qui remplace le destinataire d'enveloppe par la boîte choisie, sans inclure utilisateurs actifs ou groupes. Dans Microsoft 365, Internal Relay désactive DBEB sans créer un catch-all à lui seul : il faut annuaire, connecteurs et routes compatibles sans boucle. Un administrateur autorisé doit valider la topologie avant tout changement. Alias et boîtes partagées peuvent éviter des licences supplémentaires selon leurs conditions.

Comment désactiver un catch-all ?

Identifiez d'abord les destinataires légitimes et préparez alias ou boîtes. Dans cPanel/WHM, examinez Accueil → E-mail → Adresse par défaut et choisissez le refus SMTP avec erreur, pas l'acceptation suivie d'une suppression silencieuse. Dans Google Workspace, examinez Gmail → Routage, ou Routage par défaut si une ancienne règle s'y trouve, et retirez la règle après vérification. Dans Microsoft 365, n'utilisez le mode faisant autorité qu'avec annuaire complet et connecteurs contrôlés. Dans TrekMail, vérifiez Domaines → domaine → Routage, Connexion dans les anciennes interfaces, → Boîte catch-all → Aucun catch-all. Une fenêtre de 24-48 heures peut servir au suivi, pas de délai obligatoire de stabilisation.

Que choisir à la place ?

Définissez alias et routes pour les adresses réellement utilisées. Cinq ou moins peuvent suffire à un cas simple, pas à tous. Comparez boîtes partagées, licences et offres actuelles. Choisissez selon réception, responsables et contrôles, sans supposer qu'une tarification élimine les problèmes d'authentification ou de réputation.