Rapport suisse sur la sécurité des e-mails 2026

7 domaines e-mail suisses sur 10 ne se protègent pas efficacement contre l’usurpation d’expéditeur

Une étude nationale de la protection contre l’usurpation d’expéditeur, fondée sur 2'459'127 domaines .ch.

· Peter Hadorn

L’adresse de l’expéditeur d’un e-mail peut être falsifiée. Un message semble alors provenir d’une entreprise, d’une administration ou d’une personne connue. De fausses factures, des demandes de paiement et des liens de phishing deviennent ainsi plus crédibles.

L’essentiel en bref

Pour les résultats sur l’usurpation d’expéditeur, 1'700'148 domaines .ch étudiés constituent la base de 100 %. Ils sont configurés pour recevoir des e-mails.

  • 1'190'194 domaines (70,01 %) ne se protègent pas efficacement contre l’usurpation d’expéditeur.
  • Seuls 226'957 domaines (13,35 %) demandent le rejet des e-mails dont l’adresse d’expéditeur est falsifiée.
  • Les chiffres indiquent si une protection est publiée. Ils ne montrent pas qu’une organisation a subi une attaque ou un piratage.

Télécharger les données et les graphiques.

DMARC : comment fonctionne la protection contre l’usurpation d’expéditeur ?

DMARC relie l’adresse d’expéditeur visible aux vérifications SPF et DKIM. SPF vérifie si un serveur peut envoyer des messages pour un domaine. DKIM vérifie la signature numérique du message. Pour réussir la vérification DMARC, au moins un de ces contrôles doit réussir. Le domaine ainsi authentifié doit correspondre au domaine de l’expéditeur visible selon les règles d’alignement. Cette correspondance s’appelle l’alignement.

La valeur p= permet au titulaire du domaine de demander un traitement précis lorsque la vérification DMARC échoue. Cela complique l’utilisation frauduleuse de son domaine comme expéditeur. Les domaines ressemblants et les noms d’affichage falsifiés ne sont pas couverts.

DMARC : quelles règles de protection sont publiées ?

p=reject demande le refus du message. Cette valeur a été détectée pour 13,35 % des domaines e-mail étudiés. p=quarantine demande de traiter le message comme suspect, par exemple en le plaçant dans les spams. Cette valeur est publiée par 16,65 % des domaines.

p=none ne demande aucun traitement particulier au titre de DMARC. Cela concerne 12,91 % des domaines. D’autres filtres antispam peuvent tout de même intervenir. Pour 57,07 %, aucun enregistrement DMARC n’a été trouvé. Pour environ 0,03 % supplémentaires, la valeur p= était absente ou son contenu n’a pas été reconnu. Ensemble, ces deux groupes représentent 57,10 %.

DMARC : règles de protection publiées

Base : 1'700'148 domaines étudiés avec un enregistrement MX non vide. Chaque barre complète représente 100 %.

p=rejectDemander le refus si la vérification DMARC échoue226'957 domaines13,35 %
p=quarantineDemander un traitement comme suspect, par exemple dans les spams282'997 domaines16,65 %
p=noneNe demander aucun traitement particulier au titre de DMARC219'494 domaines12,91 %
Enregistrement DMARC absent ou valeur p non reconnue57,07 % sans enregistrement. Environ 0,03 % sans valeur p reconnue970'700 domaines57,10 %

Consignes publiées, pas de mesure de réception. Validité des enregistrements non entièrement vérifiée.

Télécharger le graphique (PNG) · Graphique vectoriel (SVG)

Les 57,10 % sans règle de protection reconnue et les 12,91 % avec p=none donnent un total de 70,01 %. La méthode explique ce que le scanner relève et les limites de la mesure.

Qu’avons-nous étudié ?

2'459'127
domaines .ch étudiés
2'316'512
analysés (94,2 % de la liste complète)
142'615
non analysables (5,8 % de la liste complète)
1'700'148
configurés pour recevoir des e-mails (73,39 % des domaines analysés)

Source : fichier de zone .ch de SWITCH. Les domaines sans réponse exploitable sont classés comme non mesurés, non comme non protégés, et sont exclus des résultats. Sauf indication contraire, les valeurs SPF, DKIM et DMARC se rapportent aux domaines avec MX.

Afficher le tableau détaillé
Chaque chiffre précise le nombre de domaines, la base de comparaison et les limites de la mesure.
MesureRésultatNombre de domainesBase de comparaisonGroupe étudiéCe que le chiffre indique
Pas de protection efficace contre les expéditeurs falsifiés70,01 %1'190'1941'700'148configurés pour recevoir des e-mailsAucune règle prise en charge détectée, ou une règle ne demandant ni mise à l’écart ni refus.
p=reject : Demander le refus si la vérification DMARC échoue13,35 %226'9571'700'148configurés pour recevoir des e-mailsDemande publiée de refus. La réception effective n’a pas été testée.
Enregistrement SPF présent86,75 %1'474'9061'700'148configurés pour recevoir des e-mailsEnregistrement détecté. Les renvois vers d’autres listes SPF n’ont pas été entièrement vérifiés.
Sélecteur DKIM détecté20,15 %342'5081'700'148configurés pour recevoir des e-mailsRecherche à partir de noms connus. D’autres enregistrements peuvent ne pas avoir été détectés.
DNSSEC : enregistrement DS pour authentifier les informations du domaine53,84 %1'247'3132'316'512analysésPrésence de l'enregistrement DNS uniquement ; aucune validation cryptographique DNSSEC ni vérification fonctionnelle DANE.

SPF et DKIM : autorisation d’envoi et signature numérique

SPF indique les serveurs autorisés à envoyer des e-mails pour un domaine. La règle peut exclure explicitement tous les autres serveurs ou les considérer comme probablement non autorisés. -all produit le résultat Fail pour les autres serveurs, tandis que ~all produit Softfail. Ce sont des résultats de vérification SPF, pas des garanties de refus par le destinataire. SPF seul ne protège pas entièrement l’adresse d’expéditeur visible. Les renvois vers d’autres listes SPF n’ont pas été entièrement vérifiés.

Pour 19,33 %, aucun mécanisme all n’a été détecté. Cela ne signifie pas automatiquement que le réglage est incorrect : redirect= peut renvoyer vers la règle SPF d’un autre domaine. Si all et redirect= sont tous deux absents et qu’aucun autre mécanisme ne correspond, le résultat est Neutral. SPF ne confirme alors ni une autorisation ni une absence d’autorisation.

DKIM est une signature numérique pour les e-mails. Elle aide le destinataire à vérifier quel domaine a signé le message et si le contenu signé est resté intact. Pour chercher une clé DKIM, il faut un nom appelé sélecteur. Le scanner a interrogé des sélecteurs connus de fournisseurs de messagerie. Un enregistrement a été trouvé pour 20,15 % des domaines e-mail étudiés. Comme la recherche ne couvre pas tous les sélecteurs possibles, la proportion réelle peut être plus élevée.

SPF et DKIM : réglages détectés

Base : 1'700'148 domaines étudiés avec un enregistrement MX non vide. Chaque barre complète représente 100 %.

Enregistrement SPF présentLes serveurs autorisés à envoyer sont publiés1'474'906 domaines86,75 %
SPF -all : FailLes autres serveurs sont déclarés non autorisés571'967 domaines33,64 %
SPF ~all : SoftfailLes autres serveurs sont considérés comme probablement non autorisés486'459 domaines28,61 %
SPF sans mécanisme allUn renvoi redirect est possible. Cela ne prouve pas une absence de protection328'576 domaines19,33 %
Sélecteur DKIM détectéClé publique de vérification trouvée via un sélecteur connu342'508 domaines20,15 %

Catégories non exclusives. Renvois SPF non entièrement suivis. Détection DKIM : limite inférieure.

Télécharger le graphique (PNG) · Graphique vectoriel (SVG)

Détails techniques de la recherche DKIM

Les deux chiffres suivants décrivent les enregistrements DKIM trouvés. Leur base est constituée des domaines avec un sélecteur détecté. Pour 31,65 %, une valeur de clé encodée courte a été enregistrée. Cela ne permet pas de conclure à une vulnérabilité. Le contrôle de longueur ne distingue pas RSA d’Ed25519, pour lequel des valeurs courtes peuvent être valides. Un indicateur de test a été détecté pour 7,44 %. Il ne prouve pas qu’un test était réellement en cours.

MX : quels fournisseurs de messagerie peut-on identifier ?

L’attribution repose sur des motifs reconnaissables dans les noms des serveurs de messagerie. Elle n’indique ni des parts de marché exactes ni la sécurité d’un fournisseur. Elle ne permet pas non plus d’identifier avec certitude l’opérateur effectif du serveur.

MX : classement selon les noms des serveurs de messagerie

Base : 1'700'148 domaines étudiés avec un enregistrement MX non vide. Chaque barre complète représente 100 %.

HostpointMotif reconnu dans le nom du serveur348'340 domaines20,49 %
InfomaniakMotif reconnu dans le nom du serveur178'072 domaines10,47 %
Microsoft 365Motif reconnu dans le nom du serveur160'129 domaines9,42 %
Google WorkspaceMotif reconnu dans le nom du serveur59'683 domaines3,51 %
Non attribué / peut-être autogéréAucun motif associé à un fournisseur432'455 domaines25,44 %
Autres catégoriesAutres motifs attribués par le scanner405'385 domaines23,84 %
Inconnu / non reconnuAucune attribution reconnue0 domaines0,00 %

Ni parts de marché ni notes de sécurité. Les noms ne prouvent pas l’identité de l’opérateur effectif.

Télécharger le graphique (PNG) · Graphique vectoriel (SVG)

Afficher le tableau détaillé
Attribution selon des motifs reconnaissables dans les noms des serveurs. Chaque ligne se rapporte aux domaines avec MX.
Fournisseur de messagerie identifiéNombre de domainesPartBase de comparaisonGroupe étudiéCe que le chiffre indique
Non attribué / possiblement autogéré432'45525,44 %1'700'148configurés pour recevoir des e-mailsAttribution selon le nom du serveur. Elle ne prouve ni la part de marché, ni la sécurité, ni l’identité de l’opérateur effectif.
Inconnu / non reconnu405'38523,84 %1'700'148configurés pour recevoir des e-mailsAttribution selon le nom du serveur. Elle ne prouve ni la part de marché, ni la sécurité, ni l’identité de l’opérateur effectif.
Hostpoint348'34020,49 %1'700'148configurés pour recevoir des e-mailsAttribution selon le nom du serveur. Elle ne prouve ni la part de marché, ni la sécurité, ni l’identité de l’opérateur effectif.
Infomaniak178'07210,47 %1'700'148configurés pour recevoir des e-mailsAttribution selon le nom du serveur. Elle ne prouve ni la part de marché, ni la sécurité, ni l’identité de l’opérateur effectif.
Microsoft 365160'1299,42 %1'700'148configurés pour recevoir des e-mailsAttribution selon le nom du serveur. Elle ne prouve ni la part de marché, ni la sécurité, ni l’identité de l’opérateur effectif.
Google Workspace59'6833,51 %1'700'148configurés pour recevoir des e-mailsAttribution selon le nom du serveur. Elle ne prouve ni la part de marché, ni la sécurité, ni l’identité de l’opérateur effectif.
Autres catégories d'empreinte116'0846,83 %1'700'148configurés pour recevoir des e-mailsAttribution selon le nom du serveur. Elle ne prouve ni la part de marché, ni la sécurité, ni l’identité de l’opérateur effectif.

DNSSEC et transport : quels enregistrements sont présents ?

D’autres enregistrements concernent la protection des informations du domaine, les certificats et le chiffrement pendant le transport des e-mails. Certains annoncent des rapports d’erreur ou renvoient vers un logo d’expéditeur. Le tableau indique si ces informations étaient présentes. Le fonctionnement des protections, la validité des certificats, l’affichage des logos et l’envoi des rapports n’ont pas été testés.

DNSSEC et transport : enregistrements détectés

Pour DS, la base est de 2'316'512 domaines analysés. Pour les autres chiffres, elle est de 1'700'148 domaines avec MX. Chaque barre complète représente 100 % du groupe concerné.

DNSSEC : DSLien servant à authentifier les informations DNS1'247'313 sur 2'316'512 domaines53,84 %
DANE : TLSAInformations pour vérifier le certificat du serveur de messagerie652'997 sur 1'700'148 domaines38,41 %
MTA-STS : TXTIndication de règles pour le transport chiffré des e-mails2'534 sur 1'700'148 domaines0,15 %
TLS-RPT : TXTInformations pour signaler les problèmes de transport2'728 sur 1'700'148 domaines0,16 %

Présence uniquement. Fonctionnement de DNSSEC, DANE, règles HTTPS et envoi de rapports non testé.

Télécharger le graphique (PNG) · Graphique vectoriel (SVG)

Afficher le tableau détaillé
Chaque chiffre précise le nombre de domaines, la base de comparaison et les limites de la mesure.
Enregistrement DNSRésultatNombre de domainesBase de comparaisonGroupe étudiéCe que le chiffre indique
DNSSEC : enregistrement DS pour authentifier les informations du domaine53,84 %1'247'3132'316'512analysésSeule la présence de l’enregistrement a été mesurée. Le fonctionnement de DNSSEC et DANE n’a pas été testé.
DANE : enregistrement TLSA pour vérifier le certificat du serveur38,41 %652'9971'700'148configurés pour recevoir des e-mailsSeule la présence de l’enregistrement a été mesurée. Le fonctionnement de DNSSEC et DANE n’a pas été testé.
MTA-STS : indication DNS de règles pour un transport chiffré0,15 %2'5341'700'148configurés pour recevoir des e-mailsEnregistrement détecté. Son fonctionnement n’a pas été testé.
TLS-RPT : enregistrement DNS pour signaler les problèmes de transport0,16 %2'7281'700'148configurés pour recevoir des e-mailsEnregistrement détecté. Son fonctionnement n’a pas été testé.
BIMI : renvoi DNS vers un logo d’expéditeur0,08 %1'3121'700'148configurés pour recevoir des e-mailsEnregistrement détecté. Son fonctionnement n’a pas été testé.
CAA : autorités de certification autorisées1,50 %25'4911'700'148configurés pour recevoir des e-mailsEnregistrement détecté. Son fonctionnement n’a pas été testé.

Ce que le rapport ne mesure pas

  • la délivrabilité réelle ou le classement antispam
  • le phishing, les violations de données ou les boîtes aux lettres compromises
  • la sécurité, la qualité ou la fiabilité de chaque entreprise, hôte ou fournisseur
  • l'exploitabilité d'hôtes MX non résolvables

Comment les mesures ont été réalisées

Le rapport examine les réglages publics des domaines .ch. Le programme de mesure a uniquement consulté l’annuaire public d’Internet. Il n’a envoyé aucun e-mail, ouvert aucune boîte aux lettres ni évalué aucune entreprise.

Les mesures ont été réalisées du 21 au 23 août 2026, à partir d’une liste fixe de domaines .ch du 12 avril 2026. Les domaines enregistrés après cette date ne sont pas tous inclus.

Pour 142'615 domaines, aucune réponse exploitable n’a été obtenue. Ils ne sont pas comptés comme non protégés et sont exclus des résultats. Ces domaines peuvent différer de ceux qui ont pu être analysés. Les résultats ne peuvent donc pas simplement leur être appliqués.

Le programme reconnaît certaines informations dans les règles DMARC publiées. Il ne vérifie pas entièrement leur validité. Si plusieurs règles sont présentes, il peut retenir la première. Il n’écarte pas non plus toutes les informations incorrectes ou répétées. Les pourcentages correspondent donc à cette méthode de détection.

Une règle qui ne s’applique qu’à une partie des e-mails ne prouve pas une protection complète. Le réglage p=none n’indique pas non plus si des rapports sont configurés ou lus.

Les termes essentiels en langage simple

  • DNS: l’annuaire public des informations techniques d’un domaine.
  • MX: indique les serveurs prévus pour recevoir les e-mails d’un domaine. Sans cet enregistrement, un domaine peut tout de même envoyer des e-mails et, dans certains cas, en recevoir.
  • SPF: indique les serveurs autorisés à envoyer des e-mails au nom d’un domaine.
  • DKIM: ajoute une signature numérique aux e-mails sortants.
  • DMARC: indique ce que le destinataire est invité à faire lorsque l’expéditeur d’un e-mail ne peut pas être confirmé.
Source de donnéesFichier de zone .ch de SWITCH (2026-04-12)
Période de mesure –
MéthodeSeules les informations des services DNS publics ont été consultées. Aucune connexion aux sites web ou aux serveurs de messagerie, aucune recherche de ports ouverts, aucune connexion à un compte et aucun envoi d’e-mail.
Services DNS utilisés1.1.1.1, 8.8.8.8, 9.9.9.9, 1.0.0.1, 8.8.4.4
Code et méthodeswiss-email-security-report
PublicChiffres regroupés, graphiques, code et documents de vérification.
Non publicDonnées brutes concernant chaque domaine.

Limites de l'analyse

  • La recherche DKIM utilise des noms connus de services de messagerie. Elle peut manquer d’autres noms. Le nombre réel de domaines utilisant DKIM peut donc être plus élevé.
  • Les clés ont été évaluées uniquement d’après la longueur de leur version codée. Leur sécurité n’a pas été testée.
  • Les renvois vers d’autres listes dans les règles SPF n’ont pas tous été suivis.
  • Pour MTA-STS, seule la présence d’un enregistrement DNS a été vérifiée. La règle publiée sur le site correspondant n’a pas été consultée.
  • Les résultats sont regroupés et ne permettent pas de juger une organisation en particulier.

Corrections et questions méthodologiques :

Citation

Hadorn, P. (2026). Rapport suisse sur la sécurité des e-mails 2026. WebEvolve.ch.
https://webevolve.ch/fr/etudes/rapport-securite-e-mail-suisse/
Jeu de données archivé (v2026.08.2), DOI : 10.5281/zenodo.22116736

Télécharger les données et les graphiques

Vous trouverez ici les résultats agrégés et les graphiques à réutiliser. Seuls les totaux et les pourcentages sont publics, pas les listes de domaines ni les résultats individuels.

Télécharger les données (CSV)
Télécharger les données (JSON)

Code source et méthode sur GitHub
Jeu de données sur Zenodo

Vous pouvez réutiliser les données et les graphiques sous licence CC BY 4.0. Merci de citer Peter Hadorn / WebEvolve, de fournir un lien vers cette étude et de signaler toute modification.

Graphiques des résultats

Les graphiques figurent dans les chapitres correspondants. Vous pouvez y télécharger chaque graphique au format PNG ou SVG.

Corrections et questions

Vous avez repéré une erreur ? Écrivez à hallo@webevolve.ch.

Indiquez le chiffre ou le fichier concerné et décrivez le problème avec des éléments vérifiables. Nous examinons les signalements et documentons les corrections confirmées. Toute modification des mesures donne lieu à une nouvelle version. Les versions précédentes restent accessibles et peuvent être citées. Les fichiers archivés sur Zenodo ne sont pas remplacés sans publication d’une nouvelle version.

Ne publiez pas de données brutes relatives à des domaines individuels. Nous répondons aux questions sur un domaine dans les limites de la protection des données et des accords sur les sources.

Les précisions du 6 septembre 2026 concernent les limites des mesures DMARC, DKIM et DNSSEC. Les mesures et l’archive publiée restent inchangées.

Précisions méthodologiques et corrections du scanner (en anglais)

Questions fréquentes

Combien de domaines .ch ne se protègent pas efficacement contre l’usurpation d’expéditeur ?

70,01 % des domaines .ch étudiés et configurés pour recevoir des e-mails ne se protègent pas efficacement contre l’usurpation d’expéditeur. Aucun enregistrement DMARC n’a été détecté pour 57,07 %. Environ 0,03 % n’ont pas de valeur p reconnue. Les 12,91 % supplémentaires publient p=none, sans demander ni mise à l’écart ni refus. Cela représente 1'190'194 domaines sur 1'700'148.

Cela signifie-t-il que ces domaines ont subi une attaque ?

Non. Le rapport mesure des réglages publics. Il ne prouve ni une attaque ni le piratage d’une boîte aux lettres.

Quelles règles de protection existe-t-il ?

Le réglage p=none ne demande ni d’écarter ni de refuser les messages. Il peut servir à observer ce qui se passe. Nous n’avons pas vérifié si des rapports sont configurés ou lus. Avec p=quarantine, les messages suspects devraient être placés dans les spams. Avec p=reject, ils devraient être refusés. Nous n’avons pas testé si le destinataire suit ces consignes pour chaque message.

SPF suffit-il à lui seul ?

Non. SPF seul ne protège pas contre toutes les formes de falsification de l’expéditeur.

Comment les domaines ont-ils été examinés ?

Nous avons uniquement consulté les services DNS publics. Aucun e-mail n’a été envoyé et aucun serveur de messagerie n’a été contacté directement.

Pourquoi certains domaines n’ont-ils pas pu être analysés ?

Ils n’ont pas fourni de réponse DNS exploitable pendant la mesure. Ils ne sont donc pas comptés comme non protégés et sont exclus des résultats. Cela concerne 142'615 domaines sur 2'459'127.

La recherche trouve-t-elle tous les domaines utilisant DKIM ?

Non. La recherche utilise des noms connus de services de messagerie. Des noms personnalisés ou inconnus peuvent lui échapper. Le nombre réel de domaines utilisant DKIM peut donc être plus élevé.

La réception des e-mails a-t-elle été testée ?

Non. Aucun e-mail n’a été envoyé et aucune boîte aux lettres n’a été examinée.

Quelles données sont publiques ?

Les chiffres regroupés, les graphiques, le code du programme et les documents de vérification sont publics. Les résultats de chaque domaine restent privés.

Comment citer le rapport ?

Hadorn, P. (2026). Rapport suisse sur la sécurité des e-mails 2026. WebEvolve.ch.

↑

Protégez votre domaine e-mail.

Nous examinons votre situation actuelle et déterminons les prochaines étapes adaptées à votre entreprise.

Prendre rendez-vous