Cloudflare Email Routing n’est pas un fournisseur de messagerie comme les autres : il réexpédie le courrier reçu sur votre domaine vers une boîte existante. Il ne sert pas à envoyer. Cette nuance change entièrement la configuration DMARC — et la simplifie beaucoup.
Votre domaine n’envoie rien. Dites-le.
Si tout votre courrier sortant part d’ailleurs — Gmail, iCloud, une plateforme — et que Cloudflare ne fait que router l’entrant, alors aucun serveur n’est légitime pour envoyer sous ce domaine via Email Routing. C’est le cas le plus simple et le plus sûr qui soit :
v=spf1 -all
v=DMARC1; p=reject; rua=mailto:votre-adresse@votredomaine.comUn domaine qui n’envoie pas peut passer directement en reject sans période d’observation : il n’y a rien à casser. C’est même le seul cas où sauter les paliers est la bonne décision. Attention toutefois : si vous envoyez aussi depuis ce domaine, cette configuration bloque vos propres messages — reprenez alors la progression normale.
Ce que Cloudflare fait à votre place
La réexpédition casse SPF par construction : le message arrive chez le destinataire final depuis les serveurs de Cloudflare, pas depuis ceux de l’expéditeur d’origine. Deux mécanismes évitent la casse :
- La réécriture de l’enveloppe (Sender Rewriting Scheme) : Cloudflare remplace l’adresse d’enveloppe par une des siennes, ce qui fait passer SPF à l’arrivée.
- ARC : les résultats d’authentification constatés à la réception sont scellés et transmis au fournisseur final, qui peut en tenir compte au lieu de rejeter un message légitime.
Depuis le 3 juillet 2025, Cloudflare exige que le courrier entrant passe SPF ou DKIM pour être réexpédié. Un expéditeur mal authentifié ne vous atteindra donc pas — ce n’est pas un défaut, c’est le comportement attendu.
Erreurs fréquentes
- Croire qu’Email Routing permet d’envoyer. Il ne le permet pas. L’envoi passe par un autre service, et c’est celui-là qui doit apparaître dans votre SPF et signer en DKIM.
- Publier un SPF permissif « au cas où » sur un domaine qui ne fait que recevoir. C’est une porte ouverte sans contrepartie.
- Les rapports de non-remise ne sont pas réexpédiés. Un message rebondi à la destination finale ne remonte pas à l’expéditeur d’origine : surveillez vos rapports pour ne pas le découvrir trop tard.
- Oublier les sous-domaines. Sans
sp=, ils héritent de la politique du domaine parent — ce qui est en général exactement ce qu’on veut ici.
Une fois en place, Clarsend lit vos rapports et vous montre ce qui passe, ce qui échoue, et qui envoie sans que vous le sachiez.