Score de sécurité e-mail
Vérifiez les contrôles publics qui protègent l’identité e-mail du domaine et obtenez vos correctifs.
Gratuit · Sans compte · Lecture seule du DNS public · En secondes
Teste DMARC, SPF, DKIM, MX, MTA-STS, TLS-RPT et BIMI. Il ne voit ni mots de passe, ni réglages privés du tenant, ni contenu des e-mails, ni réputation privée, ni placement en boîte.
Pas encore de score
Votre score s’affichera ici dès l’envoi d’un domaine.Qu’est-ce que le score de sécurité ?
Le score de sécurité évalue à un instant donné les contrôles DNS publics qui protègent l’identité e-mail d’un domaine. Il teste DMARC, SPF, DKIM, BIMI, MX, MTA-STS et TLS-RPT, puis en tire un score de 0 à 100 et une liste de correctifs ordonnée. Il ne voit ni mots de passe, ni réputation privée, ni placement en boîte.
Comment le score est calculé
L’outil lit les enregistrements publiés et juge chaque contrôle : présence, validité, réglage plus sûr. Un SPF, DKIM ou DMARC absent ou en échec est le plus urgent, car il touche l’authentification de l’expéditeur. Transport, routage et BIMI complètent le tableau du domaine public. Le rapport montre les preuves derrière le total, qui n’a jamais à être lu seul.
Le total et les tranches ci-dessous sont le modèle de priorités de Palisade, ni une certification sectorielle, ni un verdict de conformité, ni une prédiction de placement.
Exemple : du score au plan d’action
Un domaine obtient 42 : DMARC en simple suivi, un service d’envoi absent du SPF, pas de MTA-STS. L’utile n’est pas « 42 », c’est l’ordre des preuves à vérifier : trouver le vrai expéditeur, réparer l’alignement SPF ou DKIM de ce flux, lire les rapports DMARC avant l’application, puis ajouter la sécurité du transport sans couper le courrier entrant.
- Commencez par l’échec le plus grave du rapport.
- Confirmez-le dans la config du fournisseur ou un vrai en-tête d’e-mail.
- Changez un seul réglage et attendez son TTL DNS.
- Relancez le score et gardez les preuves avant/après.
Choisir le bon test ensuite
Utilisez le test DMARC, le test SPF ou le test DKIM pour réparer un enregistrement publié. Utilisez le test de délivrabilité pour des preuves tirées d’un e-mail réel envoyé en production. Un test public ne garantit pas la décision finale du destinataire.
Références techniques
Les tests suivent les normes publiques de SPF, DKIM, DMARC, MTA-STS et rapports TLS. Les constats BIMI suivent les spécifications publiées par le groupe Authenticated Mark Certificates Working Group.
Base de connaissances e-mail
Qu’est-ce qu’un bon score de sécurité ?
Un score de 80 ou plus est « très bon » sur l’échelle de 0 à 100 de cet outil : SPF, DKIM et DMARC sont en général bien configurés. De 60 à 79, c’est « bon » avec au moins une faille à combler ; de 35 à 59, la protection est faible, et sous 35 la situation est critique. Un domaine qui n’a jamais configuré DMARC tombe souvent dans les tranches basses au premier test : un score de départ bas est normal. Le rapport liste les correctifs exacts, classés par impact.
Comment le score de sécurité est-il calculé ?
L’outil lit les enregistrements DNS publics de votre domaine et lance des tests sur DMARC, SPF, DKIM, BIMI, MX, MTA-STS et TLS-RPT. Chacun cherche un enregistrement valide et une configuration sûre, et chaque constat compte dans le total sur 100. Les enregistrements d’authentification absents ou en échec (SPF, DKIM et la politique DMARC) pèsent le plus, et le rapport montre les correctifs qui font le plus monter le score.
Comment savoir si mon e-mail est sûr ?
Saisissez votre domaine dans l’outil ci-dessus. Il examine les enregistrements DNS publics qui régissent l’authentification (SPF, DKIM, DMARC), la sécurité du transport (MTA-STS, TLS-RPT), le routage (MX) et le logo de marque (BIMI), puis donne un score de 0 à 100 et les problèmes trouvés. C’est le volet domaine de la sécurité e-mail : quelqu’un peut-il se faire passer pour vous de façon crédible ? Sécuriser une boîte est un autre sujet : mots de passe solides et double authentification.
Comment améliorer mon score de sécurité ?
Suivez le rapport du constat le plus grave au moins grave. Publiez un SPF valide sous la limite des 10 requêtes DNS, activez la signature DKIM pour chaque service qui envoie en votre nom, puis publiez un DMARC et passez peu à peu de p=none à p=quarantine et p=reject à mesure que les vrais expéditeurs s’alignent. MTA-STS, TLS-RPT et BIMI ajoutent des points. Relancez le test après chaque changement DNS pour confirmer.
Pourquoi tester un domaine ?
Vérifier la sécurité d’un domaine protège contre le phishing, l’usurpation de domaine et les accès non autorisés. Des tests réguliers révèlent les failles, assurent le respect des bonnes pratiques et préservent l’intégrité et la réputation du domaine. C’est essentiel pour protéger les données sensibles, mais aussi pour garder la confiance des utilisateurs dans leurs échanges avec le domaine.
Que comprend un audit de sécurité e-mail ?
Un audit de sécurité e-mail mesure la résistance d’un domaine au spoofing, au phishing et à l’interception. Il couvre l’authentification (SPF, DKIM et la politique DMARC), le chiffrement du transport (MTA-STS, TLS-RPT), les serveurs de messagerie (MX) et la protection de la marque (BIMI). Cet outil fait automatiquement l’audit du domaine depuis le DNS public, en quelques secondes. Un audit complet de l’organisation ajouterait ce qu’aucun scan DNS ne voit : contrôle d’accès aux boîtes, sensibilisation des utilisateurs.
Que mesure un score de risque ?
Un score de risque e-mail estime l’exposition d’un domaine aux attaques par e-mail, selon que SPF, DKIM et DMARC sont absents, mal configurés ou non appliqués. Le score de 0 à 100 de cette page est une mesure de ce type, au niveau du domaine. L’expression sert aussi en lutte contre la fraude, où l’on note des adresses e-mail à l’inscription : une autre mesure. Pour l’exposition de votre domaine au spoofing, suivez le score du domaine.
Ce test de sécurité est-il gratuit ?
Oui. Le test est gratuit, en ligne, en quelques secondes et sans compte : saisissez un domaine, vous obtenez le score et les constats complets. Relancez-le autant que vous voulez, par exemple après chaque correctif DNS. Il lit seulement le DNS public et ne change rien à votre domaine.
Puis-je tester n’importe quel domaine ?
Oui. Le test fonctionne sur tout domaine, car il lit le DNS public : inutile de posséder ou vérifier le domaine. Les Équipes IT testent souvent leurs domaines et sous-domaines, les MSP ceux de leurs clients et prospects avant de parler sécurité e-mail. Tester un domaine ne le modifie en rien.
À quelle fréquence lancer un test de sécurité ?
Relancez le test après tout changement de DNS ou d’outils d’envoi : nouvelle plateforme marketing, CRM ou helpdesk qui envoie en votre nom, migration DNS, mise à jour de la politique DMARC. Pour un domaine stable, un test par trimestre est un minimum. Mais un test n’est qu’un instantané. Services d’envoi et enregistrements DNS dérivent : les équipes sérieuses sur DMARC suivent les rapports agrégés en continu au lieu de scans ponctuels.
Une référence complète des termes techniques et balises de ces protocoles d’authentification e-mail et de marque.
- vVersion
- La balise Version est indispensable dans un DMARC et doit valoir strictement « DMARC1 ». Si la valeur est incorrecte ou la balise absente, l’enregistrement DMARC n’est pas valide et il est ignoré.
- pPolitique DMARC
- La balise de politique DMARC accepte trois valeurs pour le courrier qui échoue : none ne demande aucune application, quarantine un traitement suspect, reject le rejet. Les destinataires décident en dernier et peuvent filtrer ou rejeter via d’autres contrôles en p=none. Les rapports agrégés se demandent à part, via la balise rua.
- ruaDestination des rapports agrégés
- La destination des rapports agrégés est une URI « mailto: », que les fournisseurs de messagerie (ESP) utilisent pour envoyer les rapports agrégés. La balise n’est pas obligatoire, mais sans elle vous ne recevez aucun rapport.
- rufDestination forensique
- La destination des rapports forensiques (d’échec) est une URI « mailto: », que les fournisseurs de messagerie (ESP) utilisent pour livrer les rapports d’échec. La balise n’est pas obligatoire, mais sans elle vous ne recevez aucun rapport.
- spSous-domaines
- Par défaut, la politique des sous-domaines hérite de la balise de politique du domaine principal (p=), décrite plus haut, sauf mention contraire. Comme pour le domaine, les valeurs possibles sont « none », « quarantine » ou « reject ». Cette option reste toutefois peu utilisée en pratique.
- adkimAlignement DKIM
- Cette balise fixe l’alignement de la signature DKIM, c’est-à-dire la correspondance entre le domaine DKIM et le domaine d’origine du « Header From ». Valeurs possibles : « r » (relaxed) et « s » (strict). Par défaut, « r » accepte une correspondance partielle entre ces domaines, tandis que « s » exige qu’ils soient identiques.
- aspfAlignement SPF
- Cette balise fixe l’alignement SPF, c’est-à-dire la compatibilité entre le domaine SPF (l’expéditeur) et le domaine du « Header From ». Deux valeurs : « r » (relaxed) et « s » (strict). Par défaut, « r » tolère une correspondance partielle entre les domaines. À l’inverse, « s » exige une correspondance exacte des domaines.
- foOptions forensiques
- Les options des rapports forensiques sont « 0 », « 1 », « d » et « s ». Par défaut, « 0 » déclenche un rapport seulement quand les alignements SPF et DKIM échouent tous deux. « 1 » en déclenche un dès que SPF ou DKIM ne passe pas. « d » produit un rapport pour les échecs de validation DKIM, « s » pour les problèmes SPF. Pour recevoir ces rapports forensiques, il faut renseigner la balise « ruf ».
- rfFormat des rapports
- Le format des rapports d’échec peut valoir « afrf » ou « iodef », les deux seules options autorisées.
- pctPourcentage (historique)
- L’ancienne balise Pourcentage demandait d’appliquer quarantine ou reject à une partie seulement du courrier en échec DMARC. La RFC 9989 a retiré pct, l’application partielle étant mise en œuvre de façon inégale. Les nouveaux enregistrements l’omettent et échelonnent via les rapports agrégés, des politiques entières et des sous-domaines à faible volume.
- riFréquence des rapports
- L’intervalle des rapports indique, en secondes, la fréquence des rapports XML. La valeur standard est 86400 secondes, soit un rapport par jour. Notez toutefois que, quel que soit l’intervalle indiqué, les fournisseurs d’accès (FAI) envoient en général ces rapports selon leur propre calendrier, le plus souvent une fois par jour également.