SPF, DKIM, DMARC, CAA : améliorer seul et gratuitement sa cybersécurité

16/09/2026 5409 mots 26 minutes

Contenu

En tant que lecteur fidèle et régulier de ce blog, vous recevez peut-être des propositions régulières de diagnostics de sécurité gratuits (ou pas) sur votre “exposition publique”. Les rapports vous alerteront probablement sur le fait que vos “entrées DNS” ne sont pas bonnes et présentent un risque pour vous. Ces diagnostics, vous pouvez bien entendu les faire par vous-mêmes. Ils sont réalisables d’ailleurs facilement et gratuitement sur Internet, et encore plus facilement pour ces entreprises avec l’arrivée de l’IA, car ils sont générés automatiquement à partir de données publiques. Dans cet article, je vais essayer de démystifier un peu ces acronymes, et vous donner des pistes pour mieux comprendre leur intérêt. Pour les experts en cybersécurité parmi vous, vous m’excuserez de simplifier parfois les choses, chaque standard derrière regroupant à lui seul souvent des dizaines de pages de spécifications et de complexité.

Mais n’oubliez jamais. Derrière une vulnérabilité potentielle, il faut mesurer un risque. Parce qu’une liste de vulnérabilités sans évaluation des risques conduit à traiter en premier ce qui compte… le moins (pour vous).

Le vocabulaire, traduit

À quoi sert SPF ?

SPF publie, dans l’annuaire de votre domaine, la liste des serveurs autorisés à expédier du courriel en son nom [1]. Ainsi, un serveur qui reçoit un courriel de votre nom de domaine compare l’adresse du serveur expéditeur à cette liste. Par exemple, une entreprise qui utiliserait Microsoft 365 y déclare Microsoft, plus son outil d’infolettre (newsletter) et son logiciel de facturation s’ils envoient en son nom. C’est donc une déclaration que vous devez faire, parce que seul vous connaissez correctement (oui ? non ?) les services autorisés à émettre un courriel. Précision qui compte pour la suite, SPF contrôle le domaine de l’adresse d’enveloppe, celle qui sert aux retours d’erreur et que le lecteur ne voit pas. L’adresse affichée dans le client de messagerie peut être différente, et DMARC fera le lien entre les deux.

L’enregistrement se termine par une consigne. Le -all demande de rejeter tout ce qui n’est pas dans la liste, le ~all (notez le tilde) de le traiter avec méfiance sans le rejeter, le ?all de ne rien en conclure. Un SPF qui se termine par ?all ne sert à rien. Le -all est la forme la plus stricte, et le ~all devient acceptable une fois DMARC en place, car DMARC ne retient de SPF que le résultat, réussi ou non, et le ~all évite qu’un serveur destinataire refuse un message transféré avant d’avoir consulté votre politique. Dernier piège, très fréquent dans les audits, l’évaluation de l’enregistrement ne doit pas exiger plus de 10 consultations DNS, faute de quoi il est déclaré en erreur et ignoré. Les include: de prestataires s’additionnent vite et franchissent cette limite sans qu’on s’en aperçoive.

À quoi sert DKIM ?

DKIM appose sur chaque message sortant une signature cryptographique, calculée par le serveur d’envoi avec une clé privée [2]. La clé publique correspondante est publiée dans l’annuaire du domaine. Le destinataire vérifie que la signature correspond et que le message n’a pas été altéré en route. Le rêve.

La clé publique se trouve à une adresse construite avec un identifiant appelé sélecteur, choisi librement par l’expéditeur. Ce détail a une conséquence pratique : le sélecteur ne se devine pas de façon fiable depuis l’extérieur. Les outils d’audit essaient les valeurs courantes, selector1 et selector2 chez Microsoft, google chez Google, et concluent à tort à l’absence de DKIM quand le nom choisi est moins conventionnel. Le sélecteur se lit dans l’en-tête d’un message reçu. Un diagnostic qui n’a jamais reçu de message d’une entreprise ne peut donc rien conclure de sûr sur son DKIM… juste en analysant une entrée DNS.

À quoi sert DMARC ?

DMARC dit au serveur destinataire que faire [3] d’un message pour lequel ni SPF ni DKIM ne valident le domaine affiché dans l’adresse d’expéditeur, ce que la norme appelle l’alignement : ne rien changer avec p=none, mettre en indésirable avec p=quarantine, refuser avec p=reject. Il demande aussi l’envoi de rapports quotidiens à une adresse de votre choix, qui récapitulent qui a envoyé du courriel au nom du domaine et avec quel résultat.

Ces rapports constituent la partie la plus utile du dispositif, et presque personne ne les ouvre. Ils révèlent les services oubliés qui envoient encore au nom de l’entreprise, l’ancien prestataire de recrutement, la plateforme de signature électronique abandonnée et donc, potentiellement, une tentative d’usurpation en cours.

Et les trois, posés ensemble, apportent un niveau de sécurité sympathique. Ils sont encore trop peu utilisés dans ce que j’ai pu constater, soit parce qu’on ne sait pas faire, soit parce que le prestataire informatique gère, soit parce qu’on ne l’a pas demandé au prestataire informatique…

Mais ce n’est pas fini…

MTA-STS et TLS-RPT, qu’est-ce que c’est ?

MTA-STS impose que la connexion entre deux serveurs de messagerie soit chiffrée et que le certificat du serveur d’arrivée soit valide [4]. Sans lui, le chiffrement du transport reste facultatif et se contourne. TLS-RPT est le mécanisme de rapport associé : il vous signale les échecs de chiffrement constatés par vos correspondants [5]. Une autre voie, DANE, obtient le même résultat en publiant l’empreinte du certificat dans le DNS, ce qui suppose DNSSEC [6]. Elle est répandue chez les hébergeurs néerlandais et allemands, et les outils de test européens cités plus bas la vérifient.

À quoi sert DNSSEC ?

Les réponses de l’annuaire du domaine circulent par défaut sans preuve d’origine. DNSSEC les signe, de sorte qu’un résolveur puisse vérifier qu’elles proviennent bien du détenteur du domaine et n’ont pas été fabriquées en chemin. La plupart des bureaux d’enregistrement français l’activent d’une simple case à cocher, et OVHcloud l’active par défaut sur les zones qu’il héberge [7].

À quoi sert CAA ?

Plus d’une centaine d’autorités de certification sont reconnues par les navigateurs, et chacune pourrait (techniquement) produire un certificat valide pour n’importe quel nom de domaine. L’enregistrement CAA restreint cette liste à celles que vous utilisez réellement [8]. Un second paramètre, iodef, demande aux autorités de vous signaler par courriel toute demande non conforme, ce qui transformerait l’enregistrement en détecteur. La norme laisse ce signalement facultatif et aucune autorité connue ne l’envoie aujourd’hui, Let’s Encrypt compris [9]. L’enregistrement n’agit qu’au moment de l’émission, il ne révoque rien de ce qui existe déjà. La documentation de Let’s Encrypt en donne la syntaxe (…et les pièges) [10].

Que sont les journaux de transparence des certificats électroniques ?

Toute émission de certificat électronique reconnu par les navigateurs Internet est inscrite dans des registres publics et vérifiables [11]. C’est comme cela. Le dispositif existe pour détecter les certificats frauduleux, et il a un effet de bord que peu d’équipes techniques anticipent : demander un certificat pour preprod-portail.armement.fr publie ce nom pour toujours. Consulter ces registres ne demande aucune compétence et ne laisse aucune trace chez celui qu’on regarde. Ces outils sont activement utilisés par les attaquants et autres moteurs automatisés pour identifier tous vos outils de production (et donc, de préproduction). J’ai fait le test sur ma propre infra : il a suffi de 15 minutes entre la génération d’un certificat électronique et les premiers tests automatisés d’intrusion… Classe. Là aussi, une fois que le certificat est généré, c’est à vie qu’il aura eu une existence.

Faut-il un certificat joker ?

Un certificat joker, de la forme *.armement.fr, couvre tous les sous-domaines d’un coup. Il évite la gestion d’un certificat par service et n’inscrit qu’une seule entrée dans les registres publics. En contrepartie, sa clé privée se retrouve recopiée sur chaque machine qui en a besoin, du frontal public… au serveur de recette administré par un prestataire. La compromission de l’une de ces machines livre un certificat valide pour l’ensemble du domaine. A utiliser avec précaution.

À quoi sert HSTS ?

HSTS est un en-tête envoyé par le site, qui ordonne au navigateur de n’utiliser que HTTPS pour ses visites suivantes [12]. Il protège les visites suivantes et laisse ouverte la fenêtre du tout premier contact, celui où le navigateur essaie encore HTTP, puisque l’en-tête n’a pas encore été reçu. L’inscription sur la liste de préchargement des navigateurs ferme cette fenêtre [13].

À quoi sert CSP ?

CSP, pour Content Security Policy, est un autre en-tête envoyé par le site, qui indique au navigateur d’où la page a le droit de charger ses scripts, ses feuilles de style, ses images et vers qui elle peut envoyer des formulaires [14]. Un script injecté dans une page par une extension vulnérable ou un commentaire mal filtré ne s’exécute pas s’il vient d’une origine que la politique n’autorise pas. Seul en-tête de cette liste à protéger le visiteur contre un contenu déjà modifié sur le serveur, il se règle par étapes, en mode rapport d’abord, sans rien bloquer, pour recenser ce que le site charge réellement.

Ce que chaque enregistrement empêche réellement

Maintenant, soyons clairs : un enregistrement absent n’ouvre pas une porte grande ouverte aux attaquants d’emblée. Le risque dépend de qui peut en tirer parti, et de ce qu’il en obtient au bout, de sa motivation, de son temps, de l’opportunité. Si on ne vous le dit pas, ce n’est pas très correct.

Déjà, effectivement, sans SPF ni DMARC, n’importe qui pourrait potentiellement expédier un message dont l’adresse d’expéditeur affiche exactement votre domaine. L’outillage nécessaire est public et l’effort à peu près nul. Le gain pour l’attaquant dépend entièrement de ce qu’il obtient ensuite d’un humain : un virement ou un changement de coordonnées bancaires. Cette voie mène à la fraude au virement, seul poste de la liste dont l’impact financier direct soit documenté à grande échelle. A traiter d’urgence.

Un SPF laissé à l’abandon, lui, fait bien pire que son absence. L’enregistrement peut autoriser, par la directive include:, un domaine tiers qui a cessé d’exister depuis : un prestataire d’infolettre disparu, un outil de recrutement abandonné. Quiconque rachète ce domaine entre alors dans la liste des expéditeurs autorisés, sans avoir rien à compromettre. La campagne SubdoMailing, décrite par Guardio Labs en février 2024, a ainsi exploité ce mécanisme à l’échelle [15]. Plus de 8 000 domaines et 13 000 sous-domaines, dont ceux d’eBay, MSN, McAfee et The Economist, ont servi à expédier jusqu’à cinq millions de messages par jour. L’authentification de ces entreprises fonctionnait comme prévu, elle désignait un domaine qui ne leur appartenait plus.

Sans DKIM seul, avec un SPF correct et un DMARC en rejet, l’exposition devient faible. DKIM devient déterminant quand les messages transitent par des listes de diffusion ou des services de transfert qui cassent SPF en réécrivant le chemin. Il a ses propres limites : en avril 2025, des messages de hameçonnage expédiés depuis no-reply@google.com portaient une signature DKIM authentique de Google [16]. L’attaquant avait provoqué l’envoi d’une véritable alerte, puis l’avait réexpédiée depuis un compte Outlook sans toucher au corps signé. Ce rejeu tient à ce que DKIM garantit l’intégrité d’un message… sans rien dire du chemin qu’il emprunte.

Sans MTA-STS, un attaquant déjà capable de s’interposer entre deux serveurs de messagerie peut forcer le renoncement au chiffrement. Cette position est cependant difficile à obtenir et suppose un accès réseau privilégié, sur un opérateur ou sur un point d’échange.

Sans DNSSEC, falsifier une réponse d’annuaire suppose d’empoisonner un résolveur ou de détourner le trafic. Les cas réels de détournement de domaine passent presque tous par un autre chemin, nettement plus simple : la prise de contrôle du compte client chez le bureau d’enregistrement, contre laquelle DNSSEC ne peut rien. Un second facteur sur ce compte protège mieux. La directive d’urgence 19-01 de l’agence américaine de cybersécurité, publiée en janvier 2019, répondait précisément à une campagne de détournement conduite de cette façon contre des administrations [17].

Sans CAA, obtenir un certificat frauduleux suppose de tromper la procédure de validation d’une autorité, ou de la compromettre. Le précédent de référence est néerlandais : en 2011, l’autorité DigiNotar, compromise, a émis au moins 531 certificats frauduleux, dont un certificat joker *.google.com qui aurait été employé pour intercepter les communications de quelque… 300 000 utilisateurs iraniens [18]. Elle a été déclarée en faillite la même année, et l’épisode a directement motivé… la création des journaux de transparence (et oui, tout est lié). De tels cas restent rares et relèvent d’acteurs disposant de moyens : l’impact serait sévère pour une probabilité très faible.

Les journaux de transparence révèlent une surface plutôt qu’un défaut : un attaquant y gagne la carte des sous-domaines et du temps de reconnaissance, sans franchir aucune porte. Quant à HSTS, sur un site qui ne porte ni compte ni formulaire de connexion, son absence expose à peu près à rien, les navigateurs tentant désormais HTTPS par défaut. CSP se juge autrement : sans lui, un script glissé dans une page par une extension compromise s’exécute chez chaque visiteur, et sur une boutique en ligne c’est la voie des écrémeurs de cartes bancaires (skimmers). Sur un site vitrine sans formulaire, l’exposition reste faible.

La limite qu’on prête à tort à DMARC

DMARC empêche l’usurpation de votre domaine exact. Les trois autres voies de la fraude au virement passent à côté de ce contrôle, par construction.

La première est le domaine ressemblant. Un attaquant enregistre armement-maritime.com quand vous détenez armementmaritime.com, ou remplace un l par un 1. Ce domaine lui appartient, il y publie ses propres SPF, DKIM et DMARC, et ses messages passent tous les contrôles d’authentification. Rien ne distingue techniquement ces messages d’un courrier légitime.

Vient ensuite le compte réellement compromis. Quand l’attaquant dispose des identifiants d’un comptable chez votre courtier, il écrit depuis la vraie boîte, sur le vrai fil de discussion, en répondant à un message légitime. Aucun mécanisme d’authentification de domaine ne détecte cela, puisqu’il n’y a rien d’usurpé.

La troisième voie se passe même d’infrastructure. Le fraudeur ouvre un compte chez un fournisseur de messagerie grand public, le renseigne au nom d’un salarié de l’entreprise visée, et laisse le nom d’affichage faire le travail dans la liste des messages. Le domaine d’envoi est celui du fournisseur, parfaitement authentifié puisqu’il lui appartient.

Le bulletin cyber des gardes-côtes américains que j’avais détaillé au printemps décrivait ces schémas appliqués au maritime, avec des messages calés sur les escales réelles. Ne me faites pas dire ce que je n’ai pas dit : DMARC reste bien entendu nécessaire, il retire une technique sur quatre du répertoire de l’attaquant.

DNS et fraude maritime

La fraude qui atteint réellement les entreprises du secteur emprunte une voie plus simple. J’en ai identifié 32 dossiers, du détournement de facture de soutes à la fraude au règlement de fret, sur une période qui va de 2013 à 2026. Aucun de ces 32 dossiers n’établit une usurpation du domaine exact de la victime ou de son fournisseur, la seule qu’une politique DMARC en rejet aurait arrêtée. Aucun ne mentionne d’ailleurs SPF, DKIM ou DMARC. Un seul laisse le mécanisme ouvert, et sa fiche le dit : le message se présentait comme venant de l’adresse officielle du représentant du fournisseur, ce qui décrit une apparence sans établir qui tenait la boîte. Les deux lectures possibles, boîte réellement compromise ou adresse imitée, échappent l’une comme l’autre à DMARC.

Les mécanismes établis se répartissent pour l’essentiel entre le domaine ressemblant et la compromission réelle d’une boîte ou d’un poste. Les substitutions typographiques relevées montrent le niveau d’attention exigé d’un comptable : le o du mot oil remplacé par un zéro, circle écrit clrcle, im remplacé par irn, integr8fuels.com doublé par integ8rfuels.com. Deux dossiers sortent entièrement de la messagerie, l’un par un profil de messagerie instantanée ouvert au nom du directeur général, l’autre par des instruments de financement du commerce falsifiés qui ont passé le contrôle documentaire de 8 établissements pendant 18 mois.

Deux dossiers montrent les ressorts de l’ensemble :

En avril 2021, l’assureur des intermédiaires du transport a publié le cas d’un courtier chargé de reconstituer les soutes d’un navire, c’est-à-dire son combustible, au moment où il sortait d’affrètement [19]. Le fournisseur chinois avait facturé 300 000 dollars. Une facture de remplacement est arrivée le lendemain, annonçant un changement de coordonnées bancaires. Elle venait d’une adresse où une seule lettre r avait été insérée. Les numéros de téléphone du bloc de signature avaient été modifiés eux aussi. Les fraudeurs ont ensuite appelé le courtier pour lui lire les nouvelles coordonnées, anticipant une procédure de confirmation téléphonique. Un appel entrant ne vaut pas vérification, et celui-là a désarmé le contrôle avant que le courtier ait pu l’appliquer. Un second signal est resté sans lecture : le titulaire du compte destinataire ne portait pas le nom du fournisseur. L’armateur a payé, puis a dû payer une seconde fois le véritable fournisseur, et la réclamation contre le courtier s’est réglée à 150 000 dollars.
Le dossier grec de 2026 combine les deux techniques [20]. Les auteurs ont d’abord obtenu un accès à la correspondance entre une société du groupe Neptune et une banque partenaire à l’étranger. Ils ont ensuite employé une adresse ressemblant à celle de la société, avec des ordres de paiement falsifiés, pour détourner 4 millions d’euros vers un compte bulgare. Les fonds ont été intégralement récupérés, ce qui reste exceptionnel dans cette catégorie de fraude. La plainte déposée en août 2025 auprès de la direction grecque de la cybercriminalité, puis l’intervention conjointe de l’autorité anti-blanchiment, d’Europol et des banques, ont permis de geler le virement avant sa dispersion. La récupération a été annoncée le 6 juillet 2026.

Un enregistrement DMARC n’aurait empêché ni l’une ni l’autre, et aucun des 30 autres dossiers n’établit un mécanisme qu’il aurait arrêté. Dans l’affaire des soutes, le domaine d’expédition appartenait au fraudeur, donc parfaitement authentifié. Dans le dossier grec, les instructions frauduleuses s’appuyaient sur la lecture d’une correspondance réelle. La parade se joue dans la procédure de paiement, avec des coordonnées de contrôle détenues hors du fil de discussion qui annonce le changement. La rapidité de l’alerte donnée aux banques décide du reste.

Hors du maritime, les mêmes chemins

Les grandes fraudes au virement documentées dans d’autres secteurs empruntent les mêmes voies. Ubiquiti a perdu 46,7 millions de dollars en 2015 face à des escrocs se faisant passer pour son dirigeant, puis pour son cabinet d’avocats extérieur [21]. Une filiale européenne de Toyota Boshoku a perdu plus de 37 millions de dollars en 2019 sur un schéma voisin [22]. FACC, Pathé et d’autres industriels européens ont connu la même construction, imitation d’un dirigeant et domaine ressemblant.

L’absence de ces enregistrements a pourtant causé un dommage établi, d’une tout autre nature.

Ce qui est mesuré porte sur le hameçonnage de masse. En octobre 2017, la directive contraignante BOD 18-01 a imposé aux agences fédérales américaines de publier SPF et DMARC, puis de passer en rejet sous un an, parce que les domaines en .gov étaient usurpés à grande échelle pour tromper des citoyens [23]. Les proportions de messages frauduleux qui circulent sur cette période proviennent d’éditeurs vendant des solutions DMARC et se lisent avec cette réserve. La directive elle-même atteste que l’administration jugeait le problème sérieux.

DMARC protège donc d’abord les destinataires. Une politique en rejet empêche qu’un inconnu écrive au monde entier sous votre nom, ce qui préserve vos clients comme votre réputation. Elle ne protège pas votre trésorerie contre une fraude ciblée, où l’attaquant garde trois autres chemins. Cette asymétrie explique la difficulté à financer le déploiement en interne : la dépense incombe à l’entreprise qui publie l’enregistrement, quand le bénéfice va à ceux qui reçoivent son courrier.

Les démonstrations de laboratoire sont nombreuses et vont dans le sens inverse de l’argumentaire de vente. Trois chercheurs ont présenté en 2020, à la conférence USENIX Security, 18 manières de contourner SPF, DKIM et DMARC dans des services de messagerie réels. Toutes exploitent les divergences d’interprétation entre les composants qui traitent un même message [24]. Leur outil de test est public. En 2024, à la conférence NDSS, une autre équipe a contourné SPF sur… 23 916 domaines du million le plus consulté, dont 23 du premier millier, en exploitant les réserves d’adresses partagées des hébergeurs [25].

Aucune de ces publications ne conclut qu’il faudrait renoncer à ces mécanismes. Elles établissent simplement qu’un enregistrement correct relève de l’hygiène, et que la conformité affichée dans un rapport d’audit ne dit rien de la résistance à un attaquant motivé.

La mise en perspective (= restons rationnels)

Le rapport annuel de Verizon sur les compromissions de données établit pour 2026 que l’exploitation d’une vulnérabilité est devenue le premier vecteur d’accès initial, à 31 %, contre 20 % l’année précédente [26]. Pour la première fois en dix-neuf ans d’enquête, elle passe devant l’abus d’identifiants, tombé à 13 % comme porte d’entrée mais présent dans 39 % des compromissions si l’on regarde tout le parcours de l’attaquant.

Pour une PME du secteur maritime, la vulnérabilité en question a un visage très concret qui vous parle peut-être : le site vitrine réalisé il y a quatre ans par une agence locale, sous WordPress, avec une quinzaine d’extensions. L’éditeur Patchstack recense 11 334 vulnérabilités nouvelles dans cet écosystème pour la seule année 2025, en hausse de 42 %, dont 91 % dans les extensions et 6 dans le cœur du logiciel [27]. Près de la moitié, 46 %, n’avaient pas de correctif disponible le jour de leur divulgation. Le délai médian entre la publication d’une faille lourdement exploitée et les premières tentatives de masse est de cinq heures.

L’autre voie d’entrée, l’identifiant volé, tient dans ce que collectent les voleurs d’informations installés sur des postes. Ces programmes (les fameux infostealers), récupèrent les mots de passe enregistrés dans le navigateur et les cookies de session, ces derniers permettant de reprendre une session déjà authentifiée sans repasser par le second facteur. Le poste concerné est souvent personnel, parfois celui d’un salarié qui consulte sa messagerie professionnelle depuis chez lui. J’avais mesuré, à propos de FortiBleed, l’écart entre un comptage brut d’exposition et l’exposition réelle du secteur, et la même prudence s’impose ici sur les volumes annoncés.

Du côté de la fraude au virement, le centre de plaintes du FBI recense pour 2025 un peu plus de 3 milliards de dollars de pertes déclarées sur 24 768 dossiers, soit environ 123 000 dollars par dossier, dont 86 % partis par virement [28]. Ce chiffre place la fraude au virement au deuxième rang des pertes déclarées à ce guichet, derrière la fraude à l’investissement.

L’échelle se lit alors sans difficulté. Une extension de gestion de formulaires non corrigée sur un site vitrine offre une exploitation automatisée, à grande échelle, dans les heures qui suivent la divulgation, et sans qu’aucun humain ait à se tromper. Un identifiant de messagerie récupéré sur le poste personnel d’un salarié donne un accès authentique, immédiat, et ouvre la voie à une fraude depuis une vraie boîte. Un domaine sans DMARC oblige encore l’attaquant à convaincre un destinataire, et lui offre une technique parmi trois pour le faire.

Les autres enregistrements se situent un cran en dessous. CAA, DNSSEC, MTA-STS et HSTS relèvent d’une hygiène dont le coût est proche de zéro et dont l’absence, pour une PME maritime, ne crée pas d’exposition mesurable à court terme. Les poser reste justifié par leur prix (généralement : 0 €) et par les rapports qu’ils déclenchent qui permettent une alerte précoce. Gratuit, plutôt efficace, une bonne pratique évidente. Mais à prendre pour ce que cela vaut.

L’ordre dans lequel il serait bon de s’y prendre. 10 mesures.

Cette progression suit l’échelle de risque plutôt que la structure d’un rapport automatique. Les trois premières lignes comptent davantage que les sept suivantes réunies.

Mettez à jour vos sites vitrines, ou supprimez-les s’il n’ont plus d’usage. Un WordPress non maintenu avec quinze extensions demande un contrat de maintenance ou une conversion en pages statiques. Attention aux sites de développement et de préproduction et à leur exposition. Sur ce qui reste en ligne, posez une politique de sécurité de contenu, en mode rapport le temps de recenser ce que le site charge, puis en mode bloquant. C’est la dépense la plus rentable de la liste.
Imposez un second facteur d’authentification sur la messagerie, sur le compte du bureau d’enregistrement du domaine et sur les accès distants (et sur les réseaux sociaux, tant que vous y êtes). Le vol de cookie de session contourne ce second facteur, ce qui rend nécessaire de savoir aussi révoquer les sessions en cours.
Surveillez l’apparition d’identifiants de l’entreprise dans les dépôts issus d’infostealers (ça c’est intéressant, un peu relou à faire soi-même, on est d’accord), et traitez chaque apparition comme un incident, avec changement de mot de passe et révocation des sessions. C’est un signal fort de risque imminent.
Publiez un SPF terminé par -all et un DMARC en p=none avec une adresse de rapport, puis lisez ces rapports deux à quatre semaines avant de passer en p=quarantine, enfin en p=reject [29]. Passer directement au rejet coupe la facturation ou l’infolettre avant qu’on ait compris pourquoi.
Activez DKIM chez le fournisseur de messagerie, chez Gandi [30], chez Infomaniak [31], dans Microsoft 365 [32] ou dans Google Workspace [33], et notez le sélecteur dans la documentation interne.
Recensez les domaines détenus en partant des factures du bureau d’enregistrement, puis posez sur chacun de ceux qui n’envoient pas de courrier un SPF réduit à v=spf1 -all et un DMARC en p=reject. Si le domaine n’en reçoit pas non plus, ajoutez un enregistrement MX nul, 0 ., qui annonce aux expéditeurs qu’il n’y a personne au bout [34]. Trois lignes qui ferment un vecteur d’usurpation entier.
Enregistrez les variantes de nom les plus plausibles, celles qu’un fraudeur utiliserait, et surveillez les enregistrements ressemblants. Ce geste couvre la technique que DMARC laisse passer.
Posez un enregistrement CAA restreint à l’autorité réellement utilisée, avec une adresse iodef relevée par quelqu’un, pour le jour où les autorités l’honoreront.
Consultez les registres de transparence pour le domaine, listez les noms qui en sortent, fermez ou renommez ce qui n’a plus lieu d’être exposé, et vérifiez au passage l’absence de sous-domaine pointant vers un service résilié.
Activez DNSSEC, publiez MTA-STS et TLS-RPT, puis HSTS sur les seuls sites portant une authentification, en commençant par une durée courte.

Le guide de l’ANSSI sur l’interconnexion d’un système d’information à Internet consacre un chapitre à la messagerie et constitue la référence à opposer aussi bien à un auditeur qu’à un prestataire [35]. On ne protège que ce qu’on a recensé, et la première étape de toute cette progression reste celle que j’ai décrite à propos du nécessaire inventaire.

Où tester soi-même, sans rien acheter

Les diagnostics qu’on vous propose reposent sur des outils publics, et plusieurs sont portés par des administrations ou des fondations européennes, sans compte à créer ni adresse à laisser. Tous n’interrogent que des informations déjà publiques, votre DNS et vos serveurs, ce qu’un attaquant fait de toute façon. Certains conservent le nom de domaine testé dans leur base, ce qui n’a pas d’importance pour un domaine dont l’existence est publique.

Le service du haut fonctionnaire de défense et de sécurité des ministères économiques et financiers publie un autodiagnostic de domaine de courrier [36]. On saisit le domaine, on obtient une note de E à A++ sur le modèle de l’étiquette énergie, avec la fiche technique derrière. Il vérifie SPF, DKIM, DMARC, le chiffrement opportuniste sur chacun des serveurs de réception, la configuration automatique des clients de messagerie et la localisation des serveurs, et DNSSEC y joue le rôle de multiplicateur de la note. Le site annonce ne recueillir que des informations déjà publiques et ne pose aucun cookie.

Le centre commun de recherche de la Commission européenne maintient MECSA, pour My Email Communications Security Assessment [37]. Le principe diffère des autres, on soumet une adresse, on répond au courriel reçu, et le rapport porte sur l’échange dans les deux sens. Il couvre STARTTLS, les certificats, SPF, DKIM, DMARC, DANE et DNSSEC. Comme il reçoit réellement un message de votre serveur, il est le seul de cette liste à évaluer DKIM sur une vraie signature au lieu de deviner un sélecteur.

Internet.nl est porté par la plateforme néerlandaise des standards Internet, qui réunit le NCSC-NL, le registre SIDN, le RIPE NCC et le ministère néerlandais des Affaires économiques [38]. Un premier test vise le site, IPv6, DNSSEC, HTTPS, en-têtes de sécurité, RPKI, un second la messagerie, SPF, DKIM, DMARC, STARTTLS et DANE, avec un rapport détaillé qui explique chaque point. Sa déclaration de vie privée précise que l’adresse IP du visiteur est anonymisée et que le domaine testé reste dans sa base, avec un lien permanent vers le rapport. L’outil se déploie aussi chez soi sous forme de conteneur.

Zonemaster, développé par l’AFNIC et la fondation suédoise de l’Internet, contrôle la délégation et la cohérence d’une zone DNS, DNSSEC compris, en remontant toute la hiérarchie depuis la racine [39]. Il sert à comprendre pourquoi un enregistrement fraîchement posé n’est pas vu partout. Le code est libre et l’interface existe en français.

Pour la partie web, Webbkoll, de la fondation suédoise 5th of July, examine ce qu’un site impose à ses visiteurs, cookies, requêtes vers des tiers, HSTS, politique de sécurité de contenu et politique de référent [40]. Le service n’enregistre pas les adresses IP et son code est libre. CryptCheck, développé par un contributeur français et publié sous licence libre, note la configuration TLS d’un serveur web, d’un serveur de messagerie ou de messagerie instantanée, et le fait avec une sévérité utile pour repérer les suites de chiffrement anciennes [41].

Ces six outils ne se recoupent pas entièrement, et un domaine bien noté par le premier peut être signalé par le troisième pour un DANE absent que le premier ne teste pas. Le rapport commercial que vous recevrez agrège probablement les mêmes contrôles.

Un diagnostic externe automatisé mesure la couche décrite dans ce guide, et rien d’autre. Une entreprise qui sort en tête de ce classement peut avoir un site vitrine exploitable en cinq heures et des identifiants de son comptable en circulation depuis huit mois. Une entreprise mal notée sur ces enregistrements peut à l’inverse tenir l’essentiel de son risque sous contrôle. A vous de jouer (et, pour une fois en cyber, c’est gratuit !). Sauf si c’est vous, le produit.

Sources

Olivier JACQ