Réception : les enregistrements MX et les domaines sans boîtes

Les enregistrements MX indiquent où remettre le courrier de votre domaine. Comment les lire, ce qui les casse, et comment protéger un domaine sans boîtes aux lettres.

Les enregistrements MX sont l’adresse postale de votre domaine. Quand un serveur veut remettre un message à contact@exemple.fr, il demande au DNS : qui reçoit le courrier pour exemple.fr ? La réponse est une liste de noms de serveurs, chacun avec un chiffre de priorité. Le serveur émetteur essaie le plus petit chiffre d’abord, et passe au suivant si le premier ne répond pas.

Deux conséquences que l’on oublie facilement. D’abord, sans MX, le courrier n’arrive pas – il est refusé, pas mis de côté. Ensuite, un domaine qui n’a aucune boîte aux lettres n’est pas pour autant tranquille : on peut parfaitement écrire en son nom sans qu’il puisse recevoir quoi que ce soit. C’est même la situation préférée des usurpateurs, parce que personne ne surveille ces domaines-là.

À quoi ressemble l’enregistrement

exemple.fr.  IN  MX  1   mx1.mail.ovh.net.
exemple.fr.  IN  MX  5   mx2.mail.ovh.net.
exemple.fr.  IN  MX  100 mx3.mail.ovh.net.

Un cas particulier mérite d’être connu : le MX nul, écrit 0 . – priorité zéro et un simple point comme cible. Il déclare officiellement que ce domaine ne reçoit pas de courrier. Les serveurs émetteurs abandonnent alors immédiatement, au lieu de réessayer pendant des jours.

Les trois situations d’un domaine

La deuxième ligne est celle qui est presque toujours oubliée. Une entreprise possède souvent dix à trente domaines : variantes d’écriture, extensions réservées, anciens noms de produits. Aucun n’a de boîte aux lettres, tous portent un nom crédible, et sans les trois enregistrements ci-dessus, tous sont utilisables pour écrire à vos clients.

Comment le mettre en place

Le point de départ est de savoir qui héberge quoi. Trois rôles, souvent tenus par trois prestataires différents : le bureau d’enregistrement qui détient le domaine, l’hébergeur DNS qui répond aux requêtes, et le fournisseur de messagerie qui détient les boîtes. Les MX se publient chez le deuxième et désignent le troisième.

Ne recopiez jamais ces noms depuis un tutoriel : chaque compte reçoit les siens. Prenez-les dans le panneau qui vous les propose.

Le chemin chez OVHcloud, pas à pas

1. Espace client OVHcloud → Web Cloud → Noms de domaine → votre domaine → Zone DNS.
2. Repérez les entrées de type MX déjà présentes. Si vous changez de fournisseur, supprimez les anciennes – des MX de deux fournisseurs côte à côte livrent le courrier à moitié chez l’un, à moitié chez l’autre.
3. Ajouter une entrée → type MX → priorité et cible reprises de votre fournisseur de messagerie.
4. Répétez pour chaque serveur que le fournisseur indique.
5. Attendez quelques minutes, puis envoyez-vous un message depuis une adresse extérieure.
6. Pour un domaine sans boîtes : une seule entrée MX, priorité 0, cible . – puis l’enregistrement SPF v=spf1 -all et un DMARC en p=reject.

Les constats en détail

Aucun serveur de messagerie déclaré

Le domaine ne publie aucun enregistrement MX.

Concrètement, il ne peut pas recevoir de courrier : les messages sont refusés. Si le domaine est censé avoir des boîtes, c’est une panne en cours, et probablement personne ne l’a encore signalée parce qu’un expéditeur qui reçoit un refus ne vous appelle pas.

Ce qu’il faut faire. Si le domaine doit recevoir : publiez les MX de votre fournisseur de messagerie. S’il ne doit rien recevoir : publiez un MX nul (0 .), et complétez avec v=spf1 -all et DMARC en p=reject. Ne laissez pas la situation en l’état – l’absence d’enregistrement est la seule des trois possibilités qui ne déclare rien.

Un seul serveur de messagerie

Le domaine ne publie qu’un seul MX.

Situons l’enjeu correctement : ce n’est pas grave. Si ce serveur est indisponible, les messages ne sont pas perdus – la plupart des expéditeurs réessaient pendant plusieurs jours avant d’abandonner. Vous recevrez votre courrier avec du retard, pas moins de courrier. Beaucoup d’offres d’hébergement ne proposent d’ailleurs qu’un seul nom, et c’est acceptable.

Ce qu’il faut faire. Si votre fournisseur propose un second serveur, ajoutez-le avec une priorité plus élevée. Sinon, rien. Ne construisez pas un serveur de secours de fortune : un MX de repli mal configuré accepte du courrier qu’il ne sait pas remettre, ce qui est nettement pire qu’un seul serveur.

MX pointe vers une adresse IP

La cible d’un MX est une adresse IP au lieu d’un nom d’hôte.

Le standard exige un nom. Certains serveurs émetteurs tolèrent l’écart, d’autres refusent la remise – et vous n’avez aucun moyen de savoir dans quel camp se trouve le prochain client qui vous écrit. La configuration a l’air de fonctionner tant qu’elle ne rencontre pas un serveur strict.

Ce qu’il faut faire. Créez un enregistrement A (ou AAAA) au nom du serveur – mail.exemple.fr par exemple – et faites pointer le MX vers ce nom.

MX pointe vers un alias

La cible d’un MX est un nom qui est lui-même un CNAME, c’est-à-dire un alias.

Le standard l’interdit explicitement. En pratique, beaucoup de serveurs suivent quand même l’alias, ce qui rend le défaut difficile à repérer : tout fonctionne, jusqu’au jour où un expéditeur plus rigoureux renvoie une erreur. Le cas apparaît souvent quand quelqu’un a créé un alias pratique pour ne pas avoir à retenir le nom du fournisseur.

Ce qu’il faut faire. Pointez le MX directement vers le nom final que votre fournisseur indique. L’alias peut rester pour d’autres usages, mais pas comme cible d’un MX.

Serveur de messagerie non résolu

Un nom cité dans un MX n’a ni adresse IPv4 ni adresse IPv6.

Personne ne peut remettre de courrier à ce serveur, puisqu’il n’y a aucune adresse à joindre. Les causes habituelles : une faute de frappe dans le nom, un domaine de fournisseur qui a changé, ou un serveur démonté sans que l’entrée MX ait été retirée.

Ce qu’il faut faire. Le rapport nomme le serveur concerné. Comparez-le caractère par caractère avec ce que votre fournisseur indique. S’il s’agit d’un ancien serveur, supprimez l’entrée : un MX qui ne mène nulle part retarde la remise chez tous vos correspondants.

Serveur sans résolution inverse

L’adresse IP d’un de vos serveurs n’a pas d’enregistrement PTR, c’est-à-dire pas de nom en résolution inverse.

Pour la réception, cela n’a aucun effet. Cela compte si le même serveur sert aussi à envoyer : beaucoup de grands opérateurs refusent les connexions venant d’une adresse sans résolution inverse, ou traitent ces messages avec méfiance. Si vos boîtes sont chez un hébergeur mutualisé, la question ne vous concerne pas – c’est lui qui gère ces adresses.

Ce qu’il faut faire. Si vous exploitez votre propre serveur, demandez à l’opérateur de l’adresse – OVHcloud, Scaleway, Hetzner, votre fournisseur d’accès – de publier un PTR correspondant au nom du serveur. Idéalement, le nom pointe en retour vers la même adresse.

Domaine sans boîtes, encore usurpable

Le domaine ne reçoit volontairement pas de courrier, mais son enregistrement SPF n’est pas strict.

Rien ne bloque alors l’envoi en son nom. Un domaine dormant est une cible particulièrement commode : il porte un nom crédible, souvent proche de votre marque, et personne ne reçoit les retours qui donneraient l’alerte.

Ce qu’il faut faire. Publiez v=spf1 -all – la ligne la plus courte et la plus stricte qui existe. Elle déclare qu’aucun serveur au monde n’est autorisé à écrire au nom de ce domaine. Rien à surveiller ensuite, puisque rien ne doit partir de là.

Domaine sans boîtes et sans rejet DMARC

Le domaine ne reçoit pas de courrier et sa consigne DMARC n’est pas p=reject.

Un domaine sans expéditeur légitime est le seul cas où p=reject ne comporte aucun risque : il n’y a aucun canal d’envoi à casser, donc aucune phase d’observation à respecter. Ne pas le faire, c’est laisser ouvert ce qui pouvait être fermé en une minute.

Ce qu’il faut faire. Publiez v=DMARC1; p=reject; rua=mailto:… sur _dmarc. Gardez l’adresse de rapports : c’est par elle que vous saurez si quelqu’un tente d’utiliser ce domaine, information souvent instructive. Le détail des champs se trouve sur la page DMARC.

Pas de serveur, ni de déclaration claire

Le domaine n’a pas de MX, et il ne publie pas non plus de MX nul.

C’est l’entre-deux le plus gênant. Faute de MX, certains serveurs émetteurs se rabattent sur l’adresse A du domaine – celle de votre site web – et tentent d’y remettre le courrier. Votre serveur web n’est pas un serveur de messagerie : il refuse, mais après des tentatives répétées, et le message reste en attente des jours durant chez l’expéditeur, qui croit vous avoir écrit.

Ce qu’il faut faire. Décidez, puis déclarez. Si le domaine doit recevoir, publiez de vrais MX. S’il ne doit rien recevoir, publiez un MX nul (0 .) : les expéditeurs abandonnent alors immédiatement et savent à quoi s’en tenir. Complétez avec v=spf1 -all et p=reject.

Questions fréquentes

Combien d’enregistrements MX faut-il ?

Autant que votre fournisseur en propose, ce qui fait généralement deux ou trois. Un seul suffit à fonctionner. Ce qu’il ne faut jamais faire, c’est mélanger les MX de deux fournisseurs différents : le courrier se répartit alors entre les deux, et la moitié de vos messages atterrit dans des boîtes que personne n’ouvre.

Un domaine redirigé vers mon site a-t-il besoin de tout cela ?

Oui, et c’est vite fait : MX nul, v=spf1 -all, DMARC en p=reject. Une redirection web ne dit rien sur le courrier. Tant que ces trois enregistrements manquent, ce domaine reste une adresse d’expédition crédible pour quelqu’un d’autre.

Que se passe-t-il pendant un changement de fournisseur ?

Le DNS met un certain temps à se propager, donc les deux configurations coexistent brièvement. Réduisez la durée de vie (TTL) des entrées MX la veille du changement, puis basculez d’un coup, et laissez les anciennes boîtes accessibles quelques jours : quelques messages arriveront encore chez l’ancien fournisseur.

Les MX influencent-ils la délivrabilité de mes envois ?

Indirectement. Les MX portent sur la réception, mais un domaine qui ne peut pas recevoir de courrier est un signal négatif pour certains filtres, et surtout, les retours d’erreur de vos propres envois n’arrivent nulle part. Vous envoyez alors sans jamais savoir ce qui échoue.