Un hôpital suisse peut-il être usurpé par e-mail ? Trois enregistrements publiés dans la zone DNS du domaine permettent aux serveurs destinataires de démasquer la supercherie : SPF, DMARC et DNSSEC. Un e-mail qui semble provenir d’un hôpital — fausse facture, faux rappel de rendez-vous — gagne une confiance immédiate, ce qui en fait un vecteur de fraude particulièrement efficace.
Analyses cybersécurité passives : Aucun scan de vulnérabilités, aucune tentative d’accès ni d’exploitation. Les contrôles se limitent à la lecture d’informations publiques que tout navigateur ou serveur de messagerie reçoit lors d’une connexion ordinaire au site.
Chargement de la carte…
Au 1er octobre 2026, 47 sites des hôpitaux suisses évalués (Sécurité e-mail) : 1 appliquent les bonnes pratiques (Enregistrements DNS publics qui empêchent d'envoyer un courriel en se faisant passer pour cette entité).
- Solide1(2%)
- Partiel8(17%)
- À renforcer38(81%)
Ces chiffres disent où en est le périmètre aujourd'hui. L'analyse consolidée montre leur évolution mois après mois et le plan d'action classé par gravité : voir l'analyse consolidée
Historique des évolutions
| Période | Solide | Partiel | À renforcer | Non évalué | Total |
|---|---|---|---|---|---|
| août 2026 | 1 | 28 | 18 | 0 | 47 |
| septembre 2026 | 1 | 8 | 38 | 0 | 47 |
| octobre 2026 | 1 | 8 | 38 | 0 | 47 |
Catalogue des contrôles
Voici le détail de chaque contrôle, regroupé par famille : fichier security.txt, en-têtes HTTP, enregistrements DNS. Une question, ou besoin d'exclure un domaine ? Passez par le formulaire de contact.
Sécurité e-mail
Enregistrements DNS publics qui empêchent d'envoyer un courriel en se faisant passer pour cette entité.
Guide complet : SPF, DKIM, DMARC : le guide complet de la sécurité des emails
EMAIL-SPFExpéditeurs de courrier autorisés (SPF)CritiqueDéclare quels serveurs ont le droit d'envoyer du courrier au nom du domaine. Sans lui, n'importe qui peut se faire passer pour l'entité auprès des administrés.
Publier, dans la zone DNS du domaine (chez l'hébergeur qui la gère), un enregistrement TXT « v=spf1 … -all » listant les serveurs autorisés, terminé par -all.
- Aucun enregistrement SPF n'est publié pour ce domaine.
- Deux enregistrements SPF (ou plus) sont publiés en même temps : selon la RFC 7208, les serveurs destinataires doivent alors ignorer complètement la vérification (permerror), comme s'il n'y en avait aucun.
- L'enregistrement publié se termine par « +all », qui autorise explicitement n'importe quel serveur à envoyer du courrier au nom du domaine – une autorisation générale, pas une protection incomplète.
- L'enregistrement publié se termine par « ~all » (marquage) plutôt que « -all » (rejet) : purement indicatif, un serveur destinataire a le droit de délivrer quand même le courriel frauduleux normalement. Le domaine reste donc usurpable en pratique.
- L'enregistrement publié se termine par « ?all » : ce qualificatif dit explicitement aux serveurs destinataires de ne tirer aucune conclusion d'un échec de vérification – ni marquage, ni rejet. Un cran en dessous de « ~all », qui au moins signale l'anomalie.
- L'enregistrement publié ne se termine ni par « -all », « ~all » ni « ?all » (et n'utilise pas non plus « redirect= ») : il ne restreint donc aucun expéditeur.
EMAIL-DMARCPolitique appliquée aux courriels frauduleux (DMARC)CritiqueIndique aux serveurs destinataires quoi faire des courriels qui échouent aux vérifications, et permet de recevoir des rapports sur les tentatives d'usurpation.
Publier, dans la zone DNS du domaine (chez l'hébergeur qui la gère), un enregistrement TXT sur _dmarc.<domaine>, en commençant par « v=DMARC1; p=none; rua=mailto:… » puis en durcissant vers p=reject.
- Aucun enregistrement DMARC n'est publié sur _dmarc.<domaine>.
- Deux enregistrements DMARC (ou plus) sont publiés en même temps : selon la RFC 7489, les destinataires doivent alors ignorer la politique (permerror), comme s'il n'y en avait aucune.
- Un enregistrement DMARC existe, mais sans balise « p= » exploitable (none, quarantine ou reject) : les destinataires ne savent pas quoi faire des courriels non conformes.
- La politique publiée est « p=none », mais sans balise « rua= » : aucun rapport n'est jamais envoyé au domaine, qui n'a donc aucun moyen de savoir quand des tentatives d'usurpation ont lieu, ni quand durcir vers « p=quarantine » ou « p=reject ». Cette étape de surveillance ne surveille en réalité rien.
- La politique publiée est « p=none » : c'est l'étape de surveillance recommandée avant de durcir, mais elle ne bloque ni ne marque encore aucun courriel frauduleux.
- La politique publiée est « p=quarantine » : les courriels frauduleux sont déviés vers les indésirables plutôt que rejetés – une réduction réelle du risque, mais le message atteint quand même la boîte du destinataire et reste à sa merci.
- La politique publiée est « p=quarantine », et sans balise « rua= » : les courriels frauduleux sont déviés plutôt que rejetés, ET le domaine ne reçoit aucun rapport pour vérifier l'effet réel de cette politique avant de durcir vers « p=reject ».
- La politique « p=reject » n'est appliquée qu'à une fraction des courriels frauduleux (balise « pct= » inférieure à 100) : le reste retombe sur une politique plus faible, comme si aucun rejet n'était configuré pour cette part-là.
- Le domaine lui-même est bien protégé (« p=reject »), mais ses sous-domaines le sont moins (balise « sp= » plus faible) : un courriel usurpant un sous-domaine (ex. newsletter.<domaine>) peut échapper au rejet.
- La politique publiée est « p=reject » et pleinement appliquée (pct=100, sous-domaines compris), mais sans balise « rua= » : le domaine ne reçoit jamais aucun rapport, et ne peut donc ni vérifier que sa politique se comporte comme prévu, ni détecter une tentative d'usurpation en cours.
EMAIL-DNSSECRéponses DNS signées et vérifiables (DNSSEC)MajeurSigne les réponses DNS du domaine, ce qui empêche de rediriger silencieusement les visiteurs ou le courrier vers un serveur illégitime.
Activer DNSSEC chez l'hébergeur de la zone DNS (souvent une simple case à cocher), puis publier l'enregistrement DS chez le registraire.
Guide nic.ch – DNSSECEMAIL-MTA-STSChiffrement SMTP forcé en transit (MTA-STS)MajeurSans MTA-STS, un attaquant en position d'interception peut forcer un envoi de courrier en clair (attaque de rétrogradation) entre les serveurs de messagerie, malgré un chiffrement disponible.
Publier un enregistrement TXT sur _mta-sts.<domaine> (« v=STSv1; id=… »), puis publier le fichier de politique sur https://mta-sts.<domaine>/.well-known/mta-sts.txt avec « mode: enforce » une fois vérifié.
Spécification RFC 8461 (MTA-STS)EMAIL-CAAAutorités de certification restreintes (CAA)MineurSans enregistrement CAA, n'importe quelle autorité de certification publique peut émettre un certificat pour ce domaine – y compris une autorité compromise ou trompée par une usurpation d'identité.
Publier, dans la zone DNS du domaine, un enregistrement CAA listant la ou les autorités autorisées (ex. « 0 issue "letsencrypt.org" »).
PKI Consortium – Certification Authority AuthorizationEMAIL-TLSRPTRapports d'échec de chiffrement SMTP (TLS-RPT)MineurSans TLS-RPT, le domaine ne reçoit aucun rapport quand un autre serveur échoue à chiffrer un courriel qui lui est destiné – une dégradation de la messagerie entrante peut passer inaperçue indéfiniment.
Publier un enregistrement TXT sur _smtp._tls.<domaine> (« v=TLSRPTv1; rua=mailto:… »).
Spécification RFC 8460 (TLS-RPT)Questions fréquentes
Ces analyses de cybersécurité sont-elles intrusives ?
Non. Tout ce qui est mesuré ici est public et déjà lu par n’importe quel visiteur ou serveur de messagerie : les en-têtes renvoyés par la page d’accueil, des enregistrements DNS interrogés à chaque courriel reçu, et le fichier security.txt là où il est publié. Aucun test d’intrusion, aucune recherche de vulnérabilité, aucune tentative d’authentification, aucun formulaire soumis. Une seule requête par domaine et par passage sert toutes les familles de contrôles à la fois, et le User-Agent des sondes désigne cette page, pour qu’un exploitant qui inspecte ses journaux sache d’où vient le trafic.
Pourquoi le résultat détaillé des entités n’est-il pas public ?
Publier « tel site n’applique pas telle protection » revient à dresser une liste de cibles, ce qui n’aide personne à corriger. Cette page publie donc des agrégats : combien d’entités appliquent les bonnes pratiques, dans quelles proportions, et comment la situation évolue. La carte montre le verdict de chaque entité, jamais la liste de ses manques. Le fichier security.txt fait exception et reste public car il permet de désigner à qui signaler une faille.
Qui peut consulter le résultat détaillé d’une entité ?
Le responsable de la sécurité des systèmes d’information (CISO) de l’entité concernée, ou de la collectivité dont elle dépend : un CISO cantonal voit son canton et l’ensemble des communes de ce canton, un CISO communal voit sa commune. Des portées sectorielle et nationale existent pour les organisations qui coordonnent plusieurs établissements.
Qui peut obtenir un accès, que voit-il de plus, et comment le demander ?
L’accès est ouvert aux responsables sécurité des entités suivies, sur demande et après vérification. Dans sa portée, un accès approuvé donne le détail contrôle par contrôle, la liste de ce qui reste à corriger, l’historique de chaque entité, une fiche PDF et l’analyse consolidée avec son plan d’action. La demande se fait sur cette page : demander un accès.
Que mesure le score de sécurité et comment est-il construit ?
Chaque contrôle porte un poids et une gravité. Le résultat d’une famille de contrôles est évalué selon trois niveaux : « Solide » à partir de 80 % des points, « Partiel » à partir de 40 %, « À renforcer » en dessous. Deux plafonds s’appliquent ensuite, quel que soit le total : un contrôle critique en échec ramène à « À renforcer », un contrôle critique partiel ou un contrôle majeur en échec interdit de dépasser « Partiel ». Le score global est la moyenne des sondes ayant produit un verdict, sur la même échelle. Ce qui n’a pas pu être mesuré reste « Non évalué » et n’entre pas dans cette moyenne. Pour en savoir plus : le détail des poids et des gravités, contrôle par contrôle.
À quelle fréquence ces données sont-elles mises à jour ?
Chaque périmètre est analysé sur une base mensuelle. La date exacte de la mesure affichée figure en tête des statistiques, plus haut sur cette page, et l’historique en conserve la trace mois après mois. Une correction apportée par une entité apparaît donc au passage suivant, pas le jour même.
Que concerne la sécurité e-mail ?
Pas le contenu des messages, mais la capacité d’un tiers à écrire au nom du domaine. Les contrôles portent sur des enregistrements DNS publics, que chaque serveur de messagerie interroge déjà à la réception d’un courriel. Ils se publient dans la zone DNS, sans toucher au site web ni à la messagerie elle-même. Les huit standards, les pièges courants et la trajectoire de p=none à p=reject : le guide complet de la sécurité des emails.
SPF, DMARC, DNSSEC : que fait chacun ?
SPF déclare quels serveurs ont le droit d’envoyer du courrier pour le domaine. DMARC indique au destinataire quoi faire des messages qui échouent à cette vérification – les laisser passer, les mettre en quarantaine ou les rejeter – et où envoyer les rapports : un SPF sans DMARC constate la fraude sans la bloquer. DNSSEC signe les réponses DNS pour qu’elles ne puissent pas être falsifiées en route, ce qui protège les deux premiers – un SPF parfait ne sert à rien si la réponse qui le porte peut être remplacée. S’y ajoutent CAA (quelles autorités peuvent émettre un certificat pour le domaine), MTA-STS et TLS-RPT (chiffrement du transport SMTP, et rapports d’échec). Le rôle de chacun, standard par standard : le guide de la sécurité des emails.
Pourquoi le DKIM n’est-il pas mesuré ?
DKIM compte, et sa signature est d’ailleurs utilisée par DMARC. Mais il n’est pas mesurable passivement : contrairement à SPF et DMARC, qui vivent à des noms fixes, une clé DKIM se publie sous un sélecteur libre (default._domainkey, google._domainkey, selector1._domainkey…). Le vérifier supposerait de deviner ce nom, c’est-à-dire d’énumérer des sous-domaines – hors du mode passif des contrôles réalisés ici. Le fonctionnement de DKIM et son lien avec DMARC : le guide de la sécurité des emails.