Réputation d’URL et de site web
Analysez un lien ou un site (alertes phishing et malware) avant tout clic.
Définir la réputation d’URL
La réputation d’URL est la confiance que les systèmes de sécurité accordent à une adresse web selon ce qui est enregistré sur elle : malware diffusé, page de phishing hébergée, présence dans du spam. Navigateurs, messageries et filtres s’en servent pour autoriser un lien, avertir ou le bloquer. Le même scan sert de test de réputation de site : saisissez l’adresse d’accueil pour voir comment ces sources jugent le site.
Lire votre résultat
| Verdict | Signification | Que faire |
|---|---|---|
| Listé | L’hôte ou l’IP de son serveur web figure sur au moins une blocklist de menaces qui a répondu. | Ouvrez la preuve de chaque source, corrigez la compromission, puis suivez la procédure de l’opérateur. |
| Suspect | Rien n’est listé, mais l’URL a des signaux structurels : IP brute, punycode, identifiants intégrés ou pas de HTTPS. | Lisez les signaux du résultat et confirmez que la destination est bien celle annoncée avant de faire confiance. |
| Sain | Aucune source ayant répondu n’enregistre l’adresse, et l’URL n’a aucun signal d’alerte structurel. | Rien, mais une URL malveillante toute neuve n’a pas d’historique : sain ne prouve pas la sûreté. |
| Sain, sources indisponibles | Les blocklists de domaines n’ont pas répondu, mais l’IP du serveur du site est saine. | Preuve partielle : relancez plus tard si la réponse compte. |
| Inconnu | Aucune source n’a répondu : le scan n’a aucune preuve dans un sens ou l’autre. | Traitez-le comme inconnu, pas sain, et réessayez dans un instant. |
| URL non valide | L’adresse est illisible. Un domaine seul est accepté et passé en https:// automatiquement. | Ajoutez le schéma, par exemple https://example.com/page. |
Ce que ce scan peut prouver
Le scan prouve ce que les sources publiques de menaces enregistrent sur une adresse, et si l’URL porte l’un des quatre signaux structurels. Ce sont deux preuves différentes, que le résultat sépare exprès : un listage est un fait passé, un signal d’alerte une propriété du lien que vous avez sous les yeux.
Il ne peut pas prouver qu’un lien est sûr. Les blocklists regardent le passé, et les URL d’une campagne de phishing ciblée ont souvent quelques heures et ne figurent nulle part. Un verdict sain est une absence de preuve enregistrée : vraiment utile, mais vraiment pas synonyme de fiable.
Empêchez l’envoi de liens en votre nom
La plupart des liens à tester arrivent par e-mail, et ils convainquent parce que le message semble venir d’une marque de confiance. Publier DMARC en mode appliqué empêche d’emblée les attaquants d’envoyer au nom de votre domaine. Palisade transforme les rapports agrégés DMARC en flux priorisé : identifiez chaque expéditeur du domaine, analysez les échecs d’alignement, revoyez les changements proposés et menez chaque domaine vers l’application, preuves à l’appui.
Pour les MSP, c’est multi-tenant : chaque domaine client testé, corrigé et appliqué depuis une console, avec un prix par domaine client dont le prix unitaire baisse à l’échelle, sans mesurer le volume d’e-mails.
On vous a envoyé un lien suspect ? Le test de lien phishing vous dit simplement s’il est sûr de cliquer, et quoi faire si c’est déjà fait.
Tester un lien →Tests de réputation liés
Le logiciel DMARC qui fait le travail
Palisade transforme les rapports DMARC en tâches priorisées (expéditeurs, alignement) : validez chaque changement et menez vos domaines vers l’application depuis une console.
Audit de domaine gratuit, sans carte. Une carte lance l’essai de 15 jours.
Base de connaissances e-mail
Comment tester la réputation d’un site ?
Saisissez l’adresse du site et lancez le scan. Le test de site fait le même scan qu’un test d’URL, mais sur l’adresse racine : l’hôte est testé sur les blocklists de menaces des messageries et filtres de sécurité, ainsi que l’IP de son serveur web. Un domaine seul est traité comme une adresse https:// automatiquement. Pour la confiance qu’accordent les messageries à un domaine d’envoi, utilisez plutôt le test de réputation de domaine.
Que vérifie vraiment ce scan ?
Deux couches tournent toujours. D’abord la structure de l’URL, pour quatre signaux : une IP brute au lieu d’un nom d’hôte, un hôte en punycode (xn--) qui peut masquer des caractères sosies, des identifiants avant un @, et l’absence de HTTPS. Ensuite l’hôte sur les blocklists de menaces de domaines, et l’IP du serveur web sur les blocklists IP. Une troisième couche, la base malware URLhaus d’abuse.ch, ne tourne qu’avec une clé abuse.ch et sinon s’indique non testée.
Que veut dire le verdict « Suspect » ?
Aucune blocklist ne signale l’adresse, mais l’URL porte au moins un signal structurel, comme un hôte en punycode ou des identifiants intégrés. Cela mérite un examen : une page de phishing toute neuve n’est souvent listée nulle part, car le listage suit l’attaque. Suspect invite à examiner, ce n’est pas un verdict malveillant confirmé.
Un résultat sain garantit-il qu’un lien est sûr ?
Non, et c’est la limite la plus importante. Les blocklists regardent le passé : une URL créée il y a une heure pour une campagne ciblée n’a pas d’historique et ressortira saine. Sain veut dire que rien de connu n’est enregistré sur l’adresse, pas que la destination est fiable. Jugez un lien imprévu sur sa provenance et ce qu’il vous demande, pas seulement sur un scan.
Pourquoi URLhaus indique-t-il « non testé » ?
La recherche URLhaus exige une clé d’authentification abuse.ch, et aucune n’est configurée sur ce site pour l’instant : la carte s’indique non testée au lieu d’annoncer un résultat sain. Traitez-la comme inconnue. Les couches structure et blocklist tournent quand même, et le verdict en découle.
Ce test donne-t-il un score de réputation ?
Non, et c’est voulu. Plusieurs outils renvoient un seul chiffre, qui cache son calcul. Celui-ci renvoie un verdict et ses preuves : quelles sources ont répondu, lesquelles ont enregistré quelque chose, et quels signaux structurels porte l’URL. Un chiffre ne dit pas que deux blocklists sur trois n’ont jamais répondu, et cela change la valeur du résultat.
Réputation d’URL ou réputation de domaine ?
Elles répondent à des questions différentes. La réputation d’URL demande si une adresse web est liée à du malware ou du phishing : une question de sécurité sur un lien. La réputation de domaine demande comment les messageries traitent les e-mails d’un domaine : une question de délivrabilité sur un expéditeur. Un domaine peut être sain côté sécurité et mal réputé à l’envoi, et inversement.
On m’a envoyé un lien : ce test ou le test phishing ?
Le test de lien phishing. Il fait des tests comparables mais répond simplement au destinataire : puis-je cliquer, et que faire si c’est déjà fait. Cette page sert à autre chose : tester un site que vous gérez, vers lequel vous pointez ou sur lequel vous enquêtez.
Pourquoi les messageries testent les liens ?
Parce que le lien est la charge habituelle. Un message peut passer toute l’authentification et porter une URL vers une page de vol d’identifiants : les messageries notent donc les liens à part de l’expéditeur. Un site compromis peut ainsi nuire en silence à la délivrabilité de quiconque pointe vers lui.
Mon site était signalé et je l’ai nettoyé. Et ensuite ?
Relancez le scan pour voir quelles sources le listent encore, puis suivez la procédure de retrait de chaque opérateur. Le retrait leur revient, un scan ne peut pas l’accorder. Corrigez d’abord la cause : un retrait sur un site encore compromis ne dure pas.
Chaque balise et mécanisme de DMARC, SPF et DKIM, expliqués au même endroit.
DMARC
- 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.
SPF
- v
- La balise de version doit valoir « spf1 », exclusivement. Une version fausse ou absente fait ignorer l’enregistrement SPF.
- ip4
- Cette balise liste les adresses IPv4 autorisées à envoyer pour le domaine.
- ip6
- Cette balise indique les adresses IPv6 autorisées à envoyer au nom du domaine.
- a
- La balise A valide l’expéditeur via l’adresse IP du domaine, le domaine courant par défaut s’il n’est pas précisé.
- mx
- La balise MX valide l’enregistrement MX du serveur mail, le domaine courant par défaut s’il n’est pas précisé.
- ptr
- La balise PTR lance un contrôle PTR des noms d’hôte des IP clientes, déconseillé par la RFC 7208 (trop de requêtes DNS).
- exists
- La balise exists vérifie la présence d’un enregistrement A sur le domaine indiqué.
- include
- La balise include est essentielle à un SPF exact : elle confirme aux destinataires que chaque domaine ou sous-domaine listé envoie légitimement.
- all
- La balise all est obligatoire, en fin d’enregistrement SPF : ses qualificateurs (~, +, -, ?) disent aux destinataires comment traiter les sources non autorisées.
DKIM
- v
- La balise de version indique la version de DKIM, qui doit toujours valoir 1.
- p
- La balise de clé publique, une chaîne créée à la configuration DKIM, ne doit pas être vide pour rester valide.
- t
- Cette balise liste des indicateurs séparés par deux-points ; seuls « y » et « s » sont définis, les autres doivent être ignorés.
- s
- Cette balise précise les types de service concernés. Les serveurs destinataires ignorent les types absents ou inconnus.
- h
- Cette balise indique les algorithmes de hachage permis (tous par défaut). Les destinataires ignorent ceux qu’ils ne connaissent pas ; l’expéditeur fixe la liste.
- n
- Cette balise est un champ de note facultatif pour les administrateurs, à n’utiliser qu’au besoin.