Vérifier un domaine e-mail n’est pas tester la livraison

Une vérification du domaine de messagerie peut révéler des enregistrements DNS publiés. Elle ne prouve pas qu’un message donné a été authentifié, distribué ou placé dans la boîte de réception. Lisez chaque résultat comme une observation portant sur un domaine précis à un instant donné, puis choisissez le contrôle suivant en fonction de votre véritable question sur l’envoi.

Avant une campagne, un fondateur utilise un outil de vérification et obtient plusieurs résultats positifs. Il est tentant d’y voir le feu vert pour annoncer que la messagerie est prête. Pourtant, recevoir des messages, publier une politique d’expédition, signer un message et atteindre son destinataire sont des tâches distinctes.

Le 16 octobre 2026, nous avons utilisé l’outil public de vérification des domaines de messagerie de FounderOmni pour examiner founderomni.com. Nous avons laissé vide le sélecteur DKIM facultatif. Ce résultat permet d’expliquer comment interpréter des éléments de configuration sans en déduire une preuve de distribution. Aucun message n’a été envoyé et aucun paramètre DNS n’a été modifié.

Lisez le résultat de la requête réellement effectuée

Notez le domaine et les données saisies avant d’interpréter les indicateurs. Un domaine racine et un sous-domaine d’envoi ne publient pas nécessairement les mêmes enregistrements. Une vérification sans sélecteur DKIM diffère également d’une requête portant sur le sélecteur précis d’un prestataire.

Notre résultat indiquait une vérification à 10:00 du matin, heure de New York. L’interface précisait qu’un contrôle pouvait réutiliser un résultat obtenu au cours des cinq dernières minutes. Cet horodatage décrit cette observation ; il ne garantit pas que tous les résolveurs du monde voient les mêmes informations à cet instant.

Les résultats affichés étaient les suivants :

• MX : Found (trouvé). La réponse indiquait mx1.spacemail.com et mx2.spacemail.com comme destinations des messages entrants.
• SPF : Found (trouvé). Le texte renvoyé commençait par v=spf1 et comportait deux références à des prestataires avant le ~all final.
• DMARC : Review (à examiner). L’enregistrement renvoyé était v=DMARC1; p=none;.
• DKIM : Not checked (non vérifié). L’explication était « No selector supplied » (aucun sélecteur fourni).

Chaque ligne répond à sa propre question. « Not checked » signale une donnée manquante lors de cette requête, pas l’absence de clé DKIM pour le domaine. « Found » établit que l’outil a obtenu un enregistrement correspondant, pas que l’expéditeur et chacun de ses messages ont passé une évaluation complète du protocole.

Le schéma ci-dessous résume les lignes observées et leurs limites. Il s’agit d’une explication originale de cette requête, et non d’une reproduction de l’interface. Vous pouvez aussi ouvrir la capture réelle du résultat détaillé.

Distinguez également l’échec d’une recherche de l’absence d’un enregistrement. Si une requête n’a pas abouti, l’étape utile consiste à examiner cette observation ou à réessayer avec les commandes habituelles. Remplacer un résultat indisponible par « manquant » ferait apparaître un problème de configuration qui n’a pas été établi.

Distinguez un enregistrement publié d’un message qui fonctionne

Les enregistrements MX indiquent où doivent arriver les messages entrants. Ils n’autorisent pas l’expéditeur d’une campagne sortante. Utilisez le résultat pour comparer votre configuration de réception avec le prestataire attendu, sans en faire un label d’authentification pour tous les messages de votre marque.

SPF publie des informations d’autorisation pour l’identité d’envoi concernée. La spécification SPF décrit des contrôles portant sur l’expéditeur de l’enveloppe SMTP et l’adresse IP d’envoi. Trouver le texte constitue une observation ; évaluer un expéditeur réel avec les bonnes données en constitue une autre.

Notre outil public précisait explicitement qu’il n’avait ni évalué l’IP d’envoi ni exécuté les règles SPF récursives. Les références aux prestataires affichées ne prouvent donc pas que tous les services utilisés par l’équipe sont autorisés, que la politique complète convient à chaque chemin d’envoi ou qu’un message donné passe le contrôle. Comparez la configuration réelle du prestataire avant de décider quoi modifier.

DKIM nécessite un autre élément de contexte. Son mécanisme de sélecteurs permet d’utiliser différentes clés publiques au sein d’un domaine de signature. Le sélecteur réellement employé par le prestataire est donc essentiel. En deviner un et ne trouver aucun enregistrement ne prouve pas l’absence de tous les sélecteurs possibles.

Nous n’avons volontairement fourni aucun sélecteur dans cet exemple. L’étape suivante consiste à obtenir la bonne valeur auprès du prestataire d’envoi ou dans les informations de signature d’un message que vous êtes autorisé à examiner. Même une recherche ultérieure réussie ne révélerait qu’une clé publiée ; elle ne vérifierait pas qu’un message précis a été correctement signé. Les clés privées de signature n’ont pas leur place dans un outil public de vérification.

DMARC relie l’authentification au domaine d’expédition visible et à la politique de son propriétaire. Parmi les valeurs de politique documentées, none ne demande aucune mesure particulière de distribution. Cette valeur ne demande pas le rejet des messages en échec, et sa seule présence ne prouve pas l’alignement de l’authentification.

L’enregistrement renvoyé ne contenait pas non plus de destination rua pour les rapports agrégés. Qualifier une politique de « surveillance » ne doit pas devenir une affirmation selon laquelle l’équipe reçoit des rapports : leur destination et leur collecte doivent être vérifiées séparément. Nous n’avons examiné aucun service privé de rapports ni aucune boîte mail lors de cette requête.

Ne remplacez pas une politique de surveillance par une politique d’application de mesures uniquement pour faire disparaître un indicateur de révision. Examinez les chemins d’envoi légitimes et les éléments disponibles avec la personne qui gère le domaine. Un changement de configuration doit répondre à un besoin opérationnel, au-delà d’un résumé visuellement plus rassurant.

Choisissez le prochain contrôle selon la question à résoudre

Commencez par une question précise. « Notre modification DNS apparaît-elle dans cette recherche ? » peut s’étudier avec le domaine exact, le nom de l’enregistrement, la valeur renvoyée et l’heure du contrôle. « Notre campagne est-elle authentifiée ? » exige des éléments sur le chemin d’envoi et les messages réels. « Le destinataire l’a-t-il reçu ? » exige des éléments de distribution ou des preuves côté destinataire.

Pour un test de message autorisé, consignez ensemble l’expéditeur, le destinataire, le prestataire, l’heure et le résultat d’authentification pertinent. L’acceptation par un prestataire, la réponse d’un serveur destinataire et le fait que le destinataire voie le message sont des observations différentes. Ne transformez pas l’une en preuve des trois et ne supposez pas que l’acceptation garantit l’arrivée dans la boîte de réception.

Si un message n’arrive pas comme prévu, conservez les détails de l’échec au lieu de répéter des vérifications DNS sans rapport jusqu’à obtenir un résultat vert. Examinez l’événement ou la réponse réellement enregistrés par le prestataire, ainsi que les éléments côté destinataire que vous êtes autorisé à consulter. Vous pourrez ainsi repérer l’étape précise qui manque à l’enquête.

Une courte fiche de transmission peut contenir :

• Question : le fait de configuration, d’authentification ou de distribution à établir.
• Périmètre : le domaine exact, le sélecteur fourni et, le cas échéant, le chemin d’envoi.
• Observation : les enregistrements renvoyés ou les éléments d’un message réel, avec leur horodatage.
• Inconnue : la partie que le contrôle choisi n’a pas évaluée.
• Action suivante : le réglage du prestataire, la recherche précise ou le résultat d’un message autorisé à examiner ensuite.

Cette fiche aide une petite équipe à éviter qu’une conclusion générale du type « la messagerie fonctionne » circule entre des personnes ayant vérifié des choses différentes. Conservez les en-têtes privés, les adresses et les informations de compte dans votre processus sécurisé habituel ; ne partagez que les informations nécessaires à l’enquête.

Une fois le chemin d’envoi vérifié, le message lui-même doit encore aider son lecteur. Notre guide des e-mails de bienvenue aborde une tâche distincte : rendre claire la première action utile. Ni un texte clair ni un enregistrement DNS publié ne remplacent des preuves sur le parcours d’un message réel.