Ce que vérifie la recherche MX
L'outil lit les enregistrements MX du domaine et liste chaque serveur de messagerie avec sa valeur de préférence. Lorsque les noms d'hôtes correspondent au schéma d'un fournisseur bien connu, il nomme le fournisseur probable. Il récupère ensuite la politique SPF dans les enregistrements TXT du domaine et la politique DMARC sous _dmarc, analyse les deux et présente ses constats.
Tout ici est lu dans le DNS public. L'outil ne se connecte pas à votre serveur de messagerie, n'envoie pas de messages de test et ne regarde dans aucune boîte aux lettres.
Lire les enregistrements MX
Les serveurs expéditeurs essaient d'abord le MX au plus petit numéro de préférence et ne passent aux numéros supérieurs qu'en cas d'échec. Des numéros égaux se partagent la charge. La cible d'un MX doit être un nom d'hôte qui se résout en adresse ; ce ne doit être ni une adresse IP ni un CNAME. Si un domaine n'a aucun enregistrement MX, les expéditeurs se rabattent sur son enregistrement A ou AAAA, ce qui est rarement voulu.
Un domaine qui ne doit jamais recevoir d'e-mails peut publier un MX nul : un seul enregistrement de préférence 0 dont la cible est un simple point. Cela indique aux expéditeurs d'échouer immédiatement au lieu de réessayer pendant des jours.
SPF : qui peut envoyer pour le domaine
SPF est un enregistrement TXT commençant par v=spf1, qui liste les serveurs autorisés à utiliser le domaine dans l'adresse d'expéditeur de l'enveloppe. Les constats recherchent les erreurs qui le cassent en pratique : plusieurs enregistrements SPF, ce qui fait échouer l'évaluation d'emblée ; des mécanismes qui exigent plus de dix requêtes DNS une fois les include suivis ; le mécanisme ptr, obsolète ; et une fin en +all, qui autorise Internet tout entier.
Une politique qui se termine par ~all demande aux destinataires de traiter les autres sources avec méfiance, et -all leur demande de les rejeter. L'une comme l'autre est raisonnable en combinaison avec DMARC. Un enregistrement avec ?all, ou sans mécanisme all, n'apporte presque aucune protection.
DMARC : politique et rapports
DMARC relie SPF et DKIM à l'adresse que les gens voient réellement dans l'en-tête From. Un message passe lorsque SPF ou DKIM passe et que le domaine authentifié est aligné sur le domaine du From. L'enregistrement indique ce que les destinataires doivent faire des échecs (none, quarantine ou reject) et où envoyer les rapports agrégés.
p=none est le bon point de départ, car il permet de collecter des rapports sans affecter la distribution. Ce n'est pas une destination. Un domaine qui reste indéfiniment en p=none a de la visibilité, mais aucune protection contre l'usurpation. L'outil affiche la politique, la politique des sous-domaines si elle est définie, la valeur pct et les adresses de rapport.
Pourquoi DKIM exige un sélecteur
Les clés publiques DKIM sont publiées sous selecteur._domainkey.example.com, et le sélecteur est une étiquette arbitraire choisie par le système d'envoi. Un domaine peut avoir de nombreux sélecteurs et le DNS n'offre aucun moyen de les lister ; aucun outil ne peut donc découvrir une clé DKIM à partir du seul nom de domaine. Vous trouverez le sélecteur dans l'en-tête DKIM-Signature d'un message envoyé depuis le domaine, dans la balise s=, et pourrez ensuite interroger ce nom avec une recherche DNS.
Ce que ces enregistrements ne peuvent pas prouver
Des enregistrements MX, SPF, DKIM et DMARC corrects sont nécessaires à une distribution fiable, mais ne garantissent pas qu'un message arrive en boîte de réception. Les fournisseurs de messagerie pèsent aussi la réputation de l'expéditeur, le taux de plaintes, le contenu et l'engagement des destinataires, autant d'éléments invisibles dans le DNS. De même, une configuration propre ne prouve pas que les e-mails circulent. Elle montre que la politique publiée est cohérente, et c'est la partie que vous pouvez corriger côté DNS.