Dernière mise à jour : septembre 2026
Les enregistrements DNS (Domain Name System) sont les fondations invisibles de toute présence en ligne. Chaque fois qu’un visiteur tape votre adresse dans son navigateur, qu’un email est envoyé depuis votre domaine ou qu’un certificat SSL est émis, ce sont vos enregistrements DNS qui orchestrent le tout. Mal configurés, ils peuvent rendre votre site inaccessible, vos emails rejetés ou votre domaine vulnérable.
Dans cet article, nous passons en revue tous les enregistrements DNS essentiels, avec pour chacun une explication claire, un exemple de syntaxe concret et les bonnes pratiques à appliquer.
Partie 1 — Les enregistrements de résolution
Ces enregistrements sont ceux qui permettent de faire pointer votre nom de domaine vers un serveur. C’est la base de toute configuration DNS.
L’enregistrement A (Address)
L’enregistrement A associe un nom de domaine à une adresse IPv4. C’est l’enregistrement le plus fondamental : il dit à Internet « ce domaine se trouve à cette adresse IP ».
exemple.com. 3600 IN A 203.0.113.10
www.exemple.com. 3600 IN A 203.0.113.10Bonnes pratiques : vérifiez que l’IP pointe bien vers votre serveur actuel, surtout après une migration. Un enregistrement A obsolète est une cause fréquente de site inaccessible après un changement d’hébergeur. Si vous utilisez un CDN comme Cloudflare, l’enregistrement A pointe vers le CDN et non vers votre serveur directement.
L’enregistrement AAAA (IPv6 Address)
L’enregistrement AAAA est l’équivalent de l’enregistrement A pour les adresses IPv6. Avec l’épuisement progressif des adresses IPv4, IPv6 est de plus en plus utilisé par les fournisseurs d’accès et les hébergeurs.
exemple.com. 3600 IN AAAA 2001:db8::1Bonnes pratiques : si votre hébergeur fournit une adresse IPv6, configurez l’enregistrement AAAA en parallèle du A. Cela améliore l’accessibilité de votre site pour les visiteurs dont le FAI utilise IPv6 nativement.
L’enregistrement CNAME (Canonical Name)
L’enregistrement CNAME crée un alias : il fait pointer un nom de domaine vers un autre nom de domaine (et non vers une IP). C’est très utile pour les sous-domaines.
blog.exemple.com. 3600 IN CNAME exemple.com.
shop.exemple.com. 3600 IN CNAME ma-boutique.shopify.com.Règle importante : un CNAME ne peut jamais être placé sur un domaine racine (apex). Autrement dit, exemple.com ne peut pas être un CNAME — seuls les sous-domaines le peuvent. Pour contourner cette limitation, certains fournisseurs DNS proposent des enregistrements propriétaires comme ALIAS ou ANAME qui fonctionnent de manière similaire au niveau de l’apex.
L’enregistrement NS (Name Server)
L’enregistrement NS indique quels serveurs DNS font autorité pour votre zone DNS. Ce sont eux qui répondent aux requêtes concernant votre domaine. Ils sont généralement définis par votre registrar ou votre fournisseur DNS.
exemple.com. 86400 IN NS ns1.fournisseur-dns.com.
exemple.com. 86400 IN NS ns2.fournisseur-dns.com.Bonnes pratiques : ayez toujours au minimum deux serveurs NS (idéalement sur des réseaux différents) pour assurer la redondance. Si vos NS sont injoignables, votre domaine entier devient inaccessible — site, emails, tout.
Partie 2 — Les enregistrements email
La délivrabilité de vos emails dépend directement de votre configuration DNS. Depuis février 2024, les exigences se sont considérablement renforcées.
L’enregistrement MX (Mail Exchange)
L’enregistrement MX indique quels serveurs sont chargés de recevoir les emails destinés à votre domaine. Chaque entrée MX possède une priorité : le serveur avec la valeur la plus basse est contacté en premier.
exemple.com. 3600 IN MX 10 mail1.exemple.com.
exemple.com. 3600 IN MX 20 mail2.exemple.com.Dans cet exemple, mail1 (priorité 10) reçoit les emails en priorité. Si ce serveur est indisponible, mail2 (priorité 20) prend le relais. Pour Google Workspace, les MX pointent vers les serveurs aspmx.l.google.com avec leurs priorités respectives.
SPF — Sender Policy Framework (enregistrement TXT)
SPF permet de déclarer quels serveurs sont autorisés à envoyer des emails au nom de votre domaine. C’est la première ligne de défense contre l’usurpation d’identité (spoofing). SPF se configure via un enregistrement TXT (le type d’enregistrement SPF dédié a été déprécié par le RFC 7208).
exemple.com. 3600 IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all"Décryptage de la syntaxe :
v=spf1— identifie l’enregistrement comme SPFinclude:— autorise les serveurs déclarés dans le SPF d’un autre domaine (ici Google Workspace et SendGrid)ip4:— autorise une IP spécifique (votre serveur par exemple)~all(softfail) — les emails provenant de serveurs non listés sont marqués comme suspects mais pas rejetés-all(hardfail) — les emails provenant de serveurs non listés sont rejetés (plus strict)
Attention à la limite des 10 lookups DNS : chaque include: et chaque redirect: compte comme un lookup. Au-delà de 10 au total, votre SPF est invalide et vos emails risquent d’être rejetés. Surveillez cette limite lorsque vous ajoutez des services tiers (CRM, newsletter, outil de facturation…).
DKIM — DomainKeys Identified Mail (enregistrement TXT)
DKIM ajoute une signature cryptographique à chaque email sortant. Le serveur destinataire vérifie cette signature en consultant la clé publique publiée dans votre DNS. Si la signature correspond, l’email est authentifié comme provenant bien de votre domaine et n’ayant pas été altéré en transit.
google._domainkey.exemple.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQE..."Décryptage :
google._domainkey— le sélecteur (ici « google ») suivi de._domainkey. Chaque service d’envoi utilise son propre sélecteurv=DKIM1— version du protocolek=rsa— algorithme de chiffrement utilisép=— la clé publique (fournie par votre service d’envoi)
Bonnes pratiques : chaque service qui envoie des emails en votre nom (Google Workspace, votre hébergeur, votre outil de newsletter, votre CRM) doit avoir son propre enregistrement DKIM. Ne confondez pas la clé DKIM avec le SPF — ce sont deux mécanismes complémentaires.
DMARC — Domain-based Message Authentication, Reporting and Conformance (enregistrement TXT)
DMARC est la couche de décision qui s’appuie sur SPF et DKIM. Il indique aux serveurs destinataires ce qu’ils doivent faire quand un email échoue les vérifications SPF et/ou DKIM : ne rien faire, le mettre en quarantaine ou le rejeter.
_dmarc.exemple.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-rapports@exemple.com; pct=100"Décryptage :
p=none— aucune action, mais vous recevez les rapports (mode observation, idéal pour commencer)p=quarantine— les emails non conformes sont dirigés vers le dossier spamp=reject— les emails non conformes sont purement rejetés (le plus strict)rua=mailto:— adresse où recevoir les rapports agrégés DMARCpct=100— pourcentage des emails soumis à la politique (100 % = tous)
Conseil de mise en œuvre : commencez toujours par p=none pendant quelques semaines pour analyser les rapports et vérifier que tous vos flux d’envoi légitimes sont bien couverts par SPF et DKIM. Passez ensuite à quarantine, puis à reject une fois que tout est en ordre.
Exigences Google et Yahoo : ce qui a changé depuis 2024
Depuis février 2024, Google et Yahoo ont durci leurs exigences en matière d’authentification email. Depuis novembre 2025, les emails non conformes sont activement rejetés (et non plus simplement marqués).
Pour les expéditeurs en masse (5 000+ emails/jour) :
- SPF et DKIM et DMARC sont tous les trois obligatoires
- Alignement des domaines : le domaine du
From:doit correspondre au domaine SPF ou DKIM - Mécanisme de désinscription en un clic obligatoire
- Taux de spam inférieur à 0,3 %
Pour tous les expéditeurs :
- SPF ou DKIM (au minimum l’un des deux)
- Enregistrement PTR valide pour l’IP d’envoi
- Conformité au format RFC 5322
En résumé : si vous envoyez des emails depuis votre domaine — même un simple formulaire de contact WordPress — vous devez au minimum avoir SPF et DKIM configurés. Et si vous utilisez un outil de newsletter ou de marketing, les trois (SPF + DKIM + DMARC) sont indispensables.
Partie 3 — Sécurité et vérification
L’enregistrement TXT (Text)
L’enregistrement TXT est un enregistrement polyvalent qui permet de stocker du texte libre associé à votre domaine. Au-delà de SPF, DKIM et DMARC (qui sont techniquement des enregistrements TXT), il sert principalement à la vérification de propriété de domaine.
exemple.com. 3600 IN TXT "google-site-verification=abc123..."
exemple.com. 3600 IN TXT "facebook-domain-verification=xyz789..."De nombreux services demandent d’ajouter un enregistrement TXT pour prouver que vous êtes bien le propriétaire du domaine : Google Search Console, Facebook Business, les services d’envoi d’emails, les outils analytics, etc.
L’enregistrement CAA (Certificate Authority Authorization)
L’enregistrement CAA permet de spécifier quelles autorités de certification (CA) sont autorisées à émettre des certificats SSL/TLS pour votre domaine. C’est un mécanisme de sécurité qui empêche l’émission de certificats non autorisés.
exemple.com. 3600 IN CAA 0 issue "letsencrypt.org"
exemple.com. 3600 IN CAA 0 issuewild "letsencrypt.org"
exemple.com. 3600 IN CAA 0 iodef "mailto:securite@exemple.com"Décryptage :
issue— autorise cette CA à émettre des certificats pour le domaineissuewild— autorise cette CA à émettre des certificats wildcard (*.exemple.com)iodef— adresse de notification en cas de tentative d’émission non autorisée
Bonnes pratiques : si vous utilisez Let’s Encrypt (ce qui est le cas sur la plupart des hébergements modernes), ajoutez un enregistrement CAA autorisant letsencrypt.org. Sans enregistrement CAA, n’importe quelle CA peut émettre un certificat pour votre domaine — ce qui représente un risque de sécurité.
L’enregistrement PTR (Pointer — DNS inverse)
L’enregistrement PTR fait l’inverse de l’enregistrement A : il associe une adresse IP à un nom de domaine. On parle de résolution DNS inverse (reverse DNS). Cet enregistrement est géré par le propriétaire de l’adresse IP (votre hébergeur), pas dans votre zone DNS habituelle.
10.113.0.203.in-addr.arpa. 3600 IN PTR mail.exemple.com.Pourquoi c’est important : de nombreux serveurs de messagerie vérifient le PTR de l’IP qui leur envoie un email. Si le reverse DNS ne correspond pas ou n’existe pas, l’email a de fortes chances d’être rejeté ou classé comme spam. C’est une exigence explicite de Google et Yahoo pour tous les expéditeurs. Si vous gérez votre propre serveur email, vérifiez auprès de votre hébergeur que le PTR est correctement configuré.
Partie 4 — Enregistrements avancés
L’enregistrement SRV (Service Locator)
L’enregistrement SRV permet de déclarer les services disponibles sur votre domaine avec leur emplacement, leur port et leur priorité. Il est utilisé notamment pour la VoIP (SIP), la messagerie instantanée (XMPP), ou la découverte automatique de services (comme les serveurs CalDAV/CardDAV).
_sip._tcp.exemple.com. 3600 IN SRV 10 60 5060 sipserver.exemple.com.Format : priorité poids port cible. La priorité fonctionne comme pour le MX (la plus basse est contactée en premier), et le poids permet de répartir la charge entre serveurs de même priorité.
L’enregistrement SOA (Start of Authority)
L’enregistrement SOA est automatiquement créé pour chaque zone DNS. Il contient les métadonnées de la zone : le serveur DNS principal, l’email de l’administrateur, le numéro de série et les intervalles de rafraîchissement.
exemple.com. IN SOA ns1.fournisseur.com. admin.exemple.com. (
2026091901 ; Numéro de série
7200 ; Refresh (2h)
3600 ; Retry (1h)
1209600 ; Expire (14j)
3600 ; TTL minimum (1h)
)En pratique, vous n’avez que rarement besoin de modifier le SOA directement — votre fournisseur DNS le gère. Mais le comprendre est utile pour le diagnostic : le numéro de série permet de vérifier que les modifications de zone se sont bien propagées entre les serveurs DNS.
Partie 5 — Le TTL : un paramètre souvent négligé
Le TTL (Time To Live) n’est pas un type d’enregistrement à proprement parler, mais un paramètre présent sur chaque enregistrement DNS. Il indique, en secondes, la durée pendant laquelle un résolveur DNS peut mettre en cache la réponse avant de la redemander au serveur faisant autorité.
exemple.com. 3600 IN A 203.0.113.10 ; TTL de 3600 secondes = 1 heure
exemple.com. 300 IN A 203.0.113.10 ; TTL de 300 secondes = 5 minutesLes bonnes pratiques :
- En fonctionnement normal : un TTL entre 3600 (1h) et 86400 (24h) est recommandé. Cela réduit la charge sur vos serveurs DNS et accélère la résolution pour vos visiteurs
- Avant une migration : abaissez le TTL à 300 (5 min) au moins 24 à 48 heures avant le changement. Ainsi, lorsque vous basculerez l’IP, la propagation sera quasi immédiate
- Après la migration : une fois que tout est stable, remontez le TTL à sa valeur normale
Erreur fréquente : changer l’IP d’un enregistrement A qui a un TTL de 86400 (24h) sans l’avoir abaissé au préalable. Résultat : certains visiteurs voient encore l’ancien serveur pendant 24 heures, avec des erreurs ou un site en maintenance. C’est un classique lors des migrations mal préparées.
Conclusion
Une configuration DNS rigoureuse ne se limite pas à faire pointer un domaine vers un serveur. C’est un ensemble cohérent qui couvre la résolution, la messagerie, la sécurité et la performance de votre présence en ligne. Un enregistrement SPF incomplet et vos emails finissent en spam. Un PTR absent et Google rejette vos messages. Un TTL mal géré et votre migration tourne au cauchemar.
Si vous avez un doute sur la configuration DNS de votre domaine, ou si vous constatez des problèmes de délivrabilité email ou d’accessibilité de votre site, n’hésitez pas à faire appel à un professionnel pour auditer votre zone DNS.