Quand un client ouvre un billet avec « notre courriel va dans le pourriel » ou « Microsoft rejette nos messages », le premier réflexe est de demander quel message, quel expéditeur, quel destinataire — et la réponse est généralement « tous ». Avant de plonger dans les en-têtes, vous voulez une vue d’un écran de la posture d’authentification du domaine : est-ce que les enregistrements de base existent, sont-ils syntaxiquement valides, et est-ce que quelque chose est manifestement cassé. C’est le rôle de l’Email DNS Health Check de PortJar.
Ce que l’outil fait
Il lance six tests indépendants contre le domaine et retourne chacun en pass/fail avec détail. L’ensemble est opinioné : présence et forme des MX, présence et validité de SPF, politique DMARC et champs d’alignement, disponibilité de la politique MTA-STS, point de rapport TLS-RPT, et cohérence des enregistrements les uns par rapport aux autres. Chaque test est superficiel — c’est un scan de posture, pas un audit médico-légal — mais ensemble ils répondent à « ce domaine est-il configuré pour envoyer et recevoir du courriel comme un expéditeur de 2026 devrait l’être ».
L’outil ne tente délibérément pas d’être l’analyseur en profondeur. Quand le test SPF signale un problème, vous basculez vers le SPF Lookup & Parser de PortJar pour voir la décomposition mécanisme par mécanisme. Quand DMARC demande de l’interprétation, l’analyseur DMARC dédié est à un clic. Le rôle du Health Check, c’est de vous dire laquelle des six couches investiguer ensuite.
Comment l’utiliser
Ouvrez portjar.com/tools/email-health, entrez le domaine, et lisez le résultat ligne par ligne. Chaque ligne est indépendante : un MX vert avec un MTA-STS rouge est une forme réelle et commune, pas une contradiction. Passez l’URL à un client qui veut voir « toutes les vérifications que vous feriez » ; la sortie est assez simple pour qu’une personne non technique la suive.
Lancez-le au début de chaque billet de livrabilité. Ça prend moins de cinq secondes et ça épargne souvent les vingt minutes suivantes de devinette sur l’emplacement du problème.
Quand vous y recourriez
- Un client signale que le courriel rebondit ou tombe dans le pourriel et vous avez besoin d’un triage rapide avant de décider si la faille est dans l’authentification, le routage ou le contenu. Le guide de dépannage « courriel allant dans le pourriel » de PortJar traite ça comme la première étape de la liste.
- Prise en charge d’un nouveau domaine sur une plateforme de courriel infogérée et désir d’une vérification préalable que MX, SPF et DMARC sont publiables avant de basculer les MX.
- Après un changement de fournisseur SaaS — Mailchimp, HubSpot, Postmark — pour confirmer que la déclaration include du nouvel expéditeur est entrée dans SPF et que l’alignement DMARC n’a pas cassé.
- Revue de posture périodique sur une flotte de domaines, où vous voulez repérer celui qui a discrètement perdu son enregistrement DMARC pendant une migration de registraire.
- Investigation d’une exigence MTA-STS ou TLS-RPT demandée par un client ou un régulateur — le Health Check vous dit en quelques secondes si l’un ou l’autre est publié.
Quoi faire de la sortie
Les six au vert, c’est l’objectif, et c’est atteignable sur chaque domaine qu’on gère. Tout ce qui est rouge demande un suivi mais l’urgence varie.
Un MX rouge sur un domaine qui devrait recevoir du courriel, c’est la priorité maximale — ça veut dire que le domaine n’annonce aucun serveur de courriel, et la livraison entrante échouera carrément. Confirmez avec MX Diagnostics de PortJar que les enregistrements sous-jacents existent et résolvent.
Un SPF rouge prend généralement l’une de trois formes : aucun enregistrement SPF du tout (publiez-en un), un SPF avec une syntaxe cassée (corrigez la coquille), ou un SPF qui dépasse la limite des 10 requêtes DNS (aplatissez-le ou divisez les expéditeurs). L’analyseur SPF par outil vous dira laquelle.
Un DMARC rouge sur un domaine qui a SPF et DKIM mais pas de DMARC veut dire que le domaine a de l’authentification mais pas de politique — les destinataires se rabattent sur leurs propres heuristiques. Publier au minimum p=none avec une boîte rua ne coûte rien et donne de la visibilité.
Un MTA-STS ou TLS-RPT rouge, c’est la forme la plus courante et la priorité la plus basse. Ce sont des signaux récents — ils relèvent la réputation en boîte de réception et aident à l’application TLS, mais leur absence cause rarement un incident de livrabilité. Planifiez leur ajout un jour calme, pas en plein feu.
Un résultat tout au vert sur un domaine qui a quand même des problèmes de livrabilité veut dire que le problème n’est pas dans le DNS — il est dans la réputation d’IP, le contenu, le volume d’envoi, l’hygiène de liste, ou l’alignement de signature DKIM sur les messages réels. Passez au diagnostic au niveau du message.
Stack Harbor lance l’Email DNS Health Check sur chaque domaine pris en charge sur une plateforme de courriel infogérée dans le cadre de la gestion de déploiement.