Envoyer un courriel en se faisant passer pour une commune ne demande aucune compétence particulière : le protocole de messagerie laisse l’expéditeur déclarer l’adresse de son choix. Seuls trois enregistrements publiés dans la zone DNS du domaine permettent aux serveurs destinataires de démasquer la supercherie : SPF, DMARC et DNSSEC. Cette page mesure leur présence sur les domaines de plus de 2 100 communes 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 18 août 2026, 2110 sites évalués sur Communes suisses (Sécurité e-mail) : 205 appliquent les bonnes pratiques (Enregistrements DNS publics qui empêchent d'envoyer un courriel en se faisant passer pour cette entité).
- Solide205(10%)
- Partiel923(44%)
- À renforcer982(47%)
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 | 205 | 923 | 982 | 0 | 2110 |
Questions fréquentes
Pourquoi une commune est-elle une cible intéressante ?
Parce qu’un courriel qui paraît venir de l’administration communale — facture, rappel, information au public — bénéficie d’une confiance immédiate de ses habitants. La taille de la commune ne protège pas : elle rend même l’usurpation plus crédible, une petite administration disposant rarement des moyens de démentir rapidement.
Ma commune a un SPF : est-elle protégée contre l’usurpation ?
Pas encore. Le SPF permet au serveur destinataire de constater qu’un message est illégitime, mais ne lui dit pas quoi en faire. Sans enregistrement DMARC, le message est généralement livré malgré l’échec du contrôle. Les deux sont nécessaires, et c’est le DMARC qui déclenche le blocage.
Que faut-il faire pour sécuriser SPF, DMARC et DNSSEC?
Ces trois protections se publient dans la zone DNS du domaine, pas sur le site web. La demande à adresser au prestataire qui gère le domaine tient en trois points : vérifier que l’enregistrement SPF est complet, publier un enregistrement DMARC et le faire progresser jusqu’au rejet, activer la signature DNSSEC de la zone.
Aucune de ces actions ne touche au site, à sa messagerie quotidienne ni à son hébergement. Le déploiement du DMARC se fait par étapes — observation, quarantaine, rejet — précisément pour vérifier à chaque palier qu’aucun courrier légitime n’est bloqué.
Publier un DMARC risque-t-il de bloquer les courriels légitimes de la commune ?
C’est précisément ce que le déploiement par étapes permet d’éviter. On commence par une politique d’observation, qui ne bloque rien et fait remonter des rapports sur les envois au nom du domaine. Une fois vérifié que tous les services légitimes — messagerie, formulaires du site, envois groupés — sont bien déclarés, on passe en quarantaine, puis en rejet.
Qui doit s’en charger dans une commune ?
Le prestataire qui gère le nom de domaine et sa zone DNS, qui n’est pas toujours celui qui héberge le site. Ces enregistrements se publient dans le DNS, indépendamment du site web et de son contenu.
Le DNSSEC est-il vraiment nécessaire pour une petite commune ?
Il constitue le socle des deux autres protections. Comme SPF et DMARC sont publiés dans le DNS, un DNS qui peut être falsifié rend ces règles falsifiables à leur tour. Son activation dépend surtout du registrar et de l’hébergeur DNS : chez beaucoup, c’est devenu une simple option à activer.
Combien cela coûte-t-il ?
Rien, dans la plupart des cas. SPF et DMARC sont des enregistrements DNS textuels, sans coût. Le DNSSEC est proposé gratuitement par la majorité des hébergeurs DNS et des bureaux d’enregistrement pour les domaines en .ch.
Qui peut consulter le résultat d’une commune en particulier ?
Les chiffres d’ensemble de cette page sont publics, canton par canton : combien de communes appliquent les bonnes pratiques, et comment la situation évolue. Le résultat détaillé d’une commune donnée, 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 — la maille à laquelle l’action collective se décide — et les autres cantons en vue agrégée. 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’une commune 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 la commune 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 la commune 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é du canton auquel elle appartient.