Cloudflare
Email Routing
Email
Domínio
DNS

Cloudflare Email Routing : recevez des e-mails sur votre domaine — et ce qui n'est pas inclus

Cloudflare Email Routing résout un problème spécifique avec élégance et ignore complètement tout ce qui se situe en dehors de cette portée.

Cloudflare Email Routing : recevez des e-mails sur votre domaine — et ce qui n'est pas inclus

De nombreuses personnes supposent qu'avoir des e-mails sur votre propre domaine nécessite de payer pour Google Workspace ou Microsoft 365. Ce n'est pas le cas, du moins si vous avez besoin de recevoir des e-mails sur contato@seudominio.com et de les envoyer dans une boîte de réception que vous utilisez déjà. C'est exactement ce que Cloudflare Email Routing fait, gratuitement, en moins de dix minutes d'installation. Le problème survient lorsque quelqu'un considère cette portée étroite comme un point de départ pour construire quelque chose de plus grand sans comprendre ce que le service ne fait délibérément pas.

Ce que fait le routage d'e-mails, sans fioritures

Le service reçoit les e-mails adressés à votre domaine et les transmet : à une ou plusieurs adresses e-mail vérifiées, ou à un Email Worker que vous écrivez. Juste ça. Il n’y a pas de webmail, pas de boîte de réception propre, pas de protocole sortant IMAP ou SMTP. L'e-mail arrive sur les serveurs de Cloudflare, est acheminé selon les règles que vous avez définies et continue.

Les règles fonctionnent de deux manières. Vous définissez des adresses spécifiques — hello@seudominio.com va à seu@gmail.com, suporte@seudominio.com va à une autre adresse — ou configurez un fourre-tout avec *@seudominio.com qui capture tout ce qui ne correspond à aucune règle spécifique. Les adresses de destination doivent être vérifiées : Cloudflare envoie un lien de confirmation à chaque adresse avant de l'accepter comme destination valide. Simple, pas de surprise.

La taille limite par message est de 25 Mo, ce qui correspond à ce que la plupart des fournisseurs acceptent. Il n'y a pas de limite documentée de volume de messages pour le forfait gratuit, bien que cela puisse changer à mesure que le service évolue.

L'exigence qui surprend les gens

Pour utiliser Email Routing, votre domaine doit utiliser des serveurs de noms Cloudflare. Ne vous contentez pas de pointer les enregistrements MX vers leurs serveurs tout en conservant un autre fournisseur DNS. Vous devez déléguer l'intégralité du domaine à Cloudflare. Lorsque vous activez le routage des e-mails dans le tableau de bord, Cloudflare ajoute automatiquement des enregistrements MX pointant vers leurs serveurs de réception et gère cela dans le cadre de la zone DNS.

Ceci est pertinent car de nombreuses équipes arrivent chez Cloudflare via CDN ou WAF, avec le domaine déjà délégué. Pour eux, Email Routing est simple à activer. Quiconque utilise Cloudflare uniquement comme proxy inverse pour quelques sous-domaines tout en conservant le DNS ailleurs devra migrer la zone entière – une décision plus importante qu'il n'y paraît lorsqu'il existe des enregistrements critiques répartis sur des années de configuration accumulée.

Ceux qui ne veulent pas ou ne peuvent pas déplacer les serveurs de noms ont des alternatives. Improvmx, par exemple, fonctionne avec n'importe quel fournisseur DNS : vous ajoutez un enregistrement TXT pour vérification et deux enregistrements MX, et c'est tout. Le coût est la flexibilité programmatique – Improvmx n’a pas d’équivalent à Email Workers.

Ce que tu ne pourras pas faire avec ça

Il n'est pas possible de répondre à un e-mail de contato@seudominio.com via Email Routing. Lorsque vous recevez un message transféré et cliquez sur « Répondre » dans votre Gmail, l'expéditeur apparaît comme votre adresse Gmail, et non comme votre alias de domaine. Pour envoyer des e-mails depuis votre propre domaine, vous avez besoin d'un service distinct : Resend, SendGrid, Mailgun, Amazon SES, Postmark. Le routage des e-mails n'a rien à voir avec le flux sortant.

Il ne s’agit pas d’une limitation technique accidentelle. Cloudflare a délibérément séparé les problèmes : recevoir des e-mails est une chose, les envoyer en est une autre, et les deux ont des exigences d'infrastructure très différentes. Cela a du sens sur le plan architectural, mais quiconque ne lit pas la documentation avant de configurer perdra du temps à essayer de comprendre pourquoi il ne peut pas expédier.

Autre point surprenant : le service message.reply() disponible dans Email Workers — pour les réponses programmatiques — n'envoie pas via votre domaine. La réponse laisse une adresse noreply@cloudflare.com. Si vous souhaitez des réponses automatiques qui semblent provenir de suporte@seudominio.com, vous devez intégrer un fournisseur SMTP sortant.

La configuration qui fonctionne dans la plupart des cas

Configuration la plus courante pour les petites équipes ou les projets personnels : deux ou trois adresses spécifiques renvoyées vers la boîte de réception personnelle du responsable, plus un fourre-tout pointant vers le même endroit ou vers une adresse dédiée au filtrage. Cela prend moins de dix minutes, fonctionne de manière fiable et élimine le besoin de payer pour Google Workspace simplement pour avoir une adresse avec le domaine de votre entreprise.

Pour une utilisation plus sophistiquée (création automatique de tickets à partir d'e-mails d'assistance, analyse des pièces jointes, filtrage du spam avant le transfert), l'intégration avec Workers est la voie à suivre. L'e-mail arrive au Worker en tant qu'objet avec message.from, message.to, message.headers et message.raw (un ReadableStream avec le message RFC 2822 complet). Vous décidez quoi faire : transférer, rejeter avec raison ou traiter et intégrer à d'autres services. Ce flux mérite un article séparé.

Ce qu'un responsable technique doit décider avant d'activer

La question n'est pas de savoir si le routage des e-mails est bon, mais plutôt de savoir s'il résout votre problème. Si le domaine est déjà sur Cloudflare, si vous avez uniquement besoin de recevoir des e-mails et si l'équipe comprend que l'envoi nécessitera un service distinct, la réponse est oui sans réserve. Gratuit, fiable, scriptable via Workers en cas de besoin.

Si le domaine n'est pas sur Cloudflare et que vous ne souhaitez pas déplacer les serveurs de noms, Improvmx résout le transfert simple sans cette exigence. Si vous avez besoin de quelque chose de plus complet – webmail, IMAP, envoi depuis votre propre domaine – Google Workspace à 30 R$/mois par utilisateur reste l'option la plus rapide à mettre en production sans dette de configuration.

Le risque concret de ne pas en comprendre la portée : quelqu'un met en place Email Routing, suppose que "l'email du domaine fonctionne" et découvre qu'il ne peut pas envoyer seulement en essayant d'envoyer une proposition à un client depuis l'adresse de l'entreprise.

A lire aussi

-Les limitations de Cloudflare Email Routing que le tutoriel ne mentionne pas