DNS de messagerie

Vérificateur DNS emaildes enregistrements publics

Indiquez un domaine ; ajoutez le sélecteur DKIM seulement si vous le connaissez. La requête est manuelle.

Vérificateur DNS email

Domaine à examiner

Laissez vide pour ne pas interroger DKIM. Cherchez s= dans l’en-tête d’un message signé ou chez votre fournisseur de messagerie.

Résultat DNS

Saisissez un domaine ou chargez l’exemple, puis lancez la vérification.

Après votre clic seulement, le navigateur envoie le domaine et le nom du sélecteur éventuel à Cloudflare Public DNS en HTTPS. Aucun e-mail n’est envoyé.

Saisissez un domaine ou chargez l’exemple, puis lancez la vérification.

Après une migration de messagerie, le site peut fonctionner alors que les enregistrements du courrier pointent encore vers l’ancien prestataire. Le vérificateur DNS email interroge le nom exact saisi, sans remplacer un sous-domaine par son domaine parent.

Le vérificateur DNS email distingue absence de réponse et échec du résolveur. Les enregistrements MX, SPF, DMARC et la clé DKIM choisie restent visibles avec leur valeur brute ; cela aide à vérifier SPF DKIM DMARC sans confondre DNS et authentification e-mail effective.

Pourquoi ce vérificateur DNS email ?

Une réponse en direct doit montrer aussi ce qui a été omis ou a échoué.

Ne pas confondre DKIM absent et non testé

Le vérificateur DNS email consulte MX, SPF et le nom _dmarc exact. Sans sélecteur DKIM, il affiche « Non vérifié » ; deviner quelques sélecteurs courants ne permettrait pas d’exclure les autres clés.

Trois chemins DNS atteignent un résultat tandis que le chemin DKIM s’arrête devant un sélecteur vide.

Voir les dépendances SPF et leur limite

Les cibles include et redirect sont explorées sur cinq niveaux et douze noms supplémentaires au maximum. Une branche manquante, lente ou coupée reste signalée ; l’arbre ne devient jamais un verdict SPF pour un message.

Un enregistrement SPF se ramifie vers plusieurs cibles et s’arrête sur un repère de limite de requêtes.

Vérifier le nom exact avant de toucher au DNS

01

Conserver le sous-domaine voulu

Saisissez un domaine, pas une URL ni une boîte e-mail. SPF et _dmarc peuvent différer entre parent et sous-domaine. Le bouton Exemple remplit le champ sans lancer de requête réseau.

02

N’ajouter que le sélecteur de signature connu

Une clé DKIM se trouve sous sélecteur._domainkey.domaine. Si s= n’est pas connu, laissez le champ vide. La vérification démarre au clic ou avec Ctrl/Cmd+Entrée.

03

Comparer l’état, le TTL et l’heure

Une entrée absente diffère d’un SERVFAIL ou d’un HTTPS bloqué. L’heure de requête et le TTL aident après une modification ; changer un champ bloque immédiatement la copie de l’ancien résultat.

Ce que montre la réponse du résolveur

Routage MX et TXT d’authentification

Les enregistrements MX sont classés par priorité et le MX nul est identifié. SPF, DMARC et le DKIM choisi gardent leur nom interrogé et leur valeur brute pour une comparaison avec la console du fournisseur.

Arbre SPF borné et sans boucle

Les mécanismes directs sont listés avant les cibles include et redirect accessibles. Un nom déjà visité n’est pas redemandé. Douze noms constituent un budget de requêtes, pas la preuve que la limite RFC de dix est respectée.

État et durée pour chaque catégorie

Trouvé, absent, échoué et non vérifié sont distincts. Le temps de réponse et le TTL apparaissent quand ils sont fournis. Un incident du résolveur ne se transforme jamais en faux résultat vide.

Ce qu’un instantané DNS ne démontre pas

Le clic transmet le nom au résolveur
Ni la saisie ni l’exemple ne déclenchent d’accès. Après votre clic, le navigateur envoie le domaine et le nom issu du sélecteur à Cloudflare Public DNS. Sa disponibilité et sa politique de confidentialité s’appliquent ; la page ne garde pas d’historique.
Sans sélecteur, DKIM reste inconnu
Aucun nom DNS ne répertorie tous les sélecteurs DKIM. Le vérificateur DNS email indique « Non vérifié » pour un champ vide. L’absence de clé au nom choisi ne nie pas une clé publiée ailleurs.
La présence des entrées ne prouve pas la remise
L’IP d’envoi, la signature d’un message, l’alignement From et la réputation ne sont pas testés. Même des entrées valides ne garantissent ni le passage d’une authentification réelle ni la boîte de réception.
DMARC et MX ont ici un champ précis
Seul _dmarc sous le nom saisi est interrogé, sans parcours complet de l’arbre DNS prévu par RFC 9989. Sans MX, SMTP peut se rabattre sur une adresse A/AAAA ; le MX nul indique explicitement aucune réception.
L’exploration SPF ne vaut pas verdict
Les cibles au-delà du budget et les macros exigeant le contexte de l’expéditeur restent inconnues. Le nombre de mécanismes directs et un arbre tronqué ne prouvent ni SPF pass ni le respect des dix consultations.

Questions sur le vérificateur DNS email

Que vérifie exactement le vérificateur SPF, DKIM et DMARC ?

Il lit les TXT publiés au domaine, à _dmarc et au nom du sélecteur DKIM fourni. Il peut expliquer leur syntaxe, mais ne reçoit aucun message signé et ne conclut pas à un résultat d’authentification.

Qu’est-ce qu’un sélecteur DKIM et où le trouver ?

C’est la valeur s= du champ DKIM-Signature d’un message signé, également indiquée par le service d’envoi. Elle forme le nom sélecteur._domainkey.domaine interrogé ici.

Le vérificateur ne trouve pas de clé DKIM, mais ma plateforme dit que DKIM est actif. Comment est-ce possible ?

Le nom du sélecteur saisi peut différer de celui qui signe réellement, ou le changement DNS n’est pas encore visible par ce résolveur. Comparez s=, le nom interrogé et le TTL.

Mon enregistrement SPF est correct et pourtant mes e-mails finissent en spam. Que faire ?

SPF publié ne suffit pas : l’IP réelle, l’alignement DMARC, la signature DKIM, la réputation et le contenu comptent aussi. Cet outil ne mesure pas la délivrabilité.

Pourquoi SPF a-t-il une limite de 10 lookups ?

RFC 7208 limite les mécanismes DNS exécutés pendant une évaluation pour contrôler la charge. L’arbre limité affiché ici n’évalue pas un expéditeur précis et ne certifie pas cette limite.

Mon DMARC dit p=none : est-ce mauvais ?

Non. p=none est une politique valide d’observation. Avant quarantine ou reject, étudiez les rapports et tous les expéditeurs légitimes ; cette page ne peut pas prendre cette décision.

Une autre question sur le DNS du courrier ?

Lancer le vérificateur DNS email

Relancez le vérificateur DNS email après une migration et comparez le nom, l’heure et les réponses brutes aux valeurs que vous avez voulu publier.

Le résolveur public voit les noms interrogés ; ce n’est pas un test de remise.