DMARC, DKIM, SPF : sécuriser les emails B2B d'une PME suisse

Un domaine non protégé est une porte ouverte au phishing ciblé

Un attaquant peut envoyer un email depuis compta@votrefiduciaire.ch sans jamais accéder à votre infrastructure. Sans SPF, DKIM ni DMARC, le serveur de messagerie du destinataire n'a aucun moyen technique de distinguer le vrai du faux. Résultat : vos clients reçoivent une demande de virement frauduleuse sous votre identité, et vous êtes potentiellement responsable d'une violation de données au sens de la nLPD (loi fédérale sur la protection des données révisée).

Pourquoi c'est un enjeu nLPD, pas seulement technique

L'usurpation de domaine comme vecteur de violation de données

La nLPD, en vigueur depuis le 01.09.2023, impose aux responsables du traitement de mettre en œuvre des mesures techniques et organisationnelles proportionnées pour protéger les données personnelles. Si un tiers usurpe votre domaine pour soutirer des données à vos clients ou partenaires, le Préposé fédéral à la protection des données et à la transparence (PFPDT) peut considérer que l'absence de contrôles d'authentification email constitue un manque de diligence. La notification obligatoire d'une violation de données au PFPDT dans les meilleurs délais s'applique dès que des données personnelles sont compromises — même indirectement via le canal email.

Responsabilité en cas de BEC (Business Email Compromise)

Les attaques BEC représentent une part croissante des signalements reçus par le Centre national pour la cybersécurité (NCSC). Dans le contexte B2B suisse, elles ciblent typiquement les instructions de paiement, les fiduciaires, les études d'avocats et les MSP qui gèrent des accès pour compte de tiers. L'absence de DMARC en mode reject est directement exploitable : elle permet à n'importe qui d'envoyer un email authentiquement routé depuis votre domaine.

Les trois mécanismes : fonctionnement précis

SPF — Sender Policy Framework

SPF est un enregistrement DNS TXT qui liste les adresses IP autorisées à envoyer du courrier pour votre domaine. Exemple minimal :

v=spf1 ip4:185.220.10.0/24 include:_spf.google.com ~all

Le suffixe ~all (softfail) est insuffisant en production : il n'entraîne pas de rejet, seulement un marquage. En B2B, utilisez -all (hardfail) dès que votre inventaire d'expéditeurs légitimes est complet. Attention : SPF ne protège que l'enveloppe SMTP (MAIL FROM), pas l'en-tête From: visible par l'utilisateur final — d'où la nécessité de DKIM et DMARC.

DKIM — DomainKeys Identified Mail

DKIM ajoute une signature cryptographique à chaque email sortant. La clé publique est publiée en DNS (enregistrement TXT sous selector._domainkey.domaine.ch), la clé privée reste sur le serveur d'envoi. La signature couvre les en-têtes critiques (From, Subject, Date) et le corps du message. Une clé RSA de 2048 bits est le minimum acceptable en 2024 ; les clés 1024 bits sont à considérer comme compromises. La rotation des sélecteurs DKIM devrait être planifiée tous les 12 mois minimum, avec une période de chevauchement de 48 à 72 heures pour éviter les rejets pendant la propagation DNS.

DMARC — Domain-based Message Authentication, Reporting and Conformance

DMARC est la couche de politique qui lie SPF et DKIM. Il exige un alignment : le domaine dans l'en-tête From: doit correspondre au domaine validé par SPF ou DKIM. Sans alignement, même un email passant SPF peut être identifié comme usurpé.

Un enregistrement DMARC complet :

v=DMARC1; p=reject; rua=mailto:dmarc-agg@votredomaine.ch; ruf=mailto:dmarc-forensic@votredomaine.ch; pct=100; adkim=s; aspf=s

Les trois valeurs de politique : none (monitoring uniquement), quarantine (dossier spam), reject (blocage définitif). La progression recommandée est none → quarantine → reject sur 4 à 8 semaines, en analysant les rapports agrégés (RUA) pour identifier tous les flux légitimes avant d'activer le rejet total. Les paramètres adkim=s et aspf=s activent l'alignement strict — préférable en B2B même si plus contraignant pour les sous-domaines d'envoi.

Architecture DNS : pièges courants en PME

Multiplicité des expéditeurs tiers

La majorité des PME de 20 à 150 collaborateurs envoient des emails depuis plusieurs sources sans le savoir : serveur mail principal (Exchange Online / Google Workspace), outil CRM (HubSpot, Salesforce), logiciel de facturation (Abacus, Bexio), plateforme de signature électronique, outil de newsletter, et parfois un serveur applicatif interne sur port TCP 25 ou 587. Chaque source doit apparaître dans le SPF ou disposer de son propre sélecteur DKIM. Le dépassement de la limite de 10 lookups DNS dans un enregistrement SPF est une erreur fréquente qui invalide silencieusement la politique ; utilisez ip4: direct plutôt qu'une chaîne de include: imbriqués.

Sous-domaines orphelins

Les sous-domaines non utilisés pour l'envoi (marketing.domaine.ch, staging.domaine.ch) sont des vecteurs d'usurpation souvent oubliés. Publiez un enregistrement DMARC avec p=reject et un SPF v=spf1 -all sur chaque sous-domaine non expéditeur. Le paramètre sp=reject dans l'enregistrement DMARC du domaine parent couvre automatiquement les sous-domaines non configurés, mais il vaut mieux expliciter chaque cas.

Délai TTL et propagation

Lors d'une modification de politique DMARC (passage de none à quarantine), réduisez le TTL de l'enregistrement à 300 secondes (5 minutes) 24 heures avant la modification, puis restaurez-le à 3600 secondes après validation. Cela limite la fenêtre d'incohérence pendant la propagation, qui peut atteindre 48 heures sur certains résolveurs DNS tiers.

Analyse des rapports DMARC : ce que vous devez surveiller

Les rapports RUA (agrégats XML quotidiens) contiennent les IP sources, les résultats SPF/DKIM, les volumes et les politiques appliquées. Sans outillage, ils sont illisibles. Des solutions légères permettent de les parser et de les visualiser, avec alertes sur les nouvelles sources inconnues. En PME, une revue hebdomadaire des sources inconnues est suffisante en phase de stabilité ; quotidienne pendant la phase de migration vers reject.

Indicateurs d'alerte à configurer : apparition d'une IP non listée dans le SPF avec volume > 50 messages/jour ; chute soudaine du taux de réussite DKIM sous 95 % ; apparition de résultats fail sur des sous-domaines normalement silencieux. Ces signaux précèdent souvent une campagne de phishing ciblée utilisant votre domaine.

Cas pratique : fiduciaire romande de 35 collaborateurs

Contexte : Fiduciaire basée à Lausanne, 35 collaborateurs, environ 280 clients PME actifs. Messagerie Exchange Online (Microsoft 365), logiciel Abacus hébergé chez un partenaire IT, envoi de bulletins de salaire par email via une application RH tierce. Aucune configuration DMARC en place début 2024. Un client signale en mars 2024 avoir reçu un email prétendument de la fiduciaire, demandant un virement de CHF 18 400.— vers un IBAN étranger.

Audit initial (Jour 1-2) :

1. Vérification DNS : SPF en ~all, aucun enregistrement DMARC, DKIM actif uniquement pour Exchange Online (sélecteur selector1, clé 2048 bits, valide).
2. Identification des flux sortants : Exchange Online (IP range Microsoft), Abacus hébergé (IP fixe 91.x.x.x), application RH tierce (include:_spf.hrapp.ch).
3. Comptage des lookups SPF : 4 lookups — dans la limite de 10, marge suffisante.
4. Signalement de l'incident au NCSC via le formulaire de signalement en ligne. Évaluation nLPD avec le juriste : données personnelles de clients potentiellement visées → notification PFPDT dans les meilleurs délais.

Déploiement DMARC progressif (Semaines 1-4) :

1. Semaine 1 : Publication de p=none avec adresse RUA interne. SPF mis à jour en -all. DKIM activé sur Abacus (nouveau sélecteur abacus1, RSA 2048). TTL réduit à 300 s pendant les modifications.
2. Semaine 2 : Analyse des rapports RUA : 3 IP inconnues identifiées, dont 2 appartenant à un ancien prestataire de newsletter dont le contrat avait expiré. Révocation des accès et retrait du include: correspondant.
3. Semaine 3 : Passage à p=quarantine; pct=25 (25 % des emails non conformes mis en quarantaine). Monitoring renforcé pendant 5 jours — aucune régression détectée sur les flux légitimes.
4. Semaine 4 : Passage à p=reject; pct=100. Ajout de sp=reject pour les sous-domaines. Publication d'un SPF v=spf1 -all sur les sous-domaines marketing.fiduciaire.ch et staging.fiduciaire.ch.

Résultat à 30 jours : Taux de conformité DMARC : 99,3 %. Zéro faux positif sur les flux légitimes. Coût interne estimé : 6 heures DSI + 2 heures juriste. Coût outillage analyse DMARC : CHF 0.— (solution open source auto-hébergée). La fiduciaire a pu démontrer au PFPDT qu'elle avait pris des mesures correctives dans les 30 jours suivant l'incident.

Récapitulatif opérationnel

1. Inventoriez tous vos expéditeurs légitimes : serveur principal, CRM, ERP, outils RH, applications métier — avant toute modification DNS.
2. Publiez SPF en -all uniquement après avoir listé toutes les sources. Vérifiez le comptage des lookups DNS (maximum 10).
3. Activez DKIM sur chaque expéditeur avec des clés RSA 2048 bits minimum. Planifiez la rotation annuelle des sélecteurs.
4. Déployez DMARC en none d'abord, analysez les rapports RUA pendant au moins deux semaines avant de passer en quarantine.
5. Atteignez p=reject; pct=100 en 4 à 8 semaines. N'acceptez pas de rester en quarantine indéfiniment — c'est une demi-mesure.
6. Protégez les sous-domaines orphelins : SPF v=spf1 -all + DMARC p=reject sur tout sous-domaine non expéditeur.
7. Configurez des alertes sur les rapports DMARC : nouvelles IP inconnues, chute du taux DKIM, activité sur sous-domaines silencieux.
8. En cas d'incident BEC : signalez au NCSC, évaluez l'obligation de notification au PFPDT selon la nLPD, documentez les mesures correctives prises.
9. Révisez la configuration tous les 12 mois ou à chaque changement de prestataire d'envoi — les SPF deviennent rapidement obsolètes lors de migrations cloud.
10. Testez depuis l'extérieur : utilisez les outils de vérification DNS publics pour confirmer que la politique DMARC est bien lue par les résolveurs tiers.

Les outils de MDM et de gestion d'endpoints comme SynGuard couvrent la posture des terminaux, mais la sécurité email reste une couche DNS/messagerie indépendante que chaque PME doit adresser directement sur son infrastructure de domaine.

Sources

• Loi fédérale sur la protection des données (nLPD) — fedlex.admin.ch — Texte consolidé de la LPD révisée, en vigueur depuis le 01.09.2023.
• Formulaire de signalement d'incidents — NCSC — Procédure officielle de signalement des cyberincidents au Centre national pour la cybersécurité.
• Préposé fédéral à la protection des données et à la transparence (PFPDT) — Autorité de surveillance nLPD, procédures de notification de violations de données.
• CIS — Guide to Email Authentication — Recommandations CIS sur SPF, DKIM et DMARC dans le cadre des CIS Controls.
• NIST Cybersecurity Framework — Cadre de référence pour la gestion du risque cyber, applicable aux PME dans le domaine Protect/Communications.