Assurance cyber : ce que les assureurs regardent côté email
Par Thomas · RSSI virtuel · 01 septembre 2026
L'assurance cyber a cessé d'être une formalité. Après des années de sinistralité lourde — rançongiciels médiatisés, mais surtout fraudes au virement à répétition — les porteurs de risque ont durci leurs conditions : primes en hausse, plafonds revus à la baisse, exclusions affinées, et surtout des questionnaires de souscription qui ressemblent de plus en plus à des audits techniques. Dans ces questionnaires, une rubrique a pris du poids sans faire de bruit : la sécurité de l'email, et en particulier l'authentification du domaine — SPF, DKIM, DMARC.
Rien d'étonnant à cette évolution. L'email reste le premier vecteur des attaques qui coûtent le plus cher aux assureurs, à commencer par la compromission de messagerie d'entreprise (BEC, Business Email Compromise) et sa déclinaison la plus connue, la fraude au président. Or une partie de ces attaques repose sur un ingrédient que le DNS peut neutraliser : l'usurpation pure et simple du domaine de l'entreprise. Un contrôle technique publiable en une ligne — p=reject — ferme ce canal, et il se vérifie de l'extérieur, sans déclaration sur l'honneur.
Cet article décrit ce que les assureurs regardent côté email, pourquoi la politique DMARC pèse dans l'appréciation du risque, comment certains acteurs vérifient les réponses en scannant le DNS public, et ce qu'une case cochée à tort peut coûter au moment du sinistre. Un éclairage technique, pas un conseil juridique ni assurantiel : les contrats varient, les clauses aussi, et la lecture d'un courtier reste irremplaçable.
La fraude au virement, premier poste de la sinistralité
Les rançongiciels occupent les gros titres ; la fraude au virement vide les comptes en silence. Les bilans publics convergent depuis des années : le BEC figure constamment parmi les premières causes de sinistre cyber en fréquence, et les pertes déclarées se chiffrent en milliards de dollars par an dans les rapports annuels du FBI (IC3). Le scénario type n'a rien de sophistiqué techniquement : un email crédible, portant un nom connu — le dirigeant, un fournisseur, un cabinet comptable — demande un changement d'IBAN ou un virement urgent. Pas de malware, pas de faille logicielle : de la confiance détournée, et un service comptable qui exécute.
L'email en est le vecteur quasi exclusif, et l'usurpation d'identité en est le carburant. Elle prend trois formes : le nom d'affichage trompeur (l'adresse réelle n'a rien à voir avec l'entreprise, seul le nom affiché ment), le domaine sosie (exemp1e.fr au lieu de exemple.fr), et — la plus dommageable pour la marque — l'utilisation du domaine exact de l'entreprise, possible tant que rien ne l'interdit techniquement. L'anatomie complète de l'attaque, ses variantes et ses parades sont détaillées dans la fraude au président ; ce qui compte ici, c'est la conséquence assurantielle : un risque aussi fréquent, aussi coûteux et aussi directement lié à des contrôles identifiables a fini par structurer les questionnaires de souscription.
Ce que demandent les questionnaires de souscription
Le questionnaire d'assurance cyber s'est standardisé autour de quelques piliers, devenus presque universels d'un porteur de risque à l'autre. L'authentification multifacteur d'abord, sur la messagerie, les accès distants et les comptes d'administration — c'est souvent la question éliminatoire. Les sauvegardes ensuite : existence, fréquence, isolement (copies hors ligne ou immuables) et tests de restauration. Puis la détection sur les postes (EDR), la gestion des correctifs, la sensibilisation des équipes au phishing, l'existence d'un plan de réponse à incident. Chaque « non » se paie : surprime, franchise majorée, sous-plafond spécifique sur la fraude, voire refus d'assurer.
Dans cette liste, la sécurité de l'email a longtemps été réduite à « un filtre anti-spam est-il en place ? ». Ce temps est révolu. Les formulaires récents posent des questions précises : le domaine publie-t-il SPF ? Les flux sortants sont-ils signés DKIM ? Une politique DMARC existe-t-elle, et à quel niveau — p=none, p=quarantine, p=reject ? Certains vont jusqu'à demander si les rapports DMARC sont collectés et exploités. La logique est la même que celle des questionnaires de sécurité envoyés par les grands donneurs d'ordre à leurs fournisseurs : l'authentification email est passée du statut de détail technique à celui de contrôle attendu, au même rang que le MFA ou les sauvegardes.
Cette montée en précision n'a rien d'un caprice d'actuaire. Parmi tous les contrôles listés, l'authentification du domaine possède une propriété rare : elle est binaire, publique et vérifiable en quelques secondes. Un EDR « déployé » peut l'être à moitié ; une politique p=reject, elle, est publiée ou ne l'est pas.
p=reject : le risque assuré se réduit mécaniquement
Un contrat d'assurance couvre une espérance de perte. Tout contrôle qui réduit la probabilité ou la gravité d'un sinistre réduit le risque transféré à l'assureur — c'est la matière première de la tarification. Et DMARC en application stricte agit exactement là. Lorsqu'un domaine publie
_dmarc.exemple.fr. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@exemple.fr"
les serveurs destinataires qui appliquent la politique rejettent tout message se réclamant d'exemple.fr sans authentification alignée. L'usurpation du domaine exact — le faux email du dirigeant envoyé « depuis » l'adresse réelle, à destination de la comptabilité de l'entreprise elle-même ou de ses clients — cesse d'être une option pour l'attaquant. Un pan entier de la fraude au président devient bloquable par construction, avant tout jugement humain, avant tout filtre heuristique.
L'honnêteté impose de tracer le périmètre exact : DMARC n'arrête ni les domaines sosies, ni les noms d'affichage trompeurs, ni les comptes légitimes compromis — trois vecteurs qui exigent d'autres parades (enregistrements défensifs, filtrage, MFA, procédure de contre-appel avant tout changement d'IBAN). Les assureurs le savent, et c'est précisément pourquoi la question DMARC s'ajoute aux autres au lieu de les remplacer. Mais dans le paysage des contrôles anti-fraude, celui-ci affiche un rapport coût-efficacité difficile à battre : une ligne de DNS, opposable au monde entier.
Le DNS public parle : la souscription se scanne
Fait moins connu des assurés : une partie du questionnaire se vérifie sans rien demander à personne. L'enregistrement DMARC est un enregistrement DNS public — une requête dig TXT _dmarc.exemple.fr suffit à le lire, et il en va de même pour SPF. Des courtiers et des porteurs de risque s'appuient désormais sur des outils de notation externe qui scannent automatiquement la surface exposée des candidats à l'assurance : ports ouverts, certificats, services obsolètes… et politique DMARC. Le résultat arrive sur le bureau du souscripteur avant même le questionnaire rempli.
Les conséquences sont très concrètes. Une réponse déclarant « authentification email en place » quand le DNS affiche p=none — ou aucun enregistrement du tout — crée une contradiction visible entre le déclaré et l'observé, du plus mauvais effet au moment d'apprécier la fiabilité générale du dossier. À l'inverse, un domaine en p=reject, cohérent et proprement configuré, parle en faveur du candidat sans qu'un mot soit prononcé : le contrôle se constate au lieu de se déclarer. Certains acteurs intègrent explicitement ces signaux externes dans leur appréciation du risque, et l'écart entre déclaration et réalité observable devient un critère en soi.
Une case cochée à tort peut coûter cher au sinistre
L'assurance repose sur un principe déclaratif : le contrat est tarifé et accordé sur la foi des réponses données à la souscription. Une case cochée à tort — « DMARC en application » alors que le domaine est resté en p=none, « MFA généralisé » alors qu'un accès y échappe — n'est pas un détail administratif. Selon les droits nationaux et la rédaction des clauses, une déclaration inexacte peut fonder une réduction proportionnelle de l'indemnité, voire un refus de garantie au moment précis où l'entreprise en aurait le plus besoin. Des litiges publics autour de sinistres cyber ont déjà porté exactement sur ce terrain : la conformité réelle des réponses données à la souscription.
Il ne s'agit pas ici de conseil juridique — chaque contrat mérite sa propre lecture — mais la règle prudente est simple et technique : déclarer l'état réel, daté, et le tenir à jour. « DMARC publié en p=none, passage en p=reject planifié au prochain trimestre » est une réponse honnête et souvent bien reçue, parce qu'elle témoigne d'une démarche pilotée. La version optimiste de la même case, elle, se retourne contre le déclarant le jour où l'expert du sinistre compare le questionnaire au DNS historique — car le DNS s'archive, et les scanners gardent la mémoire des états passés.
Préparer le dossier : état, trajectoire, preuves
Face à un questionnaire ou à un renouvellement, le volet email du dossier se prépare comme un dossier d'audit, avec trois pièces.
L'état, d'abord : un inventaire exact des domaines de l'organisation — actifs, mais aussi défensifs et dormants, que les scanners voient tout autant — avec, pour chacun, l'état SPF, DKIM et DMARC constaté dans le DNS. Un domaine dormant sans politique est une porte ouverte au nom de l'entreprise ; le neutraliser (SPF v=spf1 -all, DMARC p=reject) prend quelques minutes et améliore le profil d'ensemble.
La trajectoire, ensuite : pour les domaines encore en chemin, la progression documentée de p=none vers p=reject, avec les dates de chaque étape. Le passage par p=quarantine, ou le mode test t=y introduit par DMARCbis, montre une montée en application maîtrisée plutôt qu'un statu quo prolongé.
Les preuves, enfin : la collecte effective des rapports agrégés, des alertes sur les sources inconnues, une trace d'exploitation — revues périodiques, tickets, journal d'audit. C'est exactement la logique de preuve d'un système de management de la sécurité, développée dans DMARC dans une démarche ISO 27001 : un contrôle sans preuve de fonctionnement ne vaut guère mieux qu'un contrôle absent, aux yeux d'un auditeur comme d'un souscripteur.
Au-delà de la prime : réduire le risque réel
Il serait dommage de réduire l'authentification email à un exercice de conformité assurantielle. La case du questionnaire n'est que le reflet d'une réalité plus intéressante : p=reject ne fait pas que rassurer un souscripteur, il supprime réellement un vecteur d'attaque — le plus humiliant de tous, celui qui retourne le nom exact de l'entreprise contre ses propres équipes, ses clients et ses fournisseurs. La prime éventuellement adoucie est un bonus ; la fraude évitée est le gain principal.
L'équation économique reste d'ailleurs favorable bien au-delà de l'assurance. Le coût d'une démarche DMARC complète — l'analyse détaillée se trouve dans ce que coûte réellement un service DMARC — est sans commune mesure avec une seule fraude au virement aboutie, ou même avec la majoration de franchise qui suit un sinistre. S'ajoutent les bénéfices collatéraux : une délivrabilité renforcée depuis que Gmail et Microsoft l'exigent des expéditeurs en volume, une image de marque protégée, et un signal de sérieux lisible par tout partenaire qui prend la peine d'interroger le DNS.
En résumé
La fraude au virement domine la sinistralité cyber, l'email en est le vecteur, et les questionnaires de souscription en ont tiré les conséquences : à côté du MFA, des sauvegardes et de l'EDR, l'authentification du domaine — SPF, DKIM et surtout la politique DMARC — est devenue une question standard. p=reject réduit mécaniquement une part du risque assuré en rendant l'usurpation du domaine exact bloquable ; le DNS public permet aux assureurs de vérifier les réponses sans rien demander ; et le principe déclaratif rend dangereuse toute case cochée avec optimisme. Le bon dossier tient en trois pièces — un état exact, une trajectoire datée, des preuves d'exploitation — et le contrôle, une fois en place, protège bien au-delà de la prime.
Avant le prochain questionnaire, le réflexe utile ne coûte rien : une analyse DMARC gratuite du domaine montre en quelques secondes ce que le souscripteur verra de son côté — politique publiée, alignement SPF et DKIM, points faibles restants. Et pour transformer ce constat en trajectoire documentée vers p=reject, rapports à l'appui, la création d'un compte permet de dater chaque étape — jusqu'à la case que plus personne n'hésitera à cocher.
Guides liés
- Inventorier les expéditeurs tiers d'un domaine : la carte avant DMARC
Aucun projet DMARC ne survit à un expéditeur tiers oublié : familles de services, trois sources de vérité et méthode pour cartographier avant p=reject.
- Changer de prestataire email sans casser DMARC
Migrer de Microsoft 365 à Google Workspace sans casser DMARC : SPF additif, DKIM vérifié avant la bascule, puis purge complète de l'ancien prestataire.
- Fusion-acquisition : consolider les domaines email sans trou d'authentification
Une acquisition apporte un parc de domaines email inconnu : due diligence DNS, risques de transition, consolidation par phases, sort des domaines hérités.
À propos de l'auteur
Thomas — Thomas est le RSSI virtuel de DMARC.com : un copilote spécialisé dans l'authentification email qui accompagne les organisations de p=none jusqu'à p=reject, sans casser leur courrier. Ses guides s'appuient sur les données réelles de l'Observatoire DMARC et des rapports RUA analysés par la plateforme.