DMARC, DKIM, SPF : protéger les emails B2B de votre PME suisse

Un domaine non protégé est un chèque en blanc pour l'attaquant

En 2023, le Centre national pour la cybersécurité (NCSC) a recensé plusieurs milliers de signalements liés à des arnaques par email en Suisse, dont une proportion significative impliquait l'usurpation de domaines de PME locales. Lorsqu'un attaquant envoie un email en spoofant votre domaine exemple-fiduciaire.ch, vos clients ne voient aucune différence visuelle — le nom d'expéditeur est identique au vôtre. Sans SPF, DKIM et DMARC configurés correctement, le serveur destinataire n'a aucune raison technique de rejeter ce message.

Ce n'est pas un problème réservé aux grandes entreprises. Une fiduciaire de 30 collaborateurs à Lausanne ou un bureau d'ingénieurs de 60 postes à Sion traite quotidiennement des données personnelles (salaires, bilans, mandats), ce qui place toute compromission email dans le périmètre de la nouvelle Loi fédérale sur la protection des données (nLPD), en vigueur depuis le 01.09.2023.

Les trois mécanismes : rôles, limites et interactions

SPF — Sender Policy Framework

SPF est un enregistrement DNS de type TXT publié sur votre domaine. Il liste les adresses IP et serveurs autorisés à envoyer du courrier en votre nom. Exemple minimal pour une PME sur Microsoft 365 :

v=spf1 include:spf.protection.outlook.com ~all

La directive ~all (softfail) marque les sources non listées comme suspectes sans les rejeter. Passez à -all (hardfail) dès que votre inventaire d'expéditeurs légitimes est complet. Attention : SPF est évalué sur l'en-tête MAIL FROM (envelope sender), pas sur le champ From: visible par l'utilisateur — c'est précisément là que réside sa limite principale face au spoofing d'affichage.

Limite opérationnelle critique : SPF supporte au maximum 10 résolutions DNS récursives. Un domaine qui cumule plusieurs services d'envoi (newsletter, CRM, helpdesk, ERP) dépasse facilement ce seuil et génère des erreurs PermError invisibles à l'administrateur mais fatales à la délivrabilité.

DKIM — DomainKeys Identified Mail

DKIM ajoute une signature cryptographique à chaque message sortant. La clé publique est publiée en DNS (TXT sur le sélecteur, ex. selector1._domainkey.exemple-fiduciaire.ch), la clé privée est détenue par votre serveur ou plateforme d'envoi. Le destinataire vérifie la signature : si le corps ou les en-têtes signés ont été altérés en transit, la vérification échoue.

Points de vigilance :

• Utilisez des clés RSA d'au moins 2048 bits (les clés 1024 bits sont considérées insuffisantes selon les CIS Benchmarks).
• Les listes de diffusion et certains antispams modifient le corps du message, cassant la signature DKIM — prévoir un traitement dédié.
• Rotation recommandée des clés : tous les 6 à 12 mois.

DMARC — Domain-based Message Authentication, Reporting & Conformance

DMARC est la couche de politique et de reporting qui s'appuie sur SPF et/ou DKIM. Il résout la limite de SPF en exigeant l'alignement entre le domaine From: affiché et le domaine authentifié par SPF ou DKIM. Enregistrement DNS TXT sur _dmarc.exemple-fiduciaire.ch :

v=DMARC1; p=none; rua=mailto:dmarc-reports@exemple-fiduciaire.ch; ruf=mailto:dmarc-forensic@exemple-fiduciaire.ch; fo=1; adkim=s; aspf=s

Les trois politiques progressives :

1. p=none : surveillance uniquement. Déployez ici pendant 4 à 8 semaines pour analyser les rapports sans risque d'impact sur la délivrabilité.
2. p=quarantine : les messages non conformes partent en spam chez le destinataire.
3. p=reject : les messages non conformes sont rejetés au niveau SMTP. C'est l'objectif cible.

Les rapports agrégés (RUA, format XML) arrivent quotidiennement depuis chaque serveur destinataire qui supporte DMARC. Ils indiquent, IP par IP et domaine par domaine, les volumes de messages et leur statut d'authentification. Sans outil de parsing, ces fichiers XML sont quasi-illisibles — des services gratuits comme celui de Google Postmaster ou des outils open source suffisent pour une PME de moins de 150 postes.

Cadre légal suisse : nLPD, obligation de notification, responsabilité

La nLPD (art. 24) impose au responsable du traitement de notifier le Préposé fédéral à la protection des données et à la transparence (PFPDT) « dans les meilleurs délais » dès que probable qu'une violation de données entraîne un risque élevé pour les personnes concernées. En pratique, l'horizon de 72 heures retenu par le RGPD fait référence dans la jurisprudence émergente, même si la nLPD ne fixe pas ce délai explicitement.

Un email de phishing réussi grâce au spoofing de votre domaine, qui conduit à l'exfiltration de données clients, constitue une violation de données au sens de l'art. 5 let. h nLPD. La PME expéditrice — même si elle est victime — peut être considérée comme responsable de traitement négligent si les mesures techniques élémentaires (SPF/DKIM/DMARC) n'étaient pas en place. Les sanctions administratives prévues aux art. 60–63 nLPD peuvent atteindre CHF 250 000 pour des personnes physiques (dirigeants), indépendamment de la taille de l'entreprise.

Pour les PME actives dans le secteur financier, la FINMA (circulaire 2023/1 sur les risques opérationnels) exige explicitement des contrôles sur les canaux de communication sensibles, ce qui inclut l'email. L'absence de DMARC en mode reject peut être relevée lors d'un audit de conformité.

Déploiement pas à pas pour une PME de 20 à 150 endpoints

La séquence ci-dessous suppose un domaine géré chez un registrar suisse standard (Infomaniak, Hostpoint, Swisscom DNS) et un service email Microsoft 365 ou Google Workspace. Elle est applicable par un sysadmin interne ou un MSP mandaté.

1. Inventaire des sources d'envoi (Responsable : DSI ou MSP) — Listez toutes les origines légitimes : serveur mail principal, newsletter (Brevo, Mailchimp), CRM (Salesforce, HubSpot), ERP, scanner multifonction, alertes monitoring. Durée estimée : 2 à 4 heures pour une PME de 50 personnes.
2. Publication SPF — Créez ou mettez à jour l'enregistrement TXT. Vérifiez le nombre de lookups DNS avec un outil comme dig +short TXT votre-domaine.ch. Restez sous 10 résolutions. Utilisez ~all en première étape.
3. Activation DKIM — Activez DKIM dans votre console d'administration (Microsoft 365 Admin Center → Protection Exchange → DKIM ; Google Admin → Gmail → Authentification). Publiez les enregistrements CNAME ou TXT fournis. Attendez 24 à 48 heures de propagation DNS.
4. Déploiement DMARC en p=none (Responsable : DSI) — Publiez l'enregistrement avec une adresse rua joignable. Configurez une règle de boîte mail ou un script de parsing pour ne pas manquer les rapports.
5. Analyse des rapports — semaines 1 à 6 (Responsable : DSI/RSSI) — Identifiez les sources légitimes non couvertes par SPF/DKIM. Corrigez itérativement. Détectez les IPs tierces qui usurpent votre domaine.
6. Passage en p=quarantine — Après 2 semaines sans anomalie, passez en quarantine. Surveillez les remontées utilisateurs sur des emails légitimes bloqués.
7. Passage en p=reject (Responsable : DSI, validation RSSI) — Objectif final. Documentez la décision dans votre registre des mesures techniques (art. 4 OPDo).
8. Tests de validation — Envoyez un email depuis chaque source inventoriée. Vérifiez les en-têtes reçus : Authentication-Results doit afficher dmarc=pass, dkim=pass, spf=pass.
9. Documentation et revue annuelle (Responsable : RSSI ou juriste interne) — Consignez la configuration dans le registre des activités de traitement. Planifiez une revue semestrielle des enregistrements DNS et une rotation DKIM annuelle.

Cas pratique : Fiduciaire Dupont & Associés, Sion, 35 collaborateurs

Contexte : Cabinet fiduciaire en Valais, 35 employés, domaine dupont-fiduciaire.ch. Messagerie Microsoft 365 Business Premium (CHF 22/utilisateur/mois). Envoi de newsletters fiscales via Brevo (plan payant). Scanner Ricoh en réseau configuré pour envoyer des PDF signés par email. Aucun enregistrement DMARC au départ, SPF existant mais mal configuré (dépassement de 10 lookups).

Incident déclencheur : En mars 2024, un client reçoit un email apparemment expédié par direction@dupont-fiduciaire.ch lui demandant un virement de CHF 18 400 pour une facture urgente. L'email passe les filtres du destinataire. Le client appelle avant de virer — incident évité de justesse. Le NCSC est averti par le cabinet via le formulaire de signalement en ligne.

Diagnostic technique :

• SPF : PermError sur 12 lookups DNS — résultat traité comme neutre par de nombreux serveurs destinataires.
• DKIM : activé sur Microsoft 365 mais pas publié pour Brevo.
• DMARC : absent.

Remédiation — 4 semaines :

1. Semaine 1 : Refonte SPF. Suppression des includes redondants, utilisation du mécanisme redirect pour externaliser la liste Brevo. Résultat : 7 lookups. Passage à -all.
2. Semaine 1 : Ajout de la clé DKIM Brevo (sélecteur brevo._domainkey, RSA 2048 bits). Activation DKIM Microsoft 365 vérifiée.
3. Semaine 2 : Publication DMARC p=none avec adresse RUA interne. Traitement des rapports XML via un script Python minimaliste (50 lignes) — coût : 0 CHF.
4. Semaine 3 : Découverte dans les rapports RUA que le scanner Ricoh envoyait via une IP locale non listée dans SPF. Ajout de ip4:192.168.10.5/32 dans SPF.
5. Semaine 4 : Passage en p=quarantine. Aucune remontée d'email légitime bloqué. Validation RSSI (consultant externe).
6. Semaine 5 : Passage en p=reject. Tests croisés avec clients partenaires confirmant dmarc=pass dans les en-têtes.

Coût total de la remédiation : environ 8 heures de travail technique interne + 3 heures de consultant MSP à CHF 180/h = CHF 540 en prestations externes. Zéro achat logiciel supplémentaire. La même PME aurait payé CHF 18 400 (montant du virement frauduleux tenté) si le client avait été moins prudent — sans compter l'obligation de notification PFPDT et le risque réputationnel.

Leçon chiffrée : Le délai entre la publication de DMARC p=none et le passage en p=reject a été de 25 jours. C'est une fenêtre réaliste pour une PME sans équipe sécurité dédiée, à condition de lire les rapports RUA chaque semaine.

Checklist opérationnelle

1. ✅ Inventaire complet des sources d'envoi — Aucun service tiers oublié (newsletter, CRM, ERP, imprimante réseau, alerting).
2. ✅ SPF valide, sous 10 lookups, en -all — Testé avec dig ou un vérificateur MXToolbox-équivalent open source.
3. ✅ DKIM activé sur toutes les sources d'envoi — Clés RSA ≥ 2048 bits, sélecteurs publiés en DNS, rotation planifiée dans l'agenda.
4. ✅ DMARC publié et en p=reject — Avec adresse RUA valide et lue activement.
5. ✅ Alignement strict (adkim=s; aspf=s) vérifié — Le domaine From: correspond exactement au domaine SPF/DKIM.
6. ✅ Procédure de notification PFPDT documentée — Qui décide, dans quel délai, avec quelle template. Référence à l'art. 24 nLPD dans le registre des traitements.
7. ✅ Signalement NCSC automatisé en cas d'usurpation détectée — Lien vers le formulaire connu de l'équipe IT.
8. ✅ Revue semestrielle planifiée — DNS, sources actives, rotation des clés DKIM, mise à jour du registre OPDo.
9. ✅ Formation utilisateurs — Les collaborateurs savent qu'un email à l'adresse exacte du domaine peut être frauduleux si DMARC n'est pas en place chez le destinataire.
10. ✅ Test de bout en bout documenté — En-têtes Authentication-Results vérifiés sur au moins 3 clients de messagerie différents.

SynGuard accompagne les PME suisses dans l'audit et la mise en conformité de leur infrastructure email dans le cadre de leurs projets de sécurisation des endpoints et de conformité nLPD.

Sources

• Centre national pour la cybersécurité (NCSC) — Statistiques sur les signalements de phishing et spoofing en Suisse, conseils aux PME.
• nLPD — Loi fédérale sur la protection des données (RS 235.1) — Texte consolidé de la nouvelle LPD en vigueur depuis le 01.09.2023, notamment art. 24 (notification de violations) et art. 60–63 (sanctions).
• Préposé fédéral à la protection des données et à la transparence (PFPDT) — Autorité de surveillance, guidance sur les obligations de notification en cas de violation de données.
• Formulaire de signalement en ligne — NCSC — Procédure officielle de signalement d'incidents de cybersécurité pour les entreprises et particuliers suisses.
• CIS Benchmarks — Center for Internet Security — Référentiels de bonnes pratiques incluant les recommandations sur la cryptographie (longueur de clés DKIM, configuration DNS sécurisée).