Enregistrements DNS : ce que doit savoir celui qui gère un WordPress

On vous a dit qu’après avoir modifié un enregistrement DNS, il fallait attendre 24 à 48 heures. Oui, en partie… Le 31 mai 2026, j’ai changé le serveur qui fait tourner le WordPress de ce site en touchant à une seule ligne, avec une durée de vie ramenée à 60 secondes. Le jour même, la nouvelle adresse répondait chez Google, chez Cloudflare et sur les serveurs de ma zone.

Personne n’a attendu deux jours. Le lendemain, en revanche, un article est parti deux fois. Le DNS avait fait exactement ce qu’on lui demandait, et c’était bien le problème. J’y reviens plus bas.

Le DNS est la seule couche de votre site que vous tenez vraiment en main. Un WordPress n’a besoin que d’une dizaine de types d’enregistrements, et il faut les comprendre un par un pour changer d’hébergeur sans coupure. Voici ce que fait chacun, zone réelle à l’appui.

Qu’est-ce qu’un enregistrement DNS, et qui le gère vraiment ?

Un enregistrement DNS est une ligne qui associe un nom (votre domaine ou un sous-domaine) à une information d’un type précis : une adresse de serveur, un serveur de messagerie, un texte. L’ensemble de ces lignes forme la zone DNS du domaine. Celui qui publie cette zone est son gestionnaire, qui n’est pas forcément votre hébergeur.

DNS veut dire Domain Name System, le système des noms de domaine. Votre navigateur ne connaît qu’un nom : avant d’afficher une page, il demande à un résolveur (celui de votre box ou de votre fournisseur d’accès, par exemple) l’adresse qui se cache derrière.

Le résolveur parcourt alors la chaîne : les serveurs racine, ceux de l’extension (.com, .fr), puis les serveurs de noms de votre domaine, les seuls à détenir la réponse. Au passage, les fameux 13 serveurs racine sont 13 noms. Derrière, root-servers.org comptait 2 045 instances en service le 30 septembre 2026, et aucune ne connaît l’adresse de votre site.

Bureau d’enregistrement, serveurs de noms, zone : qui tient quoi

Trois niveaux se partagent le travail, et ils peuvent vivre chez autant de prestataires… ou chez un seul.

Le bureau d’enregistrement (registrar, en anglais) vous loue le nom, année après année. Il déclare au registre, le gestionnaire de l’extension, quels serveurs de noms répondent pour votre domaine. Ces serveurs de noms publient la zone. La zone contient vos enregistrements.

Retenez une règle : un domaine n’a qu’une seule zone active. La documentation d’OVHcloud le dit sans détour. Vous pouvez créer plusieurs zones chez différents prestataires pour un même nom, mais une seule sera active. Celle des serveurs de noms déclarés.

Imaginez que vous ajoutiez un enregistrement dans le panneau de votre hébergeur, et que rien ne se passe. Si les serveurs de noms déclarés sont ceux d’un autre prestataire, rien d’étonnant : vous venez de modifier une zone que personne ne lit.

Ce premier niveau est aussi celui qu’on oublie. Un nom qui expire, et le site comme les e-mails s’arrêtent : le détail est dans les questions fréquentes.

Le renouvellement du nom est l’un des maillons que je passe en revue dans ce que devient votre site WordPress si vous n’êtes plus là. Si vous partez de zéro, voyez mon guide pour créer un site WordPress de A à Z.

Lire un enregistrement DNS : nom, type, valeur, durée de vie

Dans un fichier de zone, un enregistrement tient sur une ligne. En voici un :

www.example.com.   3600   IN   CNAME   example.com.

De gauche à droite : le nom concerné, la durée de vie en secondes (le TTL, pour Time To Live), la classe (IN, pour Internet, à peu près toujours), le type, puis la valeur. Ici, www est un alias du domaine, et un résolveur peut garder cette réponse une heure.

L’arobase et le point final déroutent au début. L’arobase désigne le domaine lui-même, la racine de la zone. Le point final compte : dans un fichier de zone, un nom terminé par un point est complet, alors qu’un nom sans point est complété par celui de la zone (RFC 1035). Oubliez-le sur la cible d’un CNAME, et vous publiez un nom à rallonge qui n’existe pas.

Les RFC sont les documents numérotés qui décrivent les règles techniques d’Internet : je donne leur numéro pour que vous puissiez vérifier.

La durée de vie mérite qu’on s’y arrête. Elle fixe le temps pendant lequel un résolveur peut garder la réponse en cache avant de reposer la question. Un maximum, donc : un cache peut la garder moins longtemps. La règle n’est pas suivie partout : la RFC 9499 note que certains serveurs ignorent les durées très courtes. Tout le débat sur la "propagation" se joue là.

Quels enregistrements DNS un site WordPress demande-t-il ?

Le registre de l’IANA, l’organisme qui attribue les numéros et les paramètres d’Internet, recense une centaine de types. Un site WordPress en utilise une dizaine. Voici ceux que vous croiserez.

Type	Ce qu’il contient	À quoi il sert sur votre WordPress	Référence
A	Une adresse IPv4, quatre nombres séparés par des points	Dire où se trouve le serveur du site	RFC 1035
AAAA	Une adresse IPv6, quatre fois plus longue	Le même rôle, en IPv6	RFC 3596
CNAME	Un alias vers un autre nom	Pointer www ou un sous-domaine vers le nom fourni par un service	RFC 1034
MX	Un serveur de réception du courrier et sa préférence	Recevoir les e-mails du domaine. La cible est un nom, jamais une adresse ni un alias	RFC 2181
TXT	Une ou plusieurs chaînes de texte	SPF, DKIM, DMARC, preuve de propriété, validation de certificat	RFC 1035
NS	Un serveur de noms faisant autorité	Dire qui sert la zone, ou déléguer un sous-domaine	RFC 1035
SOA	Le début de la zone : serveur primaire, numéro de série, durées	Rien à régler, mais la version de la zone se lit ici	RFC 1035
CAA	Les autorités de certification autorisées	Limiter qui peut émettre un certificat pour le domaine	RFC 8659
HTTPS et SVCB	Les paramètres d’accès à un service, ou un alias	Annoncer HTTP/3 ou aliaser la racine : HTTPS pour le site, SVCB pour le reste	RFC 9460
SRV	L’hôte et le port d’un service	Rarement utile à un site : il localise un service précis	RFC 2782

MX, TXT, AAAA : 3 précisions à connaître

Sur un même nom, plusieurs MX cohabitent : la préférence la plus basse passe devant. Sans aucun MX, le courrier n’est pas perdu pour autant. Le serveur expéditeur se rabat sur l’adresse du domaine lui-même (RFC 5321). Pour déclarer qu’un domaine ne reçoit rien, il existe un MX nul, de préférence 0, dont la cible est un simple point.

Le TXT traîne une légende : il serait limité à 255 caractères. La limite vaut pour chaque chaîne. Un enregistrement peut en contenir plusieurs, que SPF et DKIM recollent bout à bout. Quant à l’AAAA, pensez-y le jour où le serveur change… sinon vos visiteurs en IPv6 resteront sur l’ancien.

Pourquoi le CNAME est-il interdit à la racine du domaine et comment les fournisseurs le contournent-ils ?

Beaucoup de services (un CDN, ce réseau qui sert vos pages depuis un serveur proche du visiteur, ou une plateforme d’hébergement) ne vous donnent pas une adresse mais un nom, à viser par un CNAME. Sur www, aucun souci. À la racine du domaine, votre gestionnaire refuse.

Pourquoi ce refus ? Parce qu’un CNAME ne cohabite avec aucune autre donnée sur le même nom, hormis les enregistrements de signature (DNSSEC), et que la racine d’une zone porte toujours un SOA et des NS. Les textes d’origine n’écrivent pas "pas de CNAME à la racine" : la règle découle de ces deux-là.

La RFC 1912 décrit l’erreur type, et son remède, un A à la racine. La RFC 9460, en 2023, le dit en une ligne : à la racine d’une zone, le CNAME n’est pas permis.

Seulement, un A oblige à recopier une adresse qui peut changer sans vous. Chaque fournisseur a donc bricolé sa parade.

Fournisseur	Mécanisme	Ce qu’il fait	Nature
Cloudflare	Aplatissement du CNAME (CNAME flattening)	Actif par défaut à la racine : le serveur renvoie l’adresse finale	Fonction maison
DNSimple	Enregistrement ALIAS	Ses serveurs répondent en A ou en AAAA	Invention maison
Amazon Route 53	Enregistrement alias	Accepté à la racine de la zone	Extension maison
OVHcloud	Enregistrement HTTPS en mode alias (priorité 0)	Renvoie la racine vers un autre nom, pour le web seulement	Norme (RFC 9460)

Vous croiserez aussi le nom ANAME. Il n’a rien d’une norme : le brouillon déposé à l’IETF, l’organisme qui élabore la plupart de ces RFC, a expiré, sa dernière révision date de 2019.

Attention aux effets de bord de l’aplatissement, que Cloudflare documente lui-même. Une vérification de domaine par CNAME peut échouer, puisque le CNAME n’est plus renvoyé tel quel.

HTTPS et SVCB, deux types récents

SVCB porte le numéro 64 au registre, HTTPS le 65. Tous deux sont définis par la RFC 9460, publiée en novembre 2023. Leur rôle : donner au navigateur, avant même la connexion, de quoi joindre un service (un autre point d’accès, les protocoles acceptés). En mode alias, ils font à la racine ce que le CNAME n’a pas le droit d’y faire.

La nuance compte. Pour un site web, on publie un enregistrement HTTPS. SVCB est la version générique, pour les autres protocoles, et la RFC interdit aux navigateurs de s’en servir pour le web. L’exemple qu’elle donne tient en une ligne : @ 7200 IN HTTPS 1 . alpn=h3 annonce que le site accepte HTTP/3.

Toutefois, un navigateur qui ne connaît pas ce type l’ignore, tout simplement. Gardez donc vos A et vos AAAA à la racine. L’alias HTTPS ne vaut d’ailleurs que pour le web : il ne déplace ni vos e-mails ni le reste.

À quoi ressemble la zone DNS d’un site WordPress en production ?

La zone DNS d’un site WordPress en production porte toujours un SOA et des NS, pour la zone elle-même. S’y ajoutent, selon les services branchés sur le domaine, un A et un CNAME pour le site, des MX pour le courrier, des TXT pour l’authentification des e-mails et les preuves de propriété, parfois les clés DNSSEC, qui signent la zone.

Voici celle de wpformation.com telle que n’importe qui peut la lire, relevée le 30 septembre 2026. Je n’y montre ni les adresses, ni les clés, ni les sélecteurs DKIM, ni les noms des serveurs ; le reste est tel quel.

; Zone de wpformation.com, lue le 30 septembre 2026 (extrait)
; Adresses, clés, sélecteurs et noms de serveurs masqués entre crochets

wpformation.com.                 86400  IN  SOA     [serveur primaire OVH] [contact] 2089483469 86400 3600 3600000 300
wpformation.com.                 86400  IN  NS      [deux serveurs de noms OVH]
wpformation.com.                    60  IN  A       [adresse du frontal]
www.wpformation.com.                60  IN  CNAME   [nom fourni par l'hébergeur du frontal]
wpformation.com.                    60  IN  MX      1   [serveur de messagerie OVH]
wpformation.com.                    60  IN  MX      5   [serveur de messagerie OVH]
wpformation.com.                    60  IN  MX      100 [serveur de messagerie OVH]
wpformation.com.                    60  IN  TXT     "v=spf1 mx include:mx.ovh.com include:spf.brevo.com ip4:[adresse masquée] ~all"
wpformation.com.                    60  IN  TXT     [quatre jetons de vérification de propriété]
_dmarc.wpformation.com.             60  IN  TXT     "v=DMARC1;p=none;pct=100;rua=mailto:[adresse du domaine];"
[sélecteur 1]._domainkey.wpformation.com.  86400  IN  TXT     "v=DKIM1; t=s; p=[clé publique]"
[sélecteur 2]._domainkey.wpformation.com.    300  IN  TXT     "k=rsa;p=[clé publique]"
_index._agents.wpformation.com.  86400  IN  SVCB    1 wpformation.com. alpn=h2,h3 port=443
wpformation.com.                 86400  IN  DNSKEY  256 3 8 [clé publique]
wpformation.com.                 86400  IN  DNSKEY  257 3 8 [clé publique]

; Absents à cette date : AAAA et HTTPS à la racine, CAA, MTA-STS, BIMI
; Non reproduits : le sous-domaine qui sert WordPress et les sous-domaines annexes

Que signifie chaque ligne de cette zone ?

Le SOA ouvre la zone : serveur primaire chez OVH, numéro de série 2089483469, puis quatre durées. La dernière, 300, règle le cache négatif dont je parle plus bas. Les NS disent qui sert la zone : OVH, qui est aussi le bureau d’enregistrement de ce nom, créé le 11 octobre 2012.

Le A de la racine et le CNAME de www mènent au frontal du site, la partie que vous lisez. WordPress tourne sur un autre serveur, derrière un sous-domaine que je ne reproduis pas. Le nom et la zone chez un prestataire, le frontal chez un autre, WordPress chez un dernier.

Les MX désignent la messagerie, chez OVH : la préférence 1 passe avant la 5, qui passe avant la 100. Le TXT qui commence par v=spf1 liste qui a le droit d’envoyer des e-mails au nom du domaine : les serveurs des MX, ceux d’OVH, ceux de Brevo (ma lettre d’information) et une adresse. Quatre autres TXT prouvent à des services que le domaine est bien à moi.

Sous _dmarc, la politique DMARC. Sous _domainkey, deux clés publiques DKIM. Puis, sous _index._agents, un SVCB qui n’a rien à voir avec le site : il publie un point d’entrée pour les agents IA. Je l’ai posé à la main le 14 juin 2026. Le texte qui le décrit est un brouillon individuel, sans statut à l’IETF.

Les deux DNSKEY sont les clés publiques de la zone. Elle est signée par DNSSEC, avec l’algorithme 8 (RSA/SHA-256).

Qu’ai-je corrigé depuis et que me reste-t-il à faire ?

Cette zone n’était pas un modèle. Je l’ai relue le 12 octobre sur les deux serveurs de noms d’OVH : voici ce qui a changé.

Le 1er octobre, j’ai posé le CAA, l’enregistrement qui limite les autorités autorisées à émettre un certificat pour le domaine : seule Let’s Encrypt, qui délivre les miens, y figure. Le même jour, j’ai activé la signature DKIM de ma messagerie chez OVH, avec deux clés de 2 048 bits, comme le recommande la RFC 8301. Pour ces deux réglages, Claude Code m’a guidé pas à pas dans l’espace client, puis a vérifié le résultat sur deux résolveurs DNS publics, sans avoir la main sur la zone. J’explique ce partage des rôles dans mon article sur Claude Code et WordPress.

La politique DMARC a suivi, jamais d’un coup, pour ne pas écarter du courrier légitime. Le 2 octobre, je l’ai mise en quarantaine à l’essai, p=quarantine; t=y; pct=0. Le 11 octobre, après lecture des rapports, en quarantaine pour de bon : p=quarantine.

Il me reste deux choses à faire. Les deux anciennes clés DKIM de 1 024 bits sont toujours publiées : aucun message que j’ai relevé ne les utilise, je les retirerai quand les rapports l’auront confirmé.

Et la durée de vie de mes MX, de mon SPF et de mes jetons de vérification est toujours à 60 secondes, bien bas pour des lignes qui ne bougent jamais : un résolveur peut reposer la question chaque minute, pour rien. Celle de la politique DMARC est passée à 300.

Pourquoi un changement met-il "jusqu’à 48 heures" ?

Un changement d’enregistrement DNS devient visible à mesure que les caches expirent. Chaque résolveur garde l’ancienne réponse pendant la durée de vie publiée avec l’enregistrement, puis repose la question : en principe une heure pour 3 600 secondes, une minute pour 60. Les 48 heures, elles, ont sans doute une autre origine, et elle ne concerne pas vos enregistrements courants.

Dans les documentations que j’ai fait relire pour cet article, les délais annoncés vont de 10 minutes à 72 heures : 24 heures pour une zone et 48 pour des serveurs de noms chez OVHcloud, jusqu’à 72 heures dans le cours officiel Learn WordPress. Ce sont des consignes de prudence. Le DNS, lui, ne connaît que des durées de vie.

Que faut-il entendre par le mot "propagation" ?

Cherchez "propagation" dans les textes fondateurs du DNS. Vous ne le trouverez ni dans la RFC 1035, ni dans la 2181, ni dans la RFC 9499, qui fixe le vocabulaire. La RFC 1996 l’emploie, mais pour le délai entre les serveurs d’une même zone. Rien ne "se propage" vers la planète.

Le mot recouvre en réalité une synchronisation, puis des caches. La synchronisation se joue entre les serveurs de noms de votre zone. Quand vous modifiez une ligne, le numéro de série du SOA avance, et les serveurs secondaires comparent leur numéro à celui du primaire pour savoir s’ils doivent recopier la zone. Le primaire peut aussi les prévenir sans attendre.

Les caches sont partout ailleurs. Chaque résolveur garde la réponse le temps de sa durée de vie. Pendant ce temps, deux visiteurs peuvent atteindre deux serveurs différents : tout dépend de ce que leur résolveur a gardé.

Au passage, ce numéro de série n’est pas une date. La RFC 1912 recommande bien la forme année, mois, jour et numéro de révision, mais ce n’est qu’une convention. Celui de ma zone, dans le relevé du 30 septembre, valait 2089483469… Bon courage pour y lire un jour du calendrier.

D’où vient le chiffre de 48 heures

Ce chiffre a une origine plausible, et elle se mesure. Le 30 septembre 2026, j’ai fait demander aux serveurs de l’extension .com quels serveurs de noms répondent pour wpformation.com. Leur réponse, la délégation, est publiée avec une durée de vie de 172 800 secondes. Deux jours, pile.

Même question aux serveurs du .fr et du .org, pour d’autres domaines : 3 600 secondes, une heure. Le "jusqu’à 48 heures" correspondrait donc au changement de serveurs de noms d’un .com, un cas où un cache peut garder l’ancienne délégation deux jours. Je vous le donne comme une interprétation : un résolveur peut aussi retenir la durée de vie publiée par la zone elle-même.

Pour un simple changement d’adresse, l’horloge qui compte est votre durée de vie. D’où le geste à connaître : l’abaisser avant une bascule, puis la remonter une fois le changement confirmé. Avant, c’est-à-dire au moins une ancienne durée de vie plus tôt : les caches gardent l’ancienne réponse jusque-là. Pour une durée d’une heure, la veille suffit ; pour 86 400 secondes, comptez un jour plein.

Le geste vaut aussi le jour où vous devez mettre en ligne un WordPress monté en local.

Le cache négatif : pourquoi il ne faut pas tester trop tôt

Un résolveur met aussi en cache les réponses "ce nom n’existe pas". Combien de temps ? Le plus petit de deux nombres du SOA : sa propre durée de vie et son dernier champ (RFC 2308). Pour ma zone, 300 secondes. La même RFC suggère aux résolveurs de plafonner ce cache entre une et trois heures.

Changer d’hébergeur sans coupure : la bascule du 31 mai 2026

Je le dis en ancien hébergeur (j’ai fondé WPServeur, revendu depuis) : le nom de domaine et l’hébergement ne doivent pas vivre au même endroit. Un hébergeur et un bureau d’enregistrement différents, et je peux passer de l’un à l’autre, ou changer d’hébergeur, sans aucune difficulté. Pour le choix lui-même, voyez mon comparatif des hébergements WordPress.

Mon domaine est ancien. Je l’ai pris il y a des années chez OVH, là où j’ai acheté mes premiers noms de domaine. Sa zone y est restée. Aujourd’hui, je travaille avec Hetzner pour l’hébergement, et surtout avec BookMyName pour les noms de domaine.

Et Cloudflare ? Je n’en suis pas un grand fan : quand je peux l’éviter, je l’évite. Je n’aime pas multiplier les prestataires.

Un seul enregistrement à changer

Fin mai 2026, le WordPress de ce site devait quitter o2switch pour un serveur chez Hetzner. La zone vivait déjà hors de l’hébergeur : aucun serveur de noms à changer, aucune zone à recopier. C’est elle, plus que le bureau d’enregistrement, qui a fait tenir la bascule en une ligne.

Restait un enregistrement A, celui du sous-domaine qui sert WordPress. Pas d’AAAA sur ce nom, donc rien d’autre à basculer.

Avant d’y toucher, j’ai sorti la zone complète. Chaque ligne a été passée en revue : ce qui pointait encore vers l’ancien hébergeur, et ce qui ne devait surtout pas bouger (la racine, le www, les MX).

Le nouveau serveur a été testé sans que le DNS bouge. L’option --resolve de curl force une machine à joindre un nom à l’adresse de son choix : on voit le futur site pendant que le monde entier voit encore l’ancien.

Dimanche 31 mai, vers 6 h 30, j’ai remplacé l’adresse à la main dans l’interface d’OVH. La durée de vie avait été ramenée à 60 secondes. Google, Cloudflare et les serveurs d’OVH ont confirmé la nouvelle adresse.

Le certificat Let’s Encrypt n’est venu qu’après. Son script refuse de tourner tant que le nom ne pointe pas sur le nouveau serveur, et pour cause : l’autorité vient vérifier à l’adresse que donne le DNS.

Le retour arrière tenait en une ligne : l’ancien hébergement restait allumé, il suffisait de remettre l’ancienne adresse. Une minute.

Les contrôles ont suivi. L’API de WordPress répondait, le certificat était valide, un e-mail de test est arrivé, et la comparaison de 15 pages stratégiques n’a montré aucune régression SEO. Le jour même, la durée de vie est remontée à 3 600 secondes. Pour le chantier côté serveur, voyez comment une IA administre mon serveur WordPress.

Pourquoi mon article est-il parti deux fois sur LinkedIn ?

Lundi 1er juin, l’article programmé ce jour-là est parti deux fois sur LinkedIn. Deux exécutions à moins d’une seconde d’écart. Dans le journal du nouveau serveur, à côté de sa propre adresse, celle de l’ancien hébergeur…

L’explication tenait dans la crontab de l’ancien hébergeur, son planificateur de tâches. Une ligne y appelait le fichier wp-cron.php du site par son nom, pour réveiller les tâches planifiées de WordPress. Personne ne l’avait éteinte. Elle a suivi le DNS, et frappé le nouveau serveur.

Deux lignes passées en commentaire, et le journal n’a plus montré qu’une adresse. Sauf que le correctif était incomplet. Le 8 juin, rebelote : deux déclenchements pour le même article, l’un venu du nouveau serveur, l’autre de l’ancien.

Cette fois, le DNS n’y était pour rien. La copie de WordPress restée chez l’ancien hébergeur avait gardé ses articles programmés (il lui en restait sept le 9 juin), et son propre planificateur se réveillait à chaque requête reçue. Le 9 juin, elle a été mise hors service : à partir de ce jour-là, toute requête y a reçu une réponse 410, le code HTTP d’une ressource partie pour de bon.

Je ne l’ai pas bien vécu, évidemment. Mais il fallait faire cette erreur pour en prendre conscience et pouvoir la corriger. Depuis, je répare, et je vérifie régulièrement.

À relever avant de changer une adresse

Une bascule DNS ne coupe rien chez l’ancien hébergeur. Tant que ses machines tournent, elles appellent votre site par son nom, et ce nom mène maintenant chez vous. Avant de changer une adresse, relevez donc tout ce que l’ancien serveur lance tout seul : sa crontab, et les tâches planifiées de son panneau d’administration.

Ne laissez pas non plus l’ancienne copie de WordPress répondre : tant qu’elle reçoit des requêtes, elle publie ses propres articles programmés.

Les e-mails de WordPress passent aussi par le DNS

Des erreurs de zone chez mes clients, je n’en ai pas le souvenir. Ce que je vois parfois, ce sont de mauvais réglages des adresses e-mail, qui les pénalisent : leurs messages sont classés en spam. Or l’authentification des e-mails se publie justement dans la zone.

Sans réglage de votre part, WordPress expédie ses propres messages (le mot de passe oublié, par exemple) depuis wordpress@votre-domaine. Les extensions font comme elles veulent : WooCommerce écrit avec l’adresse de l’administrateur, d’autres reprennent celle de WordPress.

Cette adresse par défaut est écrite dans le code de WordPress, avec un commentaire résigné : certains hébergeurs bloquent les envois depuis cette adresse si elle n’existe pas, "mais il n’y a pas d’alternative simple".

Les messageries jugent donc ce domaine-là. Or la page de référence de la fonction wp_mail() ne dit pas un mot du DNS, de SPF, de DKIM ni de DMARC. Pour le réglage de l’envoi lui-même, suivez mon guide SMTP pour WordPress. Ici, je m’en tiens à ce qui se publie dans la zone.

SPF, DKIM, DMARC : ce que chacun publie

SPF (Sender Policy Framework) liste les serveurs autorisés à envoyer au nom du domaine. Il se publie en TXT, et seulement en TXT : l’ancien type SPF a été abandonné. Un seul enregistrement par nom, sinon la vérification renvoie une erreur permanente, permerror (RFC 7208).

Sa limite la moins connue : dix consultations DNS au plus. Chaque include, a, mx, ptr, exists ou redirect en coûte une, y compris ceux qui se cachent dans les include de vos prestataires. Au-delà, permerror encore : l’enregistrement est publié, mais il ne protège plus rien.

DKIM (DomainKeys Identified Mail) signe chaque message. La clé publique se publie en TXT sous un nom de la forme sélecteur._domainkey. La RFC 8301 recommande des clés RSA d’au moins 2 048 bits. Trop longues pour une seule chaîne, elles sont découpées en plusieurs.

DMARC (Domain-based Message Authentication, Reporting and Conformance) relie les deux. Publié en TXT sous _dmarc, il dit aux messageries ce que le domaine souhaite pour un message qui échoue : rien (p=none), la quarantaine ou le rejet. Chaque messagerie reste libre de sa décision. Un message passe si SPF ou DKIM réussit, et si le domaine authentifié s’aligne sur celui de l’expéditeur affiché.

DMARC depuis la RFC 9989 : ce qui change

La référence a changé. Depuis mai 2026, DMARC est défini par la RFC 9989, sur la voie de normalisation. Elle remplace la RFC 7489, qui n’a jamais été une norme mais un document d’information. Elle ajoute la balise np, la politique pour les sous-domaines qui n’existent pas (sp couvre ceux qui existent), et retire pct, rf et ri.

D’où le pct=100 de ma zone au 30 septembre, désormais sans objet : un récepteur à jour ignore les balises qu’il ne connaît pas. La méthode change sur un point. On commence toujours à p=none avec une adresse de rapports, on lit ce qui remonte, puis on durcit.

Mais le durcissement par pourcentage disparaît : à sa place, la balise t=y met la politique à l’essai, un cran en dessous de celle que vous publiez. Seul un récepteur qui applique la RFC 9989 comprend cette balise : les autres l’ignorent et appliquent la politique publiée. La RFC 9989 donne t=y pour l’équivalent de pct=0, que les anciens récepteurs connaissent : publier les deux couvre les deux cas. C’est ce que j’ai fait du 2 au 11 octobre. Deux enregistrements DMARC sur le même nom s’annulent.

Que demandent Google, Yahoo et Microsoft ?

Le tableau reprend les exigences publiées par ces messageries, relues le 30 septembre 2026.

Messagerie	Tous les expéditeurs	Gros expéditeurs	Depuis
Gmail (comptes personnels)	SPF ou DKIM, DNS direct et inverse valides, chiffrement TLS, taux de spam sous 0,3 %	Plus de 5 000 messages par jour : SPF et DKIM, DMARC (p=none accepté), alignement, désinscription en un clic	1er février 2024, application durcie depuis novembre 2025
Yahoo	SPF ou DKIM au minimum, taux de spam sous 0,3 %, DNS direct et inverse valides	SPF et DKIM, DMARC au moins p=none et qui réussit. Aucun seuil de volume publié	Février 2024
Outlook.com, Hotmail, Live	Non précisé dans l’annonce	Plus de 5 000 messages par jour : SPF, DKIM et DMARC (au moins p=none, aligné). Rejet annoncé avec le code 550 5.7.515	5 mai 2025

Et si votre site envoie peu ?

Un WordPress qui expédie quelques dizaines de messages par jour relève, à lire ces textes, de la colonne "tous les expéditeurs". Côté authentification, SPF ou DKIM y est le minimum demandé ; les autres lignes de la colonne s’appliquent aussi, et aucune ne garantit l’arrivée en boîte de réception.

Mais Google compte par domaine : si votre lettre d’information part du même nom, ses envois s’ajoutent à ceux du site, et le statut de gros expéditeur ne s’efface plus.

Le DNS inverse est l’enregistrement PTR, qui associe une adresse à un nom : il se règle chez celui qui fournit l’adresse du serveur d’envoi. Google recommande aussi d’authentifier le domaine qui héberge votre site public. Si vos messages disparaissent déjà, commencez par comprendre pourquoi vos e-mails WordPress finissent en spam.

Faut-il activer DNSSEC ?

DNSSEC, les extensions de sécurité du DNS, signe les enregistrements d’une zone. Un résolveur qui valide peut ainsi vérifier qu’une réponse vient bien de cette zone et que personne ne l’a modifiée en route. Il ne chiffre rien, ne filtre personne et ne protège pas d’une attaque par déni de service (RFC 4033).

Il ne garantit pas non plus que l’information soit vraie. L’ANSSI, l’agence française de cybersécurité, le rappelle dans son guide de juillet 2024 : si quelqu’un entre dans votre compte chez le prestataire, sa modification sera signée comme les autres.

La pièce à comprendre s’appelle le DS. Cette empreinte de votre clé ne vit pas dans votre zone mais dans celle du dessus, celle de l’extension. Voilà pourquoi elle se dépose chez le bureau d’enregistrement.

Quand le nom et la zone sont au même endroit, l’affaire tient en un bouton. Chez OVH, je l’ai activé à la main le 14 juin 2026, gratuitement. La documentation annonce 24 heures pour que ce soit effectif. Si votre zone est ailleurs, vous devrez recopier vous-même les paramètres du DS chez le bureau d’enregistrement.

Notez la date : deux semaines après la bascule. L’ordre importait peu ce jour-là : changer une adresse dans une zone signée ne touche ni aux clés ni au DS. Le conseil qu’affiche Radar Domaine, l’outil que je présente plus bas (à éviter juste avant une migration), vaut pour le jour où vous changez de serveurs de noms.

Le risque, vu par l’ANSSI et par l’IETF

Le revers est brutal. Si la validation échoue (signature expirée, DS qui ne correspond plus à la clé), un résolveur qui valide ne donne plus aucune réponse exploitable : il renvoie une erreur. Pour ses utilisateurs, votre domaine a disparu.

L’ANSSI parle d’une indisponibilité totale du domaine "pendant plusieurs heures ou plusieurs jours", et son guide "ne recommande pas formellement l’implémentation de DNSSEC" : il demande une analyse de risque. L’IETF va plus loin. Sa RFC 9364, de février 2023, range DNSSEC parmi les bonnes pratiques courantes pour authentifier l’origine des données DNS.

Multisite, certificat, Search Console : les autres cas où WordPress touche au DNS

Le DNS revient dans la vie d’un site WordPress à des moments précis, et rarement quand on l’attend.

Multisite en sous-domaines : le joker n’est pas toujours nécessaire

Un réseau multisite en sous-domaines donne à chaque site son propre nom. L’écran d’installation de WordPress affirme qu’il vous faut un enregistrement joker, l’astérisque. Sa propre documentation le contredit : le joker ne sert que si les sites doivent se créer à la demande, "malgré le conseil qui peut s’afficher à l’écran".

Pour quelques sous-domaines créés à la main, un enregistrement par site suffit. À savoir aussi : un joker ne s’applique pas aux noms qui existent déjà dans la zone. Le reste est dans mon guide du réseau multisite WordPress.

Certificat : le défi DNS et le CAA

Un certificat joker, justement, ne s’obtient pas par le défi HTTP habituel. Chez Let’s Encrypt, seule la validation par le DNS le délivre : le client pose un TXT sous _acme-challenge, et l’autorité vient le lire.

Le CAA agit en amont. Par défaut, toute autorité de certification publique peut émettre un certificat pour votre domaine, pourvu qu’elle en valide le contrôle. Un CAA restreint cette liste, et il vaut pour les sous-domaines qui n’ont pas le leur. Pour Let’s Encrypt, la valeur à publier est 0 issue "letsencrypt.org".

Mais un CAA erroné bloque le renouvellement de vos certificats. Recensez qui émet quoi avant de le poser. Les pannes de certificat elles-mêmes sont dans mon guide du certificat SSL pour WordPress.

Search Console, CDN, changement de nom de domaine

Dans la Google Search Console, une propriété de type Domaine ne se valide que par un enregistrement DNS, un TXT dans le cas le plus courant.

Un CDN vous demandera un CNAME, ou vos serveurs de noms tout entiers. Dans la configuration complète de Cloudflare, vous remplacez vos serveurs de noms par les siens : il devient le gestionnaire de votre zone, et les enregistrements qu’il relaie voient leur durée de vie fixée à 300 secondes.

Si vous changez de nom de domaine, ne comptez pas sur la documentation officielle. Sa page sur la migration de WordPress ne contient pas une seule fois le mot DNS. Ce volet est traité dans mon tutoriel pour déplacer WordPress vers un nouveau nom de domaine.

Comment consulter vos enregistrements DNS ?

Pour consulter les enregistrements DNS d’un domaine, interrogez-les type par type : avec dig, l’outil de BIND, avec nslookup, présent sous Windows, ou avec un outil en ligne. Aucune commande fiable ne liste tout d’un coup. Les requêtes "ANY", encore conseillées ici ou là, peuvent recevoir une réponse partielle ou de synthèse (RFC 8482).

# Les serveurs de noms de la zone
dig +short NS example.com

# Le début de zone : serveur primaire, numéro de série, durées
dig +short SOA example.com

# Les TXT de la racine (SPF, vérifications) et la politique DMARC
dig +short TXT example.com
dig +short TXT _dmarc.example.com

# La même question posée à un serveur de la zone, sans passer par un cache
dig @ns1.example.net example.com MX +norecurse

L’option +short réduit la sortie à la réponse. La forme @serveur choisit à qui poser la question, et +norecurse lui demande de répondre seul, sans interroger personne d’autre. Remplacez example.com par votre domaine, et ns1.example.net par l’un des serveurs de noms que renvoie la première commande. Sous Windows, l’équivalent s’écrit ainsi :

nslookup -type=NS example.com
nslookup -type=TXT _dmarc.example.com
nslookup -type=SOA example.com ns1.example.net

Sur un Windows en français, nslookup écrit "Réponse ne faisant pas autorité" quand le serveur qui répond ne fait pas autorité sur la zone : c’est un résolveur, qui rapporte ce qu’il a appris ailleurs, en cache ou à l’instant. Pour interroger la source, donnez en second argument l’un des serveurs de noms de la zone (dernière ligne).

Ne vous étonnez pas si deux outils n’affichent pas un TXT de la même façon : certains résolveurs entourent chaque chaîne de guillemets, d’autres non. Mon propre outil s’y est laissé prendre, en concluant à une différence qui ne tenait qu’à ça.

Vérifiez votre zone sans ligne de commande avec Radar Domaine

Aucun de mes outils ne regardait cette couche-là. J’en ai donc fabriqué un. Radar Domaine, mon outil gratuit d’analyse d’un nom de domaine, lit en une requête et sans inscription :

• le registre : bureau d’enregistrement, date d’expiration, verrou de transfert, signature DNSSEC ;
• la zone : huit types d’enregistrements, lus chez quatre résolveurs côte à côte ;
• les e-mails : SPF, DMARC, présence de MTA-STS et de BIMI ;
• le certificat : émetteur, échéance, noms couverts.

La propagation y est jugée sur le numéro de série du SOA, vu par les quatre résolveurs, et non sur les adresses. Ce numéro dit quelle version de la zone chaque résolveur connaît, pas si l’ancienne adresse a quitté son cache.

La première version comparait les adresses. Elle concluait en permanence à une propagation en cours chez les hébergeurs qui répartissent la charge, puisqu’ils renvoient exprès des adresses différentes.

Le SPF sera décompté jusqu’au bout : l’outil ouvre chaque include et compte ce qu’il y trouve. Le 23 juillet 2026, le SPF de WPFormation a été pris en défaut, avec 13 consultations pour 10 autorisées et, en prime, un mécanisme ptr que la RFC 7208 demande de ne plus publier. In fine, le cordonnier, vous connaissez la suite…

C’est corrigé depuis : cinq consultations au dernier relevé. Deux ptr subsistent, mais dans l’enregistrement d’OVH que le mien inclut.

La surveillance au quotidien relève de la maintenance, dès 590 € HT par mois : disponibilité et certificats surveillés, mises à jour, sauvegardes contrôlées.

Les erreurs DNS à ne pas commettre

Chez mes clients, je n’en ai pas le souvenir. Celles qui suivent viennent donc des textes de référence, et des pages lues en préparant cet article.

• Prendre un CNAME pour une redirection. Un CNAME est un alias dans le DNS : l’adresse affichée par le navigateur ne change pas.
• Changer de serveurs de noms sans recopier la zone. La nouvelle démarre sans vos MX ni vos TXT, et les e-mails s’arrêtent.
• Lire la durée de vie comme un délai d’envoi.
• Poser un CNAME à la racine du domaine.
• Publier deux enregistrements SPF, ou deux DMARC, sur le même nom. Les messageries n’en retiennent aucun.
• Faire pointer un MX vers une adresse IP ou vers un alias. Sa cible doit être un nom qui possède lui-même un A ou un AAAA.
• Modifier le A en oubliant l’AAAA, ou l’inverse.
• Croire que DMARC a été normalisé en 2015. Le texte de 2015 n’était qu’un document d’information ; celui de mai 2026 est le premier sur la voie de normalisation.

Et la mienne ? Vous la connaissez : croire qu’une bascule s’arrête au DNS.

Un conseil pour finir, et il ne coûte rien. Copiez votre zone dans un fichier texte aujourd’hui, avant d’en avoir besoin. Notez la date, et rangez-le ailleurs que chez le prestataire qui la sert.

Puis regardez où vivent votre nom de domaine et sa zone, c’est-à-dire quels serveurs de noms sont déclarés. S’ils sont chez votre hébergeur, sortez-les de là tant que rien ne presse. Le jour où vous changerez de serveur, vous n’aurez que son adresse à modifier… et une liste de tâches planifiées à éteindre chez l’ancien.

Questions fréquentes

Quelle différence entre zone DNS et serveur DNS ?

La zone DNS est la liste des enregistrements d’un domaine. Le serveur DNS, ou serveur de noms, est la machine qui publie cette liste et répond aux résolveurs. Un domaine n’a qu’une seule zone active à la fois : celle des serveurs de noms déclarés chez le bureau d’enregistrement.

Combien de temps pour qu’un enregistrement DNS soit pris en compte ?

Le temps que les caches expirent, donc la durée de vie (TTL) de l’enregistrement : en principe une heure pour 3 600 secondes, une minute pour 60. Un changement de serveurs de noms peut prendre plus longtemps. La délégation d’un .com est publiée avec une durée de vie de 172 800 secondes, soit deux jours (mesure du 30 septembre 2026).

Peut-on avoir deux enregistrements SPF ?

Non. La RFC 7208 n’admet qu’un enregistrement SPF par nom : avec deux, la vérification renvoie une erreur permanente (permerror). Pour autoriser deux services d’envoi, réunissez leurs mécanismes dans un seul enregistrement, sans dépasser dix consultations DNS.

Faut-il mettre Cloudflare devant WordPress ?

Rien ne l’impose. Dans sa configuration complète, Cloudflare devient le gestionnaire de votre zone : vous remplacez vos serveurs de noms par les siens, et les enregistrements relayés ont une durée de vie fixée à 300 secondes. Je l’évite quand je le peux : c’est une préférence.

Que se passe-t-il si mon domaine expire ?

Pour un .com, les règles de l’ICANN, l’organisme qui encadre les noms de domaine, imposent deux rappels avant l’échéance, un mois puis une semaine avant, environ. Une fois le nom expiré, sa résolution est interrompue avant toute suppression : le site et les e-mails s’arrêtent. Après la suppression, il reste 30 jours pour le récupérer.

Sources

Toutes consultées le 30 septembre 2026 ; les citations anglaises sont données en traduction.

• Bases du DNS : RFC 1034, RFC 1035, RFC 1912, RFC 1996, RFC 2181, RFC 2308 et RFC 9499
• Types d’enregistrements : RFC 3596, RFC 5321, RFC 7505, RFC 2782, RFC 8482, RFC 8659, RFC 9460 et registre de l’IANA
• E-mails : RFC 7208 (SPF), RFC 6376 et RFC 8301 (DKIM), RFC 9989 (DMARC), RFC 8461 (MTA-STS) et brouillon BIMI
• Messageries : consignes de Google et leur foire aux questions, de Yahoo et de Microsoft
• DNSSEC : RFC 4033, RFC 4034, RFC 4035, RFC 9364, guide de l’ANSSI et documentation d’OVHcloud
• Alias à la racine : documentations de Cloudflare, DNSimple, Amazon Route 53 et OVHcloud, et brouillon ANAME
• WordPress : fichier pluggable.php, référence de wp_mail(), documentation du multisite et de la migration, cours Learn WordPress
• Certificats et vérifications : Let’s Encrypt (types de défis et CAA) et aide de la Search Console
• Domaines et zones : politique de l’ICANN sur les noms expirés, root-servers.org, OVHcloud (créer une zone), Cloudflare (configuration complète et durées de vie)
• Outils et mesures : manuels de dig et de nslookup ; zone de wpformation.com et durées de vie des délégations relevées le 30 septembre 2026