La plupart des entreprises possèdent plus de domaines qu’elles n’en utilisent. Il y a la marque acquise jamais migrée, la faute d’orthographe courante achetée par précaution, le domaine d’une campagne datant de deux ans et la variante nationale enregistrée par quelqu’un parce qu’elle était bon marché.
Aucun n’a besoin de boîtes. Tous reçoivent des messages: un client qui a saisi l’ancien nom, un fournisseur qui utilise encore une adresse antérieure à l’acquisition ou un système automatique que personne n’a mis à jour. Ces messages rebondissent très probablement et personne ne connaît leur nombre.
Un catch-all externe les gère sans rien créer: il dirige tout le domaine vers une adresse que vous consultez déjà. Pas de boîte, de stockage, de coût par utilisateur ni de mot de passe à gérer. Les compromis sont réels et méritent d’être compris avant l’activation.
Trois façons de gérer une adresse
| Mécanisme | Ce qui existe | Stockage | Envoi possible sous cette identité |
|---|---|---|---|
| Boîte | Stockage réel, identifiant propre | Oui, quota propre | Oui |
| Alias | Adresse supplémentaire d’une boîte existante | Non, partage celui de la cible | Oui, si l’envoi est activé |
| Acheminement catch-all | Rien, une règle au niveau du domaine | Aucun | Non |
Le catch-all est le seul mécanisme pour lequel aucune adresse n’est définie. Toute partie locale du domaine, comme sales@, john@ ou qwerty@, est acceptée et remise à la destination indiquée. C’est à la fois sa force et son problème.
Ce que fait un catch-all externe
La destination d’un catch-all peut être une boîte du même domaine ou une adresse située ailleurs, comme votre adresse professionnelle principale, une boîte partagée de l’équipe sur le domaine principal ou une file d’assistance. Le second cas est le catch-all externe.
Il devient utile pour les domaines que vous possédez mais auxquels personne n’est affecté. Rien ne doit être créé sur le domaine parqué. Ajoutez-le, faites pointer MX vers le service, choisissez la destination et l’opération est terminée. Les messages qui auraient rebondi arrivent désormais là où quelqu’un les lit.
Deux protections s’appliquent, chacune pour de bonnes raisons.
Une destination du même domaine doit être une boîte active. Diriger le catch-all d’un domaine vers une adresse de ce même domaine qui n’est pas une véritable boîte renverrait la tentative de livraison vers la même règle, créant une boucle qui produit des messages jusqu’à la défaillance d’un composant. La règle est refusée plutôt qu’acceptée pour échouer ensuite.
Un catch-all externe exige Pro ou Agency. Acheminer vers une adresse extérieure signifie que nous acceptons des messages en votre nom et les renvoyons à un tiers. Il s’agit d’une opération d’envoi qui a des conséquences sur la réputation, réservée aux offres qui comprennent l’envoi.
Les situations parfaitement adaptées au catch-all externe
Domaines parqués et défensifs. acme-inc.com lorsque vous utilisez acme.com. Personne n’a de raison d’y disposer d’une boîte, mais il est utile de ne pas rejeter les messages reçus.
Une marque acquise. Des messages continuent d’arriver pendant des années aux adresses de l’ancienne entreprise. Un catch-all externe les remet à la personne qui gère désormais la relation, sans migration de boîtes ni recherche des adresses auparavant utilisées.
Domaines réservés à l’envoi. Un domaine de campagne ou transactionnel envoie des messages mais n’a aucun destinataire humain. Il doit néanmoins accepter les réponses et les rebonds; les supprimer en silence empêche de voir les avis d’absence, les réclamations et le client qui a cliqué sur Répondre.
Découvrir ce qu’un ancien domaine reçoit réellement. Acheminez-le vers un dossier pendant un mois et lisez le journal. La réponse est souvent «deux vrais messages et beaucoup de bruit», ce qui permet de décider s’il faut créer une solution formelle ou laisser le catch-all fonctionner.
Ce que vous coûte un catch-all externe
Un catch-all externe accepte tout, ce qui entraîne des conséquences différées.
Les attaques de collecte d’annuaire ne sont plus rejetées. Les outils de spam sondent les domaines avec des listes de dictionnaire, comme info@, admin@, a@ et ab@. Sans catch-all, le domaine rejette les adresses invalides pendant la conversation SMTP, à peu de frais. Un catch-all les accepte toutes; une sonde qui n’aurait rien dû coûter impose le traitement du message complet.
Le volume est illimité et imprévisible. Dès que l’on sait qu’un domaine avec catch-all externe accepte tout, la liste des adresses circule. Ce n’est pas une évolution progressive: le domaine peut rester silencieux pendant des mois, puis devenir soudain très bruyant.
Votre domaine devient invérifiable. Quiconque cherche à vérifier l’existence d’une adresse reçoit «oui» pour chaque adresse, puisque vous acceptez tout. Les services de vérification voient alors le domaine comme accept-all et classent ses adresses parmi les adresses risquées, y compris les vraies. Consultez ce que les contrôles de vérification démontrent réellement.
Les fautes de frappe sont livrées en silence. Sans catch-all, un message à jhon@ rebondit et l’expéditeur corrige l’adresse. Avec un catch-all externe, il arrive dans le réceptacle et l’expéditeur pense que John l’a reçu. Souvent, personne ne le remarque pendant plusieurs semaines.
L’analyse générale du compromis se trouve dans le comportement réel du courrier catch-all. En bref, il convient à un domaine dans lequel personne ne travaille et beaucoup moins à un domaine utilisé au quotidien.
Le problème d’authentification du catch-all externe
Un catch-all externe effectue un transfert, et le transfert rompt l’authentification SPF. Le message conserve son expéditeur initial, mais arrive à destination depuis nos serveurs, que l’enregistrement SPF de cet expéditeur n’a jamais autorisés.
Sender Rewriting Scheme répare automatiquement la partie SPF en réécrivant l’expéditeur d’enveloppe avec un domaine qui nous autorise. Il s’applique sans configuration. Il ne peut pas réparer une signature DKIM altérée en transit ni aider si le domaine initial publie p=reject et que le destinataire applique une politique stricte.
Conséquence pratique: si vous acheminez un catch-all externe vers Gmail, certains messages peuvent finir dans les indésirables, notamment ceux provenant de domaines aux politiques les plus strictes, qui sont souvent légitimes. Consultez le dossier des indésirables pendant les deux premières semaines. Plus de contexte dans SRS et les messages transférés.
Quand les alias conviennent mieux
Pour un domaine dans lequel des personnes travaillent réellement, les alias surpassent un catch-all externe sur tous les plans.
La plupart des organisations utilisent moins de dix adresses réelles: info@, sales@, support@, billing@ et quelques noms. Les définir explicitement permet de rejeter toutes les autres pendant la conversation SMTP, à peu de frais, bloque la collecte et fait rebondir une faute de frappe afin que l’expéditeur la corrige.
Les alias offrent aussi des fonctions impossibles avec un catch-all. Vous pouvez envoyer depuis un alias, afin qu’une réponse adressée à billing@ provienne de billing@ plutôt que de votre adresse personnelle. Vous pouvez acheminer différents alias vers différentes boîtes. Un alias livre par ailleurs dans une vraie boîte, où les messages peuvent être recherchés, filtrés et sauvegardés.
La décision se réduit à une question: quelqu’un travaille-t-il dans ce domaine? Si oui, utilisez des alias. Sinon, un catch-all externe. Consultez les alias et les boîtes.
Configurer un catch-all externe
- Ajoutez le domaine et configurez le DNS pour que MX pointe vers le service. Sans MX, rien de tout cela ne s’applique et les messages continuent d’aller à leur destination précédente.
- Ouvrez l’onglet Acheminement du domaine.
- Activez le catch-all et saisissez l’adresse de destination.
- Enregistrez. La règle prend effet immédiatement, sans délai de propagation de notre côté.
Faites ensuite ce que beaucoup omettent: envoyez un message de test à une adresse fantaisiste du domaine et vérifiez son arrivée. C’est le seul moyen de savoir si la règle est active et pas seulement enregistrée, et cela prend trente secondes.
Si la destination est une boîte que vous lisez réellement, ajoutez un filtre qui range ces messages dans un dossier dédié. Sinon, le volume du réceptacle submerge la boîte et une configuration raisonnable finit par être désactivée par agacement trois semaines plus tard. Les filtres côté serveur agissent à la livraison, avant que quoi que ce soit n’atteigne votre téléphone.
Questions fréquentes
Ai-je besoin d’une boîte sur le domaine pour utiliser un catch-all externe?
Pas si la destination est extérieure. C’est précisément l’intérêt pour un domaine parqué: rien n’y est créé. Si la destination appartient au même domaine, elle doit être une boîte active, sinon la règle boucle.
Les messages catch-all utilisent-ils mon stockage?
L’acheminement vers une adresse externe n’en utilise pas. Vers l’une de vos boîtes, les messages y sont stockés et consomment son quota.
Puis-je répondre depuis l’adresse catch-all?
Non. Un catch-all ne définit aucune adresse, il n’existe donc aucune identité d’envoi. Les réponses proviennent de la boîte qui a reçu les messages. Pour envoyer sous une adresse précise, créez un alias.
Pourquoi le catch-all externe est-il réservé à Pro et Agency?
Acheminer vers une adresse extérieure signifie renvoyer des messages en votre nom, une opération d’envoi qui a des conséquences sur la réputation. Elle est proposée avec les offres qui comprennent l’envoi.
Les messages du catch-all externe finiront-ils dans les indésirables?
Certains peuvent y finir. Le transfert rompt l’autorisation SPF initiale; SRS la répare automatiquement, mais personne ne peut réparer une signature DKIM altérée en transit. Vérifiez les indésirables de la destination pendant les deux premières semaines.
Comment arrêter l’avalanche lorsqu’elle commence?
Désactivez le catch-all et définissez des alias explicites pour les adresses qui se sont révélées réelles. En attendant, filtrez le réceptacle dans son propre dossier afin qu’il ne concurrence plus votre boîte principale.
Puis-je configurer un catch-all externe par API?
Oui, sa configuration est accessible par l’API REST et aux agents via MCP, une méthode raisonnable pour la gérer sur un portefeuille de domaines clients.
