Configurer ses DNS sur Cloudflare : le guide pas à pas

Ce que tu vas configurer, et pour qui

Ce guide s’adresse à toute personne qui a basculé (ou va basculer) la gestion DNS de son domaine chez Cloudflare, pour profiter du CDN gratuit, du SSL automatique ou juste de la protection anti-DDoS. Tu vas apprendre à localiser ta zone DNS, créer les enregistrements essentiels (A, CNAME, MX, TXT), comprendre le fameux nuage orange, et éviter les pièges qui cassent un site ou bloquent les emails du jour au lendemain. Compte 20 à 30 minutes, propagation comprise.

Prérequis :

• Un compte Cloudflare avec le domaine ajouté (nameservers déjà pointés chez Cloudflare)
• Les informations de ton hébergeur ou de ta plateforme (adresse IP du serveur, ou nom d’hôte Vercel/Netlify)
• Les enregistrements MX/TXT fournis par ton hébergeur email (Gmail Workspace, OVH, etc.)
• Un accès admin au tableau de bord Cloudflare

1. Où trouver la zone DNS dans Cloudflare

Connecte-toi sur dash.cloudflare.com, sélectionne ton domaine dans la liste, puis clique sur l’onglet DNS dans le menu latéral gauche. Tu arrives sur la page Records, qui liste tous les enregistrements existants sous forme de tableau : Type, Nom, Contenu, Proxy statut, TTL.

Ce transfert suppose que les serveurs de noms déclarés chez ton registrar pointent bien vers Cloudflare : l’IANA exige au moins deux enregistrements NS dans une délégation, joignables en UDP comme en TCP sur le port 53 (source : IANA, Technical requirements for authoritative name servers). Si le domaine vient d’être ajouté, Cloudflare a généralement importé automatiquement les enregistrements de l’ancien hébergeur DNS. Vérifie-les un par un avant de toucher à quoi que ce soit : une erreur d’import est fréquente, notamment sur les MX.

2. Créer ou modifier un enregistrement A / AAAA

Un enregistrement A désigne l’entrée DNS qui associe un nom de domaine à une adresse IPv4, l’un des types de base décrits par la spécification du DNS (source : RFC 1035, IETF, 1987). Pour pointer ton domaine (ou un sous-domaine) vers un serveur, clique sur Add record en haut du tableau.

• Type : A (pour une adresse IPv4) ou AAAA (IPv6)
• Name : @ pour le domaine racine (exemple.com), ou app pour un sous-domaine (app.exemple.com)
• IPv4 address : l’adresse IP fournie par ton hébergeur
• Proxy status : orange (proxied) ou gris (DNS only), on y revient au point 6
• TTL : laisse sur “Auto” si le proxy est activé (il est de toute façon ignoré)

Clique sur Save. Le champ apparaît immédiatement dans le tableau. Si tu migres depuis un autre hébergeur, ce guide sur changer d’hébergeur sans perdre son référencement détaille l’ordre des opérations à respecter.

3. Configurer le CNAME pour www

La plupart des sites veulent que www.exemple.com redirige vers le même contenu que exemple.com. Ajoute un enregistrement :

• Type : CNAME
• Name : www
• Target : exemple.com (ou le nom d’hôte fourni par Vercel/Netlify, type cname.vercel-dns.com)
• Proxy status : orange, généralement recommandé pour bénéficier du SSL Cloudflare

Sur Vercel ou Netlify, ce CNAME doit pointer exactement vers la valeur donnée dans leur interface, pas vers ton domaine racine. Le guide domaine perso sur Vercel/Netlify détaille les valeurs exactes à utiliser selon la plateforme.

4. Configurer les enregistrements MX pour les emails

Un enregistrement MX (Mail eXchanger) désigne l’entrée DNS qui indique quel serveur reçoit le courrier d’un domaine, assortie d’une valeur de préférence numérique qui ordonne les serveurs entre eux (source : RFC 1035, IETF, 1987). C’est le point le plus souvent cassé lors d’une migration DNS. Si tes emails passent par Google Workspace, Microsoft 365 ou ton hébergeur, ajoute chaque enregistrement MX fourni :

• Type : MX
• Name : @
• Mail server : ex. aspmx.l.google.com
• Priority : la valeur exacte fournie (0, 5, 10…)
• Proxy status : les MX ne peuvent jamais être proxied, Cloudflare force automatiquement le statut gris (DNS only) sur ce type d’enregistrement, c’est normal

Ajoute tous les MX secondaires listés par ton fournisseur, pas seulement le premier. Un seul MX manquant peut faire échouer la réception d’emails de façon intermittente.

5. Ajouter les TXT (SPF, DKIM, vérification de domaine)

Les enregistrements TXT servent à la vérification de domaine (Google Search Console, Vercel) et à l’authentification email (SPF, DKIM, DMARC).

• Type : TXT
• Name : @ pour le SPF, ou un sous-domaine spécifique pour le DKIM (ex. google._domainkey)
• Content : la chaîne exacte fournie, entre guillemets si l’outil l’exige

Attention à ne créer qu’un seul enregistrement SPF par domaine : si Cloudflare en affiche déjà un (v=spf1 ...), modifie-le pour y ajouter le nouveau fournisseur plutôt que d’en créer un second, deux SPF sur le même domaine invalident la vérification. La règle vient de la spécification elle-même : un domaine ne doit publier qu’un seul enregistrement commençant par v=spf1, et une évaluation SPF ne peut déclencher plus de 10 requêtes DNS (source : RFC 7208, IETF, 2014). Le détail complet est dans email pro qui finit en spam : SPF, DKIM, DMARC.

6. Proxy (nuage orange) vs DNS only : le choix qui change tout

C’est le piège spécifique à l’interface Cloudflare. Chaque enregistrement A, AAAA ou CNAME affiche une icône de nuage cliquable :

• Nuage orange (Proxied) : le trafic passe par Cloudflare (CDN, cache, SSL, protection DDoS). L’IP visible publiquement n’est plus celle de ton serveur.
• Nuage gris (DNS only) : Cloudflare ne fait que résoudre le DNS, le trafic va directement à ton serveur, sans protection ni cache.

Règle pratique : mets en DNS only tout ce qui n’a pas besoin de passer par Cloudflare (MX, enregistrements de vérification, souvent le sous-domaine mail ou webmail). Laisse en proxy tout ce qui sert des pages web publiques, à condition que ton mode SSL soit bien configuré, sinon tu obtiens une erreur 521 ou une erreur 523 côté visiteur.

7. TTL et propagation : combien de temps attendre

Le TTL (Time To Live) correspond à la durée, en secondes, pendant laquelle un résolveur conserve une réponse en cache : c’est un entier sur 32 bits dont la valeur maximale exploitable vaut 2147483647 secondes (source : RFC 2181, IETF, 1997). Quand le proxy est activé, le TTL est géré par Cloudflare et le champ affiché n’a pas d’effet réel. En DNS only, tu peux régler un TTL court (300 secondes) avant une migration pour accélérer la bascule, puis remonter à “Auto” une fois stabilisé.

La propagation mondiale prend en général de quelques minutes à 24 heures, rarement plus avec Cloudflare (leur réseau anycast répond vite). Si un enregistrement ne semble pas pris en compte après plusieurs heures, le problème vient rarement de la propagation elle-même, voir DNS qui ne propage pas pour le vrai diagnostic.

Pièges courants

Une zone DNS Cloudflare bien tenue se résume à trois réflexes : vérifier chaque MX après une migration, choisir le statut proxy en connaissance de cause plutôt que par défaut, et ne jamais dupliquer un SPF. Le reste, cache, SSL, protection DDoS, vient gratuitement une fois ces trois bases posées.

Un point à connaître une fois le proxy actif : quand le serveur d’origine ne répond plus, Cloudflare affiche une page 502 à ses couleurs, ce qui fait croire à une panne du CDN. Le diagnostic est dans l’erreur 502 Bad Gateway sur WordPress.