Réseau
Guide de référence des types d'enregistrements DNS
Référence des types d'enregistrements DNS nécessaires à l'exploitation d'un service de messagerie et d'un site web — A, MX, TXT, SPF, DKIM, DMARC et plus — avec leur objet, des exemples de syntaxe et les pièges à éviter.
Types d'enregistrements DNS
| Type | Objet | Exemple | Remarque |
|---|---|---|---|
| Enregistrement A | Le type d'enregistrement le plus élémentaire : il associe un nom de domaine à une adresse IPv4, indiquant où se trouve réellement un serveur web ou de messagerie. | example.com. 3600 IN A 192.0.2.1 |
Un TTL trop court (3600 secondes = 1 heure dans cet exemple) augmente les requêtes vers le serveur faisant autorité et la charge ; un TTL trop long retarde la propagation lors d'un changement d'IP. |
| Enregistrement AAAA | Associe un nom de domaine à une adresse IPv6 — l'équivalent, en somme, de l'enregistrement A pour l'IPv6. | example.com. 3600 IN AAAA 2001:db8::1 |
Conserver également un enregistrement A permet aux réseaux ne prenant pas en charge l'IPv6 de basculer sur l'IPv4 (fonctionnement en double pile). |
| Enregistrement CNAME | Traite un nom d'hôte comme un alias d'un autre nom d'hôte canonique, par exemple en faisant pointer www.example.com vers example.com. | www.example.com. 3600 IN CNAME example.com. |
Un nom d'hôte doté d'un CNAME ne peut pas avoir d'autres enregistrements (comme MX ou TXT) en parallèle (contrainte de la RFC 1034). Un CNAME ne peut pas non plus être défini à la racine de la zone (@). |
| Enregistrement MX | Indique quel serveur de messagerie doit recevoir les e-mails adressés à un domaine. Plusieurs serveurs peuvent être listés avec une valeur de priorité. | example.com. 3600 IN MX 10 mail.example.com. |
Une valeur de priorité plus basse signifie une priorité plus élevée. Il est courant de lister plusieurs serveurs à des priorités différentes pour assurer la redondance. La cible d'un MX doit être un nom d'hôte avec un enregistrement A, jamais un CNAME. |
| Enregistrement TXT | Un enregistrement polyvalent qui attache du texte libre à un domaine. Utilisé pour SPF, DKIM et DMARC, ainsi que pour la vérification de propriété de domaine, entre autres usages. | example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all" |
Un domaine peut avoir plusieurs enregistrements TXT, mais en placer plusieurs pour le même usage (comme SPF) provoque des erreurs d'interprétation — il faut les regrouper en un seul enregistrement. |
| Enregistrement SPF (un type d'enregistrement TXT) | Énumère les serveurs (adresses IP) autorisés à envoyer des e-mails au nom d'un domaine, fournissant une authentification de l'expéditeur qui aide à prévenir l'usurpation. Configuré comme un enregistrement TXT. | example.com. 3600 IN TXT "v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all" |
Un seul enregistrement SPF est valide par domaine. Attention aux chaînes d'"include", car dépasser la limite de 10 résolutions DNS provoque une erreur permanente. Le type d'enregistrement dédié (RRTYPE 99) a été abandonné en 2014 ; le SPF s'exprime désormais uniquement via des enregistrements TXT. |
| Enregistrement DKIM (un type d'enregistrement TXT) | Ajoute une signature numérique aux e-mails sortants afin que le destinataire puisse vérifier qu'ils n'ont pas été altérés en transit et proviennent bien d'un expéditeur légitime. La clé publique est publiée sous forme d'enregistrement TXT. | selector._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..." |
Le sélecteur (la partie initiale du nom d'hôte) varie selon le service d'envoi. La clé privée reste sur le serveur d'envoi — seule la clé publique est publiée dans le DNS. |
| Enregistrement DMARC (un type d'enregistrement TXT) | Déclare, à partir des résultats SPF et DKIM, comment un destinataire doit traiter les e-mails qui échouent à l'authentification (les délivrer, les mettre en quarantaine ou les rejeter), et fournit un canal pour recevoir des rapports agrégés. | _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]" |
Commencer par p=none pour un simple suivi, puis durcir progressivement vers quarantine et reject une fois confirmé qu'il n'y a pas de problème, est la méthode de déploiement la plus sûre. |
| Enregistrement NS | Indique quels serveurs font autorité pour un domaine (une zone) — le point de départ de la résolution de noms sous ce domaine. | example.com. 86400 IN NS ns1.example-dns.com. |
Si les serveurs de noms enregistrés chez le bureau d'enregistrement ne correspondent pas aux enregistrements NS présents dans la zone, la résolution de noms devient instable (on parle de « lame delegation »). |
| Enregistrement SOA | Contient les informations d'administration d'une zone — serveur principal, e-mail de l'administrateur, numéro de série, intervalles de nouvelle tentative, etc. Chaque zone doit en avoir exactement un. | example.com. 86400 IN SOA ns1.example-dns.com. admin.example.com. (2026071200 3600 900 604800 86400) |
À chaque mise à jour du fichier de zone, il faut impérativement incrémenter le numéro de série, sinon les serveurs secondaires ne récupéreront jamais la modification via le transfert de zone. |
| Enregistrement CAA | Restreint quelles autorités de certification (CA) sont autorisées à émettre des certificats pour un domaine, empêchant des CA non prévues d'émettre des certificats frauduleux. | example.com. 3600 IN CAA 0 issue "letsencrypt.org" |
Si un domaine ne possède aucun enregistrement CAA, n'importe quelle CA est considérée comme autorisée à émettre pour lui. Les certificats génériques (wildcard) nécessitent une balise issuewild distincte. |
| Enregistrement PTR | Résout une adresse IP vers un nom d'hôte — l'inverse d'un enregistrement A. Configuré dans une zone inverse (in-addr.arpa / ip6.arpa). | 1.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com. |
De nombreux serveurs de messagerie marquent comme spam ou rejettent les e-mails provenant d'expéditeurs sans PTR inverse ou dont le PTR ne correspond pas à l'enregistrement A — c'est donc quasiment obligatoire pour un serveur d'envoi. |
Astuces
- En cas de doute sur SPF, DKIM ou DMARC, diagnostiquez d'abord vos enregistrements actuels avec l'outil « Vérificateur d'enregistrements SPF/DKIM/DMARC », puis comparez-les aux exemples de syntaxe de cette page.
- Un TTL d'environ une heure (3600 secondes) est une valeur par défaut sûre pour les enregistrements courants ; le réduire à environ 300 secondes juste avant une migration DNS accélère la propagation, quitte à le remonter ensuite.
- Les valeurs d'enregistrement TXT de plus de 255 caractères peuvent être automatiquement découpées en plusieurs chaînes, vérifiez donc que les guillemets restent cohérents après un copier-coller.
- Pour vérifier également le format d'une adresse e-mail elle-même, l'outil « Validateur de format d'adresse e-mail » comble cet aspect.
- Lors du déploiement d'un nouveau service d'envoi d'e-mails, démarrez DMARC avec p=none, surveillez les rapports pendant une ou deux semaines pour confirmer l'absence de problème, puis passez à une politique contraignante — c'est la voie la plus sûre.
Questions fréquentes
SPF vérifie la légitimité de l'adresse IP d'origine — autrement dit « depuis quel serveur cela a-t-il été envoyé » —, tandis que DKIM vérifie l'intégrité du message grâce à une signature numérique — « le contenu a-t-il été altéré ». Ce n'est que lorsque les deux réussissent que l'authentification de l'expéditeur offre une protection réellement efficace.
Ce n'est pas une exigence légale, mais les grands fournisseurs de messagerie comme Gmail et Yahoo Mail exigent de fait DMARC pour les envois en masse, et son absence augmente nettement le risque d'être marqué comme spam ou rejeté.
Les causes les plus fréquentes sont une cible MX pointant vers un CNAME au lieu d'un nom d'hôte avec un enregistrement A, une valeur de priorité mal configurée, ou un serveur de messagerie qui n'est lui-même pas configuré pour accepter les e-mails de ce domaine.
Utilisez un enregistrement A/AAAA lorsque l'adresse IP est fixe et que vous souhaitez la définir à la racine du domaine (@) ; utilisez un CNAME lorsque vous voulez que le nom d'hôte serve d'alias à un autre hôte, par exemple un point de terminaison CDN.
En fonctionnement normal, environ une heure (3600 secondes) est courant. La réduire à environ 300 secondes juste avant une migration de serveur ou un changement de DNS permet une propagation plus rapide une fois le basculement effectué.
Anecdote — l'histoire des enregistrements DNS et de l'authentification des e-mails
Le DNS est surtout connu pour associer des noms de domaine à des adresses IP, mais il existe en réalité bien d'autres types d'enregistrements au-delà de A et AAAA, chacun jouant un rôle distinct. Dans le monde de la délivrabilité des e-mails en particulier, plusieurs enregistrements — MX, TXT (qui porte SPF/DKIM/DMARC) et PTR — ne permettent de conclure qu'un e-mail est « légitime, non usurpé » que lorsqu'ils fonctionnent tous ensemble ; il suffit qu'un seul manque pour que le risque d'atterrir dans le dossier spam ou d'être rejeté augmente.
En retraçant l'histoire de l'authentification des expéditeurs, SPF a été proposé au début des années 2000 comme mesure contre le spam, et DKIM, destiné à détecter l'altération du contenu des messages, a été normalisé vers 2007. Pourtant, ni l'un ni l'autre, pris isolément, ne définissait ce que le destinataire devait faire en cas d'échec de l'authentification — DMARC est arrivé en 2012 pour combler ce vide. DMARC évalue conjointement les résultats de SPF et DKIM et fournit à la fois une politique d'application en cas d'échec et un mécanisme de rapports, faisant ainsi office de centre de commandement de l'authentification.
Certains enregistrements DNS ont changé de forme pour des raisons historiques. Un type d'enregistrement dédié à SPF (RRTYPE 99) a bien été défini dans une RFC de 2006, mais il a semé la confusion lors de sa mise en œuvre et a été formellement abandonné par la RFC 7208 en 2014 ; aujourd'hui, SPF s'exprime exclusivement via des enregistrements TXT. De même, DKIM et DMARC n'ont pas de type d'enregistrement propre : tous deux sont entièrement mis en œuvre à l'intérieur d'enregistrements TXT selon une syntaxe précise (des chaînes commençant par v=DKIM1 ou v=DMARC1), ce qui en dit long sur l'extensibilité réelle du DNS.