Sur les 170 milliards d'e-mails envoyés chaque jour dans le monde, une part énorme est du spam, et des milliards relèvent de l'hameçonnage : des messages qui se font passer pour un expéditeur de confiance. Le conseil qu'on entend partout — « vérifiez l'adresse de l'expéditeur » — repose sur une hypothèse fausse : que cette adresse soit fiable. Elle ne l'est pas par défaut. Usurper une adresse e-mail, pour un attaquant, est étonnamment simple.
Aujourd'hui, je vous montre pourquoi c'est si facile, puis les trois mécanismes — SPF, DKIM, DMARC — qui rendent l'usurpation de votre domaine beaucoup plus difficile. Ce sont trois enregistrements DNS (Domain Name System). Bien posés, ils font la différence entre un domaine que n'importe qui peut imiter et un domaine protégé.
Pourquoi l'usurpation est si facile : l'enveloppe et l'en-tête
Pour comprendre, il faut savoir comment un e-mail part. L'envoi passe par le protocole SMTP (Simple Mail Transfer Protocol), et l'image juste est celle de la poste. Quand vous postez une lettre, il y a deux niveaux d'information : ce que vous dites au guichet pour l'acheminement, et ce qui est écrit sur la lettre elle-même. Rien ne garantit que les deux concordent.
En e-mail, c'est pareil. Il y a l'« enveloppe » — les informations que votre client donne au serveur SMTP pour router le message, dont l'expéditeur réel utilisé pour le retour. Et il y a l'« en-tête », à l'intérieur, qui contient le champ From: — celui que votre logiciel de messagerie affiche, la fameuse « adresse de l'expéditeur » que vous regardez.
Le problème tient en une phrase : le champ From: que vous voyez est, à la base, du texte libre. Rien dans le protocole SMTP n'oblige l'expéditeur à prouver qu'il a le droit d'écrire telle ou telle adresse dans ce champ. Un attaquant peut donc parfaitement composer un message dont le From: affiche direction@votre-banque.fr tout en l'envoyant depuis son propre serveur. Techniquement, c'est presque aussi simple que de mentir sur l'expéditeur au dos d'une enveloppe papier.
C'est pour combler ce trou de conception que trois couches d'authentification ont été ajoutées par-dessus. Elles ne modifient pas SMTP ; elles permettent au serveur destinataire de vérifier si un message prétendant venir de votre domaine en vient réellement.
| Mécanisme | Question répondue | Mode de vérification | Limite |
|---|---|---|---|
| SPF | Ce serveur est-il autorisé à envoyer pour ce domaine ? | IP du serveur d'envoi comparée à la liste publiée en DNS | Valide l'enveloppe, pas le From: ; casse au transfert |
| DKIM | Le message est-il signé par une clé du domaine et non altéré ? | Signature cryptographique vérifiée via la clé publique DNS | Ne relie pas formellement la signature au From: ; n'agit pas en cas d'échec |
| DMARC | Le domaine validé correspond-il au From: affiché ? Que faire si non ? | Alignement SPF/DKIM + politique none/quarantine/reject | Ne protège pas contre les domaines cousins typographiques |
SPF : qui a le droit d'envoyer pour mon domaine
Le premier mécanisme, SPF (Sender Policy Framework), répond à une question simple : « quels serveurs sont autorisés à envoyer des e-mails au nom de mon domaine ? ».
Vous publiez, dans le DNS de votre domaine, un enregistrement TXT qui liste les adresses et serveurs légitimes. Quand un serveur reçoit un message prétendant venir de chez vous, il regarde l'adresse du serveur qui le lui envoie, la compare à votre liste publiée, et juge : autorisé, ou pas.
Concrètement, un enregistrement SPF ressemble à ceci :
v=spf1 include:_spf.google.com ip4:198.51.100.10 -allDécortiquons. v=spf1 annonce une politique SPF. include:_spf.google.com autorise les serveurs de votre prestataire de messagerie (ici, à titre d'exemple, ceux de Google Workspace). ip4:198.51.100.10 autorise une adresse précise, par exemple votre serveur applicatif qui envoie des notifications. Et -all, à la fin, est le réglage le plus important : il signifie « tout serveur non listé ci-dessus n'est PAS autorisé, rejetez ». Un ~all (tilde) dirait seulement « suspect, marquez-le » — plus permissif. Pour vérifier ce qu'un domaine publie aujourd'hui, une seule commande suffit :
dig +short TXT votre-domaine.fr # cherchez la ligne commençant par v=spf1La limite de SPF, et elle est réelle : il valide le serveur d'envoi, pas le champ From: affiché. Sur des transferts d'e-mails, SPF peut aussi « casser ». D'où la nécessité des deux couches suivantes.
DKIM : une signature qui prouve l'intégrité
Le deuxième mécanisme, DKIM (DomainKeys Identified Mail), ajoute une signature cryptographique à chaque message. Le principe repose sur un couple de clés : une clé privée, que vous gardez secrète sur votre serveur d'envoi, et une clé publique, que vous publiez dans votre DNS.
À l'envoi, votre serveur signe le message — son contenu et certains en-têtes — avec la clé privée. À la réception, le serveur destinataire récupère votre clé publique via le DNS et vérifie la signature. Si elle est valide, deux choses sont prouvées : le message vient bien d'une entité qui détient la clé privée de votre domaine, et il n'a pas été altéré en route. Si quelqu'un modifie le contenu, la signature ne correspond plus.
La clé publique se publie, là encore, dans un enregistrement TXT, à un emplacement dédié appelé « sélecteur » :
selecteur._domainkey.votre-domaine.fr TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."Le grand avantage de DKIM sur SPF : la signature voyage avec le message. Elle survit donc à certains transferts qui mettent SPF en échec. En revanche, DKIM seul ne dit pas au destinataire quoi faire si la vérification échoue, ni ne relie formellement la signature au domaine affiché dans le From:. C'est le rôle de la troisième couche.
DMARC : la politique qui orchestre les deux
Le troisième mécanisme, DMARC (Domain-based Message Authentication, Reporting and Conformance), est le chef d'orchestre. Il s'appuie sur SPF et DKIM et ajoute deux choses décisives : l'alignement et la politique.
L'alignement vérifie que le domaine validé par SPF ou DKIM correspond bien au domaine affiché dans le From: que voit l'utilisateur. C'est ce qui relie enfin l'authentification à l'adresse réellement vue — le maillon qui manquait. La politique, elle, dit au serveur destinataire quoi faire quand un message prétendant venir de chez vous échoue aux contrôles. On la publie, encore, dans un enregistrement TXT :
_dmarc.votre-domaine.fr TXT "v=DMARC1; p=reject; rua=mailto:rapports@votre-domaine.fr"p=reject demande de rejeter purement et simplement les messages frauduleux ; p=quarantine les met en indésirables ; p=none n'agit pas mais se contente d'observer. Le champ rua indique où envoyer les rapports agrégés — précieux, car ils vous montrent qui envoie des e-mails en votre nom, légitimement ou non.
La bonne démarche de déploiement, celle que je recommande toujours : commencez en p=none. Vous ne bloquez rien, mais vous recevez les rapports. Vous découvrez alors tous les services qui envoient pour votre domaine — souvent des outils marketing ou applicatifs oubliés. Vous les ajoutez à SPF et DKIM. Puis, une fois sûr que tout le légitime est couvert, vous passez à quarantine, enfin à reject. Passer directement à reject sans cette phase d'observation, c'est risquer de bloquer vos propres e-mails légitimes. Cette discipline d'observation puis durcissement progressif est le réflexe-clé qu'on travaille dans le Bootcamp DevSecOps — mesurer avant de bloquer, sur toutes les couches.
Ce que ça protège, et ce que ça ne protège pas
Soyons honnêtes sur la portée, parce que c'est là qu'on se trompe le plus.
Ces trois mécanismes protègent contre l'usurpation directe de votre domaine. Avec un DMARC en reject bien configuré, un attaquant ne peut plus facilement envoyer un e-mail qui affiche exactement vous@votre-domaine.fr et atteindre les boîtes de réception. C'est une protection majeure, et trop rare : énormément de domaines, encore aujourd'hui, n'ont pas de DMARC en politique stricte.
Mais ils ne protègent pas contre tout. Un attaquant peut toujours acheter un domaine ressemblant — votre-entreprlse.fr, avec un « l » à la place du « i » — et l'authentifier parfaitement avec ses propres SPF, DKIM, DMARC. Techniquement, son e-mail est « légitime » : il vient bien du domaine qu'il affiche. Sauf que ce domaine n'est pas le vôtre. C'est le « cousin typographique », et aucune de ces trois couches ne l'arrête. Elles garantissent l'authenticité d'un domaine, pas le fait que ce domaine soit celui que l'utilisateur croit lire.
C'est pour ça que ces protections techniques ne remplacent pas la vigilance humaine — elles la complètent. Les pièces jointes piégées, les faux domaines voisins, les attaques qui jouent sur l'urgence : tout cela passe à travers. La défense reste en couches : DMARC ferme la porte de l'usurpation exacte, la formation des utilisateurs traite le reste.
Le plan d'action concret
Si vous gérez un domaine, voici l'ordre exact à suivre ce week-end. D'abord, inspectez l'existant : un dig +short TXT sur votre domaine et sur _dmarc.votre-domaine.fr vous dit en dix secondes où vous en êtes. Beaucoup découvrent qu'ils n'ont rien, ou un SPF en ~all trop laxiste.
Ensuite, publiez un SPF qui liste tous vos émetteurs légitimes, en terminant par -all. Activez DKIM via votre fournisseur de messagerie — c'est aujourd'hui une simple case à cocher chez la plupart, qui vous donne l'enregistrement à publier. Enfin, déployez DMARC en p=none pour observer, lisez les rapports pendant quelques semaines, corrigez ce qui manque, puis durcissez vers quarantine puis reject.
Aucune de ces étapes ne demande de développer quoi que ce soit. Ce sont des enregistrements DNS et des réglages. Le coût est en rigueur et en patience, pas en technique.
Ce qu'il faut retenir
L'usurpation d'e-mail est facile parce que le protocole de base n'a jamais été conçu pour prouver qui parle. SPF, DKIM et DMARC sont la rustine collective qui corrige ce défaut d'origine — à condition que vous les posiez. Tant que votre domaine n'a pas de DMARC en politique stricte, n'importe qui peut, avec un effort minime, envoyer des e-mails en votre nom à vos clients, vos partenaires, vos employés.
Faites le test ce dimanche : dig +short TXT _dmarc. suivi de votre domaine. Si la réponse est vide, ou affiche p=none depuis des années, vous savez quel est le chantier le plus rentable de votre semaine — et il se règle dans le DNS, pas dans le code.