Comment vérifier mes enregistrements MX, SPF, DKIM et DMARC ?

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.

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.

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 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é.

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.

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.