Comment configurer SPF, DKIM et DMARC dans Cloudflare

Si vous essayez d'apprendre à configurer SPF, DKIM et DMARC dans Cloudflare, commencez par un fait simple : Cloudflare stocke les enregistrements DNS, mais votre fournisseur de messagerie fournit les valeurs. Cela peut sembler insignifiant. Ce n'est pas insignifiant.

Cloudflare est l'endroit où les enregistrements résident, et cela signifie que vous allez modifier les entrées TXT ou CNAME dans son panneau DNS. La chaîne d'inclusion SPF réelle, le sélecteur DKIM, la clé publique et la politique DMARC proviennent du service qui envoie votre courrier, que ce soit Google Workspace, Microsoft 365, SendGrid, Mailgun ou une autre plateforme. Sans ces valeurs, vous ne faites que deviner.

1. Confirmez ce que Cloudflare peut et ne peut pas faire pour l'authentification des e-mails

Cloudflare n'invente pas les valeurs SPF, DKIM ou DMARC. Il ne fait que les publier. Si votre fournisseur dit d'ajouter un enregistrement TXT pour SPF, Cloudflare peut l'héberger. Si le fournisseur vous donne un sélecteur DKIM et une cible CNAME, Cloudflare peut également l'héberger. Mais il ne peut pas décider quels serveurs peuvent envoyer des e-mails pour vous.

C'est important car les gens ouvrent souvent Cloudflare en premier et cherchent un bouton magique. Il n'y en a pas. Vous avez besoin du contenu exact de l'enregistrement de votre expéditeur avant de toucher au DNS, sinon vous risquez de publier un enregistrement qui passe un contrôle de tableau de bord et échoue dans une vraie boîte aux lettres.

2. Collectez les valeurs DNS de votre plateforme d'envoi d'e-mails

Avant de modifier quoi que ce soit, collectez trois choses dans la documentation du fournisseur. Tout d'abord, rassemblez les mécanismes d'inclusion SPF et toutes les adresses IP que le service souhaite dans votre enregistrement SPF. Deuxièmement, rassemblez les noms de sélecteurs DKIM et les données de clé publique, ou les cibles CNAME si le fournisseur utilise DKIM basé sur CNAME. Troisièmement, rassemblez la chaîne de politique DMARC, y compris la politique avec laquelle vous prévoyez de commencer et tous les tags de rapport.

Notez les valeurs à un seul endroit. Utilisez les noms de sélecteurs exacts. Si votre fournisseur vous donne deux sélecteurs, ne les renommez pas parce qu'ils semblent désordonnés. Si la documentation dit que l'enregistrement doit être `_spf.example.net`, gardez-le ainsi. De petites erreurs de formatage peuvent causer de longues après-midis.

Il y a une habitude utile ici : capturez le nom de l'expéditeur, le nom d'hôte, le type d'enregistrement et la chaîne de destination dans un tableau avant de vous connecter à Cloudflare. Cela rend la phase d'édition plus rapide et empêche également l'erreur courante de coller la bonne valeur dans le mauvais champ de nom.

3. Ajoutez un enregistrement SPF dans le DNS de Cloudflare

Dans Cloudflare, ouvrez DNS et créez ou modifiez l'enregistrement TXT à la racine du domaine si votre fournisseur envoie des e-mails depuis le domaine nu. Certains services utilisent un sous-domaine à la place, comme `mail.example.com`, donc utilisez le nom d'hôte spécifié par votre fournisseur, pas celui que vous supposez. Un nom d'hôte. Un enregistrement.

Un enregistrement SPF ne devrait généralement exister qu'une seule fois pour un nom d'hôte. C'est le point que les gens manquent. Si vous avez déjà un enregistrement SPF TXT, ne créez pas un deuxième enregistrement SPF TXT à côté. Fusionnez les expéditeurs autorisés en une seule chaîne afin que le serveur récepteur voie une seule politique, pas deux réponses concurrentes.

Une valeur SPF typique inclut des mécanismes tels que `include:` ou `ip4:`. Si votre service ajoute un deuxième expéditeur plus tard, mettez à jour l'enregistrement existant au lieu d'en ajouter un autre. Un enregistrement SPF en double peut provoquer une erreur permanente, ce qui signifie que les systèmes récepteurs peuvent considérer que la vérification a échoué même si les parties individuelles semblent correctes.

Utilisez le nom d'enregistrement que votre fournisseur vous donne. Pour le domaine racine, Cloudflare affiche souvent `@` comme champ de nom. Pour un sous-domaine, entrez cette étiquette exacte. N'ajoutez pas de guillemets autour de la valeur à moins que votre fournisseur ne vous le demande explicitement. Cloudflare stocke le texte en tant que contenu DNS brut.

4. Publiez des enregistrements DKIM TXT ou CNAME dans Cloudflare

DKIM est là où le sélecteur compte. Le fournisseur peut vous donner un enregistrement TXT comme `selector1._domainkey` avec une longue clé publique, ou il peut vous donner un enregistrement CNAME qui pointe vers un autre nom d'hôte. Cloudflare prend en charge les deux, mais le type doit correspondre à ce que dit le fournisseur. Une valeur TXT dans un champ CNAME ne vous aidera pas.

De nombreux services utilisent deux sélecteurs. C'est normal. Google Workspace utilise souvent deux clés lors de la rotation, et d'autres fournisseurs font quelque chose de similaire afin qu'une clé puisse être remplacée sans interrompre la livraison. Si l'expéditeur vous donne `s1` et `s2`, publiez les deux enregistrements. Si un deuxième expéditeur utilise une famille de sélecteurs différente, gardez ces enregistrements séparés également. Les noms peuvent sembler répétitifs ; les enregistrements ne sont pas redondants.

Entrez le nom d'hôte DKIM exactement comme indiqué. Si le fournisseur vous dit de créer `selector1._domainkey.example.com`, utilisez cette étiquette complète dans Cloudflare. Si le fournisseur donne une cible CNAME, collez la destination exactement comme écrit. Cloudflare n'a pas besoin d'une traduction. Il a besoin de précision.

Pour les équipes suivant la configuration DKIM SPF DMARC pour les transactions, la même règle s'applique même lorsque le volume de mails est faible : le sélecteur dans DNS doit correspondre au sélecteur dans l'en-tête du message. S'ils diffèrent, DKIM échoue. Pas de drame, juste un échec.

5. Créez un enregistrement DMARC à _dmarc

DMARC appartient à `_dmarc.yourdomain.com`. Dans Cloudflare, créez un enregistrement TXT avec ce nom exact. La valeur commence par `v=DMARC1`, puis ajoute votre politique et des balises optionnelles. Une politique de départ courante est `p=none`, car elle vous permet de collecter des rapports avant de bloquer quoi que ce soit. C'est le point de départ le moins agressif.

Si votre organisation est prête à recevoir des rapports, ajoutez la balise `rua` avec l'adresse de rapport agrégé et, si nécessaire, la balise `ruf` pour les rapports d'analyse. Utilisez une adresse que quelqu'un surveille réellement. Une boîte aux lettres morte n'est pas une stratégie. C'est un piège.

Une règle pratique aide ici : commencez avec une politique DMARC qui correspond à votre tolérance actuelle pour les faux positifs, puis resserrez-la plus tard après avoir vérifié que les expéditeurs légitimes sont alignés. Si vous allez trop vite, vous pouvez bloquer des factures, des alertes ou des réinitialisations de mot de passe. Cela se remarque immédiatement.

Cloudflare stockera l'enregistrement TXT DMARC comme toute autre entrée de texte, mais les détails comptent. Le nom de l'enregistrement doit être `_dmarc`, pas `dmarc`, pas `_dmarc1`, et pas le domaine racine. La chaîne de politique doit suivre la syntaxe que votre fournisseur attend. Si votre plateforme de messagerie suggère des balises telles que `sp`, `adkim` ou `aspf`, ajoutez-les uniquement lorsque vous comprenez l'effet.

6. Vérifiez les paramètres DNS spécifiques à Cloudflare qui peuvent bloquer la validation

Cloudflare a un paramètre qui cause plus de confusion qu'il ne le devrait : le proxy. Les enregistrements d'authentification par e-mail ne doivent pas être proxyés. SPF, DKIM et DMARC vivent dans le DNS, pas derrière le nuage orange. Si vous proxyez accidentellement un nom d'hôte lié au courrier, vous mélangez les règles de trafic web avec les enregistrements DNS d'e-mail.

Les noms d'enregistrement sont un autre point de défaillance courant. Un sélecteur DKIM qui devrait être `selector1._domainkey` peut être saisi comme `selector1._domainkey.` avec un point errant, ou comme `selector1 domainkey` avec un espace copié depuis une page de fournisseur. Cloudflare accepte de nombreux enregistrements DNS, mais les systèmes récepteurs sont moins indulgents que l'interface.

Les anciens enregistrements peuvent également interférer. Si un ancien enregistrement SPF TXT reste à côté du nouveau, ou si un CNAME DKIM obsolète pointe toujours vers un service retiré, la validation peut échouer de manière apparemment aléatoire. Supprimez l'entrée morte uniquement après avoir confirmé qu'elle n'est plus nécessaire. Cela garde l'expéditeur actif intact.

If you are also working on email authentication setup for transactional email, this is the moment to check every sending host listed by the vendor. A forgotten subdomain can make a support message pass while a receipt message fails, and that split behavior is hard to spot until a customer complains.

7. Vérifiez la propagation et l'authentification des mails depuis le DNS géré par Cloudflare

Après avoir enregistré les enregistrements, attendez la propagation DNS. Le temps exact dépend de votre TTL et du cache du résolveur devant vous, donc ne supposez pas que l'enregistrement est visible partout au moment où Cloudflare dit qu'il est enregistré. Vérifiez extérieurement avec un outil de recherche DNS et confirmez que chaque nom d'enregistrement renvoie la valeur attendue.

Ensuite, envoyez un vrai message de test depuis le service qui utilise les enregistrements. Ne testez pas depuis une boîte de réception aléatoire qui contourne votre flux de mails normal. Ouvrez les en-têtes du message dans la boîte aux lettres de réception et recherchez SPF pass, DKIM pass et DMARC alignment pass. Le message peut toujours atterrir dans les spams pour d'autres raisons, mais le résultat de l'authentification devrait vous indiquer si le côté DNS est correct.

Un contrôle rapide suffit pour le premier passage, mais un second contrôle depuis une boîte aux lettres différente vous donne un meilleur signal. Un test Gmail et un test Microsoft 365 peuvent se comporter différemment si un résolveur voit brièvement l'ancien enregistrement tandis qu'un autre voit le nouveau. Ce n'est pas rare. Cela arrive.

Si la délivrabilité fait partie du même projet, associez ce travail aux meilleures pratiques de délivrabilité des emails. L'authentification n'est pas toute l'histoire, mais c'est la partie qui permet aux destinataires de décider si votre domaine parle de lui-même.

8. Mettez à jour les enregistrements lorsque votre fournisseur de mail change

Les configurations de mail changent. Un fournisseur fait tourner les clés DKIM, une plateforme marketing est ajoutée, ou un service de transaction est déplacé après une migration. Lorsque cela se produit, mettez à jour les enregistrements DNS dans Cloudflare avant de changer le trafic, pas après. Cet ordre vous évite une journée de signatures cassées.

La rotation DKIM est généralement le changement le plus propre. Le fournisseur vous donne un nouveau sélecteur et une nouvelle clé, vous le publiez dans Cloudflare, et vous attendez que le nouveau sélecteur soit validé avant de retirer l'ancien. Gardez les deux actifs pendant la transition si le fournisseur le supporte. Deux sélecteurs sont plus faciles qu'une seule panne.

Les changements SPF sont un peu plus délicats car l'enregistrement doit rester sous les limites de taille et de recherche TXT DNS fixées par la norme SPF. Si un nouvel expéditeur rejoint la pile, ajoutez son mécanisme d'inclusion à l'enregistrement SPF existant au lieu d'empiler un autre enregistrement à côté. Si vous êtes proche de la limite de recherche, réduisez les inclusions inutiles lorsque cela est possible et confirmez les conseils actuels du fournisseur.

Pour les équipes qui envoient via plusieurs services, la maintenance devient plus facile si une personne possède la liste des expéditeurs autorisés. Cette liste doit indiquer le service, le nom d'hôte, le sélecteur DKIM et la date du dernier changement. Un tableau simple maintient les modifications de Cloudflare cohérentes, et la cohérence est plus importante que l'ingéniosité.

Si la gestion des rebonds et les changements d'expéditeur font partie du même projet de boîte aux lettres, la même discipline aide avec les meilleures pratiques de gestion des rebonds d'email. Une migration de fournisseur peut changer à la fois l'authentification et le comportement d'erreur le même jour, et aucun des deux côtés ne devrait être deviné.

Cloudflare rend la partie publication simple, mais les enregistrements nécessitent toujours de la discipline. Un expéditeur. Un enregistrement SPF. Chaque sélecteur DKIM au bon endroit. Un enregistrement DMARC à `_dmarc`. Si vous gardez ces quatre points en ordre, le reste est principalement de la patience, quelques vérifications d'en-tête, et la volonté de mettre à jour le DNS avant que le prochain changement de plateforme n'arrive.