emailmarketing.net
EnglishFrançais

Lire un résultat du diagnostic de domaine

Ce que signifient les résultats SPF, DKIM, DMARC, MX et listes de blocage quand le diagnostic de domaine indique Bon, Risqué, Mauvais ou Indéterminé, ce que le diagnostic ne voit pas (les sélecteurs qu’il n’a pas essayés, les adresses depuis lesquelles vous envoyez réellement, votre réputation), et la prochaine étape pour chacun.

Opérationnel12 min de lecture

À qui cela s’adresse Expéditeurs

S’applique aux expéditeurs, quelle que soit leur plateforme

SommaireSur cette page : 7 sections

Le diagnostic de domaine gratuit lit les enregistrements que votre domaine publie dans le DNS public pour SPF, DKIM, DMARC et MX, et recherche les adresses autorisées par votre enregistrement SPF sur les listes de blocage qu’il interroge. Il attribue à chaque résultat l’un de quatre mots, et chaque mot a un sens précis :

Verdict Ce qu’il signifie
Bon La vérification s’est exécutée et a trouvé ce qu’elle cherche.
Risqué La vérification s’est exécutée et a trouvé une configuration qui fonctionne mais laisse une faille.
Mauvais La vérification s’est exécutée et a trouvé un élément manquant ou défectueux.
Indéterminé La vérification n’a pas obtenu de réponse. Ce n’est ni une réussite ni un échec, et le diagnostic n’indique jamais Bon pour une vérification qui ne s’est pas terminée.

Les résultats décrivent ce que votre domaine indique aux fournisseurs de messagerie. Ils ne prédisent pas où arriveront vos emails. Les messages authentifiés « risquent moins d’être rejetés ou marqués comme spam », selon les termes de Google (consignes de Google pour les expéditeurs d’emails). Moins de risque n’est pas une garantie, même avec tous les résultats en Bon.

Chaque résultat comporte aussi sa propre prochaine étape, en une ligne. Cet article explique le raisonnement derrière ces étapes, et qui s’en charge habituellement.

SPF

SPF liste les serveurs autorisés à envoyer des emails pour votre domaine, dans un enregistrement TXT qui commence par v=spf1 (RFC 7208). Son dernier terme, le « mécanisme all », indique aux serveurs de réception comment traiter les emails provenant de n’importe où ailleurs.

Verdict Ce que le diagnostic a trouvé Prochaine étape
Bon L’enregistrement se termine par -all (échec strict) ou ~all (échec souple). L’échec souple compte sur DMARC pour arrêter les emails usurpés : le résultat DMARC compte donc aussi. Aucune action sur cet enregistrement. Tenez-le à jour quand vous ajoutez ou modifiez des services qui envoient au nom de votre domaine, et lisez le résultat DMARC.
Risqué L’enregistrement se termine par ?all ou +all, qui ne restreignent pas réellement qui peut envoyer au nom de votre domaine, ou il n’a aucun mécanisme all reconnu. Une fois tous les expéditeurs légitimes listés, terminez l’enregistrement par -all (ou ~all pendant les tests).
Mauvais Aucun enregistrement SPF ; plusieurs ; une erreur de syntaxe ; plus de 10 requêtes DNS ; ou un redirect= qui pointe vers un domaine sans enregistrement SPF, ou avec plusieurs. Publiez exactement un enregistrement commençant par v=spf1 : fusionnez les doublons, corrigez la syntaxe, ou retirez les mécanismes inutilisés jusqu’à ce que l’évaluation demande 10 requêtes ou moins.
Indéterminé Les requêtes DNS ont échoué ou ne se sont pas terminées à temps, ou l’enregistrement confie sa politique à un autre domaine avec redirect= et le diagnostic ne l’a pas suivi. Réessayez dans un instant. Pour une redirection, consultez l’enregistrement SPF du domaine cible : son mécanisme all est la politique qu’appliquent les serveurs de réception.

Pourquoi ces cas sont Mauvais : la RFC 7208 indique que plus d’un enregistrement SPF, une erreur de syntaxe n’importe où dans l’enregistrement, ou plus de 10 termes qui interrogent le DNS font tous aboutir l’évaluation SPF à une « permerror », une erreur permanente et non une réussite (RFC 7208 §4.5, §4.6 et §4.6.4).

Qui agit : le responsable du DNS modifie l’enregistrement. Votre plateforme d’envoi vous indique quoi inclure pour ses serveurs. Google indique que SPF doit inclure tous les expéditeurs d’emails de votre domaine, et que les emails des expéditeurs qui n’y figurent pas sont plus susceptibles d’être marqués comme spam (consignes de Google pour les expéditeurs d’emails).

DKIM

DKIM signe chaque message avec une clé. La moitié publique de cette clé est publiée dans le DNS sous un nom appelé sélecteur, que la signature elle-même indique dans sa balise s= (RFC 6376 §3.1 et §3.5). Le sélecteur est choisi par celui qui signe les emails : une requête DNS ne peut donc qu’essayer des noms et voir ce qui répond.

Verdict Ce que le diagnostic a trouvé Prochaine étape
Bon Une clé DKIM est publiée à un sélecteur. C’est ce que le DNS peut montrer, et non que vos messages sont signés. Le même verdict apparaît quand le domaine n’autorise aucun serveur à envoyer (v=spf1 -all), puisqu’un domaine qui n’envoie pas d’emails n’a pas besoin de clé DKIM. Vérifiez un vrai message : envoyez-en un à une boîte que vous contrôlez et cherchez dans son en-tête Authentication-Results un dkim=pass avec un d= qui correspond à votre domaine From. Faites tourner la clé périodiquement.
Mauvais Un enregistrement existe au sélecteur, mais sa clé publique est absente ou mal formée. Régénérez la paire de clés et republiez la clé publique. Votre plateforme d’envoi fournit généralement l’enregistrement à publier.
Indéterminé Aucune clé à aucun des sélecteurs courants essayés par le diagnostic, ni au sélecteur que vous avez saisi. Le résultat nomme les sélecteurs vérifiés. Demandez à votre plateforme d’envoi avec quel sélecteur elle signe, puis relancez le diagnostic avec ce nom dans le champ « Sélecteur DKIM (facultatif) ».

Il n’existe pas de résultat DKIM Risqué. Une clé est soit trouvée et utilisable, soit trouvée et défectueuse, soit introuvable là où le diagnostic a cherché.

Qui agit : la plateforme génère la clé et signe les emails ; le responsable du DNS publie la clé publique. L’en-tête Authentication-Results explique comment lire dkim=pass (RFC 8601), et Rotation des clés DKIM traite de la rotation.

DMARC

DMARC, publié à _dmarc.<your domain>, indique aux serveurs de réception que faire des emails qui échouent à l’authentification pour votre domaine, et où envoyer les rapports (RFC 7489). Sa balise p= est la politique : none ne demande aucune action particulière, quarantine demande aux serveurs de réception de traiter les emails en échec comme suspects, et reject leur demande de les rejeter. La balise rua= nomme l’adresse qui reçoit les rapports agrégés (RFC 7489 §6.3).

Verdict Ce que le diagnostic a trouvé Prochaine étape
Bon Une politique contraignante est appliquée (p=quarantine ou p=reject) avec des rapports agrégés configurés. Aucune action. Examinez périodiquement les rapports agrégés pour repérer des expéditeurs que vous ne reconnaissez pas.
Risqué Mode surveillance seule (p=none) : les rapports sont collectés, mais les serveurs de réception ne sont pas invités à mettre en quarantaine ou à rejeter les emails non authentifiés. Ou une politique contraignante est appliquée sans adresse rua=, si bien que personne ne voit les rapports. Ajoutez une adresse rua= s’il n’y en a pas. Une fois que les rapports montrent que tous les expéditeurs légitimes réussissent, passez à p=quarantine, puis à p=reject.
Mauvais Aucun enregistrement DMARC ; plusieurs, auquel cas les serveurs de réception n’en appliquent aucun ; ou un enregistrement sans politique p= reconnue. Publiez un seul enregistrement TXT à _dmarc.<your domain> commençant par v=DMARC1; p=none; pour commencer la surveillance, ou retirez les enregistrements en trop, ou ajoutez la balise p=.
Indéterminé La requête DNS a échoué ou ne s’est pas terminée à temps. Réessayez dans un instant.

Sur les enregistrements multiples, la RFC 7489 est explicite : s’il reste plus d’un enregistrement DMARC, « la découverte de la politique s’arrête et le traitement DMARC n’est pas appliqué à ce message » (RFC 7489 §6.6.3).

Risqué ne veut pas dire non conforme. Gmail, Yahoo et Microsoft acceptent p=none pour leur exigence DMARC envers les expéditeurs de gros volumes (Gmail, Yahoo, Outlook.com). Le verdict Risqué désigne la faille qui subsiste : les emails qui usurpent votre domaine ne sont pas arrêtés. Le M3AAWG recommande p=reject lorsque c’est possible, et indique que tout enregistrement DMARC, même avec p=none, devrait inclure au minimum une balise rua (meilleures pratiques M3AAWG pour l’authentification des emails).

Qui agit : le responsable du DNS publie et modifie l’enregistrement. Passer de p=none à une politique contraignante est une décision à prendre avec les rapports agrégés en main, parce qu’ils montrent quels services envoient au nom de votre domaine. Déploiement de DMARC en détail traite du déploiement.

MX

Les enregistrements MX nomment les serveurs qui reçoivent les emails de votre domaine. Ils comptent pour un domaine d’envoi parce que les réponses et les rebonds y reviennent.

Verdict Ce que le diagnostic a trouvé Prochaine étape
Bon Un ou plusieurs enregistrements MX. Ou un MX nul accompagné de v=spf1 -all : un domaine correctement configuré pour n’envoyer ni recevoir aucun email. Aucune action.
Risqué Un MX nul, qui indique que le domaine n’accepte aucun email, sur un domaine qui envoie peut-être des emails. Si le domaine envoie des emails, remplacez le MX nul par un enregistrement MX qui pointe vers un serveur capable de recevoir les réponses et les rebonds.
Mauvais Aucun enregistrement MX. Ajoutez un enregistrement MX qui pointe vers le serveur de messagerie du domaine.
Indéterminé La requête DNS a échoué ou ne s’est pas terminée à temps. Réessayez dans un instant.

Le MX nul est défini dans la RFC 7505. Son §4.2 indique que les systèmes de messagerie « NE DEVRAIENT PAS publier d’enregistrement MX nul pour des domaines qu’ils utilisent dans des adresses RFC5321.MailFrom ou RFC5322.From », et qu’un domaine qui le fait « risque de voir ses emails rejetés ». Sans aucun enregistrement MX, SMTP se rabat sur l’enregistrement d’adresse du domaine lui-même, un « MX implicite » (RFC 5321 §5.1) : le diagnostic l’indique donc comme Mauvais plutôt que comme un serveur de messagerie désigné.

Qui agit : le responsable du DNS, avec la personne qui gère les boîtes de messagerie de votre domaine.

Listes de blocage

Une liste de blocage DNS publie des adresses IP dans le DNS pour que les serveurs de réception puissent les consulter au moment de décider s’ils acceptent un email (RFC 5782). Le diagnostic lit votre enregistrement SPF pour trouver les adresses que vous autorisez, puis recherche chacune d’elles sur les listes de blocage qu’il interroge.

Verdict Ce que le diagnostic a trouvé Prochaine étape
Bon Aucune inscription sur les listes de blocage vérifiées, pour les sources d’envoi vérifiées. Si certaines listes n’ont pas pu être interrogées, le résultat indique combien. Le même verdict apparaît quand le domaine n’autorise aucun serveur à envoyer. Aucune action pour les listes vérifiées. Relancez le diagnostic périodiquement, surtout après un changement de vos adresses d’envoi.
Mauvais Inscrit sur une ou plusieurs listes de blocage. Le résultat nomme chaque adresse et chaque liste. Résolvez d’abord la cause, puis suivez la procédure de retrait de liste de chaque liste de blocage. Un retrait de liste sans correction de la cause aboutit souvent à une nouvelle inscription.
Indéterminé Votre enregistrement SPF ne nomme aucune source d’envoi qui se résout en adresse, donc rien n’a pu être vérifié ; ou les requêtes ont échoué ou n’ont donné aucune réponse exploitable. Vérifiez directement les adresses IP depuis lesquelles vous envoyez réellement, avec l’outil de recherche propre à chaque liste de blocage.

Qui agit : si vous envoyez depuis les adresses IP partagées de votre plateforme, c’est à la plateforme de résoudre l’inscription. Google note que sur une adresse IP partagée, « l’activité des expéditeurs utilisant une adresse IP partagée a une incidence sur la réputation de tous ceux qui ont recours à cette adresse » (consignes de Google pour les expéditeurs d’emails). Si les adresses sont les vôtres, la cause se trouve généralement dans votre liste ou vos systèmes. Listes de blocage DNS et zones Spamhaus traite des causes et du retrait de liste.

Ce que ce diagnostic ne voit pas

Un résultat propre couvre ce que le diagnostic a pu lire. Voici ses limites, et où regarder à la place :

Ce qu’il ne voit pas Pourquoi Où regarder à la place
Les sélecteurs qu’il n’a pas essayés Les sélecteurs DKIM sont choisis par le signataire, pas listés dans le DNS. Demandez le sélecteur à votre plateforme et saisissez-le dans le champ « Sélecteur DKIM (facultatif) », ou lisez s= dans l’en-tête DKIM-Signature d’un vrai message.
Si vos emails sont signés, réussissent et sont alignés Le diagnostic ne lit que le DNS. Une clé publiée et un enregistrement SPF correct ne montrent pas ce qui arrive à un vrai message. Envoyez un message à une boîte que vous contrôlez et lisez son en-tête Authentication-Results.
Les adresses depuis lesquelles vous envoyez réellement Les recherches sur les listes de blocage utilisent les adresses autorisées par votre enregistrement SPF. Les expéditeurs nommés par include: ne sont pas développés, l’adresse d’un site web et les serveurs de réception d’un fournisseur de messagerie ne sont jamais vérifiés, et un diagnostic couvre un nombre limité d’adresses. Le résultat indique quand l’un de ces cas s’applique. Demandez à votre plateforme depuis quelles adresses IP partent vos emails, et vérifiez-les directement avec l’outil de recherche propre à chaque liste de blocage.
Toutes les listes de blocage Le diagnostic interroge un ensemble fixe de listes de blocage. Spamhaus n’est pas vérifié : son service gratuit est réservé à un usage non commercial, et l’outil n’a pas de licence commerciale. L’outil de recherche propre à chaque liste de blocage.
Votre réputation, vos plaintes et votre placement Ces données se trouvent chez les fournisseurs de messagerie, pas dans le DNS. Les rapports de rebonds et de plaintes de votre plateforme, et Google Postmaster Tools pour Gmail. Est-ce un problème de livraison ? montre comment les lire ensemble.

Voir aussi

Vérifier votre propre enregistrement

Le diagnostic gratuit lit ce que votre domaine publie dans le DNS.

Dans ce thème

Les 5 articles du thème Fondamentaux →