Comment une équipe produit doit-elle mettre en place DMARC dans Cloudflare en toute sécurité ?

Séparer le DNS Cloudflare de la configuration des expéditeurs

Cloudflare peut gérer le DNS faisant autorité pendant qu’un autre fournisseur soumet et signe les e-mails de l’application. Documentez ces frontières avant de modifier quoi que ce soit. La zone publie la politique DMARC TXT ; chaque fournisseur d’e-mail contrôle son return path, le domaine de signature DKIM et le sélecteur, la vérification et parfois le reporting ; l’application contrôle le tenant, la catégorie de message, le destinataire, le modèle, l’adresse From visible et le chemin du fournisseur. Un enregistrement DNS valide ne peut pas réparer un expéditeur non autorisé, une signature DKIM manquante, un return path non aligné ou une valeur From inter-tenant. Inventoriez les systèmes de production, de préproduction, de support, de facturation, d’identité, de supervision, de CRM, de marketing et de messagerie humaine par domaine From visible. Attribuez à chacun un responsable et un contact pour le retour arrière, et classez les sources inconnues des rapports avant de durcir la politique.

Interroger le nom de politique évalué par les destinataires

Pour les e-mails envoyés depuis alerts@notify.example.test, commencez par l’enregistrement TXT de _dmarc.notify.example.test. Ne publiez pas par erreur la politique sur l’hôte du site web, sur le serveur de messagerie (MX), sur le sélecteur DKIM ou sur le nom du return path. La découverte DMARC actuelle peut retenir une politique applicable au niveau organisationnel ou du suffixe public lorsque le domaine auteur n’a pas d’enregistrement valide ; notez donc à la fois le nom interrogé et le domaine de politique retenu. Interrogez les réponses faisant autorité et récursives existantes avant d’ouvrir Cloudflare. Plusieurs enregistrements de politique au même nom, une syntaxe de balises malformée ou un CNAME en conflit peuvent rendre le résultat inutilisable. Consignez l’ancien contenu, le TTL, la sortie du résolveur, le responsable et la valeur attendue après le changement, afin que le retour arrière soit exact plutôt que reconstitué en plein incident.

Créer un seul enregistrement TXT relu dans Cloudflare

Ouvrez le bon compte et la bonne zone Cloudflare, allez dans DNS Records, choisissez Add record, puis sélectionnez TXT. Utilisez _dmarc comme nom relatif pour une politique à l’apex, ou le libellé _dmarc exact du sous-domaine visé. Saisissez une seule valeur relue, sans guillemets incohérents ; Cloudflare indique qu’il ajoute des guillemets autour du nouveau contenu TXT enregistré sans guillemets. Choisissez un TTL cohérent avec le déploiement et la reprise, ajoutez si besoin une référence de changement sans donnée sensible, et n’enregistrez qu’après avoir vérifié la zone, le nom, l’ancienne valeur et la nouvelle. Les politiques TXT sont des données DNS, pas des routes web proxifiées. Si un partenaire d’hébergement ou un autre fournisseur faisant autorité gère la zone, effectuez le changement chez lui au lieu de supposer que le tableau de bord Cloudflare fait autorité.

Construire la valeur DMARC à partir de décisions explicites

Un enregistrement en phase d’observation peut commencer par v=DMARC1; p=none et une URI de rapports agrégés approuvée, mais ce n’est qu’un exemple, pas une valeur universelle. Placez la version en premier, choisissez délibérément la politique demandée et autorisez chaque destination de rapports. N’examinez la politique des sous-domaines, le mode d’alignement, le pourcentage et les balises de reporting que s’il existe un besoin documenté et une interprétation à jour des normes. Ne copiez pas un exemple de fournisseur contenant la boîte rua de quelqu’un d’autre et ne passez pas à p=reject simplement parce que la syntaxe est valide. Un enregistrement valide exprime le traitement demandé aux destinataires ; il ne prouve pas que SPF ou DKIM authentifie, que l’un des identifiants authentifiés s’aligne sur le domaine From, que tous les chemins d’envoi légitimes ont été inventoriés, ni qu’un message a atteint une boîte de réception.

Vérifier l’alignement SPF et DKIM sur des messages réels

Envoyez des exemples contrôlés depuis chaque chemin applicatif vers des destinataires dont vous pouvez inspecter les en-têtes bruts. Consignez le From visible, le SMTP MAIL FROM, l’IP d’envoi, le domaine d= et le sélecteur DKIM, Authentication-Results, l’identifiant du fournisseur, la catégorie de message, l’environnement et l’heure. DMARC peut réussir grâce à un SPF authentifié et aligné ou à une signature DKIM vérifiée et alignée. SPF évalue une identité SMTP et peut changer en cas de transfert ; DKIM vérifie une signature portant sur un contenu sélectionné. Aucun des deux ne remplace l’autorisation applicative. Testez délibérément l’alignement relaxed ou strict, y compris les sous-domaines et les routes de basculement. L’acceptation par l’API du fournisseur, l’acceptation par le serveur de destination, un DMARC réussi, le placement en boîte de réception et l’engagement sont des observations distinctes. Gardez ces états séparés, afin qu’un appel d’API réussi ou un indicateur de politique au vert ne soit jamais présenté comme une preuve de livraison plus forte.

Valider le DNS et les rapports en dehors du tableau de bord

Après l’enregistrement, interrogez les serveurs de noms faisant autorité de Cloudflare et plusieurs résolveurs récursifs indépendants pour l’enregistrement TXT au nom _dmarc exact. Stockez les réponses brutes, le domaine de politique retenu, le TTL, le résolveur, l’horodatage et le résultat de l’analyseur. Confirmez qu’il existe exactement un enregistrement exploitable, que v=DMARC1 vient en premier, que les valeurs requises sont valides et que les URI de rapports sont approuvées. Recommencez après la fenêtre de cache prévue. Renvoyez des messages contrôlés et inspectez les en-têtes côté destinataire. Cloudflare présente DMARC Management comme un moyen de visualiser les sources d’envoi et les résultats agrégés SPF, DKIM et DMARC, mais les rapports sont des observations différées fournies par les destinataires, pas un recensement complet en temps réel. Recoupez-les avec les preuves du fournisseur. Faites une pause en cas de désaccord entre résolveurs, de trafic peu fréquent manquant, de sources légitimes inconnues, de messages contrôlés non alignés ou de variations inattendues du volume de rapports.

Traiter Cloudflare DMARC Management comme un changement DNS

Selon Cloudflare, l’activation de DMARC Management peut proposer de créer un enregistrement s’il n’en existe aucun, ou ajouter une adresse de rapports agrégés Cloudflare à une balise rua existante. Examinez cette modification proposée comme une infrastructure de production : exportez la valeur antérieure, confirmez que les destinations existantes restent voulues, vérifiez le périmètre du domaine et préservez la possibilité de retour arrière. Sa documentation d’activation décrit aussi le périmètre actuel limité au domaine apex et une réserve concernant les enregistrements SPF externes. N’en déduisez pas que la fonctionnalité peut réécrire sans risque un chemin SPF hébergé ailleurs. Une source ou une IP listée ne prouve pas quelle application, quel tenant ou quelle personne l’a autorisée, et l’absence de ligne ne prouve pas l’absence de trafic. Utilisez cette vue pour collecter des preuves, tout en conservant les preuves issues du DNS faisant autorité, des messages bruts, des logs du fournisseur et de l’audit applicatif.

Durcir la politique par étapes, preuves à l’appui

Observez assez longtemps pour couvrir chaque expéditeur légitime, chaque catégorie de message, les variations selon les jours de la semaine, les traitements par lots, les routes de basculement et les workflows peu fréquents. Classez les sources comme appartenant à l’organisation, provenant d’un fournisseur approuvé, transférées, inconnues ou abusives. Corrigez l’alignement du trafic légitime avant de demander un traitement plus strict. Un point de décision go/no-go doit inclure un DNS valide, des messages contrôlés qui réussissent, une couverture alignée acceptable, aucune source légitime inconnue, des responsables d’incident désignés, un support prêt et un retour arrière testé. Ne durcissez la politique que par un changement borné et approuvé, et surveillez les échecs d’authentification comme les échecs métier. Revenez en arrière ou faites une pause en cas de rejet de messages légitimes, de perte de rapports, de sources inattendues, d’incohérences entre résolveurs, de migration de fournisseur ou d’héritage surprenant par les sous-domaines. Modifiez SPF, DKIM et DMARC séparément quand c’est possible, pour pouvoir attribuer clairement toute régression.

Éviter les erreurs courantes avec DMARC dans Cloudflare

Les échecs fréquents consistent à modifier la mauvaise zone, publier sous le mauvais nom _dmarc, laisser deux enregistrements de politique, ajouter des guillemets cassés, remplacer une liste rua approuvée, supposer que les politiques de l’apex et des sous-domaines sont identiques, et passer à p=reject avant que les expéditeurs occasionnels ne se soient manifestés. Une autre erreur consiste à considérer l’état enregistré ou détecté dans le tableau de bord comme une preuve au niveau du message. Utilisez des diffs exacts, des destinataires contrôlés, des requêtes indépendantes, des en-têtes bruts et des logs d’incident limités au destinataire concerné. Gardez les adresses des clients, le corps des messages, les clés API et les données de rapport non bornées hors des tickets et des outils d’analyse. Si les réponses faisant autorité et en cache restent incohérentes au-delà du délai prévu, si un expéditeur attendu manque ou si un message réel échoue à l’alignement, arrêtez-vous et diagnostiquez séparément la délégation, le cache, la syntaxe de l’enregistrement, l’inventaire des expéditeurs, SPF et DKIM.

Comment SendHQ s’intègre

La limite sûre est indépendante du fournisseur : l’application autorise un message, le fournisseur d’envoi l’authentifie, Cloudflare publie ou analyse l’état DNS, et les destinataires évaluent le message. Appuyez-vous sur la documentation officielle actuelle de Cloudflare, la norme DMARC actuelle, les réponses DNS observées et les preuves issues de messages reçus contrôlés.

Questions fréquentes

Sources

• Gérer les enregistrements DNS — Cloudflare
• Types d’enregistrements DNS Cloudflare — Cloudflare
• Présentation de Cloudflare DMARC Management — Cloudflare
• Activer Cloudflare DMARC Management — Cloudflare
• Consulter les statistiques Cloudflare DMARC — Cloudflare
• RFC 9989 : DMARC — RFC Editor
• RFC 7208 : SPF — RFC Editor
• RFC 6376 : DKIM — RFC Editor