Les enregistrements DNS expliqués (A, AAAA, MX, TXT, CNAME)

Chaque fois que vous ouvrez un site, envoyez un e-mail ou vérifiez un domaine, vous lisez des enregistrements DNS — les petites entrées texte qui indiquent à Internet où pointe votre domaine. Ce guide explique les types d'enregistrements que vous rencontrerez vraiment, à quoi ressemble chacun, et comment le TTL et la propagation décident du moment où vos changements deviennent actifs. Vous pouvez tous les voir pour n'importe quel domaine avec notre outil de recherche DNS.

Réponse rapide

Un même domaine possède généralement plusieurs types à la fois — A/AAAA pour le site, MX pour l'e-mail, TXT pour la vérification, et NS pour déléguer qui répond.

A et AAAA — les adresses

Les deux enregistrements d'adresse sont les piliers du DNS. Tous deux répondent à la question « à quelle IP me connecter ? » — ils parlent simplement des versions différentes du protocole IP.

• Enregistrement A → une adresse IPv4 (104.16.132.229)
• Enregistrement AAAA → une adresse IPv6 (2606:4700::6810:84e5)

Un domaine peut publier les deux ; un client utilise celui que son réseau prend en charge (les appareils modernes préfèrent IPv6 quand c'est possible). Si un site se charge sur un appareil mais pas un autre, des enregistrements AAAA manquants ou erronés sont un coupable classique. Pour la différence entre les deux protocoles, voir IPv4 vs IPv6 expliqué.

CNAME — les alias

Un enregistrement CNAME (nom canonique) dit « ce nom est en réalité un autre nom ». C'est ainsi que www.example.com peut pointer vers example.com, ou qu'un domaine personnalisé pointe vers un hébergeur comme myapp.netlify.app.

Deux règles posent souvent problème :

1. Pas de CNAME à l'apex. On ne peut pas placer un CNAME sur le domaine racine (example.com) à côté d'enregistrements requis comme MX et NS. Les fournisseurs proposent « ALIAS »/« ANAME »/« flattening » pour contourner cela.
2. Un CNAME ne peut coexister avec d'autres types d'enregistrements sur le même nom. L'alias est la réponse.

MX — où va l'e-mail

Les enregistrements MX (mail exchange) routent l'e-mail. Quand un autre serveur veut écrire à vous@example.com, il consulte vos enregistrements MX pour trouver les serveurs de réception.

Priorité   Serveur de mail
10         aspmx.l.google.com.
20         alt1.aspmx.l.google.com.

• Plus le numéro de priorité est bas, plus la préférence est haute — les expéditeurs essaient 10 avant 20.
• Les MX pointent vers des noms d'hôte, pas des IP, et ces noms ont besoin de leurs propres A/AAAA.
• Pas d'enregistrement MX signifie généralement que le domaine ne peut pas recevoir d'e-mail.

TXT — vérification et authentification e-mail

Les enregistrements TXT contiennent du texte libre et accomplissent discrètement des tâches parmi les plus importantes du DNS :

• SPF — liste les serveurs autorisés à envoyer du courrier pour votre domaine : v=spf1 include:_spf.google.com ~all
• DKIM — publie une clé publique servant à signer votre courrier sortant.
• DMARC — définit une politique pour le courrier qui échoue à SPF/DKIM.
• Vérification de domaine — des chaînes comme google-site-verification=… qui prouvent que vous possédez le domaine.

Si vos e-mails atterrissent en spam, vos enregistrements TXT (SPF/DKIM/DMARC) sont la première chose à vérifier.

NS — qui commande

Les enregistrements NS (serveur de noms) listent les serveurs faisant autorité pour un domaine — ceux qui détiennent les vraies réponses. Quand vous déplacez votre DNS vers Cloudflare, Route 53 ou un autre fournisseur, vous changez les enregistrements NS chez votre registraire. Tout le reste (A, MX, TXT…) réside sur les serveurs de noms désignés par les NS.

TTL et propagation — pourquoi les changements ne sont pas instantanés

Chaque enregistrement porte un TTL (durée de vie) en secondes — la durée pendant laquelle un résolveur peut le mettre en cache.

example.com.   300   IN   A   104.16.132.229
               ↑ TTL = met cette réponse en cache 300s (5 min)

Après une modification, les résolveurs qui ont déjà mis en cache l'ancienne valeur continuent de la servir jusqu'à l'expiration du TTL. C'est pourquoi un changement peut sembler actif pour vous mais obsolète pour quelqu'un d'autre — il détient une copie en cache. À l'échelle mondiale, la propagation complète peut prendre jusqu'à 48 heures.

Astuce : avant une migration prévue, réduisez le TTL (par ex. à 300s) un jour à l'avance. La bascule se vide alors en minutes plutôt qu'en heures.

Vous pouvez voir si un changement s'est propagé en comparant les résolveurs : si Cloudflare 1.1.1.1 et Google 8.8.8.8 renvoient des réponses différentes pour le même enregistrement, le changement est encore en cours de déploiement (ou le domaine utilise un DNS géographique / split-horizon). Notre outil DNS effectue cette comparaison pour vous et signale si les deux grands résolveurs publics sont d'accord.

Lire les enregistrements comme un pro

1. Le site ne charge pas sur certains réseaux ? Vérifiez A et AAAA.
2. E-mails qui rebondissent ? Vérifiez MX, puis SPF/DKIM/DMARC dans TXT.
3. Domaine personnalisé mal pointé ? Vérifiez le CNAME (et rappelez-vous : pas à l'apex).
4. Vous venez de changer de fournisseur ? Confirmez les NS chez votre registraire.
5. Changement invisible ? C'est le TTL — comparez les résolveurs et attendez l'expiration du cache.

Vous voulez le tableau complet pour votre domaine ? Lancez une recherche DNS — elle affiche les enregistrements A, AAAA, MX, TXT, NS et CNAME avec leurs TTL, permet de basculer entre les résolveurs Cloudflare et Google, et vérifie la propagation. Pour comprendre comment les requêtes circulent, lisez Qu'est-ce que la résolution DNS et le DNS over HTTPS.