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

Un domaine sans DMARC est une porte ouverte à l'usurpation

Un attaquant peut envoyer aujourd'hui un email desde votre domaine (@votre-fiduciaire.ch) à vos clients sans jamais toucher à votre infrastructure — il lui suffit que votre DNS ne publie ni SPF strict, ni DKIM, ni politique DMARC. Le destinataire voit votre nom, votre domaine, et clique. Depuis le 01.09.2023, la nLPD (nouvelle Loi fédérale sur la protection des données) impose de notifier toute violation de données susceptible d'entraîner un risque élevé pour les personnes concernées — un phishing réussi via votre domaine entre clairement dans cette catégorie.

Ce que SPF, DKIM et DMARC font — et ce qu'ils ne font pas

SPF : déclarer les serveurs autorisés à envoyer

Le Sender Policy Framework (SPF, RFC 7208) est un enregistrement TXT dans votre zone DNS qui liste les adresses IP et blocs CIDR autorisés à émettre du courrier pour votre domaine. Exemple minimaliste pour une PME utilisant Microsoft 365 et un expéditeur transactionnel tiers :

v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all

Le mécanisme -all (hardfail) indique à tout serveur destinataire de rejeter tout email provenant d'une source non listée. ~all (softfail) ne fait que marquer le message — insuffisant en production. Limite technique importante : SPF ne suit pas les redirections et échoue sur le transfert de messages (forward). Il ne protège pas l'en-tête From: visible par l'utilisateur, uniquement l'enveloppe SMTP (MAIL FROM).

DKIM : signer cryptographiquement chaque message

DomainKeys Identified Mail (DKIM, RFC 6376) ajoute une signature cryptographique dans l'en-tête de chaque email. La clé publique est publiée dans votre DNS sous un sélecteur, par exemple :

selector1._domainkey.votre-fiduciaire.ch TXT "v=DKIM1; k=rsa; p=MIGfMA0G..."

La clé privée est détenue par votre serveur de messagerie ou votre prestataire. Taille minimale recommandée : 2048 bits RSA (les clés 1024 bits sont révoquées par la plupart des grands fournisseurs depuis 2023). La rotation des sélecteurs DKIM devrait intervenir au minimum tous les 12 mois. DKIM résiste aux redirections contrairement à SPF, mais ne chiffre pas le contenu : il garantit l'intégrité et l'authenticité de l'origine, pas la confidentialité.

DMARC : la politique qui orchestre SPF et DKIM

Domain-based Message Authentication, Reporting and Conformance (DMARC, RFC 7489) est l'enregistrement DNS qui définit ce que les serveurs destinataires doivent faire quand SPF ou DKIM échoue, et vers qui envoyer les rapports d'usage. Structure type :

_dmarc.votre-fiduciaire.ch TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@votre-fiduciaire.ch; ruf=mailto:dmarc-forensics@votre-fiduciaire.ch; pct=100; adkim=s; aspf=s"

Les trois niveaux de politique (p=) :

• none : monitoring uniquement, aucun filtrage. Phase initiale obligatoire pour cartographier les flux légitimes.
• quarantine : messages non conformes dirigés en spam/quarantaine. Seuil intermédiaire acceptable 4 à 8 semaines après le déploiement.
• reject : messages non conformes refusés à la connexion SMTP. Cible finale pour toute PME traitant des données personnelles.

Le paramètre pct= permet une montée en charge progressive (ex. pct=10 pour appliquer la politique à 10 % du trafic non conforme). Les rapports rua (agrégés, format XML quotidien) et ruf (forensiques, par message) permettent de détecter les sources d'envoi non référencées avant de passer à reject.

Ce que ces trois mécanismes ne couvrent pas

SPF + DKIM + DMARC protègent l'authenticité du domaine d'envoi, pas :

• Le contenu du message (chiffrement de bout en bout → S/MIME ou PGP).
• Les attaques de type lookalike domain (votre-fiduciaire-ch.com vs votre-fiduciaire.ch).
• Les comptes légitimes compromis qui envoient depuis votre propre domaine avec tous les mécanismes en règle.

Cadre légal suisse : nLPD et obligation de notification

L'article 24 de la nLPD 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 en cas de violation de données présentant un risque élevé. Un phishing réussi via usurpation de domaine qui aboutit à l'exfiltration de données clients (numéros AVS, données bancaires, contrats) est une violation au sens de la loi.

Concrètement pour une PME :

1. Détecter la violation (alertes DMARC forensiques, signalement client, logs du fournisseur de messagerie).
2. Évaluer le risque : nombre de personnes concernées, nature des données, probabilité de préjudice.
3. Si risque élevé confirmé : notifier le PFPDT via le formulaire en ligne sur edoeb.admin.ch — délai : aussi vite que possible, pas de délai fixe en heures en droit suisse (contrairement au RGPD), mais la jurisprudence européenne de 72 h est la référence pratique adoptée par de nombreux RSSI suisses.
4. Notifier les personnes concernées si le risque pour elles est élevé.
5. Documenter l'incident dans le registre des violations (exigence implicite de l'art. 24 al. 4).

Les sanctions prévues par la nLPD (art. 60 ss) peuvent atteindre 250 000 CHF pour les personnes physiques responsables — pas l'entreprise directement, contrairement au RGPD, mais le dirigeant ou le RSSI en faute. Absence de DMARC n'est pas une infraction en soi, mais elle constitue un manquement aux mesures techniques appropriées (art. 8 nLPD, principe de sécurité), invocable comme circonstance aggravante.

Le Centre national pour la cybersécurité (NCSC) publie régulièrement des bulletins sur les campagnes de phishing ciblant les PME suisses et recommande explicitement DMARC à politique reject comme mesure de base.

Déploiement pas-à-pas pour une PME de 20 à 150 employés

Phase 1 — Audit de l'existant (J1 à J5)

1. Lister tous les domaines envoyant des emails : domaine principal, sous-domaines utilisés par CRM/ERP/marketing, domaines de redirection.
2. Pour chaque domaine, interroger le DNS : dig TXT votre-domaine.ch, dig TXT _dmarc.votre-domaine.ch, dig TXT selector._domainkey.votre-domaine.ch.
3. Identifier tous les expéditeurs légitimes : serveur SMTP interne, Microsoft 365 / Google Workspace, plateforme de facturation, newsletter, outil de signature électronique.
4. Vérifier les enregistrements MX et la présence éventuelle d'un SPF existant. Un SPF avec +all ou sans all final est dangereux — à corriger immédiatement.

Phase 2 — Déploiement SPF et DKIM (J6 à J15)

1. Publier l'enregistrement SPF en -all, en listant tous les expéditeurs identifiés à la phase 1. Attention : la limite est de 10 lookups DNS dans un enregistrement SPF ; au-delà, utiliser des mécanismes ip4:/ip6: directs plutôt que des include: en chaîne.
2. Activer DKIM sur chaque plateforme d'envoi (génération du sélecteur et de la paire de clés, publication de la clé publique dans le DNS).
3. Attendre la propagation DNS (TTL habituel : 300 à 3 600 secondes) puis vérifier avec un outil comme nslookup ou un vérificateur DKIM en ligne (non requis pour ce guide).

Phase 3 — DMARC en mode monitoring (J16 à J45)

1. Publier p=none; rua=mailto:dmarc@votre-domaine.ch; pct=100.
2. Configurer une boîte dédiée ou un outil de parsing XML (les rapports agrégés sont en XML brut, illisibles sans traitement). Plusieurs solutions open source existent (parseDMARC, dmarc_viewer).
3. Analyser pendant 4 semaines les sources qui envoient en votre nom : identifier les expéditeurs légitimes manquants dans SPF, corriger.

Phase 4 — Montée en quarantine puis reject (J46 à J75)

1. Passer à p=quarantine; pct=25, puis pct=100 après 1 semaine sans incident.
2. Après validation complète (zéro faux positif sur 2 semaines), passer à p=reject; pct=100.
3. Conserver la surveillance des rapports rua en continu — un nouveau prestataire SaaS non référencé dans SPF peut casser silencieusement les emails transactionnels.

Cas pratique : fiduciaire vaudoise, 45 employés

Contexte : Fiduciaire basée à Lausanne, 45 collaborateurs, domaine principal fiduciaire-exemple.ch, utilisation de Microsoft 365 pour la messagerie, d'un logiciel de comptabilité cloud (envoi automatique de bulletins de salaire par email), et d'une plateforme de signature électronique tierce. Aucun enregistrement DMARC publié au démarrage du projet. SPF existant en ~all.

Incident déclencheur : En mars 2024, trois clients reçoivent un email frauduleux depuis direction@fiduciaire-exemple.ch demandant un virement urgent. L'email passe les filtres antispam car le domaine est légitime et aucune politique DMARC n'existe. Un client transfère 8 400 CHF avant de réaliser la fraude. La fiduciaire est exposée à une plainte PFPDT et à une action en responsabilité civile.

Procédure mise en œuvre :

1. J0 (détection) : Signalement par le client lésé. Le DSI identifie l'absence de DMARC via dig TXT _dmarc.fiduciaire-exemple.ch → réponse vide.
2. J0-J1 (confinement immédiat) : Publication d'un enregistrement DMARC p=quarantine; pct=100 en urgence, sans phase none (acceptable en mode réactif si SPF et DKIM sont déjà en place — ici le SPF existe, DKIM est activé sur M365 mais pas sur le logiciel comptable). Correction du SPF de ~all à -all.
3. J1 (notification) : Le dirigeant et le RSSI externe évaluent : 3 clients ciblés, données personnelles (nom, relation commerciale) exposées dans le corps du faux email. Risque élevé retenu. Notification soumise au PFPDT via edoeb.admin.ch dans les 24 heures. Signalement parallèle au NCSC (formulaire en ligne) et dépôt de plainte pénale.
4. J2-J10 : Audit des expéditeurs — le logiciel comptable envoie via un SMTP relay propre non listé dans SPF. Ajout de l'IP dans SPF. Activation de DKIM sur le relay comptable (sélecteur compta1, clé RSA 2048 bits). Publication de la clé publique dans le DNS.
5. J11-J40 : Phase monitoring avec p=none après correction pour valider les flux. Aucun faux positif détecté sur les 4 semaines d'analyse des rapports XML.
6. J41 : Passage à p=reject; pct=100. Configuration d'une alerte automatique sur les rapports forensiques (ruf) pour notification immédiate en cas de nouvelle tentative d'usurpation.

Résultat : Coût du déploiement DMARC complet : environ 1 200 CHF (temps DSI interne + RSSI externe 8 h à 150 CHF/h). Coût de l'incident sans DMARC : 8 400 CHF de préjudice client + frais juridiques estimés à 4 000–6 000 CHF + atteinte réputationnelle non chiffrée. Le PFPDT a pris acte de la notification sans ouvrir d'enquête formelle, notamment grâce aux mesures correctives immédiates documentées.

Récapitulatif opérationnel

• Auditer le DNS aujourd'hui : vérifier SPF (-all obligatoire), DKIM (sélecteurs actifs, clés ≥ 2048 bits), DMARC (présence de _dmarc). Durée : 30 minutes.
• Corriger SPF en priorité : remplacer ~all par -all, lister tous les expéditeurs (M365, G-Workspace, CRM, ERP, plateformes SaaS). Ne pas dépasser 10 lookups DNS.
• Activer DKIM sur chaque plateforme d'envoi : clé RSA 2048 bits minimum, rotation annuelle des sélecteurs planifiée dans le calendrier RSSI.
• Déployer DMARC en trois étapes : p=none (monitoring 4 semaines) → p=quarantine (2 semaines) → p=reject. Ne pas brûler les étapes sauf en mode incident.
• Monitorer les rapports rua en continu : traiter le XML, configurer une alerte sur tout nouveau domaine source non référencé dans SPF.
• Couvrir les domaines inactifs : tout domaine enregistré mais n'envoyant pas d'emails doit avoir p=reject et un SPF v=spf1 -all pour empêcher leur usurpation.
• Documenter dans le registre de traitement nLPD : les mesures techniques (SPF, DKIM, DMARC) comme contrôles de sécurité associés aux traitements impliquant des envois par email.
• Préparer la procédure de notification PFPDT avant qu'un incident survienne : formulaire, contacts, seuils de déclenchement, délai cible 24–72 h.
• Tester annuellement : envoyer un email de test depuis une IP non autorisée et vérifier que le message est bien rejeté (confirmation du fonctionnement de p=reject).
• Ne pas négliger les sous-domaines : newsletter.votre-domaine.ch, no-reply.votre-domaine.ch — chacun requiert son propre enregistrement DMARC ou est couvert par le DMARC organisationnel si correctement configuré.

SynGuard accompagne les PME romandes dans l'audit et le déploiement de ces contrôles dans le cadre d'une gestion globale de la sécurité des endpoints et de la messagerie.

Sources

• nLPD — Loi fédérale sur la protection des données (fedlex.admin.ch) — Texte consolidé en vigueur depuis le 01.09.2023, articles 8 (sécurité), 24 (notification de violations) et 60 ss (sanctions).
• Préposé fédéral à la protection des données et à la transparence (PFPDT) — Autorité de surveillance nLPD, formulaire de notification des violations de données.
• Centre national pour la cybersécurité (NCSC) — Recommandations techniques pour PME, bulletins sur les campagnes de phishing et formulaire de signalement d'incidents.
• CIS — Guide DMARC (cisecurity.org) — Recommandations pratiques CIS sur le déploiement DMARC, alignées avec les benchmarks de durcissement.
• NIST Cybersecurity Framework (nist.gov) — Référentiel de gestion du risque cyber, fonctions Protect/Detect applicables à la sécurité de la messagerie.