Rien n’empêche techniquement quiconque d’envoyer un courriel en inscrivant l’adresse d’un canton comme expéditeur. Ce qui l’en empêche, ce sont trois enregistrements publiés dans la zone DNS du domaine : SPF, qui déclare quels serveurs ont le droit d’envoyer ; DMARC, qui indique aux destinataires quoi faire des messages qui échouent au contrôle ; et DNSSEC, qui garantit que ces réponses DNS n’ont pas été falsifiées en chemin. Cette page mesure ces trois protections sur les domaines des 26 cantons suisses.
Aucun scan de vulnérabilités, aucune tentative d’exploitation. Ces contrôles se limitent à lire des informations déjà publiques — les mêmes qu’un navigateur ou un serveur de messagerie reçoit de toute façon en se connectant normalement à ce site.
Chargement de la carte…
Au 5 septembre 2026, 26 sites évalués sur Cantons suisses (Sécurité e-mail) : 2 appliquent les bonnes pratiques (Enregistrements DNS publics qui empêchent d'envoyer un courriel en se faisant passer pour cette entité).
- Solide2(8%)
- Partiel19(73%)
- À renforcer5(19%)
Vue nationale : 2 cantons sur 26 appliquent les bonnes pratiques (8 %). Le détail par canton est réservé aux responsables de sécurité (CISO) cantonaux et communaux.
SPF, DMARC, DNSSEC : que fait chacun ?
Le SPF est un enregistrement DNS qui énumère les serveurs autorisés à envoyer du courrier au nom du domaine. Un message venu d’ailleurs échoue au contrôle. C’est la brique la mieux adoptée par les cantons.
Le DMARC est un enregistrement DNS qui indique au serveur destinataire quoi faire d’un message ayant échoué : le laisser passer, le placer en indésirable, ou le rejeter. Sans DMARC, le résultat du contrôle SPF existe mais reste consultatif — le message frauduleux arrive quand même.
Le DNSSEC signe cryptographiquement les réponses DNS du domaine, ce qui permet de vérifier qu’elles n’ont pas été falsifiées. Sans lui, un attaquant capable d’altérer les réponses DNS peut aussi altérer les règles SPF et DMARC qu’elles transportent.
Catalogue des contrôles
Détail technique de chaque contrôle ci-dessous. Sources : en-têtes HTTP, enregistrements DNS, fichier security.txt. Vérification automatique et périodique (hebdomadaire ou mensuelle selon le jeu de données) par DCOD, dans le cadre d'un observatoire public de la sécurité des sites suisses. Une question, ou besoin d'exclure un domaine ? hello@dcod.ch
Sécurité e-mail
Enregistrements DNS publics qui empêchent d'envoyer un courriel en se faisant passer pour cette entité.
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 un enregistrement TXT « v=spf1 … -all » listant les serveurs autorisés. Terminer par -all (rejet) : sans cela, l'enregistrement n'a pas d'effet contraignant réel (~all ne fait que marquer, ?all ne fait rien), et « +all » autorise au contraire le monde entier. Un seul enregistrement SPF par domaine : plusieurs annulent la protection.
- 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é ne se termine ni par « -all » ni par « ~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 un TXT sur _dmarc.<domaine>, en commençant par « v=DMARC1; p=none; rua=mailto:… » pour observer, puis durcir vers p=reject (p=quarantine reste une étape intermédiaire : le courriel frauduleux atteint quand même la boîte du destinataire). Une fois à p=reject, viser pct=100 (ou l'omettre, valeur par défaut) et sp=reject si le domaine a des sous-domaines. Un seul enregistrement DMARC par domaine : plusieurs font ignorer la politique par les destinataires.
- 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 » : 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 « 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.
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.
En savoir plus ↗Comment la situation évolue-t-elle ?
| Période | Solide | Partiel | À renforcer | Non évalué | Total |
|---|---|---|---|---|---|
| 2026-07 | 0 | 0 | 0 | 0 | 0 |
| 2026-08 | 2 | 19 | 5 | 0 | 26 |
| 2026-09 | 2 | 19 | 5 | 0 | 26 |
Questions fréquentes
Qu’est-ce que le SPF ?
Le SPF (Sender Policy Framework) est un enregistrement DNS public qui énumère les serveurs autorisés à envoyer du courrier au nom d’un domaine. À la réception d’un message, le serveur destinataire consulte cet enregistrement et vérifie si le serveur émetteur y figure.
Qu’est-ce que le DMARC, et pourquoi ne suffit-il pas de publier SPF ?
Le DMARC (Domain-based Message Authentication, Reporting and Conformance) est un enregistrement DNS qui indique au destinataire quoi faire d’un message ayant échoué au contrôle SPF : ne rien faire, le placer en indésirable, ou le rejeter. Sans DMARC, l’échec est constaté mais sans conséquence : le message frauduleux arrive quand même dans la boîte de réception.
À quoi sert le DNSSEC pour la messagerie ?
Le DNSSEC signe cryptographiquement les réponses DNS d’un domaine, ce qui permet de vérifier qu’elles n’ont pas été altérées en chemin. Comme SPF et DMARC sont eux-mêmes publiés dans le DNS, un DNS falsifiable rend ces deux protections falsifiables à leur tour.
Une politique DMARC en observation protège-t-elle vraiment ?
Non, pas encore. Une politique déclarée en observation seule fait remonter des rapports sur les abus, mais demande aux destinataires de livrer les messages malgré tout. C’est une étape de déploiement utile pour vérifier qu’aucun courrier légitime n’est bloqué, avant de passer en quarantaine puis en rejet.
Pourquoi le DKIM n’est-il pas mesuré ici ?
Parce qu’il ne peut pas l’être de façon fiable sans deviner. Contrairement à SPF et DMARC, publiés à des adresses fixes, le DKIM se trouve à un nom qui dépend d’un sélecteur choisi par l’organisation. Le chercher reviendrait à énumérer des noms au hasard, ce qui sort du périmètre strictement passif de cet observatoire.
Qui peut consulter le résultat d’un canton en particulier ?
Les chiffres d’ensemble de cette page sont publics : combien de cantons appliquent les bonnes pratiques, dans quelles proportions, et comment la situation évolue. Le résultat détaillé d’un canton donné, en revanche, est réservé aux responsables de la sécurité des systèmes d’information (CISO) des cantons et des communes.
Un CISO qui obtient un accès voit en clair son canton et l’ensemble des communes de ce canton — de quoi agir chez lui — et les autres cantons en vue agrégée, de quoi se comparer. Le fichier security.txt fait exception et reste public sans condition : son objet même est d’être trouvé par qui cherche à signaler une faille.
Pourquoi le résultat détaillé d’un canton n’est-il pas public ?
Le résultat individuel de chaque entité est réservé aux responsables de sécurité (CISO) des cantons et des communes.
Qui peut obtenir un accès, et que voit-il de plus ?
Les responsables de sécurité des cantons et des communes suisses, sur demande et après validation manuelle. Un accès couvre tout un canton : le CISO cantonal et celui d’une commune de ce canton voient exactement la même chose, à savoir le détail du canton et de toutes ses communes. Les autres cantons restent en vue agrégée, ce qui permet la comparaison sans exposer personne.
Une zone grise sur la carte signifie-t-elle que l’entité n’est pas évaluée ?
Pas nécessairement. Le gris couvre deux situations, que la carte distingue au clic : soit la mesure n’a pas pu se faire — site injoignable, domaine qui ne résout plus — soit l’entité est bien évaluée mais son résultat individuel est réservé. Dans ce second cas, la carte affiche à la place le résultat agrégé de l’ensemble des cantons.