DMARC, DKIM, SPF : protéger les emails B2B d'une PME suisse

Intro

Un attaquant envoie un email depuis factures@votre-domaine.ch à votre client clé — sans jamais toucher à vos serveurs. Si vous n'avez pas publié de politique DMARC en mode reject, cet email arrive en boîte de réception, et votre client transfère 45 000 CHF sur un IBAN frauduleux. Ce scénario représente la majorité des incidents BEC (Business Email Compromise) signalés au NCSC en Suisse ces trois dernières années.

Pourquoi ces protocoles existent et ce qu'ils couvrent réellement

SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) et DMARC (Domain-based Message Authentication, Reporting and Conformance) sont trois couches indépendantes qui se complètent. Aucune n'est suffisante seule.

SPF — déclarer qui peut envoyer

SPF est un enregistrement DNS TXT qui liste les adresses IP et les services autorisés à émettre des emails pour votre domaine. Le serveur destinataire vérifie que l'IP source figure dans cet enregistrement. Problème : SPF ne protège que l'adresse Return-Path (envelope sender), pas le champ From visible par l'utilisateur. Un phisher peut donc passer SPF tout en affichant votre domaine dans le From.

Limite technique importante : la directive ~all (softfail) ne rejette rien — elle marque simplement le message. Seule -all (hardfail) indique un refus explicite. La majorité des PME restent en ~all par défaut après configuration initiale.

DKIM — signature cryptographique du message

DKIM appose une signature numérique (RSA 2048 bits minimum, Ed25519 recommandé) sur les en-têtes et le corps du message. La clé publique est publiée en DNS sous sélecteur._domainkey.votre-domaine.ch. Le serveur destinataire vérifie la signature : toute altération en transit casse la validation.

DKIM protège l'intégrité du message, pas l'identité du domaine From. Il ne bloque pas le spoofing si DMARC n'est pas configuré pour exiger l'alignement.

DMARC — la politique qui unit les deux

DMARC publie en DNS (_dmarc.votre-domaine.ch) une politique qui précise : que faire si SPF et/ou DKIM échouent ou ne sont pas alignés avec le domaine From. Les trois modes :

• p=none — surveillance uniquement, aucun blocage. Étape initiale obligatoire pour collecter les rapports RUA/RUF.
• p=quarantine — emails suspects déviés en spam/quarantaine.
• p=reject — rejet définitif au niveau SMTP. Seul ce mode bloque le spoofing direct.

L'alignement est la clé : DMARC exige que le domaine SPF ou DKIM corresponde (aligned) au domaine du champ From. Sans alignement strict (adkim=s; aspf=s), un attaquant peut contourner la vérification via un sous-domaine.

Cadre légal suisse : nLPD et obligation de mesures techniques

La nouvelle Loi fédérale sur la protection des données (nLPD), en vigueur depuis le 01.09.2023, impose à tout responsable du traitement de prendre des mesures techniques et organisationnelles appropriées (art. 8 nLPD). L'email est le vecteur principal de traitement de données personnelles dans les PME B2B : coordonnées clients, données RH, documents contractuels.

Un spoofing de domaine qui aboutit à une exfiltration ou à une fraude impliquant des données personnelles constitue une violation de données au sens de l'art. 24 nLPD. Le responsable du traitement — votre PME — doit notifier le Préposé fédéral à la protection des données et à la transparence (PFPDT) dans les meilleurs délais si la violation présente un risque élevé pour les personnes concernées.

L'absence de SPF/DKIM/DMARC sera interprétée comme un manque de mesures de sécurité appropriées. Ce n'est pas une spéculation : le PFPDT a explicitement cité les contrôles d'authentification email parmi les mesures techniques attendues dans ses recommandations sectorielles. Pour les entités régulées (banques cantonales, gérants de fortune indépendants), la FINMA intègre ces exigences dans son cadre de cyber-résilience opérationnelle.

Déploiement étape par étape pour une PME de 20 à 150 endpoints

Pré-requis : inventaire des flux d'envoi

Avant de toucher au DNS, listez tous les systèmes qui envoient des emails depuis votre domaine :

1. Serveur de messagerie principal (Microsoft 365, Google Workspace, serveur Exchange on-prem)
2. CRM, ERP, logiciel de facturation (envoi de confirmations/factures)
3. Outil de newsletter ou de marketing automation
4. Monitoring / alertes système (Nagios, Zabbix, serveurs Linux via sendmail/postfix)
5. Formulaires web, e-commerce, portail client

Chaque source manquante dans SPF génère des faux positifs. Un inventaire incomplet est la cause n°1 d'échec lors du passage en reject.

Étape 1 — Publier SPF avec hardfail

Exemple pour une PME sur Microsoft 365 + outil de facturation externe (IP : 185.12.34.56) :

v=spf1 include:spf.protection.outlook.com ip4:185.12.34.56 -all

Contraintes à respecter : maximum 10 lookups DNS (chaque include: et mx compte), sinon SPF échoue en permerror. Utilisez ip4: et ip6: directs pour les services dont vous contrôlez les IPs fixes.

Étape 2 — Configurer DKIM sur chaque service émetteur

Pour Microsoft 365 : activer DKIM dans le portail Defender (Protection > DKIM), générer les clés, publier les deux enregistrements CNAME fournis. La longueur de clé minimale recommandée par les CIS Benchmarks est RSA 2048 bits ; préférez Ed25519 si votre stack le supporte.

Pour chaque service tiers (newsletter, ERP), générez un sélecteur distinct (mailchimp2024._domainkey, erp._domainkey) avec rotation planifiée tous les 12 mois. Documentez les sélecteurs actifs dans votre registre des actifs.

Étape 3 — Déployer DMARC en mode none, puis escalader

1. Semaines 1-4 (none) : publier v=DMARC1; p=none; rua=mailto:dmarc-reports@votre-domaine.ch; ruf=mailto:dmarc-forensics@votre-domaine.ch; pct=100. Collecter et analyser les rapports agrégés RUA (format XML, quotidien).
2. Semaines 5-8 (quarantine 10 %) : passer à p=quarantine; pct=10. Observer les faux positifs sans impacter 90 % du trafic.
3. Semaines 9-12 (quarantine 100 %) : si aucun flux légitime bloqué, monter pct=100.
4. Semaines 13+ (reject) : basculer en p=reject. C'est le seul état qui bloque le spoofing au niveau réseau.

Acteurs impliqués : DSI (configuration DNS et serveurs), RSSI (validation des politiques, analyse des rapports), prestataire de messagerie ou MSP (support technique), juriste (documentation des mesures pour conformité nLPD).

Étape 4 — Surveiller et maintenir

Les rapports RUA contiennent des données sur chaque source émettrice : IP, volume, résultat SPF/DKIM. Configurez une alerte si un nouveau domaine source apparaît avec volume > 50 messages/jour. Planifiez la rotation des clés DKIM dans votre calendrier de maintenance (rappel automatique à J-30 avant expiration). Vérifiez la validité de l'enregistrement SPF à chaque changement de prestataire email.

Pièges courants et cas limites

Forwarding et listes de diffusion

Le forwarding casse DMARC/SPF : quand un serveur intermédiaire relaie un email, l'IP source change et SPF échoue. DKIM résiste au forwarding simple, mais les listes de diffusion qui modifient l'objet ou le corps cassent DKIM. Solution : activer ARC (Authenticated Received Chain, RFC 8617) sur votre passerelle si elle le supporte, et documenter les flux de forwarding connus pour les exclure des alertes.

Sous-domaines non couverts

Un DMARC sur @votre-domaine.ch ne couvre pas automatiquement @newsletter.votre-domaine.ch. Publiez un enregistrement DMARC spécifique pour chaque sous-domaine actif, ou utilisez la directive sp=reject dans la politique parente pour les sous-domaines sans envoi légitime.

Domaines parqués et domaines défensifs

Vos domaines secondaires (votre-entreprise.com, votre-domaine.fr) enregistrés défensivement doivent aussi avoir SPF v=spf1 -all et DMARC p=reject. Un domaine parqué sans ces enregistrements est exploitable pour du phishing ciblant vos clients.

Cas pratique : fiduciaire romande, 35 collaborateurs, Lausanne

Contexte : fiduciaire de 35 collaborateurs (Lausanne, canton de Vaud), 12 associés avec accès à des données fiscales et financières de plusieurs centaines de clients PME. Parc de 42 endpoints Windows 11 + 8 MacBook. Messagerie Microsoft 365 Business Premium. Outil de génération de fiches de salaire (envoi automatique de bulletins PDF par email depuis une application RH SaaS, domaine d'envoi : salaires@fiduciaire-exemple.ch).

Situation initiale

Audit DNS réalisé par le DSI en novembre 2024 : SPF publié avec ~all (softfail), DKIM actif uniquement pour Microsoft 365, aucun enregistrement DMARC. L'application RH SaaS utilise ses propres IPs (non listées dans SPF). Résultat : 100 % des emails de l'outil RH échouent SPF chez les destinataires Exchange Online avec filtrage strict.

Incident déclencheur

Le 14.11.2024, un associé reçoit un signalement d'un client : un email reçu depuis contact@fiduciaire-exemple.ch demandant un virement de 18 500 CHF pour une prétendue régularisation fiscale urgente. L'email n'est pas passé par les serveurs de la fiduciaire. Aucun mécanisme ne l'a bloqué. Le client a failli exécuter le virement.

Procédure de remédiation (J+0 à J+45)

1. J+0 : DSI inventorie tous les services émetteurs. Résultat : Microsoft 365, outil RH SaaS (2 IPs fixes : 91.204.x.x et 91.204.x.y), formulaire de contact web (serveur mutualisé, IP dynamique → migration vers relay SMTP fixe planifiée).
2. J+1 : SPF mis à jour : v=spf1 include:spf.protection.outlook.com ip4:91.204.x.x ip4:91.204.x.y -all. Passage de ~all à -all.
3. J+2 : DKIM activé sur l'outil RH SaaS (sélecteur rh2024, RSA 2048 bits). Enregistrement DNS publié.
4. J+3 : DMARC publié en p=none, rapports RUA vers boîte dédiée surveillée par le DSI.
5. J+7 : Analyse des premiers rapports RUA : découverte d'un ancien outil de newsletter non inventorié (prestataire marketing, 3 campagnes annuelles). Ajout de l'IP dans SPF, DKIM configuré côté prestataire.
6. J+21 : Aucun flux légitime non couvert. Passage à p=quarantine; pct=100. Surveillance pendant 14 jours.
7. J+35 : Zéro faux positif. Passage à p=reject.
8. J+45 : Documentation des mesures techniques transmise au juriste pour le registre des activités de traitement (art. 12 nLPD). Signalement de l'incident initial au NCSC via le formulaire de signalement NCSC.

Coût et bénéfice

Charge interne : environ 12 heures DSI sur 45 jours. Coût externe nul (outils DNS natifs, rapports DMARC traités manuellement). Risque évité : un incident BEC similaire à celui subi par le client aurait potentiellement impliqué des données fiscales personnelles de tiers — violation nLPD avec obligation de notification PFPDT, sans compter la responsabilité civile envers le client lésé. Le virement évité (18 500 CHF) représente à lui seul un ROI immédiat.

Récapitulatif opérationnel

• Inventoriez tous les émetteurs avant toute modification DNS : ERP, CRM, newsletter, monitoring, formulaires web. Chaque source manquante génère des échecs SPF sur les emails légitimes.
• Passez SPF en -all (hardfail) dès que l'inventaire est complet. Le ~all n'apporte aucune protection réelle.
• Activez DKIM RSA 2048 bits minimum sur chaque service émetteur, avec un sélecteur distinct par service et rotation annuelle planifiée.
• Déployez DMARC en trois phases : none (collecte de rapports) → quarantine (surveillance) → reject (protection effective). Ne sautez pas les phases intermédiaires.
• Publiez DMARC sur tous vos sous-domaines et domaines défensifs (même parqués) avec p=reject.
• Traitez les rapports RUA au moins hebdomadairement pendant les deux premiers mois, puis mensuellement. Automatisez les alertes sur les nouvelles sources inconnues.
• Documentez les mesures dans votre registre des activités de traitement (art. 12 nLPD) — SPF/DKIM/DMARC constituent des mesures techniques au sens de l'art. 8.
• En cas d'incident BEC : vérifiez si des données personnelles ont été exfiltrées ou compromises. Si oui, évaluez l'obligation de notification au PFPDT et signalez l'incident au NCSC.
• Vérifiez les domaines tiers de vos prestataires critiques (avocats, fiduciaires, banques partenaires) : si leur domaine est spoofable, vous êtes exposé même si le vôtre est protégé.
• Planifiez un audit DNS annuel : chaque nouveau service SaaS ou changement de prestataire email doit déclencher une révision SPF/DKIM.

Un déploiement DMARC complet sur une PME de 20 à 150 endpoints ne nécessite pas d'outillage spécialisé pour les phases initiales — les outils DNS natifs et les rapports XML standards suffisent. Les solutions MDM et de gestion d'endpoints comme SynGuard peuvent compléter cette posture en enforçant les configurations client-side (MTA-STS, TLS obligatoire, blocage des clients email non conformes), mais la fondation reste dans le DNS.

Sources

• Loi fédérale sur la protection des données (nLPD) — fedlex.admin.ch — Texte consolidé de la nLPD en vigueur depuis le 01.09.2023, art. 8 (mesures techniques) et art. 24 (violation de données).
• Centre national pour la cybersécurité (NCSC) — Conseils aux entreprises, formulaire de signalement d'incidents cybernétiques, statistiques sur les incidents BEC en Suisse.
• Préposé fédéral à la protection des données et à la transparence (PFPDT) — Recommandations sur les mesures techniques de sécurité, procédure de notification des violations de données.
• CIS Benchmarks — Center for Internet Security — Recommandations techniques sur la configuration DKIM (longueur de clé, rotation), SPF et DMARC dans les benchmarks Exchange/Microsoft 365.
• NIST Cybersecurity Framework — nist.gov — Cadre de référence pour la gestion du risque cyber, incluant les contrôles d'authentification email dans la fonction Protect (PR.AC, PR.DS).