Vérification de la délivrabilité des e-mails

Avant la réputation, avant le contenu, les destinataires posent une seule question : ce domaine peut-il prouver que le courrier vient vraiment de lui ? Cette vérification lit la preuve — enregistrements MX, liste d’expéditeurs SPF (développée et comptée comme la compte un destinataire), politique DMARC sur _dmarc, et clés DKIM sous les sélecteurs courants — et renvoie des constats en langage clair, ordonnés comme un opérateur les corrigerait.

Vous voulez que ce soit surveillé en continu ? Surveillez-le gratuitement avec myeventwatch — alertes d’expiration et de panne, sans carte.

Ce que mesure la vérification

Le filtrage du spam commence par l’identité, parce que l’identité se vérifie en quelques millisecondes. Quand un courrier arrive en prétendant venir d’un domaine, le serveur de réception consulte les règles publiées de ce domaine. SPF nomme les serveurs autorisés à envoyer. DKIM offre une signature à vérifier contre une clé publiée. DMARC exige que le domaine From visible s’aligne sur l’une de ces deux preuves et fixe la sanction — aucune, quarantaine, rejet — pour le courrier qui n’en a aucune. La page appelle GET /api/check/email-auth sur le serveur de sysosx, qui lit les mêmes enregistrements via les analyseurs DNS qu’utilise le bilan de santé, et les traduit en constats : chaque protocole, chaque problème, une gravité, dans l’ordre où il vaut la peine de les corriger.

Deux des constats méritent un mot sur l’honnêteté, parce que ce sont deux endroits où les vérificateurs feignent souvent la précision. Le comptage des consultations SPF est réel : le vérificateur développe les chaînes include et redirect terme à terme selon les mêmes règles qu’applique un destinataire, donc le nombre qu’il rapporte est celui qu’un destinataire strict calculerait — y compris quand l’enregistrement a dérivé en silence au-dessus de la limite de dix consultations à mesure que les fournisseurs changeaient leurs propres enregistrements. Et le résultat DKIM est un sondage, pas un recensement : les clés sont publiées sous des noms de sélecteur que choisit le propriétaire, la vérification essaie les courants, et n’en trouver aucun ne prouve pas que DKIM est absent — une clé sous tout autre sélecteur est invisible de l’extérieur, et le résultat le dit clairement au lieu de déclarer un domaine non signé. Le seul test DKIM complet reste un vrai message et son en-tête Authentication-Results.

Comment lire un résultat

Commencez par les échecs ; ce sont les causes favorites du dossier spam. Pas de MX signifie que le domaine ne peut pas recevoir de courrier du tout. Pas de SPF, ou un enregistrement SPF se terminant par +all, signifie que n’importe qui peut prétendre être vous — le second est pire, parce que la prétention est officiellement permise. Plusieurs enregistrements SPF annulent en silence l’évaluation SPF tout entière. Un enregistrement DMARC manquant signifie que le courrier en échec n’a pas de sanction énoncée et, tout aussi coûteux, personne ne collecte les rapports agrégés qui montrent qui envoie en tant que votre domaine — ces rapports sont la façon dont les campagnes d’usurpation sont habituellement découvertes. Quand les rapports arrivent, ils arrivent en XML brut ; l’analyseur de rapports DMARC ouvre les fichiers .xml, .gz et .zip localement et les transforme en un tableau par source de qui a réussi, qui a échoué et quoi corriger. Les avertissements sont l’état intermédiaire : p=none est un bon endroit pour commencer DMARC et un mauvais endroit pour s’arrêter ; ~all est un mode de test, pas une destination. Prenez ensuite l’autre moitié du tableau : l’authentification prouve l’identité, tandis que le vérificateur de listes noires DNS mesure la réputation — lancez les deux, parce qu’un domaine parfaitement authentifié sur une IP listée finit quand même en spam, et une IP propre avec un SPF cassé aussi. Le guide qui relie le tout est pourquoi votre e-mail finit en spam.

Questions fréquentes

Que sont SPF, DKIM et DMARC, et comment s’articulent-ils ?

Ce sont trois réponses publiées dans le DNS à la question « ce courrier vient-il vraiment du domaine qu’il prétend ? ». SPF liste les serveurs autorisés à envoyer pour un domaine. DKIM permet à un domaine de signer cryptographiquement les messages, pour qu’un destinataire puisse vérifier la signature contre une clé publiée dans le DNS. DMARC les relie : il exige que le domaine expéditeur de l’en-tête From visible s’aligne sur le résultat SPF ou DKIM, et dit aux destinataires quoi faire — surveiller, mettre en quarantaine ou rejeter — quand aucun ne s’aligne. SPF sans DMARC est une suggestion non signée ; DMARC est ce qui transforme les deux autres en politique.

Mon courrier finit quand même en spam alors que les trois passent. Pourquoi ?

Parce que l’authentification est le ticket d’entrée, pas le plan de salle. Passer SPF, DKIM et DMARC signifie que les destinataires croient que le courrier est vraiment le vôtre — après cela, le placement dépend de la réputation et du contenu : inscriptions sur listes noires (vérifiez-les avec le vérificateur de listes noires de ce site), engagement des destinataires, taux de plaintes, schémas de volume d’envoi et le message lui-même. Les échecs d’authentification sont la cause corrigeable la plus courante du placement en spam, c’est pourquoi cette vérification vient en premier, mais un résultat propre ici et un placement persistant en spam signifient que le problème vit dans la réputation ou le contenu, pas dans l’identité.

La vérification dit qu’aucune clé DKIM n’a été trouvée. Cela signifie-t-il que mon domaine ne signe pas ?

Non — et le résultat le dit en ces termes. Les clés DKIM vivent sous des noms de sélecteur que choisit le propriétaire du domaine, et il n’y a aucun moyen d’énumérer les sélecteurs d’un domaine de l’extérieur. Cette vérification sonde les sélecteurs courants utilisés par les grands fournisseurs (default, google, selector1, selector2, mail, dkim, s1, s2, k1, mandrill et quelques autres). Une clé sous tout autre nom est invisible pour le sondage. Le test définitif est un vrai message : envoyez un courrier à une boîte que vous contrôlez et inspectez l’en-tête Authentication-Results, qui rapporte le sélecteur utilisé et si la signature a été vérifiée.

Pourquoi la vérification compte-t-elle les consultations SPF, et pourquoi la limite est-elle de 10 ?

Évaluer un enregistrement SPF peut exiger d’autres consultations DNS — chaque terme include, a, mx, ptr, exists et redirect en coûte une. La RFC 7208 plafonne le total à 10 ; au-delà, les destinataires renvoient une erreur permanente et le résultat SPF est annulé, ce qui peut être pire qu’un enregistrement modeste qui s’évalue proprement. Les enregistrements accumulent des consultations en silence à mesure que des fournisseurs s’ajoutent (chaque include apporte ses propres termes), donc un enregistrement légal à la configuration peut dériver au-dessus de la limite à mesure que les fournisseurs changent leurs enregistrements. Cette vérification développe l’enregistrement comme le ferait un destinataire et rapporte le compte réel, pour que la dérive soit visible avant qu’elle n’annule votre authentification.

Que dois-je corriger en premier si plusieurs constats sont des échecs ?

Dans l’ordre : plusieurs enregistrements SPF (fusionnez-les en un seul — tout ce qui suit n’est pas fiable tant que ce n’est pas corrigé), un enregistrement SPF manquant ou en +all (publiez la vraie liste d’expéditeurs, terminée par -all), un enregistrement DMARC manquant (commencez à p=none avec une adresse de rapport, pour voir qui envoie en tant que vous avant d’appliquer), puis relevez DMARC de p=none vers p=reject à mesure que les rapports arrivent propres. Les inscriptions sur listes noires, s’il y en a, sont un travail parallèle — corrigez leur cause et demandez le retrait pendant que les enregistrements sont réparés. Notre guide parcourt l’ordre avec le raisonnement : pourquoi votre e-mail finit en spam.