Enregistrements MX et TXT expliqués

Que sont les enregistrements MX ?

Un enregistrement MX associe un domaine à un ou plusieurs échangeurs de courrier, chacun avec un entier de priorité (préférence). Les expéditeurs essaient d'abord le nombre le plus bas ; des priorités égales peuvent être réparties en équilibre. Exemple : `10 mail.example.com` et `20 mail-backup.example.com`.

Les cibles MX doivent être des noms d'hôte avec des enregistrements A ou AAAA — pas des adresses IP nues. Après un changement MX, vérifiez avec le DNS Checker et laissez expirer le TTL sur les anciens caches. Associez la vérification MX au Blacklist Checker si le courrier entrant finit soudain en spam.

Les domaines de production doivent publier au moins deux hôtes MX sur des réseaux distincts. Si l'échangeur principal est injoignable, RFC 5321 exige que les sites expéditeurs essaient l'hôte de priorité suivante. Documentez les deux priorités dans les tickets de changement et relancez le DNS Checker après chaque modification MX pour que les fils support montrent des priorités live, pas des captures de panneau.

Que sont les enregistrements TXT ?

Les enregistrements TXT stockent des chaînes de texte arbitraires. Les opérateurs de messagerie publient SPF à l'apex (ou sous-domaine legacy) sous la forme `v=spf1 ...`, DKIM sur des sélecteurs comme `default._domainkey.example.com`, et DMARC sur `_dmarc.example.com`. La vérification de site utilise de courts jetons (`google-site-verification=...`, `MS=ms...`).

Plusieurs chaînes dans une même réponse TXT sont normales. Certains panneaux découpent de longues clés DKIM en fragments. Lors du dépannage, copiez la valeur concaténée exacte du DNS Checker plutôt que de la retaper depuis un PDF.

TXT sert aussi pour BIMI, MTA-STS et TLS-RPT sur des configurations mail avancées — toujours publié en texte à des noms prévisibles. Si votre fournisseur fait tourner des sélecteurs DKIM, anciens et nouveaux sélecteurs peuvent coexister brièvement ; interrogez TXT après chaque rotation et notez le TTL avant de retirer les clés obsolètes.

SPF, DKIM et DMARC en TXT

SPF liste les hôtes autorisés à envoyer du courrier pour votre domaine (`v=spf1 include:... ~all`). Un seul TXT SPF peut exister par owner name — des chaînes SPF dupliquées invalident entièrement la politique. Fusionnez les includes au lieu d'ajouter un second enregistrement à l'apex.

DKIM publie une clé publique sur `selector._domainkey.example.com`. L'alignement avec le domaine de l'en-tête From compte pour pass/fail DMARC. Après onboarding d'un relais, confirmez le TXT du sélecteur dans le DNS Checker selon le tableau de bord du fournisseur avant l'envoi massif.

DMARC sur `_dmarc.example.com` fixe la politique (`p=none`, `quarantine`, `reject`) et les adresses de rapports (`rua=`, `ruf=`). Commencez par `p=none` pour collecter des rapports agrégés, puis resserrez quand SPF et DKIM s'alignent de façon fiable. Revérifiez les trois familles avec le DNS Checker après toute migration mail — MX seul ne prouve jamais que SPF est correct.

Comment vérifier MX et TXT en ligne

Étape 1 — Ouvrez le DNS Checker et saisissez le domaine (apex ou sous-domaine). Étape 2 — Lancez une recherche complète ou concentrez-vous sur les sections MX et TXT. Étape 3 — Comparez priorité, cibles et chaînes TXT avec le guide de configuration de votre fournisseur de messagerie. Étape 4 — Si les valeurs sont obsolètes, notez le TTL et relancez la requête après expiration.

Pour une requête MX ciblée uniquement, ouvrez l'outil DIG, choisissez le type MX et inspectez la section de réponse. Utilisez le même domaine dans WHOIS pour confirmer que les serveurs de noms correspondent au panneau DNS que vous avez modifié.

Archivez la sortie du checker dans les tickets : priorités, noms d'hôtes d'échangeurs, chaînes SPF/DKIM/DMARC complètes et valeurs TTL. Si Authentication-Results montre encore des échecs après correction, attendez une fenêtre TTL complète et relancez le DNS Checker — les caches récursifs survivent souvent au clic Save dans le panneau.

Vérification et jetons TXT tiers

Search Console, Microsoft 365, Stripe et les autorités de certification demandent chacun une preuve TXT unique à l'apex ou sur des labels `_dnsauth`. Ces jetons coexistent avec SPF en tant qu'enregistrements TXT séparés au même nom — contrairement à SPF, plusieurs chaînes TXT non liées sur un owner sont valides.

Avant de supprimer d'« anciens » TXT lors d'un nettoyage, confirmez qu'aucun n'est une vérification active ou des clés DKIM. Le DNS Checker liste chaque réponse TXT sur un nom pour comparer à la doc du fournisseur au lieu de deviner de mémoire.

Après ajout d'un TXT de vérification, interrogez immédiatement avec le DNS Checker, puis à nouveau après TTL si le fournisseur signale encore un échec. Certains registrars publient les zones par lots toutes les quelques minutes — deux exécutions identiques du checker à cinq minutes d'intervalle inspirent confiance plus vite que de rafraîchir seule l'UI du fournisseur.

Problèmes courants

L'absence de SPF est le chemin le plus rapide vers les dossiers spam. Une mauvaise priorité MX envoie le courrier vers un hôte décommissionné. Un TXT de vérification mal saisi casse Search Console ou la configuration Microsoft 365. Des réponses en cache après un TTL non abaissé avant une bascule ressemblent à « DNS cassé » alors que la propagation est encore en cours.

Deux enregistrements SPF au même nom invalident SPF entièrement — fusionnez en un seul TXT. DMARC sans DKIM/SPF alignés signale les échecs mais ne les corrige pas ; traitez DMARC comme couche de politique au-dessus d'enregistrements d'authentification fonctionnels.

Pointer MX vers un label CNAME-only casse la résolution sur des resolvers stricts. Publier MX vers un nom d'hôte sans A/AAAA opérationnels crée une perte silencieuse de courrier — confirmez les cibles d'échangeurs dans le DNS Checker après chaque changement de cible MX.

MX et TXT pendant les migrations

Les migrations mail échouent silencieusement quand MX est mis à jour avant que SPF/DKIM/DMARC soient prêts chez le nouveau fournisseur, ou quand d'anciens MX restent avec des numéros de priorité plus bas que prévu. Publiez une baseline avec le DNS Checker avant cutover, puis comparez les sections MX et TXT chaque heure pendant la fenêtre de migration.

Baissez le TTL sur MX et TXT critiques vingt-quatre à quarante-huit heures avant la bascule si votre hôte DNS le permet. Confirmez le TTL plus bas publiquement avec le DNS Checker — certains panneaux affichent 300 secondes tandis que la zone live sert encore 3600 jusqu'à la fin du prochain cycle de publication.

Gardez le MX de l'ancien fournisseur avec une priorité plus haute (nombre plus grand) jusqu'à valider la livraison entrante sur la nouvelle stack, puis retirez les échangeurs obsolètes. Le courrier sortant peut encore utiliser d'anciens includes SPF tant que vous n'avez pas mis à jour le TXT apex — vérifiez les deux directions avec le DNS Checker avant de clore le ticket.

Documentez qui possède chaque chaîne TXT (vérification marketing, mail IT, rapports DMARC finance) pour que les futurs nettoyages ne suppriment pas par erreur des enregistrements d'authentification de production.

Questions fréquentes

Combien de temps faut-il pour que les changements DNS apparaissent ?

La plupart des résolveurs respectent le TTL (time to live). Si le TTL est de 3600 secondes, attendez jusqu'à une heure avant l'expiration des réponses en cache. Baissez le TTL avant les migrations, appliquez le changement, puis vérifiez avec le DNS Checker jusqu'à voir les nouvelles valeurs.

Puis-je vérifier MX et TXT sans installer dig ?

Oui. Ouvrez le DNS Checker, saisissez votre domaine et filtrez ou faites défiler jusqu'aux sections MX et TXT. Pour un seul type d'enregistrement, utilisez aussi l'outil DIG avec le type MX ou TXT.

Pourquoi le courrier fonctionne mais SPF échoue encore ?

SPF n'autorise que les IP d'envoi ou les chaînes include. Un enregistrement MX correct n'implique pas que SPF soit correct. Comparez vos IP SMTP sortantes avec la chaîne include SPF et utilisez des requêtes TXT pour confirmer que la chaîne publiée correspond à la documentation de votre fournisseur de messagerie.

Dois-je utiliser plusieurs enregistrements MX ?

Oui en production. Publiez au moins deux hôtes MX avec des priorités différentes (nombre plus bas = préférence plus haute). Si le primaire tombe, les expéditeurs essaient la priorité suivante selon RFC 5321.

Quel RFC définit SPF ?

SPF est défini dans RFC 7208 (anciennement RFC 4408). DKIM est RFC 6376 et DMARC est RFC 7489. Tous sont publiés comme enregistrements TXT à des noms prévisibles.

Puis-je publier MX et SPF sur la même étiquette de nom d'hôte ?

MX et SPF vivent généralement sur des noms différents — MX à l'apex ou sous-domaine mail, SPF en TXT à l'apex. Ne placez jamais de CNAME sur une étiquette qui a aussi besoin de MX ou SPF. Utilisez le DNS Checker pour confirmer qu'aucun type conflictuel ne partage le même owner name.

À quelle fréquence revérifier MX et TXT en production ?

Après chaque changement DNS ou de fournisseur mail, plus des audits trimestriels pour les domaines qui envoient du courrier en masse. La surveillance automatisée via l'API DN01 peut alerter quand les priorités MX ou les chaînes SPF dévient des valeurs attendues.

DNS Checker conserve-t-il mes recherches ?

Les vérifications réussies peuvent apparaître dans l'historique récent local de votre session navigateur par commodité. Utilisez l'API documentée avec votre propre token si vous avez besoin d'une surveillance répétable sans l'interface web.