Configurer SPF, DKIM et DMARC sur Cloudflare

Cloudflare n'héberge pas tes emails : il héberge ton DNS. C'est donc l'endroit où tu publies les trois enregistrements, mais les valeurs, elles, viennent de ton service email (Google Workspace, Microsoft 365, ton hébergeur, ton outil d'emailing). Tout se passe dans DNS > Records. Compte 10 minutes, et une propagation rapide : la plupart des changements sont effectifs en 5 à 15 minutes, là où les autres hébergeurs annoncent 24 à 48 h.

Ces trois réglages permettent aux serveurs qui reçoivent tes emails de vérifier que c'est bien toi qui écris. Ils ne garantissent pas l'arrivée en boîte de réception — le contenu et ta réputation d'expéditeur comptent aussi — mais sans eux, n'importe qui peut envoyer un email à ta place.

Le piège spécifique à Cloudflare est ailleurs : ce n'est pas la saisie des enregistrements, c'est le nuage orange. Un enregistrement mal proxifié et ta réception d'emails s'arrête net, sans rapport avec SPF ou DKIM. On y revient plus bas.

Les valeurs à copier-coller

1. SPF — la liste de ceux qui envoient pour toi

Ce que tu dois remplacer : LE-SERVICE-QUE-TU-UTILISES par la valeur que ton service email t'a donnée. Cloudflare ne fournit pas de valeur SPF « maison » — sauf si tu utilises son propre service de routage d'emails (voir plus bas).

Si tu as plusieurs expéditeurs, ils vont tous dans la même ligne :

v=spf1 include:_spf.mx.cloudflare.net include:_spf.google.com ~all

⚠️ Deux règles que Cloudflare rappelle noir sur blanc :

• Une seule ligne SPF par domaine. Deux enregistrements v=spf1 = SPF cassé, pas SPF doublé.
• Maximum 10 recherches DNS. Chaque include:, a, mx ou redirect en consomme au moins une, et les include: en contiennent souvent d'autres. Au-delà de 10, la vérification renvoie une erreur (permerror) et ton SPF échoue entièrement — pas partiellement, entièrement.

⚠️ Si tu actives Email Routing, Cloudflare pose lui-même un SPF sur ton domaine racine (v=spf1 include:_spf.mx.cloudflare.net ~all). Si tu avais déjà une ligne SPF pour ton fournisseur de boîtes, tu te retrouves avec deux lignes — c'est exactement le conflit décrit ci-dessus. Vérifie et fusionne.

2. DKIM — la signature de tes emails

Cloudflare ne génère pas de clé DKIM (sauf pour son propre service d'envoi). C'est ton service email qui te donne la valeur, et le format change de l'un à l'autre :

Tu recopies exactement ce que ton service affiche : la clé est propre à ton domaine, elle ne se devine pas et ne se recopie jamais depuis un tutoriel.

Trois choses à savoir avant de coller ta clé :

a) Le guillemet au milieu de la valeur est normal. Une clé DKIM en 2048 bits dépasse 255 caractères. Le protocole DNS impose alors de la découper en plusieurs morceaux entre guillemets — tu verras donc quelque chose comme "première partie" "seconde partie". Ce n'est pas une erreur, ce n'est pas propre à Cloudflare (tous les fournisseurs le font, Cloudflare a juste l'honnêteté de te le montrer), et le serveur qui vérifie recolle les morceaux. Ne supprime pas les guillemets à la main.

b) Un DKIM en CNAME arrive proxifié par défaut — et c'est le piège n°1. Cloudflare l'écrit : seuls les enregistrements A, AAAA et CNAME peuvent être proxifiés, et « Proxying is on by default ». Un TXT (_dmarc, SPF, DKIM en TXT) ne peut jamais être proxifié — la question ne se pose pas. Mais un DKIM en CNAME (selector1._domainkey, s1._domainkey…), lui, se crée avec le nuage orange par défaut, et le service email ne retrouve plus sa clé. Passe-le en DNS only (nuage gris) dès la création. Cloudflare a une page de dépannage entière consacrée à ce cas.

c) Un DKIM en CNAME peut aussi être cassé par le CNAME flattening. Si tu as activé cette option, Cloudflare transforme le CNAME en enregistrement A — et le service email ne retrouve plus sa clé. Si ton DKIM en CNAME refuse obstinément de se valider alors que le nuage est bien gris, c'est la chose suivante à vérifier.

3. DMARC — la consigne donnée aux boîtes de réception

Ce que tu dois remplacer : TON-ADRESSE@TON-DOMAINE.fr par une adresse que tu relèves vraiment. C'est là que tu recevras les rapports.

Pourquoi p=none et pas p=reject tout de suite : p=none veut dire « observe et raconte-moi » — personne n'est bloqué, et tu reçois les rapports. Tu regardes pendant 2 à 4 semaines, tu vérifies que tous tes outils légitimes sont bien reconnus, et seulement après tu durcis d'un cran vers p=quarantine, puis p=reject.

⚠️ Si tu utilises le service d'envoi de Cloudflare (« Email Sending »), sache qu'il pose lui-même un enregistrement _dmarc — en p=reject. Une politique stricte que tu n'as pas choisie, publiée avant que tu aies lu le moindre rapport. Si tu envoies aussi depuis d'autres services, vérifie qu'ils passent DMARC avant de laisser ce p=reject en place — sinon, remplace-le par la valeur p=none ci-dessus et durcis par paliers.

Le chemin de clics dans le tableau de bord Cloudflare

Ajouter un enregistrement DNS

1. Connecte-toi au tableau de bord Cloudflare, sélectionne ton compte puis ton domaine.
2. Va dans DNS → Records.
3. Bouton Add record.
4. Choisis le Type (TXT ou CNAME).
5. Remplis le champ Name et le champ de valeur. Attention, son nom change selon le type : Content pour un TXT, Target pour un CNAME, Mail server pour un MX.
6. Laisse le TTL sur Auto.
7. Save.

Le champ « Name » attend le nom relatif. Pour ton domaine racine, tape @. Pour DMARC, tape _dmarc et rien d'autre. Les tirets bas en début de nom sont parfaitement valides en DNS — Cloudflare l'écrit lui-même (« Underscores are valid in DNS and commonly used for service records »), ne t'en inquiète pas.

L'outil DMARC gratuit de Cloudflare

Cloudflare propose DMARC Management, un outil qui collecte et analyse tes rapports DMARC gratuitement, sur tous les plans.

1. Tableau de bord → sélectionne ton compte et ton domaine.
2. Email → DMARC Management.
3. Enable DMARC Management.

Ce qu'il fait : si tu n'as pas encore d'enregistrement DMARC, il te propose d'en créer un. Si tu en as déjà un, il y ajoute une adresse rua supplémentaire, chez Cloudflare, pour recevoir une copie de tes rapports. Ton adresse à toi reste en place. Pour chaque enregistrement analysé (SPF, DKIM, DMARC), il affiche un statut passed ou failed — deux états, pas trois ; l'avertissement sur les 10 recherches SPF est un signal séparé.

Deux limites à connaître : il ne fonctionne que sur le domaine racine (pas sur un sous-domaine comme blog.tondomaine.fr), et il faut compter jusqu'à 24 h avant l'arrivée du premier rapport.

On te le dit franchement : si tu veux seulement voir passer des rapports DMARC, cet outil suffit et il est gratuit. Ce qu'il ne fait pas, c'est te dire en français ce que ces rapports veulent dire, te prévenir quand un nouveau service se met à envoyer en ton nom, ou t'accompagner jusqu'à p=reject sans rien casser. C'est là que nous intervenons.

On ne touche jamais à ta zone DNS à ta place. Tu restes seul aux commandes de ton domaine : nous, on te dit quoi taper, où, et on te dit si c'est bon après.

Les 3 erreurs qu'on voit le plus souvent sur Cloudflare

1. Le nuage orange sur ce que vise ton MX

C'est l'erreur reine de Cloudflare, et elle n'a rien à voir avec SPF ou DKIM. Le proxy Cloudflare (le nuage orange) fait passer le trafic web par ses serveurs. Il ne sait pas transporter les protocoles email (SMTP, IMAP, POP3). Ton enregistrement MX, lui, est toujours en « DNS only » — Cloudflare ne le proxifie pas, ni les TXT d'ailleurs. Mais le nom qu'il vise, typiquement mail.tondomaine.fr, est souvent un enregistrement A qu'on a proxifié sans y penser.

Comment tu le reconnais : tu ne reçois plus rien, ou ton logiciel de messagerie n'arrive plus à se connecter au serveur. Dans la liste DNS, l'enregistrement A mail affiche un nuage orange au lieu de gris.

Le correctif : clique sur le nuage pour le repasser en DNS only (gris). Vérifie de la même façon tous les noms utilisés par la messagerie : le serveur d'envoi, le serveur de réception, l'autodiscover — et tes CNAME DKIM (…._domainkey), proxifiés par défaut à la création.

2. Deux lignes SPF, ou plus de 10 recherches DNS

Ça arrive dès qu'on branche un outil de plus : on ajoute une deuxième ligne v=spf1 au lieu de compléter l'existante. Cas particulier fréquent sur Cloudflare : on active Email Routing, qui pose son propre SPF sur le domaine racine, alors qu'on envoie déjà via Google Workspace.

Comment tu le reconnais : ton scan affiche « plusieurs SPF détectés », ou tes rapports montrent un SPF en permerror alors que la ligne a l'air correcte. Certains destinataires t'acceptent, d'autres non, sans logique apparente.

Le correctif : une seule ligne, tous les include: dedans. Si tu dépasses 10 recherches, retire les services que tu n'utilises plus — c'est presque toujours là que se cache le surplus.

3. Activer Email Routing en gardant un autre service email

Email Routing (aujourd'hui dans Compute > Email Service) fait suivre les emails reçus vers une autre adresse. En l'activant, Cloudflare pose ses propres MX et son SPF, qui entrent en conflit avec ceux de ton fournisseur de boîtes. Les enregistrements posés sont d'ailleurs verrouillés (statut « Locked ») et ne peuvent plus être modifiés depuis DNS > Records tant que tu ne les déverrouilles pas.

Comment tu le reconnais : tes emails arrivaient dans Google Workspace ou Microsoft 365, et depuis hier ils n'arrivent plus — ou ils arrivent en double, redirigés. Tes MX affichent route1.mx.cloudflare.net alors que tu attendais ceux de ton fournisseur.

Le correctif : choisis. Email Routing sert à faire suivre le courrier d'un domaine que tu n'héberges pas ailleurs. Si tu as de vraies boîtes chez un fournisseur, désactive-le, ou déverrouille les enregistrements et remets les MX de ton fournisseur (Compute > Email Service > Email Routing > ton domaine > Settings > section DNS records > Unlock).

Combien de temps avant que ça prenne effet

• Chez Cloudflare : la formulation officielle est prudente — la propagation « peut prendre jusqu'à 24 h à l'échelle mondiale, mais se termine généralement en 5 à 15 minutes ». Cloudflare précise même : « It may take longer than 5 minutes for you to actually experience record changes ». C'est rapide, mais ce n'est pas instantané.
• Mais l'ancienne valeur peut rester en cache aussi longtemps que le TTL que tu avais fixé avant la modification. Si ton ancien enregistrement avait un TTL d'un jour, certains résolveurs mettront un jour à voir le changement. Ce n'est pas une contradiction, c'est du cache.
• Pour la vérification par ton service email : attends 15 minutes avant de cliquer sur « vérifier » chez le fournisseur, et réessaie plus tard si ça échoue.
• Pour les rapports DMARC : les premiers arrivent 24 à 72 h après la publication, puis environ une fois par jour.

À savoir sur le TTL : les enregistrements proxifiés sont forcément sur Auto (300 secondes), non modifiable. Les enregistrements « DNS only » acceptent une valeur entre 60 secondes et 1 jour.

Pour aller plus loin

• Configurer SendGrid avec un domaine sur Cloudflare
• Configurer SPF, DKIM et DMARC chez Infomaniak
• Configurer SPF, DKIM et DMARC chez Hostinger
• Passer son DMARC en p=reject sans casser ses emails