RFC 1035 – Noms de domaine : Implémentation et Spécification

Norme Internet Routage DNS et courrier Published March 2026

ELI5: Quand vous envoyez une lettre, vous devez savoir quel bureau de poste gère l'adresse du destinataire. DNS est l'annuaire téléphonique qui répond à cette question pour le courrier électronique. Vous recherchez le nom de domaine et DNS vous indique quels serveurs de messagerie acceptent le courrier pour celui-ci (enregistrements MX), quelles sont leurs adresses IP (enregistrements A/AAAA) et quelles politiques s'appliquent (enregistrements TXT pour SPF, DKIM, DMARC). Sans DNS, il n'y a aucun moyen de livrer le courrier électronique.

Pourquoi cette RFC existe

RFC 1035, publiée en 1987 aux côtés de RFC 1034, définit les détails d'implémentation du Système de noms de domaine. Bien que DNS soit une infrastructure à usage général, il est absolument critique pour le courrier électronique. Chaque livraison d'e-mail commence par une recherche DNS — le serveur d'envoi doit découvrir quels serveurs acceptent le courrier pour le domaine du destinataire.

RFC 1035 définit les types d'enregistrements, les formats de requête et les structures de réponse qui le rendent possible. Pour le courrier électronique, quatre types d'enregistrements sont essentiels : MX (routage de l'échange de courrier), A (adresses IPv4), AAAA (adresses IPv6, définies ultérieurement dans RFC 3596), et TXT (enregistrements texte utilisés pour SPF, clés DKIM, politiques DMARC, et plus).

Sans RFC 1035, il n'y aurait aucun moyen standard de mapper un nom de domaine aux serveurs qui gèrent son courrier. Chaque mécanisme d'authentification et de routage du courrier électronique moderne en dépend.

Comment cela fonctionne

Quand un MTA d'envoi a besoin de livrer un message à user@example.com, il suit une séquence de recherche DNS spécifique :

Interroger les enregistrements MX pour example.com. La réponse contient un ou plusieurs échangeurs de courrier, chacun avec une valeur de priorité (inférieur = préféré).
Trier par priorité. Si plusieurs enregistrements MX partagent la même priorité, l'expéditeur les randomise pour l'équilibrage de charge.
Résoudre le nom d'hôte MX en une adresse IP en utilisant des requêtes A (IPv4) ou AAAA (IPv6).
Se connecter au serveur de courrier à l'adresse IP résolue sur le port 25 et commencer la session SMTP.
Si le MX préféré est inaccessible, essayez le prochain avec la priorité la plus basse, et ainsi de suite.
Si aucun enregistrement MX n'existe, basculez sur l'enregistrement A/AAAA du domaine lui-même (selon RFC 5321).

Détails techniques clés

Enregistrements MX — Routage du courrier

L'enregistrement MX est la pierre angulaire du routage du courrier électronique. Il mappe un domaine au(x) nom(s) d'hôte de ses serveurs de courrier, avec une valeur de préférence qui détermine l'ordre dans lequel ils sont essayés :

example.com. IN MX 10 mx1.example.com. example.com. IN MX 20 mx2.example.com. example.com. IN MX 30 mx-backup.example.com.

La cible MX doit être un nom d'hôte, jamais une adresse IP. Le MTA d'envoi résout ensuite ce nom d'hôte en une adresse IP via des requêtes A/AAAA. Un enregistrement MX pointant vers un CNAME est techniquement interdit par la spécification, bien que certains résolveurs le tolèrent.

Enregistrements A et AAAA — Résolution IP

Une fois que le nom d'hôte MX est connu, les enregistrements A fournissent les adresses IPv4 et les enregistrements AAAA fournissent les adresses IPv6 :

mx1.example.com. IN A 198.51.100.25 mx1.example.com. IN AAAA 2001:db8::25

Si un nom d'hôte MX se résout en enregistrements A et AAAA, le MTA d'envoi choisit en fonction de sa propre configuration et connectivité. La plupart des MTA modernes préfèrent IPv6 si disponible, en revenant à IPv4.

Enregistrements TXT — Authentification du courrier

Les enregistrements TXT étaient à l'origine un mécanisme générique pour joindre des données texte à un nom de domaine. L'authentification du courrier électronique les a adoptés largement :

# SPF — quels serveurs peuvent envoyer du courrier pour ce domaine example.com. IN TXT "v=spf1 include:mailertogo.com ~all" # Clé publique DKIM — utilisée pour vérifier les signatures de message selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGf..." # Politique DMARC — que faire avec le courrier qui échoue l'authentification _dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Les enregistrements TXT sont limités à 255 octets par chaîne, mais un seul enregistrement peut contenir plusieurs chaînes qui sont concaténées. Les enregistrements SPF qui dépassent 255 octets doivent être divisés de cette manière.

MX nul — RFC 7505

Un domaine qui n'accepte pas de courrier électronique peut publier un enregistrement MX nul — un MX avec une priorité de 0 pointant vers « . » (la racine). Cela indique aux serveurs d'envoi de ne pas tenter la livraison, évitant les retards et les rebonds :

no-reply.example.com. IN MX 0 .

TTL et mise en cache

Chaque enregistrement DNS a un TTL (durée de vie) qui contrôle la durée pendant laquelle les résolveurs mettent en cache le résultat. Pour les enregistrements MX, les TTL typiques vont de 300 à 3600 secondes. Des TTL plus faibles permettent un basculement plus rapide mais augmentent le volume de requêtes DNS. Lors des migrations, réduisez le TTL bien à l'avance afin que les enregistrements mis en cache expirent avant le changement.

Exemple de recherche DNS

Une séquence de recherche DNS complète pour la livraison à user@example.com :

# Étape 1 : Interroger les enregistrements MX $ dig example.com MX +short 10 mx1.example.com. 20 mx2.example.com. # Étape 2 : Résoudre le nom d'hôte MX préféré $ dig mx1.example.com A +short 198.51.100.25 $ dig mx1.example.com AAAA +short 2001:db8::25 # Étape 3 : Vérifier SPF pour le domaine d'envoi $ dig example.com TXT +short "v=spf1 include:mailertogo.com ~all" # Étape 4 : Vérifier la politique DMARC $ dig _dmarc.example.com TXT +short "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Erreurs courantes

Pointer un enregistrement MX vers une adresse IP. Les enregistrements MX doivent pointer vers un nom d'hôte, pas une IP. MX 10 198.51.100.25 est invalide et causera des défaillances de livraison.
Pointer un enregistrement MX vers un CNAME. La cible MX doit se résoudre directement en enregistrements A/AAAA. Un MX pointant vers un CNAME est interdit par la spécification et cause un comportement imprévisible sur différents résolveurs.
DNS inverse manquant (PTR) pour les adresses IP des serveurs de courrier. Bien que non défini par RFC 1035, la plupart des serveurs récepteurs vérifient que l'adresse IP de votre serveur de courrier a un enregistrement PTR qui se résout en arrière vers la même IP. Les enregistrements PTR manquants ou mal appariés déclenchent les filtres à spam.
Oublier de mettre à jour DNS après migration de fournisseur de courrier. Si vous changez de service de courrier électronique mais laissez les anciens enregistrements MX en place, le courrier va chez l'ancien fournisseur. Vérifiez toujours les enregistrements MX après la migration.
Définir les TTL trop haut avant une migration. Si vos enregistrements MX ont un TTL de 24 heures et que vous changez de fournisseur, certains serveurs continueront à livrer à l'ancienne destination pendant jusqu'à 24 heures. Réduisez le TTL à 300 secondes au moins 48 heures avant le changement.
Dépasser la limite de 10 recherches pour SPF. L'évaluation SPF suit les directives include: et redirect=, chacune générant des requêtes DNS supplémentaires. Plus de 10 recherches entraîne une erreur SPF permanente. Gardez votre enregistrement SPF plat.
Pas d'enregistrement MX et pas d'enregistrement A. Si un domaine n'a ni enregistrements MX ni secours A/AAAA, le courrier vers ce domaine est non livrable. Publiez des enregistrements MX explicites ou au minimum un enregistrement A.

Impact sur la délivrabilité

Les enregistrements MX sont la première chose vérifiée. Si vos enregistrements MX sont manquants, mal configurés ou pointent vers des serveurs inaccessibles, aucun courrier ne vous atteint. C'est l'exigence de délivrabilité la plus fondamentale.
SPF, DKIM et DMARC vivent tous dans DNS. Chaque vérification d'authentification du courrier électronique commence par une recherche d'enregistrement TXT. Si votre DNS est lent, peu fiable ou mal configuré, l'authentification échoue et vos messages sont signalés ou rejetés.
Le DNS inverse affecte la réputation de l'expéditeur. Les serveurs de courrier avec un DNS direct et inverse correctement configuré sont davantage approuvés par les serveurs récepteurs. Les enregistrements PTR mal appariés ou manquants sont un signal fort de spam.
Les délais de propagation DNS affectent les migrations. Lors du changement de fournisseur de courrier électronique, la mise en cache DNS signifie que la transition n'est jamais instantanée. Planifiez une période où l'ancien et le nouveau systèmes doivent accepter le courrier.
IPv6 nécessite des enregistrements AAAA et PTR correspondants. Si vous envoyez à partir d'adresses IPv6, vous avez besoin d'enregistrements AAAA pour vos noms d'hôte d'envoi et d'enregistrements PTR pour les adresses IPv6. Une configuration DNS IPv6 incomplète cause des défaillances de livraison aux fournisseurs qui préfèrent IPv6.