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

Aucun didacticiel Cloudflare Email Routing ne commence par expliquer ce que le service ne fait pas. Ils affichent la configuration en cinq étapes, confirment que l'e-mail a atteint sa destination et se ferment. Ce qui est laissé de côté, ce sont les cas dans lesquels le transfert commence à rejeter les messages légitimes, le fourre-tout devient un spam ou le travailleur supprime le courrier électronique du client parce qu'une ligne de code a généré une exception. Ces cas existent, ils sont prévisibles et il vaut la peine de les connaître avant de mettre le service en production pour quelque chose de critique.

L'envoi via domaine n'existe pas ici

Le point le plus important, et le plus souvent mal compris : Email Routing reçoit les emails. Seulement. Il n'existe aucun moyen d'envoyer un message de voce@seudominio.com en utilisant ce service. Lorsque vous configurez le transfert et que quelqu'un vous envoie un e-mail à contato@seudominio.com, vous le recevez dans Gmail. Lorsque vous répondez dans Gmail, l'expéditeur que voit le destinataire est votre adresse Gmail, et non l'alias de votre domaine.

Pour envoyer des e-mails via votre propre domaine, vous avez besoin d'un service distinct : Resend, SendGrid, Mailgun, Amazon SES, Postmark, Brevo. Chacun d’entre eux nécessitera ses propres enregistrements DNS – SPF et DKIM spécifiques au fournisseur choisi. Cloudflare configure automatiquement les enregistrements SPF pour les enregistrements entrants, mais cela n'a rien à voir avec les enregistrements dont un fournisseur sortant aura besoin. Quiconque mélange les deux flux dans une même configuration DNS se retrouve avec des erreurs d'authentification dans les deux sens.

Le problème de délivrabilité avec le forwarding et DMARC

Lorsque Cloudflare transfère un e-mail, il relaie le message depuis ses propres serveurs, et non depuis les serveurs d'origine de l'expéditeur. Cela crée des frictions avec DMARC qui affectent des cas spécifiques mais importants.

Si l'expéditeur d'origine a une politique DMARC avec p=reject — courante dans les banques, les grandes entreprises, les fournisseurs de messagerie comme Gmail et Outlook — et que l'e-mail est transféré via Cloudflare, le serveur de destination finale reçoit un message dont l'en-tête From: indique le domaine de l'expéditeur d'origine, mais dont l'adresse IP d'envoi appartient à Cloudflare. L'alignement DMARC échoue car SPF vérifie l'adresse IP d'envoi (Cloudflare) par rapport au domaine sur From: (la banque, l'entreprise), et ils ne s'alignent pas.

Cloudflare utilise ARC (Authenticated Receiver Chain) lors du transfert, ce qui préserve les informations d'authentification du saut d'origine. Cela améliore la situation pour les fournisseurs qui comprennent et respectent ARC – Microsoft, Google inclus. Mais ce n’est pas universel. Certains serveurs de messagerie d'entreprise dotés de politiques plus strictes rejettent toujours les e-mails transférés, même avec ARC. Résultat pratique : vous risquez de manquer des e-mails légitimes envoyés depuis des domaines p=reject stricts, et Cloudflare n'a aucun contrôle sur la politique de réception du serveur de destination.

Il n’existe pas de solution complète pour cela dans Email Routing. Quiconque a besoin d'une livraison garantie à tous les expéditeurs possibles a besoin d'une solution avec sa propre boîte de réception : Google Workspace, Fastmail, Microsoft 365.

Catch-all et le spam qui va avec

L'activation du fourre-tout *@seudominio.com est utile : toute adresse que vous indiquez dans les formulaires, les newsletters et les événements tombe dans la même boîte de réception sans avoir à créer d'alias à l'avance. Le problème est que les spammeurs analysent les domaines en essayant de transmettre des e-mails à des adresses aléatoires. Avec catch-all actif, chaque tentative arrive dans votre boîte de réception.

Un domaine avec une certaine visibilité sur le Web peut recevoir des centaines d'e-mails par jour à des adresses qui n'ont jamais existé : info@, admin@, noreply@, sales@, des variations aléatoires. Tout le monde arrive. Gmail dispose de filtres anti-spam, mais le volume crée du bruit.

L'atténuation au sein d'Email Routing lui-même consiste à acheminer le fourre-tout vers un Email Worker plutôt que directement vers une adresse de destination. Le Worker peut vérifier si l'adresse de destination est l'un des alias légitimes que vous avez définis, rejeter tout ce qui ne correspond pas et transférer uniquement le reste. Vous conservez une flexibilité fourre-tout sans accepter toutes les cochonneries.

Le travailleur qui supprime le courrier électronique en production

Les Email Workers ont un comportement qui surprend les développeurs : si le Worker lève une exception non interceptée, le message est rejeté avec une erreur 5xx. Il n’y a pas de nouvelle tentative, il n’y a pas de file d’attente, il n’y a pas de lettre morte. L'e-mail disparaît.

Imaginez un Worker qui POST sur une API externe pour créer un ticket de support. L'API externe est en panne. Le Worker renvoie une erreur réseau. L’e-mail du client demandant de l’assistance est rejeté – et vous ne le saurez jamais à moins que le client ne réessaye et ne se plaigne.

Le modèle correct consiste à envelopper toute la logique de traitement dans un try/catch et, dans catch, à appeler message.forward() pour une adresse de tri manuel. L'e-mail n'est pas perdu et vous pouvez traiter ce qui a échoué après le retour du service externe. Sans cette solution de secours, toute défaillance passagère dans une dépendance Worker entraîne une perte de courrier électronique.

Qu'est-ce qui change lorsque vous dépassez les cas de base

Le simple transfert de quelques alias vers des adresses Gmail ou Fastmail fonctionne de manière fiable et sans surprise. Des problèmes apparaissent lorsque vous ajoutez des dépendances : travailleurs avec des appels externes qui peuvent échouer, fourre-tout sans filtrage, scénarios avec des expéditeurs qui ont restreint DMARC. Dans ces cas, le service est toujours utile, mais il vous oblige à comprendre les surfaces de défaillance et à créer les atténuations correspondantes.