Usurpation de domaine et sécurité de la messagerie : SPF, DKIM, DMARC et protection de la marque

Une adresse d’expéditeur que n’importe qui peut écrire

Un client reçoit un courriel lui demandant de mettre à jour ses informations de connexion. Le message reprend la charte de sa banque, et l’adresse d’expéditeur porte le nom de domaine exact de l’établissement. Rien, dans le protocole de messagerie, n’empêche un tiers d’écrire cette adresse. L’ANSSI le rappelle : l’adresse source d’un courriel est laissée à la discrétion de l’expéditeur, et SMTP permet par construction d’usurper un domaine. Pour le CERT-FR, sans compromettre le moindre compte, il est aisé de contrefaire des courriels avec le nom de domaine d’une entité ou de ses interlocuteurs.

Les parades existent depuis plus de dix ans. SPF, DKIM et DMARC permettent de déclarer les serveurs autorisés, de signer les messages et de demander aux destinataires d’écarter les contrefaçons. Elles restent pourtant souvent déployées à moitié : politique en simple observation, rapports non lus, sous-domaines oubliés, prestataires mal intégrés. Octobre, Mois européen de la cybersécurité, s’y prête : dans son Threat Landscape 2026, publié le 22 septembre, l’ENISA relève que l’hameçonnage représente 77,8 % des techniques d’ingénierie sociale recensées.

Cet article passe en revue ce que couvrent ces mécanismes, ce que change la publication de DMARC comme standard en mai 2026, la montée vers le rejet, le cas des sous-domaines, des domaines dormants et des prestataires, l’exploitation des rapports et la surveillance des domaines ressemblants.

Usurpation exacte, domaine ressemblant, nom affiché : ne pas tout confondre

L’usurpation exacte utilise le domaine réel de l’établissement. C’est le seul cas que DMARC traite directement : le RFC 9989 précise lui-même qu’il ne combat directement que certaines formes d’usurpation du domaine exact.

Le domaine ressemblant — faute de frappe, variante orthographique, autre extension — est un domaine distinct, enregistré par l’attaquant, qui peut publier ses propres enregistrements et obtenir une authentification valide. L’ANSSI le souligne : ces mécanismes ne protègent ni contre le typosquattage, ni contre l’usurpation en amont du serveur d’envoi, ni contre un contenu piégé.

L’usurpation du nom affiché place le nom de la banque ou d’un dirigeant dans la partie visible de l’expéditeur, avec une adresse quelconque. Le RFC 9989 la classe hors du champ de DMARC. Elle relève du filtrage à la réception et de la vigilance des destinataires, que les techniques d’ingénierie sociale savent déjouer.

Enfin, un message parti d’une boîte légitime compromise passe toutes les vérifications : c’est le terrain de la fraude au président et de la compromission de messagerie professionnelle. DMARC ne la prévient pas. Il ferme en revanche la variante la moins coûteuse et oblige l’attaquant à investir dans un domaine ressemblant ou une compromission réelle.

Ce que vérifient réellement SPF, DKIM et DMARC

SPF ne regarde pas l’adresse affichée. Défini par le RFC 7208 (avril 2014), il publie dans le DNS la liste des serveurs autorisés à émettre pour un domaine. Mais ce domaine est celui de l’enveloppe SMTP, l’adresse de retour, et non celui que lit le destinataire. SPF échoue en général lorsqu’un message est redirigé, et son évaluation est limitée à dix mécanismes ou modificateurs déclenchant une requête DNS : au-delà, le résultat est une erreur permanente.

DKIM signe, mais pour n’importe quel domaine. Défini par le RFC 6376 (septembre 2011) et complété par le RFC 8301 (janvier 2018), qui proscrit la signature en rsa-sha1, impose des clés RSA d’au moins 1 024 bits et recommande 2 048 bits, DKIM appose une signature vérifiable par une clé publiée dans le DNS. Elle survit généralement aux relais, mais prouve seulement qu’un domaine, quel qu’il soit, assume le message.

DMARC relie les deux au domaine visible. Il exige qu’au moins un des deux mécanismes réussisse pour un domaine aligné sur celui du champ « From » : alignement relâché lorsque les deux partagent le même domaine organisationnel, strict lorsqu’ils sont identiques. Le titulaire publie une politique — « none », « quarantine » ou « reject » — et désigne les adresses de rapports.

DMARC devient un standard : les RFC 9989, 9990 et 9991

Pendant onze ans, DMARC a reposé sur le RFC 7489 de mars 2015, un document informatif publié hors des groupes de travail de l’IETF. La révision dite « DMARCbis » a abouti en mai 2026 avec trois RFC sur la voie des standards : le RFC 9989 définit le protocole et rend obsolètes les RFC 7489 et 9091, le RFC 9990 décrit les rapports agrégés, le RFC 9991 les rapports d’échec. Les enregistrements commencent toujours par « v=DMARC1 », mais plusieurs changements justifient une revue.

La découverte du domaine organisationnel change. La liste publique des suffixes cède la place à une interrogation successive du DNS, le « DNS Tree Walk ». Le texte indique que l’alignement strict et un enregistrement explicite pour chaque domaine expéditeur évitent tout écart avec les anciennes implémentations.

« pct » disparaît. Le RFC constate que ce pourcentage était rarement appliqué avec exactitude. Il est remplacé par « t=y », qui signale un test : « reject » est alors traité comme « quarantine », et « quarantine » comme « none ». « rf » et « ri » sont supprimés, et les paramètres inconnus doivent être ignorés : un enregistrement fondé sur une valeur intermédiaire de « pct » doit être revu.

« np » entre dans le standard. Issu du RFC 9091, il fixe la politique des sous-domaines inexistants.

« reject » n’est pas une garantie de rejet. Le RFC 9989 interdit aux récepteurs de rejeter un message sur le seul fondement de cette politique : ils la combinent avec leurs propres analyses et, à défaut, appliquent « quarantine ». Symétriquement, un domaine en « reject » ne doit pas reposer sur SPF seul et doit signer avec DKIM.

Pourquoi tant de politiques restent en p=none

Dans son étude du 30 septembre 2025 sur la zone .fr, l’Afnic relève que 19,5 % des domaines publient une politique DMARC, que 62,7 % de ces politiques sont en « p=none », et que 49,7 % le sont sans même désigner d’adresse de rapports — ce qui ne protège ni n’informe. Les politiques bougent très peu : un domaine en « p=none » en 2023 a toutes les chances de l’être encore deux ans plus tard.

Les grandes messageries ont fait de DMARC une condition de délivrabilité, sans exiger davantage. Depuis le 1er février 2024, Gmail impose aux expéditeurs d’environ 5 000 messages ou plus en 24 heures vers des comptes personnels SPF, DKIM, une politique DMARC pouvant se limiter à « p=none » et l’alignement sur SPF ou DKIM ; le statut d’expéditeur en masse est définitif une fois le seuil atteint, et l’application a été durcie à partir de novembre 2025, avec des rejets temporaires ou définitifs. Yahoo applique des règles comparables depuis février 2024, sans seuil publié. Microsoft les a étendues à compter du 5 mai 2025 aux domaines envoyant plus de 5 000 messages par jour vers outlook.com, hotmail.com et live.com. Une politique qui ne protège pas encore le domaine suffit donc à les satisfaire.

Les freins sont surtout organisationnels. Le DNS relève d’une équipe, la messagerie d’une autre, les campagnes du marketing, les envois transactionnels des métiers. Personne ne détient l’inventaire complet des flux, et la crainte de bloquer un envoi légitime fige la politique.

Une exposition particulière pour les banques et les assurances

Le domaine d’un établissement financier est une marque de confiance auprès de clients habitués à recevoir des messages de leur banque ou de leur assureur. L’ENISA relève que la fraude et l’usurpation représentent 14,8 % des événements recensés en 2025 dans le secteur finance et banque. Les textes générés par IA renforcent la crédibilité des campagnes, comme l’a montré l’analyse du phishing augmenté par l’IA : quand la rédaction ne trahit plus le fraudeur, le domaine d’expédition reste l’un des rares éléments vérifiables.

Les parcs de domaines sont étendus — marques, filiales, entités fusionnées, enregistrements défensifs — et les flux largement externalisés : routage marketing, gestion de la relation client, signature électronique, gestion des sinistres. Le RFC 9989 prend l’exemple d’une banque dont les messages à ses clients transitent par des adresses de redirection : SPF y échoue le plus souvent, DKIM reste en général valide.

Enfin, un prestataire qui émet des courriels au nom de l’établissement fournit un service TIC au sens de DORA : le contrat correspondant relève de la gestion du risque lié aux prestataires tiers et doit figurer au registre d’informations prévu à l’article 28, paragraphe 3.

De p=none à p=reject : cartographier, corriger, durcir

Inventorier avant de durcir. Domaines actifs, marques, filiales, domaines défensifs ou hérités : chacun doit avoir un propriétaire. Le RFC 9989 décrit ensuite la démarche : publier « p=none » avec une adresse de rapports agrégés, puis s’en servir pour auditer ses propres flux, car hors configuration triviale, un serveur ou un accord d’envoi avec un tiers est vite oublié. L’ANSSI recommande la même progression dans son guide relatif à l’interconnexion d’un système d’information à Internet.

Corriger flux par flux. Le standard impose de corriger chaque source légitime non alignée avant toute politique contraignante, et prévient que plusieurs mois de rapports peuvent être nécessaires : un envoi trimestriel n’apparaît pas en quinze jours. Une observation sans plan de correction ni échéance devient l’état permanent que décrit l’Afnic.

Monter par paliers. Observation, quarantaine, rejet : chaque palier se valide par les rapports avant le suivant. Il faut privilégier l’alignement DKIM, qui résiste aux redirections.

Distinguer les domaines selon leurs usages. Le RFC 9989 met en garde les domaines dont les utilisateurs écrivent à des listes de diffusion : une politique « reject » y crée des problèmes d’interopérabilité. Il recommande de s’en abstenir, ou à défaut de passer au moins un mois en « p=none » puis une durée équivalente en « p=quarantine » en comparant les résultats, et d’informer les utilisateurs. Isoler les flux applicatifs — transactionnel, marketing, alertes — sur des sous-domaines dédiés permet d’y appliquer « reject » sans attendre, et d’arbitrer séparément le domaine des boîtes nominatives.

Sous-domaines et domaines dormants : fermer les portes oubliées

Un attaquant n’a pas besoin du domaine principal s’il peut utiliser un sous-domaine inexistant au nom rassurant, ou une ancienne marque que plus personne ne surveille.

Couvrir les sous-domaines. « sp » fixe la politique des sous-domaines existants, « np » celle des sous-domaines inexistants. Un domaine principal en « reject » dont les sous-domaines resteraient en « none » laisse une porte ouverte.

Fermer les domaines qui n’envoient pas. Pour un domaine qui n’émet ni ne reçoit de courrier, les bonnes pratiques du M3AAWG sur les domaines parqués (mise à jour de juin 2022) recommandent un enregistrement SPF n’autorisant aucun serveur (« v=spf1 -all »), aucune clé DKIM, une politique « p=reject » et un enregistrement MX nul, défini par le RFC 7505. Quelques lignes de DNS privent ainsi un domaine dormant de toute valeur pour l’usurpation exacte auprès des récepteurs qui appliquent DMARC.

Assainir le DNS. Des enregistrements orphelins pointant vers des ressources abandonnées permettent de détourner des sous-domaines légitimes : l’ENISA cite un acteur exploitant des enregistrements « CNAME » oubliés pour s’approprier des sous-domaines réputés. L’ANSSI recommande en outre DNSSEC sur les domaines de messagerie, puisque SPF, DKIM et DMARC reposent sur l’intégrité des réponses DNS.

Prestataires d’envoi : déléguer l’envoi sans perdre la maîtrise du domaine

Une identité par prestataire. Un sous-domaine dédié, une clé DKIM propre identifiée par un sélecteur distinct et une adresse de retour alignée permettent de suivre chaque flux dans les rapports et de le couper sans toucher aux autres.

Des autorisations SPF mesurées. Inclure l’enregistrement SPF d’une plateforme mutualisée revient à autoriser toute son infrastructure ; l’ANSSI relève que, lorsqu’une même adresse IP sert plusieurs domaines, un utilisateur de l’un peut usurper l’autre. Le RFC 9989 suggère d’exclure une source trop permissive de l’évaluation DMARC par le qualificatif neutre « ? ».

Des clauses de sortie. Le prestataire détient la clé privée : le contrat doit prévoir sa protection, sa rotation et le retrait du sélecteur et des autorisations en fin de relation. Une clé DKIM oubliée chez un ancien prestataire reste une capacité d’émission au nom de l’établissement.

Exploiter les rapports agrégés, arbitrer sur les rapports d’échec

Les rapports agrégés pilotent le déploiement. Définis par le RFC 9990, ce sont des fichiers XML, de préférence compressés, couvrant en général une journée, qui indiquent par adresse IP émettrice les volumes, les résultats SPF et DKIM, l’alignement et le traitement appliqué. Le RFC 9989 recommande de les traiter par machine. S’ils sont confiés à un tiers, le domaine de celui-ci doit publier un enregistrement d’acceptation, faute de quoi les récepteurs ignorent l’adresse.

Ils sont aussi un capteur de détection. Une nouvelle source émettant au nom du domaine, un pic d’échecs, un sous-domaine inconnu : ces signaux révèlent une campagne d’usurpation ou un service ouvert sans validation. Les intégrer au SIEM, les partager avec la lutte contre la fraude et verser les infrastructures identifiées dans la threat intelligence en fait une source de renseignement.

Les rapports d’échec appellent un arbitrage. Demandés par « ruf », ils décrivent des messages individuels et peuvent contenir des en-têtes, voire le contenu, donc des données personnelles. Le RFC 9991 relève que de nombreux grands fournisseurs limitent ou désactivent leur production, et recommande de les réserver à des diagnostics ciblés et limités dans le temps, avec minimisation des données. Le RFC 9989 ajoute que leurs adresses de réception sont des cibles attractives. Pour un établissement soumis au RGPD et à des obligations de confidentialité, mieux vaut ne pas les demander par défaut.

Domaines ressemblants : la surveillance qui prend le relais

Une politique « reject » déplace la menace plus qu’elle ne la supprime. Selon des données citées par l’ENISA, 77 % des domaines de phishing sont enregistrés spécifiquement pour mener des attaques. Le CERT-FR, dans son rapport d’octobre 2023 sur le mode opératoire APT28, souligne que des moyens techniques, organisationnels et juridiques sont souvent nécessaires pour filtrer les courriels usurpant une entité, et pour détecter et faire fermer les domaines de typosquattage comme les sites usurpant son identité.

Surveiller les signaux précoces. Nouveaux enregistrements proches de la marque, certificats émis pour ces noms et visibles dans les journaux publics de Certificate Transparency, apparition d’enregistrements de messagerie sur un domaine ressemblant : ces indices permettent souvent d’agir avant la campagne.

Organiser la riposte. Signalement aux bureaux d’enregistrement et aux hébergeurs, procédures SYRELI et PARL EXPERT de l’Afnic pour les noms en .fr, procédure UDRP pour les extensions génériques : la réponse suppose un circuit associant sécurité, juridique et communication. L’enregistrement défensif couvre les variantes évidentes, jamais toutes.

Informer les clients. Publier la liste des domaines légitimes réduit l’efficacité des imitations. Les fraudeurs se reporteront vers le smishing ou le quishing, et les parcours prévus pour la personne qui a déjà cliqué restent nécessaires. Quant à BIMI, qui affiche le logo de la marque, il exige chez Gmail une politique « quarantine » ou « reject » et un certificat de marque, et reste un projet de spécification à l’IETF : un bénéfice de visibilité, pas un contrôle de sécurité.

Perspective Forum des Compétences

L’authentification des messages n’a rien de nouveau, et c’est ce qui la rend embarrassante : les mécanismes existent depuis plus de dix ans, DMARC est désormais un standard, et l’usurpation exacte d’un domaine reste possible chez de nombreuses organisations. Le blocage n’est pas technique. Il tient à l’inventaire, à la propriété des flux et à la gouvernance des prestataires.

Trois actions se dégagent. Désigner un propriétaire de la posture DMARC, doté d’un inventaire des domaines et des sources d’envoi et d’un calendrier daté de passage en rejet. Fermer les portes faciles : domaines dormants en rejet, sous-domaines couverts par « sp » et « np », prestataires dotés de clés propres et de clauses de sortie. Exploiter les rapports comme une source de détection reliée au SOC et aux équipes fraude, et prolonger la démarche par la surveillance des domaines ressemblants, là où DMARC s’arrête.

Les exigences des grandes messageries ont fait de DMARC une condition de délivrabilité, pas une protection, puisque « p=none » suffit à les satisfaire. Or n’importe qui lit en quelques secondes, dans le DNS public, la politique d’un domaine.

Pour chaque domaine que détient l’établissement, y compris ceux qui n’envoient jamais de courrier, quelle politique un fraudeur y trouverait-il aujourd’hui, et qui serait prévenu s’il commençait à s’en servir ?

Sources publiques utilisées

Cet article s’appuie sur les standards de l’IETF, les publications des autorités françaises et européennes et la documentation des fournisseurs de messagerie :

• IETF, RFC 7208 (SPF, avril 2014), RFC 6376 (DKIM, septembre 2011), RFC 8301 (algorithmes et tailles de clés DKIM, janvier 2018) et RFC 7505 (« Null MX », juin 2015).
• IETF, RFC 9989 (DMARC, mai 2026, voie des standards), qui rend obsolètes les RFC 7489 et 9091, notamment ses sections 4.7, 5.1, 7.4 et 11 ; RFC 9990 (rapports agrégés) et RFC 9991 (rapports d’échec), mai 2026.
• ANSSI, Recommandations relatives à l’interconnexion d’un système d’information à Internet (ANSSI-PA-066, version 3.0 du 19 juin 2020), section 5.4 « Protection contre les courriels illégitimes », recommandations R43 à R50.
• CERT-FR, Campagnes d’attaques du mode opératoire APT28 depuis 2021 (CERTFR-2023-CTI-009, 26 octobre 2023), recommandations sur l’usurpation d’identité dans les courriels et de l’identité de marque.
• ENISA, Threat Landscape 2026 (22 septembre 2026, incidents de l’année 2025).
• Afnic, étude « SPF, DKIM, DMARC and BIMI on .fr: still on the rise in 2025 » (30 septembre 2025) et présentation des procédures SYRELI et PARL EXPERT.
• M3AAWG, Protecting Parked Domains Best Common Practices (juin 2022).
• Google, Email sender guidelines et FAQ associée ; Yahoo, Sender Requirements et FAQ ; Microsoft, annonce des exigences d’Outlook pour les expéditeurs à fort volume (avril 2025) ; Google, documentation relative à BIMI.
• OMPI, présentation de la procédure UDRP.
• Règlement (UE) 2022/2554 (DORA), article 3, point 21, et article 28, paragraphe 3.