Sécurité de la messagerie : ce que SPF, DKIM et DMARC protègent réellement

Ces trois sigles reviennent dans tous les questionnaires sécurité, et sont presque toujours mal compris. Ils protègent une chose précise : l’usurpation de votre domaine. Ils ne protègent pas vos salariés contre les courriels malveillants qu’ils reçoivent.

Ce que chacun fait

SPF publie, dans le DNS, la liste des serveurs autorisés à envoyer du courrier pour votre domaine. Le serveur destinataire vérifie que l’expéditeur figure dans cette liste.

DKIM ajoute une signature cryptographique aux messages sortants. Le destinataire vérifie, via une clé publiée dans le DNS, que le message n’a pas été altéré et provient bien de votre domaine.

DMARC relie les deux. Il indique au destinataire quoi faire lorsque les vérifications échouent — ne rien faire, mettre en quarantaine, ou rejeter — et permet de recevoir des rapports sur les tentatives.

Le point clé : SPF et DKIM sans DMARC ne produisent aucune décision. Le destinataire constate l’échec et fait ce qu’il veut.

Ce que ça protège

Un attaquant qui envoie un courriel en se faisant passer pour votre directeur financier, à destination de votre comptable ou d’un de vos clients.

C’est un risque de réputation autant que de sécurité : vos clients reçoivent des messages frauduleux portant votre nom, et c’est vous qu’ils tiendront pour responsable.

Ce que ça ne protège pas

L’hameçonnage entrant depuis un domaine légitime. Un attaquant qui utilise son propre domaine, correctement configuré, passe toutes les vérifications. Elles ne disent rien du contenu.

Les domaines ressemblants. Un domaine avec une lettre changée est un domaine différent, parfaitement authentifiable.

La compromission d’un compte réel. Un message envoyé depuis la boîte compromise d’un de vos salariés est authentique au sens technique.

Ces trois cas couvrent l’essentiel de ce qui arrive réellement dans les boîtes — d’où le fait que la sensibilisation et le signalement restent nécessaires.

Déployer sans casser vos envois

C’est là que la plupart des projets s’arrêtent : passer directement en rejet coupe des flux légitimes oubliés — outil de facturation, plateforme de recrutement, prestataire d’emailing, application métier qui envoie des notifications.

La séquence qui fonctionne :

1. Recenser tous les émetteurs légitimes. La liste est toujours plus longue que prévu. C’est un travail d’inventaire, et il révèle souvent du shadow IT.
2. Publier SPF et DKIM pour ces émetteurs.
3. Activer DMARC en mode observation, sans action, et exploiter les rapports pendant plusieurs semaines.
4. Passer en quarantaine progressivement.
5. Passer en rejet une fois les rapports stabilisés.

Compter trois à six mois sur une organisation de taille moyenne. Vouloir aller plus vite produit un incident métier et un retour arrière définitif.

Les sous-domaines et les domaines dormants

Deux angles morts fréquents.

Les sous-domaines héritent ou non de la politique selon la configuration. Un sous-domaine non couvert reste usurpable.

Les domaines que vous possédez sans les utiliser — anciennes marques, variantes défensives — doivent publier une politique de rejet explicite. Un domaine sans configuration est un domaine usurpable, même s’il n’envoie jamais de courrier.

Ce que ça change côté conformité

Ces mécanismes figurent dans la quasi-totalité des questionnaires d’assurance et des questionnaires clients. Une réponse « SPF uniquement » est de plus en plus considérée comme insuffisante.

Côté normatif, cela relève des mesures de sécurité des communications d’ISO/IEC 27002:2022 — notamment 8.20 et 8.21.

Lire les rapports sans y passer ses journées

Le mécanisme de remontée est ce qui rend le déploiement pilotable, et c’est aussi ce qui décourage : les rapports agrégés arrivent quotidiennement, au format XML, et deviennent illisibles au-delà de quelques sources d’envoi.

En pratique, une seule question compte pendant la phase de déploiement : parmi les envois qui échouent à l’authentification, lesquels sont légitimes ?

Les sources légitimes oubliées reviennent toujours des mêmes endroits, et il est plus rapide d’aller les chercher que d’attendre qu’elles apparaissent dans les rapports :

• Les plateformes d’envoi en nombre, gérées par le marketing ou la communication.
• Les applications métier qui envoient des notifications — facturation, ressources humaines, outils de billetterie interne.
• Les copieurs multifonctions configurés pour envoyer les numérisations par courriel.
• Les outils de gestion de la relation client, quand ils envoient au nom du commercial.
• Les prestataires qui communiquent pour votre compte : cabinets de recrutement, sociétés d’enquêtes, plateformes d’événementiel.

Le reste — l’essentiel du volume en échec dans un rapport typique — correspond à des usurpations, et c’est précisément ce que le passage en rejet va supprimer.

Le calendrier de durcissement

C’est l’étape où la plupart des déploiements s’arrêtent : la politique reste en observation pendant des années, ce qui ne protège de rien. Le durcissement progressif tient en quatre étapes et demande environ un trimestre.

• Observation, 4 à 6 semaines. Aucune action sur les messages, collecte des rapports, recensement des sources légitimes.
• Mise en quarantaine partielle. Application à une fraction des messages non conformes, en augmentant progressivement. Cette montée graduelle est le mécanisme de sécurité du projet : une source oubliée se manifeste sur une petite part du trafic, pas sur la totalité.
• Quarantaine complète, maintenue quelques semaines pour confirmer l’absence de faux positif.
• Rejet. C’est le seul état qui protège réellement vos destinataires, et c’est celui que vérifient les clients grands comptes et certains questionnaires d’assurance.

Le point de vigilance porte sur l’alignement : un message peut satisfaire les vérifications techniques sans que le domaine visible par le destinataire corresponde au domaine authentifié. C’est cet alignement qui bloque l’usurpation, et c’est l’erreur de configuration la plus fréquente chez les prestataires d’envoi.

Ce qui passe malgré une configuration parfaite

Le point à faire comprendre à une direction, faute de quoi le dispositif sera cru plus protecteur qu’il ne l’est.

Ces mécanismes authentifient un domaine d’envoi. Ils n’authentifient ni l’expéditeur réel, ni l’intention.

• Les domaines ressemblants. Un attaquant qui enregistre une variante proche de votre nom et configure correctement l’authentification sur ce domaine passera tous les contrôles. Il est légitime — sur son domaine.
• Le nom affiché. La plupart des clients de messagerie montrent le nom, pas l’adresse. Un message envoyé depuis une adresse quelconque avec un nom affiché correspondant à votre directeur financier s’affiche correctement chez le destinataire.
• Les comptes légitimes compromis. Un message envoyé depuis une boîte réellement détournée est authentifié sans difficulté, puisqu’il est authentique. C’est le scénario des fraudes au virement les plus efficaces, et aucun de ces mécanismes ne le traite.
• Les réponses détournées. Un champ de réponse pointant vers une adresse contrôlée par l’attaquant n’est couvert par aucune de ces vérifications.

La conséquence pratique : ces mécanismes protègent principalement vos partenaires et vos clients contre l’usurpation de votre nom. Ils protègent beaucoup moins vos propres salariés contre ce qu’ils reçoivent. Ce sont deux problèmes distincts, et le second relève du filtrage entrant, de la sensibilisation et surtout des procédures de validation des opérations sensibles.

La vérification qui prend deux minutes

Avant tout projet, un contrôle suffit à situer le point de départ : interroger les enregistrements publics de votre domaine principal, et de vos domaines secondaires.

Les trois situations rencontrées sont, par ordre de fréquence : aucune politique déclarée, une politique en observation posée il y a plusieurs années et jamais durcie, ou une politique en rejet — cas le plus rare. Les domaines secondaires et les domaines déposés à titre défensif, eux, sont presque systématiquement sans protection, alors qu’ils portent un nom crédible pour une usurpation.

Sources

• ANSSI — recommandations pour la sécurisation de la messagerie
• ISO/IEC 27002:2022, mesures 8.20 et 8.21
• CERT-FR

Aller plus loin

Ce déploiement fait partie de nos missions de sécurité, et l’état des lieux de votre configuration relève de l’audit 360.