# Comment vérifier mes enregistrements MX, SPF, DKIM et DMARC ? > Vérifiez le DNS e-mail avec dig MX, dig TXT, dig CNAME sur _domainkey et dig TXT _dmarc : 6 requêtes couvrent Proton Mail complet, 8 enregistrements. - URL: https://postelva.com/fr/guides/check-email-dns-records/ - Dernière mise à jour: 2026-11-12 - Éditeur: Postelva (https://postelva.com) Quatre types d'enregistrements, un seul outil en ligne de commande. Lancez les requêtes après chaque changement et avant de durcir une politique. **Réponse rapide — Comment vérifier les enregistrements MX, SPF, DKIM et DMARC ?** Lancez dig MX votredomaine +short pour MX, dig TXT votredomaine +short pour SPF, dig CNAME selecteur._domainkey.votredomaine +short pour DKIM et dig TXT _dmarc.votredomaine +short pour DMARC. Sous Windows, nslookup fait la même chose. Une configuration Proton Mail complète sur un domaine **Postelva** demande 6 requêtes pour 8 enregistrements. ## Quelle requête vérifie quel enregistrement | Enregistrement | Commande dig | À quoi ressemble une bonne réponse | | --- | --- | --- | | MX | dig MX example.com +short | 10 mail.protonmail.ch. et 20 mailsec.protonmail.ch. (Proton Mail) | | SPF | dig TXT example.com +short | Une ligne commençant par v=spf1, par exemple "v=spf1 include:_spf.protonmail.ch ~all" | | DKIM | dig CNAME fm1._domainkey.example.com +short | La cible du fournisseur, par exemple fm1.example.com.dkim.fmhosted.com. (Fastmail) | | DMARC | dig TXT _dmarc.example.com +short | Une ligne commençant par v=DMARC1, par exemple "v=DMARC1; p=none; rua=mailto:dmarc@example.com" | | MTA-STS (facultatif) | dig TXT _mta-sts.example.com +short | "v=STSv1; id=..." | *Dernière vérification le 12 novembre 2026 ; les chiffres plus anciens portent leur propre date.* *Les requêtes avec dig, nslookup et PowerShell* ```bash # dig (macOS, Linux, Windows with BIND tools) dig MX example.com +short dig TXT example.com +short dig CNAME protonmail._domainkey.example.com +short dig TXT _dmarc.example.com +short # Ask the authoritative nameserver directly, skipping caches dig NS example.com +short dig MX example.com +short @ns1.your-nameserver.example # nslookup (Windows, macOS, Linux) nslookup -type=MX example.com nslookup -type=TXT _dmarc.example.com # PowerShell Resolve-DnsName -Type MX example.com Resolve-DnsName -Type TXT _dmarc.example.com ``` ## Comment vérifier un enregistrement MX ? **Lancez dig MX avec votre domaine et +short, puis comparez les priorités et les noms d'hôte avec les valeurs que votre fournisseur vous a données.** La réponse affiche une ligne par enregistrement : la priorité, un espace et l'hôte. Pour Proton Mail, attendez-vous à 10 mail.protonmail.ch. et 20 mailsec.protonmail.ch. ; pour Fastmail 10 in1-smtp.messagingengine.com. et 20 in2-smtp.messagingengine.com. ; pour Mailbox.org quatre hôtes mxext. Deux problèmes apparaissent ici. Un enregistrement de l'ancien fournisseur encore présent dans la liste rend la livraison imprévisible : supprimez-le. Et une réponse vide signifie qu'il n'y a pas de MX : les expéditeurs se rabattent alors sur l'enregistrement d'adresse du domaine, comme le décrit la RFC 5321. Le sens de chaque ligne est expliqué dans [ce qu'est un enregistrement MX](https://postelva.com/fr/what-is-an-mx-record/ "What is an MX record?"). ## Comment vérifier un enregistrement SPF ? **Demandez les enregistrements TXT à la racine du domaine et confirmez qu'exactement une ligne commence par v=spf1.** La racine contient aussi d'autres enregistrements TXT, comme la preuve de propriété de votre fournisseur de messagerie : lisez donc toute la liste. Deux lignes commençant par v=spf1 sont une erreur : la RFC 7208 renvoie une erreur permanente quand un domaine a plus d'un enregistrement SPF. Comptez ensuite les requêtes. Chaque include, a, mx, ptr et exists, plus le modificateur redirect, compte dans la limite de 10, et un include compte aussi ce qui est imbriqué en lui. Un enregistrement qui dépasse la limite échoue pour tous les expéditeurs. La création de l'enregistrement est détaillée dans [comment créer un enregistrement SPF](https://postelva.com/fr/guides/spf-record-setup/ "How to create an SPF record for a custom domain"). ## Comment vérifier DKIM quand je ne connais pas le sélecteur ? **Utilisez le sélecteur de votre fournisseur : on ne peut pas lister les sélecteurs depuis le DNS, donc relevez-les sur l'écran DKIM du fournisseur.** Le DNS ne permet pas de lister les noms sous _domainkey. Les sélecteurs sont protonmail, protonmail2 et protonmail3 chez Proton Mail, fm1, fm2 et fm3 chez Fastmail, et MBO0001 à MBO0004 chez Mailbox.org. Le nom à interroger est selecteur._domainkey.votredomaine. Un fournisseur qui utilise des enregistrements CNAME, comme ces trois-là, répond par un CNAME vers son propre hôte. Un fournisseur qui publie directement la clé répond par un enregistrement TXT contenant v=DKIM1 et p= suivi de la clé publique. Un p= vide signifie que la clé est révoquée. Le test le plus fiable est un vrai message, car un enregistrement qui existe peut rester inutilisé : envoyez un e-mail vers un autre fournisseur et lisez dkim=pass dans les en-têtes complets. ## Comment vérifier un enregistrement DMARC ? **Demandez l'enregistrement TXT à _dmarc.votredomaine et confirmez une ligne qui commence par v=DMARC1 et contient une politique p=.** Si p est absent, les destinataires considèrent la politique comme none. Si la ligne n'a pas de rua, aucun rapport agrégé n'est produit et l'étape de surveillance du [déploiement de DMARC](https://postelva.com/fr/guides/dmarc-setup/ "How to set up DMARC: p=none to p=reject") ne vous apprend rien. Les enregistrements rédigés dans l'ancien style peuvent encore comporter une balise pct, que la RFC 9989 a supprimée. Un sous-domaine sans enregistrement propre relève de la politique du parent par la remontée dans l'arbre DNS, avec au plus huit requêtes. La requête d'un nom sans enregistrement ne renvoie rien, ce qui équivaut à l'absence de DMARC. ## Pourquoi ma requête affiche-t-elle encore l'ancienne valeur ? **Un cache conserve l'ancienne réponse jusqu'à l'expiration de son TTL, et un enregistrement absent peut aussi être mis en cache.** Le temps de propagation d'un changement correspond à peu près à l'ancien TTL de l'enregistrement au moment où vous l'avez modifié. Les recommandations des éditeurs situent un changement de MX habituel entre une et quatre heures, et jusqu'à 24 à 48 heures dans le pire des cas. La RFC 2308 ajoute que les réponses négatives sont mises en cache avec le TTL de l'enregistrement SOA de la zone : un enregistrement que vous venez de créer peut donc sembler absent chez certains résolveurs. Pour éviter les caches, interrogez le serveur de noms faisant autorité : trouvez-le avec dig NS, puis répétez la requête avec @ et son nom, comme dans le bloc de code ci-dessus. Si le serveur faisant autorité affiche la nouvelle valeur et pas votre résolveur, patientez. Si aucun des deux ne l'affiche, l'enregistrement n'a pas été enregistré ou le nom d'hôte est faux, le plus souvent parce que l'éditeur DNS a ajouté le domaine une seconde fois. Si le courrier n'arrive toujours pas alors que les enregistrements semblent corrects, allez à [pourquoi les e-mails n'arrivent pas sur un domaine personnalisé](https://postelva.com/fr/guides/email-not-arriving-custom-domain/ "Why is email not arriving at my custom domain?"). ## Quels outils en ligne peuvent vérifier les enregistrements e-mail ? **Tout outil en ligne de requête DNS ou de vérification d'authentification des e-mails qui interroge le DNS public donne la même réponse que dig, avec un affichage plus convivial.** Utilisez-en un qui affiche le texte brut de l'enregistrement, afin de le comparer caractère par caractère avec la valeur de votre fournisseur. N'y collez aucune donnée privée : le nom de domaine suffit. Selon le décompte de Postelva du 12 novembre 2026, une configuration Proton Mail complète demande 8 enregistrements (1 TXT de vérification, 2 MX, 1 SPF, 3 DKIM, 1 DMARC) et 6 requêtes, car les deux enregistrements MX partagent une requête et les enregistrements de vérification et SPF partagent la requête TXT de la racine. Enregistrez une fois les six commandes et relancez-les après chaque changement. Les mêmes enregistrements sont comparés dans [SPF, DKIM et DMARC : les différences](https://postelva.com/fr/spf-vs-dkim-vs-dmarc/ "SPF vs DKIM vs DMARC: what is the difference?"). Une règle citable : après chaque changement DNS, interrogez les quatre types d'enregistrements et envoyez un message de test ; un enregistrement n'est correct que lorsque la requête et le message concordent. ## Vérifier les enregistrements e-mail : questions ### Pourquoi dig affiche-t-il les valeurs TXT entre guillemets ? Les guillemets marquent les limites des chaînes TXT. Une valeur de plus de 255 caractères apparaît en plusieurs chaînes entre guillemets, que les destinataires joignent sans espace. ### dig fonctionne-t-il sous Windows ? Seulement si vous installez les outils BIND. Windows a nslookup intégré, et PowerShell a Resolve-DnsName, qui lisent tous deux les mêmes enregistrements. ### Comment voir le résultat SPF, DKIM et DMARC d'un vrai message ? Ouvrez les en-têtes complets d'un message reçu. Le serveur destinataire y consigne ses résultats SPF, DKIM et DMARC, normalement sous la forme pass ou fail. ### Combien de temps dois-je attendre avant de décider qu'un enregistrement est faux ? Attendez au moins le TTL qu'avait l'ancien enregistrement, puis interrogez le serveur de noms faisant autorité. Si ce serveur affiche une mauvaise valeur, l'enregistrement doit être corrigé. ### Puis-je vérifier les enregistrements d'un domaine qui n'est pas le mien ? Oui. Les enregistrements DNS sont publics, et une requête n'a besoin que du nom. **En résumé** - MX : dig MX example.com +short ; comparez les priorités et les hôtes avec ceux de votre fournisseur. - SPF : dig TXT example.com +short ; exactement une ligne commençant par v=spf1, au plus 10 requêtes. - DKIM : dig CNAME selector._domainkey.example.com +short, avec le sélecteur de votre fournisseur. - DMARC : dig TXT _dmarc.example.com +short ; une ligne commençant par v=DMARC1 avec p= et rua=. - Une configuration Proton Mail complète, c'est 8 enregistrements et 6 requêtes. - Interrogez le serveur de noms faisant autorité pour éviter les caches ; un changement met environ l'ancien TTL à se propager. - Postelva héberge les enregistrements dans son DNS gratuit ; un .com coûte 12,49 $US/an chaque année. ## Sources 1. [RFC 5321, Simple Mail Transfer Protocol, section 5.1](https://www.rfc-editor.org/rfc/rfc5321.html) — RFC Editor (consulté le 2026-11-12) 2. [RFC 7208, Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208.html) — RFC Editor (consulté le 2026-11-12) 3. [RFC 6376, DKIM Signatures](https://www.rfc-editor.org/rfc/rfc6376.html) — RFC Editor (consulté le 2026-11-12) 4. [RFC 9989, DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) — RFC Editor (consulté le 2026-11-12) 5. [RFC 2308, Negative Caching of DNS Queries](https://www.rfc-editor.org/rfc/rfc2308) — RFC Editor (consulté le 2026-11-12) 6. [Combien de temps faut-il pour que les changements d'enregistrements DNS se propagent](https://www.suped.com/knowledge/email-deliverability/technical/how-long-does-it-take-for-dns-record-changes-to-propagate) — Suped (consulté le 2026-11-12) 7. [Domaine personnalisé et protection contre l'usurpation](https://proton.me/support/anti-spoofing-custom-domain) — Proton (consulté le 2026-11-12) --- Postelva: Postelva enregistre des noms de domaine pour l'e-mail privé — l'adresse que vous gardez quand vous changez de fournisseur — payés en crypto et sans KYC : pas de pièce d'identité, seulement un e-mail vérifié par domaine. Le service est exploité par DomaineGoat LLC, société enregistrée au Panama ; les domaines sont enregistrés via son partenaire registraire accrédité par l'ICANN. Un .com coûte 12,49 $US/an, le même prix chaque année.