Ce que le fraudeur exploite réellement

L’usurpation d’email ne nécessite pas toujours de “pirater” une boîte. Dans beaucoup de cas, l’attaquant envoie un message depuis une infrastructure qu’il contrôle, en affichant votre domaine dans l’adresse d’expéditeur ou dans le champ visible par l’utilisateur. Si le domaine n’est pas correctement authentifié, certains destinataires accepteront le message, ou le classeront en courrier indésirable mais le laisseront consultable.

Pourquoi l’email reste efficace

• Faible coût, forte portée : il suffit d’envoyer des volumes importants, ou de cibler quelques interlocuteurs clés (comptabilité, direction, ADV).
• Crédibilité contextuelle : l’attaquant copie le ton, les signatures, le logo, et s’appuie sur des scénarios réalistes (changement d’IBAN, urgence de paiement, demande de RIB, validation d’un virement).
• Chaîne de confiance implicite : beaucoup de processus internes reposent encore sur “si ça vient du dirigeant / du fournisseur, c’est légitime”.

Les 3 couches à distinguer

1. Authentification technique du domaine : SPF et DKIM disent “ce message vient-il d’un serveur autorisé ?” et/ou “son contenu a-t-il été signé ?”.
2. Politique de traitement : DMARC dit “si l’authentification échoue, que doit faire le destinataire (surveiller, mettre en quarantaine, rejeter) ?”.
3. Contrôles humains et process : même avec DMARC au maximum, un message peut rester persuasif (lookalike domains, réponses à des fils existants, compromission de boîte). D’où l’importance de procédures DAF et de formation.

Conséquence pratique pour votre projet

Avant de “passer DMARC en reject”, l’objectif est de cartographier toutes les sources légitimes d’envoi (messagerie principale, CRM, facturation, support, marketing, signatures, outils RH). Cette phase explique pourquoi une approche progressive est la meilleure manière de sécuriser sans interrompre des emails critiques.

À quoi sert SPF (et ce qu’il ne fait pas)

SPF publie, dans le DNS, la liste des serveurs autorisés à envoyer des emails pour votre domaine. Le destinataire compare l’IP du serveur émetteur avec cette politique. SPF est particulièrement utile contre l’usurpation “simple” (envoi direct depuis une IP non autorisée).

Limites importantes à connaître :

• SPF peut être contourné si l’attaquant utilise un autre domaine, très proche du vôtre (lookalike).
• SPF peut échouer en cas de transfert ou de redirection d’emails (le serveur final n’est pas celui autorisé), ce qui plaide pour DKIM + DMARC.

Erreurs fréquentes qui cassent la délivrabilité

• Plusieurs enregistrements SPF : il ne doit y avoir qu’un seul enregistrement SPF par domaine.
• Accumulation de fournisseurs : ajout d’`include:` au fil des années sans nettoyage.
• Politique trop permissive : `+all` (à éviter) ou `~all` conservé “par défaut” sans stratégie DMARC.
• Oubli des sous-domaines : certains outils envoient depuis `mail.votredomaine.tld` ou `notifications.votredomaine.tld`.

Méthode concrète pour un SPF “propre”

1. Inventorier les sources d’envoi : Microsoft 365 / Google Workspace, outil de facturation, CRM, plateforme d’emailing, ticketing, formulaires web.
2. Vérifier qui envoie réellement : dans les headers des emails reçus (chemin d’acheminement) et via vos futurs rapports DMARC.
3. Consolider : supprimer les fournisseurs non utilisés, documenter chaque `include:`.
4. Choisir un mécanisme de fin : en pratique, `-all` (strict) devient réaliste quand DMARC est correctement déployé.

Exemple d’enregistrement SPF (à adapter)

• `v=spf1 include:spf.protection.outlook.com include:un-fournisseur.example -all`

Point de vigilance : les limites de requêtes DNS

SPF impose des contraintes techniques côté évaluation (notamment un plafond de recherches DNS lors du traitement). Si votre SPF grossit, vous risquez des erreurs d’évaluation et des faux négatifs. Référez-vous à la spécification SPF et privilégiez la consolidation et la réduction des dépendances DNS inutiles.

DKIM en une phrase

DKIM permet au serveur expéditeur de signer certains éléments du message (en-têtes et contenu). Le destinataire vérifie la signature via une clé publique publiée dans le DNS. Cela prouve qu’un système autorisé, configuré pour votre domaine, a signé le message et que le contenu n’a pas été altéré depuis la signature.

Pourquoi DKIM est souvent la pièce qui stabilise la délivrabilité

Quand SPF échoue (transfert, routage indirect), une signature DKIM valide peut encore permettre l’alignement DMARC si le domaine de signature correspond à votre domaine (ou sous-domaine) attendu. Résultat : moins de “faux rejets” tout en restant exigeant contre l’usurpation.

Multi-services : l’erreur classique

Beaucoup d’entreprises ont :

• une messagerie principale (ex. Microsoft 365)
• un CRM qui envoie des emails transactionnels
• un outil de facturation (relances, factures)
• une solution marketing (campagnes)

Chaque service peut signer avec DKIM, mais pas forcément avec le même sélecteur. Il faut donc :

• activer DKIM chez chaque fournisseur (quand disponible)
• publier les entrées DNS attendues (souvent des CNAME ou TXT selon le service)
• vérifier que le domaine de signature est cohérent avec votre domaine d’envoi

Rotation des clés : objectif et organisation

La rotation réduit l’impact si une clé est exposée et améliore l’hygiène opérationnelle. Concrètement :

1. Documentez le propriétaire de chaque sélecteur (IT / prestataire / outil SaaS).
2. Planifiez la rotation selon les recommandations du fournisseur et votre politique interne.
3. Conservez une capacité de retour arrière (ancien sélecteur) le temps de la transition.

Contrôles pratiques

• Valider qu’un email sortant contient un header `DKIM-Signature`.
• Vérifier, côté destinataire, que le résultat DKIM est pass.
• S’assurer que les services “oubliés” (scanners MFP, outils métiers, ERP on-prem) ne sortent pas en direct sans DKIM : idéalement, ils doivent relayer via un service qui signe.

DMARC : la règle du jeu pour les destinataires

DMARC relie SPF et DKIM à une exigence clé : l’alignement. Autrement dit, ce n’est pas suffisant que SPF ou DKIM passe ; il faut que le domaine authentifié corresponde au domaine visible (le domaine du champ From). DMARC permet ensuite de publier une politique :

• `p=none` : surveiller (monitoring)
• `p=quarantine` : traiter comme suspect (souvent dossier spam)
• `p=reject` : refuser la livraison

Démarche progressive recommandée

1) Démarrer en monitoring (p=none)

Objectif : voir qui envoie en votre nom avant d’appliquer des sanctions.

• Publier un enregistrement DMARC avec `rua=` (rapports agrégés).
• Laisser tourner suffisamment longtemps pour couvrir vos cycles d’activité (facturation, fins de mois, campagnes, relances).

Exemple (à adapter) :

• `v=DMARC1; p=none; rua=mailto:dmarc@votredomaine.tld; adkim=s; aspf=s; fo=1`

2) Corriger l’alignement et les “vrais” émetteurs

À partir des rapports :

• repérer les services légitimes non alignés
• activer DKIM (ou ajuster le domaine d’envoi) pour qu’ils s’alignent
• éliminer les sources inconnues (usurpation) sans impacter les métiers

3) Passer à quarantine puis reject

Montez progressivement :

1. `p=quarantine` pour observer l’impact en conditions réelles.
2. `p=reject` quand la majorité des flux légitimes est alignée.

Vous pouvez utiliser `pct=` pour appliquer la politique à une partie des messages, afin de réduire le risque lors de la montée en charge.

Sous-domaines : ne pas les oublier

• Si des sous-domaines envoient (ex. `notifications.`), publiez DMARC au bon niveau ou utilisez `sp=`.
• Vérifiez la cohérence entre le domaine visible, SPF, et la signature DKIM.

Point clé : la boucle d’amélioration

DMARC n’est pas “mettre un TXT et oublier”. C’est un pilotage : rapports, corrections, puis durcissement. Bien mené, c’est le chemin le plus sûr vers `p=reject` sans interrompre factures, devis et messages transactionnels.

Pourquoi SPF/DKIM/DMARC ne suffisent pas seuls

Ces mécanismes protègent votre domaine contre l’usurpation, mais ils ne bloquent pas :

• les domaines ressemblants (ex. fautes de frappe)
• les boîtes compromises chez un partenaire légitime
• certains scénarios de fraude par “conversation” (réponses, relances, pression temporelle)

Il faut donc ajouter des couches complémentaires.

Filtrage et durcissement côté messagerie

• Activer des politiques anti-phishing/anti-spam adaptées (protection contre l’usurpation d’affichage, liens malveillants, pièces jointes à risque).
• Surveiller les faux positifs sur les emails métiers (facturation, commandes, support) et mettre en place un processus de déblocage tracé.
• Harmoniser les règles entre messagerie interne et passerelles externes éventuelles.

Bannière “expéditeur externe” : utile, mais à cadrer

Ajouter une bannière sur les emails venant de l’extérieur peut réduire les erreurs de jugement, notamment pour les demandes sensibles. Points d’attention :

• éviter une bannière trop verbeuse que les utilisateurs ne lisent plus
• exclure des flux techniques internes si cela génère du bruit
• accompagner le déploiement d’un rappel de procédure (quoi faire en cas de doute)

Sensibilisation ciblée (DAF/finance, ADV, direction)

Préférez des scénarios concrets :

• changement d’IBAN
• urgence “confidentielle”
• nouveau fournisseur
• demande de validation en dehors du circuit habituel

Procédures DAF anti-fraude (le vrai filet de sécurité)

Mettez en place des règles opérationnelles qui ne dépendent pas de l’email :

1. Double contrôle pour tout changement de coordonnées bancaires (appel sur un numéro connu, pas celui de l’email).
2. Séparation des rôles : la personne qui reçoit la demande n’est pas celle qui valide.
3. Canal secondaire obligatoire pour les montants sensibles (outil interne, validation signée, ticketing).
4. Journalisation : qui a demandé, qui a validé, sur quelle base.

L’objectif est simple : même si un email trompeur passe, il ne doit pas suffire à déclencher un paiement.

Checklist de validation (avant de durcir DMARC)

DNS et cohérence

• Un seul enregistrement SPF sur le domaine.
• SPF documenté : chaque `include:` correspond à un service réellement utilisé.
• DKIM activé sur la messagerie principale et les services critiques (facturation, CRM, marketing, support).
• DMARC publié et syntaxiquement valide (vérifié via un outil de contrôle DNS).

Alignement et tests fonctionnels

• Envoyer des emails de test vers plusieurs fournisseurs (boîtes externes) et vérifier :

- SPF=pass quand applicable - DKIM=pass - DMARC=pass sur les emails légitimes

• Vérifier les flux “à haut risque métier” :

- factures et relances - devis / bons de commande - emails transactionnels applicatifs - confirmations d’inscription / réinitialisations de mot de passe

Pilotage des rapports DMARC

• `rua=` pointe vers une boîte/solution réellement surveillée.
• Les rapports sont analysés : identification des sources inconnues et des sources légitimes non alignées.
• Une décision est actée pour chaque source : corriger, migrer, ou couper.

Plan de montée en puissance (sans chiffre arbitraire)

1. p=none : collecte et correction.
2. p=quarantine : validation en situation réelle, traitement des cas résiduels.
3. p=reject : verrouillage, puis surveillance continue.

Plan de rollback (si un flux légitime est impacté)

1. Identifier rapidement le flux concerné (type d’email, application, domaine/sous-domaine, fournisseur).
2. Mesure immédiate : revenir temporairement à une politique moins stricte (`p=none` ou `p=quarantine`) le temps de corriger.
3. Correction durable :

- activer DKIM chez le fournisseur, ou - changer le domaine d’envoi pour l’alignement, ou - faire relayer via votre messagerie qui signe, ou - isoler un sous-domaine avec une politique adaptée.

1. Revalidation : renvoyer des tests, vérifier dans les rapports DMARC, puis redurcir.

Tableau de dépannage rapide