Un enregistrement DNS Mail Exchanger (MX record) est l’entrée publiée dans la zone DNS d’un domaine qui indique au reste d’Internet quels serveurs doivent recevoir les emails envoyés à ce domaine. Quand quelqu’un envoie un mail à contact@exemple.com, son serveur d’envoi interroge le DNS pour récupérer l’enregistrement MX d’exemple.com et savoir où livrer le message. Sans MX valide, un domaine ne peut pas recevoir d’email. Mal configuré, vos campagnes cold email finissent en spam ou ne partent jamais.
Ce guide détaille ce qu’est un DNS mail exchanger, comment fonctionne la priorité, comment il s’articule avec SPF, DKIM et DMARC pour la délivrabilité, et comment vérifier puis corriger un MX avant de lancer un programme cold email. Si vous faites de l’outbound à l’échelle en 2026, le MX record n’est pas un détail IT : c’est une porte d’entrée délivrabilité.
Au programme
- Ce qu’est réellement un enregistrement DNS mail exchanger
- Le format exact d’un MX record et la priorité
- MX records et SPF, DKIM, DMARC : la chaîne complète
- Comment vérifier ses MX en 3 méthodes
- Les erreurs MX qui tuent la délivrabilité
- Comment ajouter ou modifier un enregistrement MX
- Cas pratique chiffré : refonte délivrabilité sur 3 domaines d’envoi
- MX records et cold email + 3 FAQ + 3 actions datées
L’essentiel à retenir
Un MX record dirige votre domaine vers les serveurs autorisés à recevoir ses emails. Chaque MX a une valeur de priorité (plus bas = préféré). Plusieurs MX permettent du failover, ou du load balancing à priorité égale. Mais le MX seul ne protège pas la délivrabilité : il faut aligner SPF, DKIM et DMARC. Si vous faites du cold email en 2026, auditez MX, SPF, DKIM, DMARC sur chaque domaine d’envoi avant le premier batch. Outils : MXToolbox, dig, nslookup vérifient la configuration en moins d’une minute.
Ce qu’est réellement un enregistrement DNS mail exchanger
Un enregistrement DNS Mail Exchanger, communément appelé MX record, est un type spécifique de DNS resource record. Son unique fonction : diriger le trafic email vers un domaine. Quand un serveur d’envoi (un MTA, Mail Transfer Agent) doit livrer un message à utilisateur@exemple.com, il ne devine pas où l’envoyer. Il interroge le DNS : “quels MX records publie exemple.com ?”
La réponse DNS renvoie un ou plusieurs hostnames de serveurs mail, chacun avec une valeur de priorité. Le MTA expéditeur ouvre alors une connexion SMTP vers le serveur le plus prioritaire (valeur numérique la plus basse) et livre le message. Si ce serveur est injoignable, le MTA bascule sur le suivant, et ainsi de suite.
Deux propriétés essentielles : un MX doit pointer vers un hostname, jamais une adresse IP (il doit donc se résoudre via un A ou AAAA record), et il ne gère que les emails entrants. L’email sortant de votre domaine est régi par SPF, DKIM, DMARC et le reverse DNS de l’IP d’envoi, pas par votre MX.
Le format exact d’un MX record
Un MX record contient trois composants : nom de domaine, priorité, hostname cible. En syntaxe DNS zone file standard, une entrée type s’écrit : exemple.com. 3600 IN MX 10 mail1.exemple.com., avec une seconde ligne pour un backup en priorité 20 pointant vers mail2.exemple.com.
Champ par champ : exemple.com. est le domaine, 3600 est le TTL (Time To Live en secondes), IN signifie classe Internet, MX est le type de record, 10 et 20 sont les valeurs de priorité, et mail1.exemple.com. / mail2.exemple.com. sont les hostnames des serveurs mail récepteurs.
Deux remarques de format. Premièrement, la cible doit toujours être un hostname (FQDN), jamais une IP : pointer un MX vers 192.0.2.1 viole la RFC 5321 et la plupart des serveurs mail rejettent la livraison. Deuxièmement, le hostname cible doit lui-même avoir un A ou AAAA record correspondant pour être résolu en IP par le MTA expéditeur.
Comment fonctionne la priorité MX
La priorité est la propriété la plus mal comprise du MX. La règle : valeur plus basse = préférence plus haute. Un MX en priorité 10 est tenté avant un MX en priorité 20. Les nombres eux-mêmes sont arbitraires (priorité 5 et 50 se comportent identiquement tant que 5 est inférieur à 50), mais la convention est d’espacer les valeurs par 10 pour laisser de la place à de futurs ajouts.
Cette logique permet deux usages concrets :
Redondance failover : publier un MX primaire en priorité 10 et un MX backup en 20 (ou 30, 40). Si le primaire est injoignable (panne, maintenance, DDoS), les serveurs d’envoi retentent automatiquement sur le backup. Les emails continuent à circuler sans intervention manuelle.
Load balancing : publier plusieurs MX avec la même priorité. Les MTA expéditeurs répartissent la charge entre eux, typiquement en randomisant le choix. Ce pattern est courant sur les grandes infrastructures (Google Workspace publie 5 MX records en priorités 1, 5, 5, 10, 10 pour cette raison).
Ce que la priorité ne fait pas : elle n’affecte pas l’email sortant, ne change pas le scoring spam, et n’impacte pas la délivrabilité au-delà de la décision de routage.
MX records et SPF, DKIM, DMARC : la chaîne complète
Le MX gère les emails entrants. Le triptyque SPF / DKIM / DMARC gère l’authentification des emails sortants, et c’est ce qui détermine si votre cold email atterrit en inbox ou en spam.
SPF (Sender Policy Framework) : un record TXT listant les IP et hostnames autorisés à envoyer du mail au nom de votre domaine. Sans SPF valide, la majorité des fournisseurs (Gmail, Outlook, Yahoo) jettent vos messages.
DKIM (DomainKeys Identified Mail) : un record TXT contenant une clé publique. Votre serveur d’envoi signe chaque message sortant avec la clé privée correspondante. Le destinataire vérifie la signature contre la clé publique dans votre DNS. DKIM prouve que le message n’a pas été altéré en transit.
DMARC (Domain-based Message Authentication, Reporting and Conformance) : un record TXT qui définit ce que doivent faire les destinataires des messages qui échouent SPF ou DKIM (none, quarantine, reject). DMARC active aussi le reporting sur qui envoie du mail en se faisant passer pour votre domaine.
Pour le cold email en 2026, le baseline minimum avant d’envoyer : MX valides, SPF aligné avec votre plateforme d’envoi, DKIM signing activé sur chaque domaine, DMARC au moins en p=none pour la visibilité. Manquer un seul de ces éléments, et vos campagnes sous-performent indépendamment de la qualité du copy.
Comment vérifier ses MX en 3 méthodes
Vérifier vos MX records prend moins d’une minute. Trois méthodes fiables :
1. MXToolbox (outil web) : rendez-vous sur mxtoolbox.com, entrez votre domaine, cliquez MX Lookup. Renvoie la liste complète des MX records avec priorités, plus des warnings si quelque chose est mal configuré. La méthode la plus simple pour non-techniques.
2. Commande dig (Linux, macOS, WSL) : lancez dig MX exemple.com +short pour obtenir priorité + hostname par record. Ajoutez +noall +answer pour un output plus propre avec TTL.
3. Commande nslookup (multi-plateforme, Windows-friendly) : lancez nslookup -type=mx exemple.com depuis l’invite de commande ou un terminal. Structure de sortie identique à dig, fonctionne nativement sans installation.
Lancez ces vérifications sur chaque domaine d’envoi avant chaque lancement outbound. Découverte fréquente : des domaines achetés il y a des années pour une campagne disparue ont encore des MX records obsolètes qu’il faut nettoyer avant réutilisation.
Les erreurs MX qui tuent la délivrabilité
Trois patterns récurrents quand on audite des setups cold email B2B :
1. Aucun MX record : le domaine est enregistré mais aucun MX n’est publié. Conséquence : vous ne pouvez pas recevoir de réponse. Les destinataires bouncent, votre reply rate tombe à zéro, et vous ne voyez jamais les retours négatifs qui pourraient permettre d’itérer.
2. MX pointant vers une adresse IP : viole la RFC. La majorité des serveurs mail rejettent la livraison, certains acceptent avec warnings. Correction : remplacer l’IP par un hostname propre résolu en A ou AAAA.
3. MX records obsolètes ou en doublon : anciens records issus de fournisseurs email précédents (legacy Office 365, G Suite abandonné, passerelles de sécurité retirées) qui traînent dans la zone. Les serveurs d’envoi peuvent essayer la mauvaise route. Auditez et supprimez tout ce qui n’est pas activement utilisé.
Bonus : des MX records avec un TTL très élevé (86400 = 24h ou plus). Si vous devez migrer de fournisseur dans l’urgence, vous attendez une journée complète pour la propagation. Baissez le TTL à 3600 plusieurs jours avant toute migration prévue.
Comment ajouter ou modifier un enregistrement MX
La modification des MX records se fait chez votre fournisseur DNS, qui est habituellement votre bureau d’enregistrement (OVH, Gandi, Namecheap, GoDaddy) ou un hébergeur DNS dédié (Cloudflare, Route 53, Google Cloud DNS).
Le flow général :
Étape 1 : connectez-vous au panel de votre fournisseur DNS et ouvrez l’éditeur de zone pour votre domaine.
Étape 2 : ajoutez un nouveau record de type MX. Fournissez trois valeurs : hostname (généralement @ ou votre domaine nu), priorité (par exemple 10), et cible (le hostname du serveur mail fourni par votre service email, par exemple aspmx.l.google.com pour Google Workspace).
Étape 3 : répétez pour chaque MX record documenté par votre fournisseur email. Google Workspace, Microsoft 365, et la plupart des services pro vous donnent la liste exacte à copier.
Étape 4 : supprimez les anciens MX records qui ne sont plus nécessaires.
Étape 5 : attendez la propagation. Avec un TTL à 3600, comptez 1 à 4 heures pour que les changements soient visibles globalement. Vérifiez avec MXToolbox ou dig.
L’erreur la plus fréquente : oublier de supprimer les MX du fournisseur précédent. Plusieurs MX records non liés créent une ambiguïté de routage que les serveurs mail gèrent mal.
MX records et cold email : ce que tout SDR doit savoir
Si vous opérez du cold email à l’échelle, les MX records croisent votre travail à trois endroits.
Gestion des réponses : les réponses au cold email reviennent vers l’adresse du header From ou Reply-To. Le domaine de cette adresse doit avoir des MX records valides pointant vers une boîte que vous lisez réellement. Beaucoup d’équipes outbound déploient des domaines d’envoi dédiés et oublient de configurer le MX, puis s’étonnent que leur tracking de réponses affiche zéro.
Warmup de domaine : des outils comme Lemwarm, Smartlead, Mailwarm échangent des emails artificiels entre domaines pour bâtir la réputation expéditeur. Le côté réception de cet échange nécessite des MX fonctionnels. Sans MX, pas de warmup, pas de réputation construite.
Audits de délivrabilité : avant de scaler un nouveau domaine d’envoi, lancez un audit complet : MX (entrant), SPF (policy d’envoi), DKIM (signature), DMARC (alignement). MXToolbox fait les quatre checks dans un même rapport. Corrigez les problèmes avant d’envoyer le premier cold email, pas après l’effondrement de la délivrabilité.
Zeliq et la délivrabilité multi-domaines
Zeliq lance des contrôles MX, SPF, DKIM, DMARC sur chaque domaine d’envoi avant le démarrage des campagnes, et tient en permanence l’état de santé infrastructure pour vos séquences sur la base 450 millions de contacts B2B. Vous savez en temps réel si un domaine est sain, en warmup, ou en risque de blacklist, avant que la délivrabilité ne s’effondre.
Concrètement : votre équipe outbound démarre une séquence sur un domaine et reçoit une alerte si DKIM expire, si SPF perd un IP autorisé, ou si MX renvoie une erreur. Aucun audit manuel mensuel à programmer.
Cas pratique chiffré : refonte délivrabilité sur 3 domaines d’envoi
Prenons une équipe outbound B2B (3 SDR, vente mid-market) qui utilise 3 domaines d’envoi dédiés pour absorber 25 000 emails par mois. Avant audit, deux domaines avaient un SPF non aligné avec leur séquenceur récent, un avait perdu son DKIM lors d’une migration DNS, et tous trois avaient un TTL MX à 86 400 (24 heures), héritage d’une ancienne config.
| Indicateur | Avant audit | Après refonte | Delta |
|---|---|---|---|
| Domaines avec MX, SPF, DKIM, DMARC alignés | 0 / 3 | 3 / 3 | +3 |
| TTL MX moyen | 86 400 s | 3 600 s | -96 % |
| Taux de placement inbox (Google Workspace) | 71 % | 89 % | +18 pts |
| Taux de placement inbox (Outlook 365) | 64 % | 84 % | +20 pts |
| Bounce rate moyen | 4,8 % | 1,7 % | -3,1 pts |
| Taux de réponse séquence cold | 3,1 % | 4,9 % | +1,8 pt |
| Conversations générées / mois | 775 | 1 225 | +450 |
L’effet le plus net : 450 conversations supplémentaires par mois sur le même volume d’envoi de 25 000 emails. À deal size moyen 11 K€ ARR et taux de transformation conversation, deal de 4 %, ce gain vaut environ 20 K€ d’ARR signé en plus par mois au seul niveau équipe.
Coût de la refonte : 1 journée d’admin DNS senior (700 €) plus mise en place d’un monitoring continu (150 € par mois, soit 1 800 € par an). Total année 1 : 2 500 €. ROI cash sur 12 mois : (20 K€ × 12) / 2 500 € = plafonné à 10-12× sous raisonnement cash strict sur le delta marginal. La leçon : un seul enregistrement DNS manquant ou mal configuré peut coûter plus que toute optimisation de copy email.
Lancez votre cold email sur des domaines sains
Zeliq monitore MX, SPF, DKIM et DMARC sur chaque domaine d’envoi et n’autorise les campagnes que sur infra propre. Demandez une démo de 20 minutes.
Testez gratuitementÀ quoi sert un enregistrement DNS MX ?
Un enregistrement DNS MX a une seule fonction : indiquer aux serveurs émetteurs (les MTA) où acheminer les emails destinés à votre domaine. Sans MX valide, votre domaine ne peut pas recevoir d’email, ce qui casse votre capacité à recueillir des réponses sur les campagnes outbound. Avec un MX correct mais une stack SPF, DKIM ou DMARC absente ou cassée, vos campagnes peuvent envoyer mais finir massivement en spam. C’est le premier maillon technique de la chaîne email : invisible mais critique.
Comment configurer un enregistrement MX ?
La configuration se fait chez votre fournisseur DNS (registrar ou hôte DNS dédié comme Cloudflare ou Route 53). Trois informations à fournir : le hostname (généralement @ ou votre domaine nu), la priorité (valeur entre 0 et 65 535, plus bas = plus prioritaire), et la cible (hostname du serveur mail, jamais une IP). Pour Google Workspace, la doc officielle vous donne 5 MX records à priorités 1, 5, 5, 10, 10 pour le load balancing. Pour Microsoft 365, c’est généralement un seul MX pointant vers votre domaine .mail.protection.outlook.com. Après modification, comptez 1 à 4 heures de propagation avec un TTL à 3600.
Comment vérifier ses enregistrements MX ?
Trois méthodes équivalentes selon votre confort technique. La plus simple : MXToolbox.com, qui renvoie l’ensemble de votre configuration MX, SPF, DKIM, DMARC en un rapport, avec warnings si quelque chose est cassé. La plus rapide en ligne de commande : dig MX votredomaine.com depuis Linux ou macOS. La plus universelle sur Windows : nslookup -type=mx votredomaine.com. Lancez ces checks sur chaque domaine d’envoi avant chaque démarrage de campagne, pas seulement à la mise en service initiale.
Conclusion : 3 actions datées
Cette semaine : auditez via MXToolbox vos 3 domaines d’envoi les plus utilisés. Notez les warnings sur MX, SPF, DKIM, DMARC dans un wiki partagé avec l’équipe outbound.
Sous 30 jours : corrigez les erreurs prioritaires (MX absents, IP au lieu d’hostnames, doublons hérités d’anciens fournisseurs) et baissez les TTL MX à 3 600 s pour préparer toute migration future.
Sous 90 jours : mettez en place un monitoring continu sur l’infrastructure email pour éviter le cycle “panne, audit pompier, correction tardive”. Si vous voulez intégrer ce monitoring dans votre workflow outbound, essayez Zeliq gratuitement et vérifiez l’état santé de votre stack en deux semaines.
