DMARC, DKIM, SPF pour PME suisses

Un email usurpant votre domaine suffit à compromettre un virement, exfiltrer des données clients ou déclencher une violation nLPD. SPF, DKIM et DMARC sont les trois contrôles qui l'empêchent — et la majorité des PME romandes ne les ont pas tous en place.

Un domaine sans DMARC est une porte ouverte au spoofing

Chaque semaine, des PME suisses reçoivent des demandes de virement ou de modification de données bancaires envoyées depuis un domaine qui ressemble à celui d'un fournisseur légitime — ou pire, qui est exactement leur propre domaine. Sans SPF, DKIM et DMARC correctement configurés, n'importe quel serveur SMTP peut émettre un email au nom de votrePME.ch avec un taux de délivrabilité proche de 100 %.

Ce guide couvre la mécanique de chaque standard, leur articulation, les exigences de conformité liées à la nLPD, et une procédure de déploiement calibrée pour un parc de 20 à 150 endpoints.

Pourquoi ces trois standards sont devenus incontournables

Le problème fondamental du protocole SMTP

SMTP date de 1982 et n'intègre aucune authentification de l'expéditeur. L'en-tête From: est libre — n'importe qui peut y inscrire direction@monentreprise.ch. Les trois mécanismes SPF, DKIM et DMARC ont été développés indépendamment puis articulés pour combler ce vide :

SPF (Sender Policy Framework) — enregistrement DNS TXT qui liste les adresses IP autorisées à émettre pour votre domaine.
DKIM (DomainKeys Identified Mail) — signature cryptographique ajoutée à chaque email, vérifiable via une clé publique publiée en DNS.
DMARC (Domain-based Message Authentication, Reporting and Conformance) — politique DNS qui indique aux serveurs destinataires comment traiter les emails qui échouent à SPF ou DKIM, et où envoyer les rapports agrégés.

Threat landscape en Suisse romande

Le NCSC recense régulièrement des campagnes de Business Email Compromise (BEC) ciblant des PME helvétiques. Les vecteurs dominants sont :

Usurpation exacte du domaine (exact-match spoofing) — bloquée par DMARC p=reject.
Domaines sosies (lookalike domains, ex. monentreprise-ch.com) — non bloquée par DMARC mais détectable via monitoring DNS.
Compromission de boîte mail réelle — DMARC ne protège pas contre ça ; c'est le rôle du MFA et d'une politique d'accès conditionnel.

Les pertes financières par incident BEC se situent typiquement entre CHF 15 000 et CHF 250 000 pour une PME de moins de 100 collaborateurs, selon les données publiques du NCSC.

Architecture technique : SPF, DKIM, DMARC en détail

SPF : ce qu'il fait et ce qu'il ne fait pas

Un enregistrement SPF correct pour une PME utilisant un seul fournisseur cloud ressemble à :

v=spf1 include:_spf.google.com include:_spf.protection.outlook.com ~all

Points critiques :

La directive finale -all (hard fail) est préférable à ~all (soft fail) dès que l'inventaire des sources SMTP est stabilisé.
SPF ne protège que l'enveloppe SMTP (MAIL FROM), pas l'en-tête From: visible par l'utilisateur. C'est DMARC qui fait le lien.
Limite dure de 10 lookups DNS : au-delà, SPF échoue par spécification. Les PME avec de nombreux services SaaS (Mailchimp, HubSpot, Zendesk, Jira…) doivent soit aplatir les includes (SPF flattening), soit router tout l'email sortant via un relais unique.

DKIM : signature et rotation de clés

DKIM signe cryptographiquement un sous-ensemble des en-têtes et le corps du message. La clé privée réside sur le serveur SMTP émetteur ; la clé publique est publiée en DNS sous un sélecteur :

selector._domainkey.monentreprise.ch  IN TXT  "v=DKIM1; k=rsa; p=MIGfMA0G..."

Recommandations de configuration :

Longueur de clé : RSA 2048 bits minimum — les clés 1024 bits sont considérées insuffisantes depuis 2013.
Rotation : planifiez une rotation annuelle minimum. La plupart des ESPs (Email Service Providers) gèrent la rotation automatiquement si vous leur déléguez la gestion DNS du sélecteur.
Sélecteurs multiples : si vous utilisez plusieurs ESPs (transactionnel + marketing), chacun doit avoir son propre sélecteur DKIM.

DMARC : la politique qui donne du sens aux deux premiers

Sans DMARC, SPF et DKIM sont des signaux que chaque serveur destinataire interprète à sa guise. DMARC standardise la réponse :

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

Les trois niveaux de politique :

p=none — mode monitoring. Aucune action ; les rapports arrivent mais les emails non authentifiés sont livrés normalement. Phase initiale obligatoire.
p=quarantine — les emails suspects partent en spam/quarantaine. Phase intermédiaire, 2-4 semaines.
p=reject — les emails non authentifiés sont refusés à la réception. Cible finale pour tout domaine professionnel.

Le paramètre rua (rapport agrégé, format XML quotidien) est essentiel : il vous indique quels serveurs émettent au nom de votre domaine, légitimes ou non. Sans cette visibilité, vous déployez DMARC à l'aveugle.

DMARC requiert l'alignement : le domaine de l'en-tête From: doit correspondre au domaine SPF authentifié (aspf) ou au domaine signataire DKIM (adkim). C'est cet alignement qui ferme la porte au spoofing de l'en-tête visible.

Conformité nLPD et implications pour les PME suisses

Obligation de sécurité technique

La nLPD (en vigueur depuis le 01.09.2023) impose aux responsables du traitement de prendre les mesures techniques et organisationnelles appropriées pour protéger les données personnelles contre tout traitement non autorisé — ce qui inclut explicitement leur exfiltration par ingénierie sociale facilitée par un email spoofé. L'absence de DMARC sur un domaine qui traite des données personnelles (clients, RH, santé, données financières) peut être retenue comme manque de diligence en cas d'incident.

Notification au PFPDT

Si une campagne de phishing exploitant votre domaine conduit à une violation de données personnelles (ex. un collaborateur clique sur un lien, ses identifiants sont volés, des données clients sont exfiltrées), la notification au PFPDT devient obligatoire dans les 72 heures si le risque pour les personnes concernées est vraisemblable. L'absence de mesures d'authentification email sera un facteur aggravant dans l'évaluation du traitement de l'incident.

Secteurs régulés

Pour les PME sous supervision FINMA (gestionnaires de fortune indépendants, direction de fonds), les circulaires sur les risques opérationnels et la cybersécurité imposent une gestion active des vecteurs d'attaque email. L'authentification SPF/DKIM/DMARC fait partie des contrôles attendus lors des audits.

Déploiement étape par étape pour une PME de 20-150 collaborateurs

Cette procédure suppose un domaine principal hébergé chez un registrar suisse (Infomaniak, Hostpoint, Switch) avec accès à la zone DNS.

Inventaire des sources SMTP (J1-J3) — DSI : listez tous les services qui émettent des emails au nom de votre domaine : serveur Exchange/M365, Google Workspace, outils marketing, CRM, plateforme de facturation, monitoring (Zabbix, Grafana), imprimantes multifonctions. Chaque source doit être documentée avec son IP ou son range CIDR.
Publication de SPF (J3-J5) — DSI : créez l'enregistrement TXT en incluant uniquement les sources identifiées. Commencez avec ~all (soft fail). Validez avec dig TXT monentreprise.ch ou un outil comme MXToolbox (vérifiez que le résultat ne dépasse pas 10 lookups).
Activation DKIM sur chaque source (J3-J10) — DSI : activez DKIM dans votre ESP (M365 : Exchange Admin Center > DomainKeys ; Google Workspace : Admin Console > Apps > Gmail > Authenticate email). Publiez la clé publique dans votre DNS. Vérifiez la signature avec dig TXT selector._domainkey.monentreprise.ch.
Publication DMARC en mode p=none (J10) — DSI + RSSI : publiez l'enregistrement avec une adresse rua fonctionnelle. Attendez 7 à 14 jours de rapports agrégés. Analysez les rapports XML (parseur recommandé : dmarcian, parsedmarc en self-hosted) pour identifier les sources légitimes manquantes ou les sources inconnues.
Correction des anomalies (J14-J21) — DSI : ajoutez au SPF les sources légitimes omises. Bloquez ou redirigez via relais les sources qui ne supportent pas DKIM. Documentez les exceptions (ex. imprimante qui ne supporte pas DKIM : routez via un relais SMTP interne qui signe).
Passage à p=quarantine (J21-J35) — DSI + RSSI : vérifiez que les rapports ne montrent plus de sources légitimes non authentifiées. Informez les utilisateurs qu'ils pourraient voir des emails internes arriver en spam pendant la transition. Surveillez les faux positifs.
Passage à p=reject (J35+) — RSSI (validation) : une fois les rapports stables pendant 7 jours consécutifs sans faux positifs, passez en reject. Mettez à jour la documentation et planifiez une revue trimestrielle des rapports DMARC.
Passage SPF en -all (simultané à reject) — DSI : renforcez SPF en hard fail maintenant que toutes les sources légitimes sont identifiées.
Surveillance continue — DSI ou MSP : configurez une alerte si le volume d'échecs DMARC dépasse un seuil (ex. >50 failures/jour sur un domaine qui émet normalement 200 emails/jour).

Cas pratique : fiduciaire vaudoise de 35 collaborateurs

Contexte : Cabinet fiduciaire basé à Lausanne, 35 collaborateurs, domaine fiduciaire-exemple.ch, Microsoft 365 comme suite principale, plus un logiciel de comptabilité (Abacus) qui envoie des rappels de paiement clients, et un outil de signature électronique (DocuSign). En octobre 2023, le DSI reçoit une alerte d'un client : il a reçu un email prétendant venir du partenaire principal de la fiduciaire, lui demandant de modifier les coordonnées bancaires pour le prochain virement. L'email a été émis depuis un serveur tiers non autorisé avec l'en-tête From: info@fiduciaire-exemple.ch. Il est passé sans encombre car le domaine n'avait ni DKIM activé sur M365, ni DMARC.

Analyse des sources SMTP : Inventaire révèle 4 sources — M365 (principal), serveur SMTP Abacus (IP fixe 185.x.x.x), DocuSign (include DNS fourni par DocuSign), et une ancienne instance Outlook on-premises encore active pour un associé. Total : 4 sources, 7 DNS lookups SPF après optimisation.

Timeline de déploiement :

J1-J3 : SPF publié avec ~all, DKIM activé sur M365 (sélecteur selector1) et DocuSign (sélecteur docusign). Le serveur Abacus ne supporte pas DKIM natif — relais SMTP interne configuré sur Exchange pour signer les sorties Abacus.
J4 : DMARC p=none publié. Adresse rua : boîte fonctionnelle surveillée par le DSI.
J5-J18 : Analyse des rapports XML. Découverte de 3 sources inconnues émettant depuis des ranges IP asiatiques — tentatives de spoofing en cours. Découverte d'une 5e source légitime oubliée : système de monitoring Zabbix avec alertes email. Ajouté au SPF.
J18-J32 : DMARC p=quarantine. Zéro faux positif après correction. Les sources inconnues continuent d'émettre mais arrivent désormais en quarantaine chez les destinataires Gmail et M365.
J32 : DMARC p=reject + SPF -all. Le volume de spoofing détecté tombe de ~80 tentatives/semaine à ~5 (domaines sosies non couverts par DMARC).

Coût et effort : 2,5 jours DSI sur 5 semaines, aucun coût logiciel additionnel. La fiduciaire utilise parsedmarc en mode conteneur Docker sur un VPS existant pour lire les rapports XML — coût infrastructure : CHF 8/mois. L'incident initial (demande de modification bancaire) n'a pas abouti car le client a appelé pour vérifier, mais sans DMARC, la prochaine tentative aurait eu les mêmes chances de succès.

Obligation nLPD : La fiduciaire traite des données financières et fiscales de personnes physiques. L'absence de DMARC dans ce contexte représentait un risque documenté. Depuis le déploiement, le RSSI (externalisé, mi-temps) a intégré la revue mensuelle des rapports DMARC dans le registre des mesures de sécurité technique — élément tangible en cas d'audit ou de demande du PFPDT.

Récapitulatif opérationnel

Inventoriez toutes les sources SMTP émettrices pour votre domaine avant de toucher au DNS — une source oubliée en phase p=reject bloque des emails légitimes.
Publiez SPF avec ~all d'abord ; passez à -all uniquement quand DMARC est en reject et que les rapports sont stables.
Activez DKIM avec des clés RSA 2048 bits minimum sur chaque source ; planifiez la rotation annuelle dans votre calendrier de sécurité.
Déployez DMARC en trois phases : p=none (monitoring, 2 semaines min.) → p=quarantine (2-4 semaines) → p=reject (cible finale).
Configurez l'adresse rua et traitez réellement les rapports agrégés — sans lecture des rapports, DMARC est borgne.
Documentez le déploiement et les sources autorisées dans votre registre des mesures techniques (exigence nLPD Art. 8 OPDo).
Protégez aussi vos sous-domaines et domaines de parking avec une politique DMARC p=reject — un domaine inactif ancien-nom.ch sans DMARC est aussi exploitable.
Complétez avec BIMI (Brand Indicators for Message Identification) si la notoriété de votre marque le justifie — requiert DMARC p=reject ou quarantine comme prérequis.
Signalez toute campagne de spoofing active exploitant votre domaine via le formulaire de signalement du NCSC.
Réévaluez la configuration à chaque changement de fournisseur d'email ou ajout d'un SaaS émettant des emails — c'est le moment le plus fréquent de régression SPF.

Les PME qui souhaitent externaliser la surveillance continue de leurs rapports DMARC ou intégrer ces contrôles dans une politique d'accès conditionnel plus large peuvent s'appuyer sur des solutions MDM et de gestion d'endpoints comme SynGuard pour coordonner la visibilité sur l'ensemble des vecteurs d'attaque.

Sources

Loi fédérale sur la protection des données (nLPD) — fedlex.admin.ch — Texte consolidé de la nouvelle LPD en vigueur depuis le 01.09.2023, base légale des obligations de sécurité technique.
Centre national pour la cybersécurité (NCSC) — Alertes, statistiques d'incidents, conseils techniques pour PME suisses, formulaire de signalement.
Préposé fédéral à la protection des données et à la transparence (PFPDT) — Autorité de contrôle nLPD, procédure de notification des violations de données.
CIS — Using DMARC, DKIM, and SPF to Prevent Spoofing — Référence technique du Center for Internet Security sur l'articulation des trois standards.
NIST SP 800-177 Rev. 1 — Trustworthy Email — Publication spéciale NIST détaillant les bonnes pratiques de déploiement SPF, DKIM et DMARC.

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