Comment une équipe produit doit-elle mettre en place le routage des e-mails Cloudflare en toute sécurité ?

Définissez la tâche de réception et le périmètre de responsabilité

Commencez par décrire précisément la tâche de réception : quels domaines et parties locales doivent accepter du courrier, à qui appartient chaque destination, si un message doit être transféré, traité par du code ou abandonné, et combien de temps les preuves opérationnelles peuvent être conservées. Cloudflare Email Routing est une couche de routage des e-mails entrants. À elle seule, elle ne crée pas de ticket de support, n’établit pas l’identité de l’expéditeur, ne prouve pas que le courrier transféré est parvenu à un humain et ne garantit pas le placement dans la boîte aux lettres de destination. Gardez ces états applicatifs ultérieurs séparés. Désignez un responsable opérationnel pour le DNS, les règles de routage, le code du Worker, la vérification des destinations, les incidents de sécurité et le retour arrière. Utilisez des alias dédiés comme support@ ou invoices@ plutôt qu’un catch-all lors du premier déploiement. Une route étroite réduit la collecte accidentelle, rend les résultats de test interprétables et limite l’impact d’une destination erronée ou d’une branche de Worker fautive.

Intégrez le domaine sans traiter le DNS comme une étape d’installation à l’aveugle

La documentation actuelle de Cloudflare Email Service indique que le domaine doit utiliser le DNS de Cloudflare pour Email Routing. Le parcours d’onboarding peut ajouter des enregistrements MX pour le routage entrant, ainsi que les enregistrements TXT liés à SPF et DKIM décrits par le produit. Examinez les enregistrements exacts proposés avant de les appliquer. Inventoriez d’abord les MX, SPF, DKIM, DMARC, boîtes aux lettres, services de transfert, jetons de vérification et délégations de sous-domaines existants. Remplacer les enregistrements MX modifie la destination des nouvelles sessions SMTP entrantes : prévoyez une fenêtre de maintenance et conservez les valeurs précédentes comme référence de retour arrière. Évitez de créer plusieurs enregistrements TXT SPF sous un même nom de propriétaire. Après le changement, interrogez les serveurs faisant autorité et des résolveurs publics, puis testez la livraison depuis un compte sans lien avec la destination. Les estimations de propagation DNS ne prouvent pas que tous les expéditeurs voient désormais la même réponse, et un tableau de bord au vert ne prouve pas le transfert de bout en bout.

Vérifiez les destinations avant de créer des routes actives

Cloudflare documente les adresses de destination comme des ressources au niveau du compte, qui doivent être vérifiées avant que les règles de routage puissent les utiliser. Cette étape de vérification est une barrière anti-abus importante : elle démontre le contrôle de la boîte aux lettres à ce moment-là, mais n’établit ni une autorisation métier durable ni l’appartenance correcte à une équipe. Consignez dans votre propre système le demandeur responsable, l’objectif, la date de vérification et la date de revue. Préférez une destination contrôlée par l’équipe à l’adresse personnelle d’un employé. Supprimez rapidement les destinations des personnes parties et vérifiez quelles règles dépendent d’une adresse avant de la supprimer, car Cloudflare indique que la suppression d’une destination désactive les routes qui l’utilisent. Traitez les e-mails de vérification comme sensibles pour la sécurité et ne cliquez jamais dessus automatiquement ni ne les transférez vers une automatisation non fiable. Pour les changements en production, exigez la relecture d’une deuxième personne dans votre processus d’infrastructure habituel, même si le tableau de bord permet à un seul opérateur d’enregistrer la règle.

Créez des règles explicites et comprenez leur priorité

Une règle de routage associe un motif d’adresse à une destination vérifiée ou à un Worker. Cloudflare documente trois actions : envoyer vers une adresse e-mail, envoyer vers un Worker et abandonner (drop). Créez d’abord les routes les plus spécifiques par partie locale, nommez leur propriétaire dans les enregistrements de changement et confirmez qu’il n’existe qu’une seule règle voulue par motif. La documentation avertit que si plusieurs règles utilisent le même motif, seule la première de la liste traite le courrier entrant. Ne vous fiez pas à l’ordre visuel comme règle métier informelle ; supprimez plutôt l’ambiguïté. Justifiez étroitement les règles drop, car la suppression équivaut volontairement à une non-livraison. N’activez le catch-all qu’après avoir recensé ses conséquences en matière de vie privée, de volume de spam, de fautes de frappe et de stockage. Un catch-all peut collecter des adresses que personne n’avait l’intention de créer : il doit donc disposer d’une destination ou d’une politique de Worker dédiée, d’alertes et d’un moyen rapide de désactivation, plutôt que d’hériter discrètement d’une boîte aux lettres personnelle.

Utilisez les sous-adresses à dessein

Cloudflare documente un adressage « plus » optionnel conforme à la RFC 5233. Lorsqu’il est activé, le courrier destiné à une adresse comme user+detail@example.com peut correspondre à la règle de base user@example.com tout en conservant le détail dans le destinataire du message exposé au Worker et dans les logs. Cela peut servir à des tags de routage, à des identifiants de test ou à des alias par workflow, mais le détail est un texte contrôlé par l’expéditeur. Ne le traitez pas comme une identité de tenant authentifiée, une autorisation ou un secret. Normalisez-le et bornez-le avant de l’utiliser comme clé de base de données, dimension de métrique ou nom de file d’attente. Cloudflare indique aussi qu’une règle explicite pour la sous-adresse complète prend le pas sur la règle de base. Testez à la fois le cas explicite et le cas de repli pour qu’une règle spécifique ajoutée plus tard ne modifie pas silencieusement un workflow existant. Évitez de placer des données personnelles ou confidentielles dans les tags plus, car ils peuvent apparaître dans les en-têtes, les logs, les messages transférés, les exports du support et les analyses.

Ne choisissez un Worker que pour de vrais besoins de traitement

Utilisez le transfert direct lorsque le besoin se résume à une adresse vers une boîte aux lettres vérifiée. Routez vers un Worker lorsque vous avez besoin d’embranchements contrôlés, d’inspection des messages, de stockage, de rejet, de réponses ou de transferts multiples. Le gestionnaire d’e-mails de Cloudflare expose l’expéditeur et le destinataire d’enveloppe, les en-têtes, un flux MIME brut, sa taille, ainsi que des méthodes pour transférer, répondre ou rejeter. Gardez le gestionnaire compact : validez d’abord la politique des destinataires, appliquez des limites sur le message et l’analyse, passez les appels externes par des files d’attente limitées dans le temps lorsque c’est possible et définissez l’issue de chaque erreur. Les en-têtes, objets, noms d’affichage, pièces jointes, liens et délimiteurs MIME sont contrôlés par l’attaquant. Ne journalisez pas par défaut les corps bruts ni les adresses complètes. Si le contenu doit être stocké, chiffrez-le, restreignez l’accès par tenant et par tâche, définissez sa suppression et analysez les pièces jointes en dehors du chemin de routage synchrone. Une exception d’analyse ne doit jamais aboutir à un transfert ou à une réponse non voulus.

Implémentez un chemin de décision unique et explicite

Un gestionnaire sûr doit déterminer une action approuvée avant tout effet de bord. Par exemple, associez le destinataire d’enveloppe exact à un workflow configuré, rejetez les destinataires inconnus, mettez en file d’attente un enregistrement de métadonnées borné, puis ne transférez que vers une destination vérifiée choisie dans la configuration. N’acceptez jamais une destination provenant d’un en-tête, d’un objet, d’un tag plus ou du corps du message. Pour un transfert vers plusieurs destinations, la documentation des limites de Cloudflare indique qu’un Worker doit appeler forward une fois par destination vérifiée ; décidez si un succès partiel est acceptable et enregistrez chaque tentative séparément. Utilisez dans les logs un identifiant de corrélation interne stable plutôt que le contenu du destinataire. Si le gestionnaire peut répondre, respectez les contraintes de réponse actuelles de Cloudflare et ajoutez une protection contre les boucles. Une réponse n’est pas un accusé de réception d’une équipe humaine. Si une prise en charge applicative durable est nécessaire, enregistrez le ticket ou l’événement avant d’envoyer une réponse automatique et rapprochez les échecs ambigus plutôt que de promettre que le travail a été créé.

Traitez transferts et réponses comme des résultats au périmètre de preuve limité

Un appel de méthode réussi dans un Worker prouve une opération de la plateforme, pas le résultat final pour l’utilisateur. SMTP définit le transfert entre systèmes, tandis que le filtrage ultérieur, le transfert, la quarantaine, les règles de boîte aux lettres et la lecture humaine restent en dehors de ce saut. Modélisez séparément des états comme reçu par Cloudflare, Worker invoqué, action tentée, accepté par le serveur de destination, retardé ou en échec, et enregistrement applicatif créé. Ne les étiquetez pas tous comme délivrés. Conservez des logs structurés et minimisés pour la vie privée, avec l’identité de la règle, la révision du Worker, l’action, l’horodatage, l’identifiant de corrélation et un résultat grossier ; ne stockez les adresses complètes ou le contenu que là où un besoin opérationnel documenté le justifie. Déclenchez des alertes sur les échecs d’invocation, les rejets liés à la taille, un volume catch-all anormal, des schémas d’expéditeurs répétés, les échecs de destination et les variations soudaines de trafic. Échantillonnez en continu des messages de test contrôlés, mais n’utilisez jamais de vrai contenu client comme jeu de données d’observabilité.

Respectez les limites et modes de défaillance actuels de la plateforme

Cloudflare documente actuellement des limites d’Email Routing, dont 200 règles de routage par domaine, 200 adresses de destination par compte, une taille maximale de 25 MiB pour les messages entrants et les limites standard de CPU et de mémoire des Workers pour les messages routés vers un Worker. Considérez-les comme la documentation actuelle du fournisseur, pas comme des constantes permanentes. Consultez la page des limites en vigueur pendant la planification et déclenchez une alerte bien avant d’approcher un plafond. Les gros messages MIME peuvent épuiser la mémoire ou le CPU même en dessous du plafond de taille brute de la plateforme s’ils sont décodés sans précaution. Traitez en flux ou rejetez le contenu inutile, plafonnez le nombre de pièces jointes et placez l’analyse coûteuse derrière un traitement asynchrone borné. Selon la documentation de routage de Cloudflare, renommer un Worker peut rompre sa liaison de routage : incluez donc l’inspection des routes dans la vérification du déploiement. Les invocations en échec devraient apparaître dans les logs des Workers, mais les logs seuls ne permettent pas de rejouer les messages. Décidez si un expéditeur doit réessayer via SMTP, si un opérateur peut rejouer une tâche applicative en toute sécurité et comment éviter les enregistrements en aval en double.

Testez le déploiement et le retour arrière comme un seul changement

Créez d’abord une route de préproduction ou à faible risque. Envoyez des messages contrôlés depuis un autre compte que la destination vérifiée, en couvrant le texte brut, le contenu multipart, les pièces jointes attendues, l’adressage plus, les parties locales inconnues et des entrées volontairement malformées dans des limites sûres. Vérifiez les réponses DNS, la configuration du tableau de bord, la révision du Worker, le résultat du transfert, l’enregistrement en aval et le comportement en matière de vie privée. Testez ensuite les chemins négatifs : destination non vérifiée, règle désactivée, exception du Worker, message trop volumineux, livraison répétée et règle qui tomberait sinon dans le catch-all. Consignez les preuves attendues à chaque étape. Avant d’étendre le trafic, répétez la désactivation de la règle, la restauration des anciens enregistrements MX si nécessaire, le détachement du Worker et la communication sur le courrier retardé ou rejeté. Revenez en arrière en cas de perte de routage inexpliquée, d’exposition entre tenants, de fuite de contenu, de réponses inattendues, de stockage non borné ou d’échec persistant du Worker. Conservez des instantanés de configuration et les résultats de test sans garder le contenu des messages plus longtemps que nécessaire.

Comment SendHQ s’intègre

SendHQ prend en charge les e-mails entrants. Ce guide traite de Cloudflare Email Routing ; suivez la documentation de chaque service pour sa propre configuration et ses limites.

Questions fréquentes

Sources

• Acheminer les e-mails — Cloudflare
• Règles et adresses d’Email Routing — Cloudflare
• API Workers pour les e-mails routés — Cloudflare
• Limites de Cloudflare Email Service — Cloudflare
• RFC 5321 : Simple Mail Transfer Protocol — RFC Editor
• RFC 5233 : Sieve Email Filtering: Subaddress Extension — RFC Editor