Poser DMARC, SPF et DKIM dans Cloudflare DNS

dig NS exemple.fr +short

Type    : TXT
Nom     : _dmarc
Contenu : v=DMARC1; p=none; rua=mailto:rapports@exemple.fr
TTL     : Auto

SPF à la racine, DKIM au format du prestataire

SPF d'abord. C'est un TXT posé à la racine de la zone : dans le champ Nom, @ désigne le domaine lui-même.

Type    : TXT
Nom     : @
Contenu : v=spf1 include:spf.protection.outlook.com include:_spf.brevo.com -all

La valeur agrège tous les émetteurs légitimes, chacun via son include:. Règle absolue : un seul enregistrement commençant par v=spf1 par nom. Un nouvel émetteur s'ajoute dans l'enregistrement existant, jamais par un second TXT.

DKIM ensuite, et là le prestataire dicte le format. Deux écoles coexistent :

• Le TXT direct : le prestataire fournit une clé publique à coller. Google Workspace, par exemple : Nom google._domainkey, contenu v=DKIM1; k=rsa; p=MIIBIjANBg….
• Le CNAME de délégation : le prestataire fournit un ou plusieurs alias pointant vers ses serveurs, où la clé vit — et où elle tourne sans intervention. Microsoft 365 en demande deux : selector1._domainkey et selector2._domainkey, vers selector1-exemple-fr._domainkey.exemple.onmicrosoft.com et son jumeau. SendGrid, Mailjet ou Brevo procèdent de même avec leurs propres noms (s1._domainkey, s2._domainkey…).

Les deux formats se créent au même endroit, en choisissant le type TXT ou CNAME. La délégation par CNAME a un avantage réel — la rotation des clés devient l'affaire du prestataire — mais elle soulève chez Cloudflare une question spécifique, traitée deux sections plus bas.

Ce qui est propre à Cloudflare

Trois particularités distinguent la plateforme des interfaces DNS classiques.

Le statut proxy est sans objet pour les TXT. Le fameux nuage orange — le proxy qui fait transiter le trafic web par le réseau Cloudflare — ne concerne que les enregistrements A, AAAA et CNAME. Les TXT (_dmarc, SPF, clé DKIM collée) n'ont tout simplement pas ce commutateur : aucune décision à prendre, aucun risque de se tromper. La question ne se pose que pour les CNAME de sélecteurs, et elle est traitée juste après.

Le TTL « Auto » vaut 300 secondes. Pour un enregistrement non proxifié, « Auto » signifie cinq minutes. C'est un excellent réglage pour des enregistrements d'authentification : une correction se propage vite, une erreur se rattrape vite. Rien n'oblige à y toucher, et chercher un TTL long « pour soulager les serveurs » n'a aucun intérêt sur un réseau anycast de cette taille.

Un outil « DMARC Management » est intégré. Dans la rubrique e-mail de la zone, la plateforme propose un module qui publie l'enregistrement _dmarc et collecte les rapports agrégés sur une adresse rua hébergée par Cloudflare, avec restitution graphique dans le tableau de bord. C'est une fonctionnalité de la plateforme DNS, gratuite, qui peut servir de premier contact avec les rapports agrégés. Un point mérite d'être connu avant d'activer quoi que ce soit : la balise rua accepte plusieurs adresses séparées par des virgules. Il est donc possible de faire coexister l'adresse de collecte Cloudflare et une autre destination — le choix de l'adresse de réception des rapports DMARC est d'ailleurs une décision qui mérite sa propre réflexion, car c'est elle qui conditionne toute l'exploitation ultérieure.

CNAME de sélecteurs : nuage gris obligatoire, « flattening » à connaître

Le piège numéro un de Cloudflare pour l'e-mail tient en une couleur. À la création d'un CNAME, l'interface propose volontiers le proxy (nuage orange). Pour un site web, c'est souvent le bon choix ; pour un sélecteur DKIM, c'est fatal. Un CNAME proxifié disparaît de la vue publique : Cloudflare répond à sa place avec ses propres adresses IP pour servir le trafic web, et une requête TXT sur selector1._domainkey.exemple.fr ne renvoie plus rien. La clé devient introuvable, les signatures DKIM échouent, et l'alignement DMARC ne tient plus que par SPF. Tout CNAME de sélecteur doit donc rester en « DNS only » — nuage gris. Le symptôme typique de l'oubli : le prestataire de messagerie affiche « enregistrement introuvable » alors que le CNAME est parfaitement visible dans le tableau de bord.

Deuxième subtilité : le CNAME flattening. Au sommet de zone, Cloudflare aplatit systématiquement les CNAME — le protocole interdit un CNAME à la racine, la plateforme le résout donc elle-même et sert directement le résultat. Une option permet d'étendre cet aplatissement à tous les CNAME de la zone. Appliqué à un sélecteur DKIM, l'aplatissement ne casse pas la validation : la résolution reste dynamique, le contenu final est servi, la rotation de clés du prestataire est suivie. Mais la chaîne devient invisible dans les diagnostics, ce qui complique le débogage le jour où quelque chose cloche. Sauf besoin précis, les sélecteurs restent plus lisibles hors aplatissement. L'homonymie, enfin, prête à confusion : ce flattening de CNAME n'a rien à voir avec le « SPF flattening », qui consiste à remplacer les include: par des adresses IP pour contourner la limite des dix lookups DNS — une technique de dernier recours, aux inconvénients bien documentés.

Les erreurs courantes

L'enregistrement posé au mauvais endroit. Un _dmarc amputé de son underscore, un SPF posé sur www au lieu de la racine, ou — cas plus subtil — une politique attendue sur un sous-domaine d'envoi dédié mais posée sur la zone. Avec DMARCbis, un sous-domaine sans enregistrement propre hérite de la politique du domaine organisationnel via le DNS Tree Walk ; pour donner à news.exemple.fr sa propre politique, l'enregistrement se pose sur _dmarc.news. Dans l'autre sens, un enregistrement égaré sur un nom fantaisiste ne sera tout simplement jamais lu.

Les doublons. Cloudflare accepte sans broncher deux TXT v=spf1 sur le même nom — et ce doublon invalide SPF (permerror) chez tous les récepteurs. Même sanction pour deux enregistrements sur _dmarc : face à plusieurs politiques, les serveurs n'en appliquent aucune. Avant toute création, un passage par la liste des enregistrements existants évite la collision, particulièrement après un changement de prestataire d'envoi où l'ancien enregistrement traîne encore.

La zone dupliquée. Deux variantes du même mal. D'abord le domaine ajouté à Cloudflare sans que les serveurs de noms aient été basculés chez le registrar : la zone Cloudflare existe, se laisse éditer avec application… et personne ne l'interroge — les modifications restent sans effet, pendant que l'ancienne zone continue de répondre. Ensuite la migration entrante : à l'import d'un domaine, Cloudflare scanne la zone d'origine pour en recopier les enregistrements, et ce scan rate volontiers les TXT les moins standards — _dmarc, sélecteurs sous _domainkey. Un domaine migré peut ainsi perdre son DKIM du jour au lendemain sans que rien n'ait été « supprimé » consciemment. Après toute migration, une comparaison ligne à ligne avec l'ancienne zone s'impose.

Vérifier, puis observer

La propagation est rapide chez Cloudflare — TTL Auto de cinq minutes, réseau anycast — et la vérification peut suivre la création de quelques minutes. En ligne de commande :

dig TXT _dmarc.exemple.fr +short
dig TXT exemple.fr +short
dig TXT selector1._domainkey.exemple.fr +short

La première requête doit renvoyer la politique DMARC, la deuxième l'enregistrement SPF (parmi d'autres TXT éventuels), la troisième la clé DKIM — y compris à travers un CNAME, que dig suit silencieusement. Une réponse vide sur un sélecteur pourtant visible dans le tableau de bord signe presque toujours un nuage orange oublié.

La vérification DNS n'est toutefois que la moitié du chemin. La preuve définitive, ce sont les rapports agrégés qui arrivent à l'adresse rua et confirment, source par source, que SPF et DKIM passent et s'alignent. C'est sur cette base — des données, pas des suppositions — que la politique pourra monter de p=none vers p=quarantine puis p=reject.

En résumé

Cloudflare héberge la zone, la messagerie vit ailleurs, et tout se pose dans l'onglet DNS : un TXT _dmarc en p=none avec une adresse rua, un TXT v=spf1 unique à la racine, des sélecteurs DKIM en TXT ou en CNAME selon le prestataire. Les réflexes propres à la plateforme tiennent en quatre points : nuage gris obligatoire sur les CNAME de sélecteurs, TTL Auto laissé tel quel, flattening cantonné au sommet de zone, vigilance sur les doublons et sur les zones fantômes après migration. L'outil DMARC intégré peut amorcer la collecte ; la balise rua à plusieurs adresses garde toutes les portes ouvertes.

Pour valider le résultat d'un seul geste — enregistrement DMARC, SPF, sélecteurs, alignement — une analyse DMARC gratuite du domaine dresse l'état des lieux en quelques secondes. Et quand les premiers rapports arrivent, la création d'un compte ouvre la suite du chantier : inventaire des sources, alertes sur les nouveautés, et montée progressive vers p=reject au rythme que l'écosystème du domaine autorise.