← RFC Reference

Routage DNS et courrier

Comment le DNS pilote l'intégralité du chemin de livraison des courriels — enregistrements MX, priorité et basculement, secours A/AAAA, MX nul, enregistrements PTR et les enregistrements DNS dont chaque domaine d'envoi a besoin.

L'algorithme d'acheminement du courrier

Quand un serveur d'envoi doit livrer un message à user@example.com, il suit cet algorithme, défini dans la RFC 5321 section 5 :

1. Interroger les enregistrements MX pour example.com
2. Si des enregistrements MX existent, les trier par priorité (le nombre le plus bas = la préférence la plus haute)
3. Pour chaque nom d'hôte MX, résoudre ses enregistrements A et/ou AAAA pour obtenir les adresses IP
4. Tenter de se connecter au MX de plus haute priorité. En cas d'échec, essayer le suivant.
5. Si aucun enregistrement MX n'existe (réponse NODATA), basculer sur l'enregistrement A/AAAA du domaine et tenter la livraison là-bas
6. Si l'enregistrement MX est un MX nul (0 .), le domaine n'accepte pas le courrier — générer un échec permanent
7. Si le domaine n'existe pas du tout (NXDOMAIN), générer un échec permanent

Enregistrements MX

L'enregistrement MX (Mail Exchanger) est le type d'enregistrement DNS principal pour l'acheminement du courrier. Il mappe un domaine à un ou plusieurs serveurs de courrier avec des priorités :

Chaque enregistrement a deux parties :

• Priorité (valeur de préférence) — Les nombres les plus bas sont essayés en premier. Le serveur d'envoi essaie toujours le MX de plus basse priorité en premier.
• Exchange (nom d'hôte) — Le serveur de courrier auquel se connecter. Ce doit être un nom d'hôte, jamais une adresse IP. Le nom d'hôte doit avoir un enregistrement A ou AAAA.

Priorité et basculement

Dans l'exemple ci-dessus, l'expéditeur essaie d'abord mx1.example.com (priorité 10). Si ce serveur est inaccessible, retourne une erreur 4xx temporaire, ou la connexion expire, l'expéditeur essaie mx2.example.com (priorité 20), puis mx-backup.example.com (priorité 30).

Si plusieurs enregistrements MX partagent la même priorité, l'expéditeur doit les randomiser. Cela fournit l'équilibrage de charge :

Ici, les trois serveurs ont une priorité égale. Le serveur d'envoi en sélectionne un au hasard pour chaque tentative de livraison, distribuant la charge entre les trois.

MX doit pointer sur un nom d'hôte, pas une IP

Le champ exchange d'un enregistrement MX doit être un nom d'hôte. Il ne peut pas être une adresse IP (la RFC 5321 est explicite à ce sujet). Le nom d'hôte lui-même doit être résolu en un enregistrement A et/ou AAAA. Il ne doit pas être un CNAME — bien que certains résolveurs tolèrent les cibles MX qui sont des CNAME, c'est techniquement interdit et cause des problèmes d'interopérabilité.

MX ne doit pas pointer sur un CNAME

C'est une configuration erronée courante. Si mx1.example.com est un CNAME pointant vers mail.provider.com, certains serveurs d'envoi échoueront à livrer. Utilisez toujours des enregistrements A/AAAA pour les cibles MX.

Secours A/AAAA

Si un domaine n'a aucun enregistrement MX du tout (pas même un MX nul), le serveur d'envoi bascule sur l'enregistrement A ou AAAA du domaine et tente la livraison SMTP là-bas. C'est la règle « MX implicite ».

Le serveur d'envoi tentera de livrer à 198.51.100.50 sur le port 25. Cela fonctionne, mais c'est considéré comme une mauvaise pratique pour tout domaine qui envoie ou reçoit activement du courrier. Publiez toujours des enregistrements MX explicites.

Le secours ne s'applique que quand il y a zéro enregistrement MX. Si des enregistrements MX existent mais que tous les hôtes MX sont inaccessibles, l'expéditeur ne bascule pas vers l'enregistrement A — il met le message en file d'attente pour une nouvelle tentative.

MX nul : « Ce domaine n'accepte pas le courrier »

La RFC 7505 définit le MX nul — un moyen de déclarer explicitement qu'un domaine n'accepte pas le courrier électronique :

Le point unique (.) comme exchange, avec priorité 0, signifie « ne pas tenter la livraison ». Le serveur d'envoi doit immédiatement générer un échec permanent (5.1.2 — mauvais système de destination) plutôt que de perdre du temps en connexion.

Utilisez le MX nul pour :

• Les domaines qui n'envoient que du courrier et ne le reçoivent jamais
• Les domaines stationnés
• Les domaines utilisés exclusivement pour l'hébergement web

Sans un MX nul, les expéditeurs basculeront sur l'enregistrement A et gaspilleront du temps en tentant des connexions qui n'aboutiront jamais.

Enregistrements PTR : DNS inversé

Un enregistrement PTR mappe une adresse IP vers un nom d'hôte. C'est l'inverse d'un enregistrement A :

Les enregistrements PTR ne font pas partie de l'algorithme d'acheminement du MX, mais ils sont essentiels pour la livrabilité. La plupart des grands fournisseurs de boîtes de réception vérifient l'enregistrement PTR de l'adresse IP du serveur de connexion :

• L'IP doit avoir un enregistrement PTR (PTR manquant = probablement du spam)
• Le nom d'hôte PTR doit être résolu en retour vers la même IP (DNS inversé confirmé en avant, ou FCrDNS)
• Le nom d'hôte PTR ne doit pas sembler « générique » (par exemple, 198-51-100-42.dynamic.isp.com suggère une connexion résidentielle)

Les enregistrements PTR sont gérés par le propriétaire du bloc d'adresses IP (généralement votre fournisseur d'hébergement ou FAI), et non via le DNS de votre domaine. Vous devrez peut-être contacter votre fournisseur pour définir ou modifier les enregistrements PTR.

Enregistrements DNS que chaque domaine d'envoi doit avoir

Voici l'ensemble complet des enregistrements DNS pour un domaine qui envoie du courrier via un service comme Mailer To Go :

Pour un domaine qui envoie mais ne reçoit pas de courrier (par exemple, un sous-domaine utilisé pour le courrier transactionnel) :

Considérations TTL

Les enregistrements DNS ont un Time To Live (TTL) qui contrôle la durée pendant laquelle les résolveurs les mettent en cache. Pour les enregistrements liés au courrier :

• Enregistrements MX : 1 heure (3600) est typique. Les TTL plus courts permettent un basculement plus rapide mais augmentent la charge de requêtes DNS.
• Enregistrements SPF/DKIM/DMARC : 1 heure est courant. Utilisez des TTL plus courts (300 secondes) lors de la configuration initiale ou des changements, puis augmentez.
• Enregistrements A/AAAA pour les hôtes MX : 5 minutes à 1 heure. Plus court si vous avez besoin de changements d'IP rapides.

Lors de modifications DNS, réduisez le TTL avant le changement (attendez l'expiration de l'ancien TTL), effectuez le changement, vérifiez, puis augmentez le TTL à la valeur opérationnelle.

DNSSEC et courrier

DNSSEC (DNS Security Extensions) ajoute des signatures cryptographiques aux enregistrements DNS, prévenant l'usurpation et l'empoisonnement du cache. Pour le courrier, DNSSEC est particulièrement important parce que :

• Il authentifie les enregistrements MX — un attaquant ne peut pas rediriger le courrier vers un serveur voyou en empoisonnant le DNS
• C'est requis pour DANE (authentification DNS des entités nommées), qui lie les certificats TLS au DNS
• Il authentifie la clé publique SPF, DKIM et les enregistrements DMARC

Sans DNSSEC, un attaquant de réseau peut forger des réponses DNS et rediriger ou intercepter le courrier. L'adoption de DNSSEC pour les domaines de courrier augmente mais n'est pas encore universelle.

Enregistrements SRV pour la soumission de courrier

La RFC 6186 définit les enregistrements SRV que les clients de courrier peuvent utiliser pour découvrir automatiquement les serveurs de soumission et IMAP/POP :

Ceux-ci sont utilisés pour l'autoconfigurations du client de courrier — quand un utilisateur tape son adresse e-mail, le client interroge les enregistrements SRV pour trouver le serveur correct, le port et le protocole. C'est séparé de l'acheminement serveur-à-serveur basé sur MX.

Ce qui peut mal tourner

Enregistrements MX manquants

Sans enregistrements MX, les expéditeurs basculer sur votre enregistrement A. Si votre serveur web n'exécute pas de serveur SMTP sur le port 25, la livraison du courrier échoue après expiration du délai. Publiez toujours des enregistrements MX explicites, ou un MX nul si vous n'acceptez pas le courrier.

MX pointant vers un CNAME

Comme noté ci-dessus, c'est techniquement invalide. Certains expéditeurs suivront le CNAME ; d'autres échoueront. Utilisez des enregistrements A/AAAA pour tous les noms d'hôtes cibles MX.

Références MX circulaires

Si example.com a un MX pointant vers mail.example.com, et mail.example.com a son propre MX pointant vers example.com, le courrier peut boucler. Les cibles MX doivent être des noms d'hôtes feuilles avec des enregistrements A/AAAA uniquement.

Enregistrement PTR manquant

Votre IP d'envoi n'a pas de DNS inversé, ou elle se résout sur un nom d'hôte ISP générique. Les grands fournisseurs de boîtes de réception (Gmail, Microsoft, Yahoo) repousseront ou rejetteront votre courrier. Assurez-vous que vos IP d'envoi ont des enregistrements PTR qui se résolvent en avant vers la même IP.

Délai d'expiration DNS lors de la livraison

Si les serveurs DNS du domaine destinataire sont lents ou inaccessibles, le serveur d'envoi ne peut pas résoudre les enregistrements MX. Le message est mis en file d'attente pour une nouvelle tentative. Les échecs DNS persistants aboutissent finalement à un rebond (généralement après 4-5 jours). Il n'y a rien que vous puissiez faire en tant qu'expéditeur — c'est un problème d'infrastructure du destinataire.

L'enregistrement SPF dépasse la limite UDP DNS

Les réponses DNS via UDP sont limitées à 512 octets (ou 4096 avec EDNS0). Un enregistrement SPF très long avec de nombreuses directives include: peut être tronqué. Le résolveur bascule sur TCP, ce qui ajoute de la latence et peut échouer si le serveur DNS ne supporte pas TCP. Gardez votre enregistrement SPF concis.

Débogage DNS pour le courrier

Commandes essentielles pour diagnostiquer les problèmes d'acheminement du courrier :

Points clés à retenir

• Les enregistrements MX sont le mécanisme principal pour l'acheminement du courrier. Les nombres de priorité les plus bas sont essayés en premier.
• S'il n'existe aucun enregistrement MX, les expéditeurs basculer sur l'enregistrement A/AAAA. Publiez des enregistrements MX explicites (ou un MX nul) pour éviter l'ambiguïté.
• Les cibles MX doivent être des noms d'hôtes avec des enregistrements A/AAAA — jamais des IP, jamais des CNAME.
• Les enregistrements PTR (DNS inversé) ne font pas partie de l'acheminement mais sont essentiels pour la livrabilité. Chaque IP d'envoi a besoin d'un PTR qui correspond à un enregistrement A en avant.
• Un domaine d'envoi complet a besoin d'enregistrements MX (ou MX nul), SPF, DKIM et DMARC au minimum.
• Utilisez dig pour vérifier chaque enregistrement DNS avant et après les changements.

Lectures complémentaires

Related RFCs