L'authentification des e-mails comporte trois couches (SPF, DKIM et DMARC) et une erreur courante commise par ceux qui utilisent Cloudflare Email Routing est de supposer que l'activation du service résout les trois à la fois. Cloudflare configure automatiquement SPF pour la réception, gère DKIM via ARC sur les e-mails transférés et ne configure pas DMARC pour vous. Si vous utilisez un fournisseur d'expédition distinct, le SPF et le DKIM de ce fournisseur doivent être ajoutés manuellement. La confusion de ces rôles entraîne le rejet d'e-mails, parfois les vôtres.
Ce que fait SPF et ce que Cloudflare ajoute
SPF (Sender Policy Framework) est un enregistrement TXT dans votre zone DNS qui répertorie les serveurs autorisés à envoyer des e-mails via votre domaine. Lorsqu'un serveur de réception accepte un e-mail prétendant provenir de seudominio.com, il interroge le SPF de seudominio.com pour vérifier si l'adresse IP d'envoi figure dans la liste.
Lorsque vous activez le routage des e-mails, Cloudflare ajoute automatiquement un include:_spf.mx.cloudflare.net au SPF de votre domaine. Cela autorise les serveurs de Cloudflare à recevoir des e-mails pour votre domaine, ce qui est logique, car ce sont eux qui accepteront les messages entrants avant de les transférer.
Le point qui mérite attention : si vous utilisez également un fournisseur d'expédition sortante — Resend, SendGrid, Amazon SES, Mailgun — ce fournisseur possède ses propres serveurs qui doivent apparaître dans votre SPF. L'enregistrement SPF final doit inclure à la fois Cloudflare et le fournisseur d'expédition. Un exemple avec Renvoyer :
v=spf1 include:_spf.mx.cloudflare.net include:amazonses.com ~all
SPF a une limite de 10 recherches DNS par évaluation. Chaque include: compte comme une recherche et peut déclencher des recherches plus récursives. Avec de nombreux fournisseurs combinés, il est possible de dépasser cette limite, ce qui fait échouer le SPF pour tous les expéditeurs, pas seulement pour certains. Des outils comme MXToolbox et dmarcian disposent de validateurs qui comptent les recherches et vous alertent avant que cela ne devienne un problème.
DKIM lors de la réception et de l'envoi
DKIM (DomainKeys Identified Mail) fonctionne via un cryptage asymétrique : le serveur expéditeur signe l'e-mail avec une clé privée et le serveur destinataire vérifie la signature par rapport à la clé publique publiée sous forme d'enregistrement TXT dans le DNS du domaine expéditeur.
Pour les e-mails reçus et transférés via Email Routing, Cloudflare utilise ARC (Authenticated Receiver Chain). ARC est un ensemble d'en-têtes qui enregistre la chaîne d'authentification des e-mails lorsqu'elle passe par des intermédiaires – dans ce cas, le serveur Cloudflare. Lorsque Cloudflare transfère un e-mail, il ajoute des en-têtes ARC qui indiquent au serveur de réception final : "J'ai reçu cet e-mail, la signature DKIM d'origine était valide au moment où il est arrivé ici, et je l'abandonne pour préserver ces informations." Cloudflare re-signe avec sa propre clé DKIM lors du transfert.
Pour les e-mails envoyés par votre fournisseur sortant, DKIM fonctionne différemment. Resend, SES ou tout autre fournisseur d'envoi vous demandera d'ajouter un ou plusieurs enregistrements TXT à votre zone DNS avec leur clé publique DKIM. Vous ajoutez ces enregistrements au tableau de bord Cloudflare et le fournisseur utilise la clé privée correspondante pour signer les e-mails sortant via votre domaine. Cloudflare ne génère ni ne gère cette clé : vous hébergez simplement l'enregistrement TXT créé par le fournisseur.
DMARC : que configurer et dans quel ordre
DMARC (Domain-based Message Authentication, Reporting and Conformance) se trouve dans un enregistrement TXT en _dmarc.seudominio.com et définit ce que les serveurs de réception doivent faire lorsqu'un e-mail échoue simultanément avec SPF et DKIM. Il définit également où envoyer les rapports d'authentification.
Cloudflare ne configure pas DMARC pour vous. Vous créez l'enregistrement manuellement. Un premier bilan raisonnable :
v=DMARC1; p=none; rua=mailto:dmarc@seudominio.com; ruf=mailto:dmarc@seudominio.com; pct=100
p=none signifie « surveiller, ne pas rejeter ». Les rapports arrivent aux adresses définies en rua (rapports agrégés quotidiens) et ruf (rapports médico-légaux de défaillance). Ces rapports au format XML montrent quelles IP envoient des e-mails via votre domaine et quel est le résultat SPF/DKIM pour chacune d'elles.
La séquence correcte est la suivante : activez d'abord p=none, attendez au moins une semaine de rapports, vérifiez que tous les expéditeurs légitimes — le fournisseur d'envoi, les serveurs de formulaires, les outils marketing — apparaissent comme alignés dans SPF ou DKIM. Ce n'est qu'après avoir confirmé cet alignement que vous passez au p=quarantine (les e-mails suspects vont dans le spam) et éventuellement au p=reject (les e-mails suspects sont rejetés à la réception).
L'activation de p=reject avant d'ajouter les enregistrements SPF et DKIM du fournisseur d'envoi est l'erreur la plus courante. Résultat : vos propres e-mails commencent à être rejetés par les serveurs de destination car ils sont envoyés via Resend ou SES, mais SPF n'inclut pas encore ces serveurs, ou l'enregistrement DKIM n'a pas encore été ajouté. DMARC échoue et avec p=reject, l'e-mail est rejeté — silencieusement du point de vue de l'expéditeur.
Que vérifier avant de modifier la politique DMARC
Avant de passer de p=none à une politique plus restrictive, il convient de vérifier trois choses dans les rapports globaux : que Cloudflare apparaît comme étant aligné sur SPF pour les e-mails entrants que vous transférez vers vos propres comptes, que le fournisseur d'envoi apparaît comme aligné sur DKIM pour les e-mails sortants et qu'il n'y a pas d'adresses IP inattendues qui envoient des e-mails via votre domaine - ce qui indiquerait une configuration d'un autre service que vous n'avez pas mappé ou que vous avez mal utilisé.
Des outils tels que dmarcian, Postmark (qui dispose d'un analyseur DMARC gratuit) et MXToolbox facilitent la lecture des rapports XML. Cela vaut le temps investi. Un domaine avec DMARC correctement configuré a moins de chances que de faux e-mails soient acceptés par les destinataires – et moins de chances que des e-mails légitimes soient rejetés en raison d'un échec de configuration.
A lire aussi
- Les limitations de Cloudflare Email Routing que le tutoriel ne mentionne pas
- Cloudflare Email Routing : recevez des e-mails sur votre domaine — et ce qui n'est pas inclus -Cloudflare KV : Que signifie une distribution mondiale lorsque vous devez écrire
- Cloudflare Workers vs Pages : la différence qui compte avant de choisir
- Email Routing vs Improvmx vs Forward Email : comparaison honnête
- Email Routing + Workers : traiter les e-mails par programmation en périphérie