MX et reverse DNS : les enregistrements qui font exister un serveur de mail

Un domaine ne reçoit du courrier que s'il publie des enregistrements MX, et un serveur n'en envoie durablement que si son adresse IP possède un reverse DNS cohérent. Ces deux mécanismes sont le socle sur lequel reposent ensuite SPF, DKIM, DMARC et MTA-STS.

L'enregistrement MX#

Un enregistrement MX (Mail eXchanger) désigne le ou les serveurs chargés de recevoir le courrier d'un domaine. Chaque entrée porte une priorité (un entier, le plus petit étant essayé en premier) et un nom d'hôte, jamais une adresse IP directement.

exemple.fr.    3600  IN  MX  10 mx1.exemple.fr.
exemple.fr.    3600  IN  MX  20 mx2.exemple.fr.
mx1.exemple.fr. 3600 IN  A   203.0.113.10
mx2.exemple.fr. 3600 IN  A   203.0.113.11

Un MTA expéditeur contacte mx1 ; si celui-ci ne répond pas, il passe à mx2. Deux entrées de même priorité sont utilisées en alternance. Pour interroger ces enregistrements :

$ dig +short MX exemple.fr
10 mx1.exemple.fr.
20 mx2.exemple.fr.

Quand un domaine confie sa réception à un fournisseur, les MX pointent vers les serveurs de celui-ci. Les formes les plus courantes sont aspmx.l.google.com pour Google Workspace, <domaine>.mail.protection.outlook.com pour Microsoft 365, ou les noms des filtres anti-spam externes placés devant une messagerie interne. C'est précisément à partir de ces noms d'hôtes que SenderRadar identifie le prestataire qui reçoit le courrier d'un domaine.

Deux cas particuliers méritent d'être connus :

• Absence de MX : la RFC 5321 prévoit qu'en l'absence de MX, le MTA tente l'enregistrement A du domaine lui-même. Ce repli fonctionne mais signale une configuration peu soignée.
• Null MX (RFC 7505) : un domaine qui ne reçoit jamais de courrier publie exemple.fr. IN MX 0 . pour le dire explicitement. Les MTA refusent alors immédiatement au lieu de réessayer pendant des jours.

Le reverse DNS et l'enregistrement PTR#

Le reverse DNS fait le chemin inverse : il associe une adresse IP à un nom d'hôte. Il repose sur un enregistrement PTR publié dans la zone in-addr.arpa (IPv4) ou ip6.arpa (IPv6), administrée par le détenteur du bloc d'adresses, c'est-à-dire l'hébergeur ou l'opérateur, et non par le propriétaire du domaine.

Pour l'adresse 203.0.113.10, les octets sont inversés :

10.113.0.203.in-addr.arpa.  3600  IN  PTR  mx1.exemple.fr.

$ dig +short -x 203.0.113.10
mx1.exemple.fr.

Les routeurs vérifient le PTR de chaque connexion SMTP entrante. Une IP sans PTR, ou dont le PTR est un nom générique attribué par l'opérateur (203-0-113-10.dyn.exemple-isp.net), est traitée comme un poste résidentiel ou une machine compromise et se voit fréquemment refuser la connexion dès le 220.

FCrDNS : la boucle complète#

Le FCrDNS (Forward-Confirmed reverse DNS) exige que le nom obtenu par le PTR résolve en retour vers l'adresse IP de départ :

1. 203.0.113.10 → PTR → mx1.exemple.fr
2. mx1.exemple.fr → A → 203.0.113.10

Si les deux étapes concordent, l'adresse est confirmée. Un PTR qui pointe vers un nom dont l'enregistrement A renvoie une autre adresse ne vaut rien. Google, Microsoft et Yahoo exigent un FCrDNS valide pour tout serveur envoyant en volume, et le nom annoncé dans EHLO doit idéalement être ce même nom d'hôte.

Ce qu'il faut vérifier#

Pour la réception :

• Chaque nom d'hôte MX possède un enregistrement A (et AAAA si IPv6) ; un MX pointant vers un CNAME est interdit par la RFC 2181 et mal géré par certains MTA.
• Les serveurs MX répondent effectivement sur le port 25 depuis Internet, avec un bandeau 220 et STARTTLS.
• Les MX secondaires acceptent bien le courrier des domaines concernés ; un secondaire mal configuré devient un relais ouvert ou un trou noir.
• Les TTL sont raisonnables (une heure est courant) pour permettre une migration sans coupure.

Pour l'envoi :

• Chaque IP d'envoi a un PTR qui pointe vers un nom du domaine de l'expéditeur ou de son prestataire, et ce nom résout vers l'IP.
• Le nom du PTR, le nom EHLO et le sujet du certificat TLS sont alignés.
• Le PTR est demandé à l'hébergeur dès la mise en service d'une IP, avant tout envoi.

Erreurs fréquentes#

• Mettre une adresse IP comme cible de MX : l'enregistrement est syntaxiquement invalide et ignoré.
• Laisser un ancien MX après une migration ; les messages continuent d'arriver sur un serveur abandonné.
• Oublier que le PTR est géré par l'hébergeur : le domaine est parfait, mais l'IP reste anonyme.
• Partager une IP entre un site web et un serveur de mail, avec un PTR qui pointe vers le nom du site : le FCrDNS tient, mais l'identité est brouillée.
• Publier un MX de priorité 0 vers un filtre externe sans fermer le port 25 du serveur interne, ce qui permet de contourner le filtre.

Un domaine dont les MX et le reverse DNS sont propres n'a pas pour autant une bonne réputation, mais un domaine dont ils ne le sont pas n'en aura jamais.