Un transfert de nameservers sur un .fr se vend comme « juste un clic DNS ». En pratique, la page d’accueil peut répondre en 200 pendant que la boîte contact@ disparaît, que les factures OVH/Gandi rebondissent, et que le SPF d’un ancien hébergeur continue d’autoriser un serveur que vous n’utilisez plus. Le mail ne voyage pas sur le même chemin que le HTML. Si vous inversez l’ordre — flip NS d’abord, copier MX ensuite — vous collez pages et courrier dans la même fenêtre d’erreur. D’où le titre : domaine .fr, MX avant le flip DNS.
Ce guide décrit l’ordre qui tient pour un site vitrine ou un petit SaaS français : inventorier MX / SPF / DKIM / DMARC avant de pointer les NS vers Cloudflare (ou l’inverse), laisser le proxy orange hors du courrier, et vérifier avec deux résolveurs, pas un seul ping.
Afnic, registrar, Cloudflare: trois consoles
Le .fr n’appartient pas à Cloudflare. L’Afnic publie le registre ; votre registrar (OVH, Gandi, IONOS, Scaleway, un revendeur) tient le contrat et les nameservers délégués ; Cloudflare, si vous l’ajoutez, n’est qu’un DNS / proxy que vous déclarez chez le registrar. Mélanger les trois dans la tête produit le classique « j’ai mis l’A orange, le MX a suivi ». Non : le MX ne doit pas passer par le proxy HTTP.
Avant tout flip, ouvrez les trois écrans le même matin :
Registrar : NS actuels, verrouillage de domaine, contacts admin (une adresse qui n’est pas sur le domaine que vous allez casser).
Zone DNS actuelle : export zone file, ou captures datées de chaque MX, TXT, CNAME mail (autodiscover, selector._domainkey, sip, lyncdiscover si Microsoft 365).
Cloudflare (ou le futur DNS) : zone encore vide ou déjà peuplée ? Une zone « presque prête » avec un A orange et zéro MX est un piège, pas un gain de temps.
L’Afnic n’est pas un support mail. Un ticket « mes MX ont disparu » se règle chez le registrar ou chez l’opérateur DNS, pas au registre. Le WHOIS .fr peut encore montrer l’ancien registrar 24–48 h : ce n’est pas un signal pour re-flipper.
Copier MX, SPF, DKIM avant les NS
Le minimum à coller dans la nouvelle zone, à l’identique, avant de changer les NS :
1. Tous les MX (priorité et cible). Google Workspace, Microsoft 365, mailbox OVH, Proton, un Postfix maison : chacun a sa liste. Une priorité 1 oubliée vers l’ancien hébergeur = double livraison ou trou.
2. Le TXT SPF (v=spf1 …). Un seul enregistrement SPF par nom. Deux v=spf1 cassent la politique ; coller l’include Cloudflare et l’include Google sans fusionner produit un SPF illisible et souvent trop de lookups.
3. Les TXT / CNAME DKIM (google._domainkey, selector1._domainkey, s1._domainkey selon l’outil). Le sélecteur change quand vous tournez la clé : copiez ce qui est live, pas un PDF de 2023.
4. Le _dmarc TXT. p=none avec rua vers une boîte que vous lisez vaut mieux qu’un p=reject copié d’un tutoriel US le jour du flip.
5. Les CNAME de découverte mail : autodiscover, parfois enterpriseenrollment. Sans eux, Outlook « trouve » encore l’ancien hébergeur.
Faites l’inventaire dans un fichier daté (date du jour, 2026, pas un modèle 2024). Favokres ne considère pas un tampon « Operator notes » sous chaque H2 comme une procédure : une liste plate, vérifiable, suffit.
Si le registrar propose un export BIND, prenez-le. Si l’UI ne montre que cinq lignes, descendez : les DKIM sont souvent en bas, coupés par la pagination.
Proxy orange: le A n’est pas le MX
Le nuage orange Cloudflare termine le TLS HTTP. Un MX qui pointe vers un nom orangé envoie le SMTP dans un proxy qui n’est pas un serveur mail. Symptôme typique : timeout 25/tcp, ou un 5xx « that host does not accept mail ».
Règle simple :
Enregistrements A / AAAA / CNAME du site (apex et www) : orange possible, si vous assumez le proxy.
Enregistrements MX : cible en gris (DNS only). La cible MX est un hostname (smtp.google.com, mx.ovh.net, domaine-fr.mail.protection.outlook.com) — jamais l’IP orange du site.
SPF : include: des vrais expéditeurs (Google, Microsoft, Sendinblue/Brevo, Postmark). include:_spf.google.com n’a rien à voir avec le proxy de la page.
Séparer « le site passe par Cloudflare » et « le courrier va chez Google » n’est pas une architecture exotique ; c’est le défaut raisonnable. Ce qui casse, c’est l’assistant UI qui propose « proxy all DNS records » d’un clic.
Les enregistrements SRV_sip._tls / _sipfederationtls Microsoft, s’ils existent, restent hors proxy. Idem pour un TXT de vérification de domaine : ce n’est pas du HTTP.
TTL: deux résolveurs, pas un slogan
« C’est immédiat » est faux. Un TTL à 3600 s sur les NS chez le registrar, plus le cache du FAI, plus 1.1.1.1 vs 8.8.8.8 qui n’ont pas vidé en même temps, donnent une fenêtre de 30 minutes à plusieurs heures où une partie d’Internet voit encore l’ancienne zone.
Avant le jour J :
Baissez le TTL des NS et des MX / A concernés 24–48 h à l’avance (300 s si le registrar l’autorise ; certains .fr restent coincés à 3600).
Notez l’heure UTC du changement NS, pas l’heure de Paris affichée dans trois consoles différentes.
Ne jugez pas au ping de votre box. Interrogez au moins deux résolveurs publics, plus un regard dig NS / dig MX depuis un VPS hors de votre FAI.
Si a.nic.fr (autorité registre) et 1.1.1.1 divergent, vous n’avez pas « cassé Internet » : vous êtes dans la propagation. N’empilez pas un second flip.
Un test mail pendant cette fenêtre est trompeur : Gmail peut encore viser l’ancien MX pendant que votre téléphone, en 4G, vise le nouveau. Envoyez depuis et vers le domaine, plus un tiers (une adresse perso hors du même registrar).
www, apex, un seul canonique
Le mail ne se soucie pas de www. Le SEO si. Le jour où vous orientez l’apex vers Cloudflare et laissez www chez l’ancien hébergeur, vous obtenez deux certificats, deux robots.txt, et un canonical qui ment.
Choisissez un hôte canonique (souvent https://www.exemple.fr ou l’apex, pas les deux) avant le flip, et alignez :
redirection 301 de l’autre hôte ;
rel=canonical et sitemap sur le même hôte ;
A / AAAA / CNAME cohérents (CNAME sur l’apex .fr est souvent interdit : flattening ou A).
Le MX reste sur l’apex exemple.fr, pas sur www. Si quelqu’un a collé un MX sur www.exemple.fr « pour tester », supprimez-le : ça n’aide pas, ça divise les diagnostics.
Jour J: l’ordre qui limite la casse
1. Zone cible (Cloudflare ou autre) déjà peuplée : MX, SPF, DKIM, DMARC, A/AAAA du site, redirections. Vérifiez en preview (dig vers les NS Cloudflare avant qu’ils soient délégués) — la plupart des UI montrent les nameservers *.ns.cloudflare.com : interrogez-les directement.
2. Contact de secours hors domaine (Gmail perso, téléphone). Le registrar enverra le mail de confirmation NS sur le contact : s’il tombe dans le trou MX, vous êtes bloqué.
3. Changement NS chez le registrar. Un seul jeu. Pas « Cloudflare + OVH » en même temps.
4. Attente mesurée : dig NS registre vs 1.1.1.1 vs 8.8.8.8. Quand les trois alignent, testez HTTP et SMTP séparément.
5. Envoi d’un message de test avec en-têtes : SPF pass, DKIM pass, DMARC aligned. Un « reçu dans le spam » n’est pas un MX mort ; un timeout SMTP l’est.
Si le site est orangé trop tôt et que Let’s Encrypt chez l’ancien hôte expire, ce n’est pas un bug MX. Ne « réparez » pas en re-orangant le MX.
Reculer sans panique
Rollback = remettre les anciens NS chez le registrar, pas vider la zone Cloudflare « pour voir ». Gardez l’export de l’ancienne zone 14 jours. Un rollback 20 minutes après le flip est encore lisible ; 48 h plus tard, des clients mail ont déjà mis en cache le nouveau MX.
Si seul le HTML est cassé (502 proxy, certificat) et que le MX est vert : ne touchez pas aux MX. Si seul le mail est cassé et que le site est bon : corrigez MX/SPF dans la nouvelle zone, ne re-flippez pas les NS.
Les .fr ont parfois un délai de délégation plus visqueux qu’un .com chez le même registrar. Ce n’est pas une raison pour empiler des tickets Afnic.
Liste de contrôle avant le flip
Une seule liste, une seule date (2026), pas un tampon sous chaque titre :
Export BIND ou captures de tous les MX / SPF / DKIM / DMARC / autodiscover.
Contact registrar sur une boîte hors du domaine.
Zone cible déjà peuplée ; cibles MX en DNS only (gris), jamais orangées.
TTL baissé 24–48 h avant si le registrar .fr l’autorise.
Après le changement NS : dig vers 1.1.1.1 et 8.8.8.8, puis un mail aller-retour avec en-têtes SPF/DKIM.
Si le HTML 502 et le MX vert : on ne touche pas au courrier. Si le SMTP timeout et le site 200 : on corrige la nouvelle zone, on ne re-flippe pas les NS.
OVH, Gandi et IONOS n’affichent pas les TTL au même endroit. Si l’UI cache les DKIM en page 2, ils n’existent pas « plus tard » : ils manquent le jour J.
FAQ
Le registrar, c’est Cloudflare ? Non. Cloudflare est un DNS / CDN que vous déclarez. Le contrat .fr et les NS délégués restent chez OVH, Gandi, IONOS, etc. L’Afnic publie le registre ; elle ne configure pas vos MX.
Faut-il orangé le MX « pour la sécurité » ? Non. Le proxy orange n’est pas un antispam SMTP. Laissez la cible MX en DNS only. La sécurité mail, c’est SPF + DKIM + DMARC + le vrai serveur.
Pourquoi deux résolveurs ? Parce que 1.1.1.1 et 8.8.8.8 (et le cache du FAI) n’expirent pas ensemble. Un seul dig « OK » le matin ne dit rien pour un client Orange à Lyon deux heures plus tard.
www doit-il avoir un MX ? Non. Le courrier de contact@exemple.fr suit l’apex. Un MX sur www ajoute de la confusion, pas de la redondance.
SPF trop long après le flip ? Fusionnez les include dans un TXT. Si vous dépassez 10 lookups, aplatissez ou retirez des expéditeurs morts (l’ancien hébergeur, un outil d’emailing abandonné). Deux enregistrements v=spf1 = politique cassée.
DMARC en reject le jour J ? Dangereux. Restez en p=none ou quarantine le temps de lire les rapports. Un reject copié d’un blog US coupe la compta et les accusés de réception.
Le WHOIS montre encore l’ancien registrar. Souvent 24–48 h. Ce n’est pas un ordre de re-changer les NS. Croisez dig NS @a.nic.fr.
TTL à 60 s partout ? Seulement si le registrar .fr l’accepte. Beaucoup imposent 3600. Baissez ce que vous pouvez 48 h avant ; n’imaginez pas un cut-over mondial en trente secondes.
Nine years in software — backend and frontend with equal weight, not a slogan. I also spent a year in IT operations, the kind of work that makes you respect uptime.
The same hands that ship APIs come from graphic design through modeling, 2D and 3D. I care how a thing looks and how it holds together.
Favokres is my personal digital hub: AI-assisted publishing, SEO, a forum, and a shop. An autonomous brain keeps the site moving so pages stay useful, not frozen.
