SPF, DKIM, DMARC : protéger sa messagerie, expliqué simplement
Huit protections empêchent qu'on envoie des e-mails en votre nom ou qu'on lise ceux qui vous sont destinés. Voici comment elles fonctionnent, illustrées sur mon propre domaine.
Sans protection, n'importe qui peut envoyer un e-mail en se faisant passer pour votre entreprise. Votre client reçoit alors un « changement de RIB » qui semble venir de votre adresse habituelle, il paie, et c'est votre nom qui est en cause.
Des protections existent, gratuites pour la plupart. Leurs noms (SPF, DKIM, DMARC, MTA-STS, DNSSEC, CAA…) découragent souvent avant même de commencer. Cet article les explique sans jargon, avec une image simple pour chacune, puis montre à quoi elles ressemblent concrètement sur fhconsulting.fr.
Les explications se lisent d'une traite ; les détails techniques sont rangés dans des encarts « Le détail technique », à déplier si vous êtes curieux.
L'e-mail est une carte postale
Quand l'e-mail a été inventé, au début des années 1980, Internet reliait quelques universités qui se faisaient confiance. Personne n'a prévu de vérifier qui envoie quoi.
Un e-mail fonctionne donc comme une carte postale : on peut écrire « Expéditeur : votre banque » au dos, la poster, et elle sera distribuée. C'est exactement ce qu'exploitent l'hameçonnage, la fraude au président et la fraude au faux RIB.
Toutes les protections présentées ici ont été ajoutées après coup. Elles ne changent pas l'e-mail : elles lui ajoutent des vérifications. Pour les illustrer, suivons une entreprise imaginaire, la société Dupont.
Le DNS, l'annuaire sur lequel tout repose
Toutes ces protections sont des consignes publiées dans un annuaire public mondial, le DNS. Chaque nom de domaine y possède une fiche : on y indique où se trouve le site web, quel serveur reçoit les mails, et les consignes de sécurité.
Seul le propriétaire du domaine peut modifier sa fiche, mais tout le monde peut la lire. Quand un serveur reçoit un message, il consulte la fiche de l'expéditeur pour vérifier que le message respecte ces consignes.
Deux conséquences en découlent : ces protections sont gratuites et universelles, puisqu'il suffit de publier les bonnes lignes ; et la sécurité de la fiche elle-même est fondamentale, puisque celui qui la modifie contrôle toutes les protections. Nous y reviendrons.
Le détail techniquelire la fiche d'un domaine soi-même
N'importe qui peut consulter ces consignes, depuis un simple terminal Windows. Voici la consigne DMARC de fhconsulting.fr :
PS C:\> nslookup -type=TXT _dmarc.fhconsulting.fr
_dmarc.fhconsulting.fr text =
"v=DMARC1; p=reject; sp=reject; np=reject; psd=n; rua=mailto:dmarc-reports@fhconsulting.fr"SPF : la liste des bureaux de poste autorisés
La société Dupont affiche publiquement : « Notre courrier ne part que de ces bureaux de poste. » Quand une lettre arrive en disant venir de Dupont, le destinataire regarde de quel bureau elle est partie. S'il n'est pas sur la liste, c'est suspect.
Les « bureaux de poste » sont les serveurs qui envoient vos mails : votre messagerie (Google Workspace, Microsoft 365…), mais aussi votre outil de facturation, votre logiciel de newsletter ou votre site web.
Ses limites. SPF vérifie une adresse technique, invisible dans votre boîte mail, et non le nom d'expéditeur affiché. Un fraudeur peut donc poster depuis son propre bureau, parfaitement en règle, tout en signant « Dupont ». Et quand un message est réexpédié par un intermédiaire, il repart d'un autre bureau : la vérification échoue alors que le message est légitime.
Le détail techniquel'enregistrement SPF de fhconsulting.fr
v=spf1 include:_spf.google.com -allv=spf1: « ceci est une liste SPF » ;include:_spf.google.com: « mes mails partent des serveurs de Google Workspace » ;-all: « tout autre serveur n'est pas autorisé ».
~all ou -all ? Le premier dit « probablement non autorisé, soyez indulgent », le second « non autorisé ». Sans DMARC, préférez -all. Avec un DMARC en refus et une signature DKIM en place, ~all est souvent recommandé : certains serveurs rejettent un échec SPF avant même de regarder DKIM, ce qui peut faire perdre un message transféré pourtant légitime. Les deux réglages restent défendables.
DKIM : le sceau de cire
La société Dupont appose sur chaque lettre un sceau que personne d'autre ne peut reproduire, et publie le modèle de ce sceau dans l'annuaire. À l'arrivée, le destinataire vérifie que le sceau correspond au modèle, donc que la lettre vient bien de Dupont, et qu'il est intact, donc que personne ne l'a modifiée en route.
Son avantage : le sceau voyage avec la lettre et reste valable si elle est réexpédiée. Ses limites : si un intermédiaire modifie la lettre (une liste de diffusion qui ajoute un pied de page), le sceau est brisé. Surtout, un fraudeur peut tout simplement envoyer sans sceau : seul, DKIM ne dit pas quoi faire dans ce cas.
Le détail techniquela clé DKIM et un en-tête réel commenté
Techniquement, c'est une signature électronique : une clé secrète reste sur le serveur d'envoi, et la clé publique est publiée dans le DNS, sous un nom appelé « sélecteur ».
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkkr2EOxi34jQ…IDAQABPour vérifier que vos messages sont bien signés, envoyez-vous un mail vers une autre adresse, puis affichez sa source : « Afficher l'original » dans Gmail, « Afficher la source » dans Thunderbird. Le serveur de réception y inscrit le résultat de ses vérifications. Voici ce qu'a noté le serveur d'OVHcloud pour un message envoyé de fhconsulting.fr vers mon adresse personnelle :
Authentication-Results: mx.mail.ovh.net;
dkim=pass (2048-bit rsa key) header.d=fhconsulting.fr
dmarc=pass (p=reject,sp=reject) header.from=fhconsulting.fr;
spf=pass smtp.mailfrom=fhalle@fhconsulting.fr;
x-tls=pass smtp.version=TLSv1.3
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=fhconsulting.fr; s=google;
h=subject:from:to:mime-version:date:message-id: …
b=NN3JWLGqj9pNmsg9+FU5clpfeomZ11/+57OuB901ure2F…dkim=pass: le sceau est intact, signé parfhconsulting.fravec le sélecteurgoogleet une clé de 2048 bits ;spf=pass: le message est parti d'un serveur autorisé, ici ceux de Google ;dmarc=pass: les deux correspondent au nom affiché, et le serveur a bien lu la consignep=reject;x-tls=pass: le trajet entre Google et OVHcloud était chiffré, en TLS 1.3.
Dans la signature, h= liste les champs protégés par le sceau (objet, expéditeur, destinataire, date…) et b= est la signature elle-même.
DMARC : la consigne au guichet
SPF et DKIM fournissent des indices, mais aucun ne les relie au nom affiché que voit le destinataire, et aucun ne dit quoi faire en cas d'échec. DMARC est la consigne que Dupont publie à l'attention de toutes les messageries du monde :
« Toute lettre signée Dupont doit soit venir de l'un de nos bureaux, soit porter notre sceau intact, et ce bureau ou ce sceau doivent être les nôtres. Sinon, refusez-la. Et envoyez-moi chaque jour un rapport sur le courrier reçu en mon nom. »
C'est un « ou », pas un « et » : un message transféré perd souvent la preuve du bureau de poste mais garde son sceau, et passe quand même. Un fraudeur, lui, n'a ni l'un ni l'autre au nom de Dupont.
La consigne a trois niveaux :
| Niveau | Effet | Rôle |
|---|---|---|
| Observer | Rien n'est bloqué | Les rapports révèlent qui envoie en votre nom |
| Mettre de côté | Les messages douteux vont en indésirables | Étape intermédiaire |
| Refuser | Les messages douteux sont rejetés | La seule vraie protection contre l'usurpation |
Les rapports sont précieux : ils révèlent les outils oubliés qui envoient au nom de l'entreprise (vieux logiciel de devis, copieur qui envoie les scans…) et les tentatives d'usurpation en cours. Ils permettent de passer au refus sans perdre de messages légitimes.
Le détail techniquel'enregistrement DMARC et l'alignement
v=DMARC1; p=reject; sp=reject; np=reject; psd=n; rua=mailto:dmarc-reports@fhconsulting.frp=reject: refuser les messages qui échouent (les trois niveaux s'écriventnone,quarantineetreject) ;sp=rejectetnp=reject: même consigne pour les sous-domaines, y compris ceux qui n'existent pas, souvent oubliés par les fraudeurs… et par leurs propriétaires ;rua=…: l'adresse qui reçoit les rapports quotidiens.
L'alignement, relâché ou strict ? Les balises adkim et aspf règlent la sévérité de la comparaison entre le domaine vérifié et le domaine affiché. Par défaut (r, relâché), un sous-domaine compte : news.dupont.fr est aligné avec dupont.fr. En mode strict (s), il faut une correspondance exacte. Gardez le mode par défaut : il n'enlève rien à la sécurité et évite de bloquer les outils d'envoi qui utilisent un sous-domaine.
SRS et ARC : quand le courrier fait suivre
Certains messages passent par un intermédiaire : une ancienne adresse qui redirige vers une nouvelle, une liste de diffusion, une passerelle antispam. Ces intermédiaires cassent parfois les preuves de l'expéditeur. Deux mécanismes y remédient, appliqués par les intermédiaires eux-mêmes : vous n'avez rien à configurer.
- SRS, le concierge qui met son nom sur l'adresse de retour. Il fait suivre la lettre sous sa propre responsabilité, ce qui évite qu'elle soit prise pour une fraude en chemin.
- ARC, l'attestation signée du concierge. Il certifie : « quand j'ai reçu cette lettre, les preuves de Dupont étaient valides ». Si ce concierge est connu et digne de confiance, le destinataire final peut faire une exception.
MTA-STS : le camion blindé
Les mécanismes précédents vérifient qui envoie. MTA-STS protège le trajet des messages que vous recevez.
Entre deux serveurs, le chiffrement est facultatif : le serveur d'envoi propose « on passe en canal sécurisé ? » et, faute de réponse, envoie en clair, sans alerte. Un attaquant placé sur le chemin peut faire croire que le chiffrement n'est pas disponible, ou détourner les messages vers un faux serveur.
Avec MTA-STS, la société Dupont affiche : « Livrez mon courrier uniquement à ces adresses, uniquement en camion blindé, avec une plaque d'immatriculation vérifiable. Sinon, ne livrez pas. » Le camion blindé est le chiffrement ; la plaque est le certificat du serveur. Les expéditeurs mémorisent cette consigne pendant plusieurs semaines, et envoient chaque jour un bilan des livraisons.
Le détail techniqueles enregistrements et la politique MTA-STS
# Signale qu'une politique MTA-STS existe (id = sa version)
_mta-sts.fhconsulting.fr "v=STSv1; id=2026100801"
# Adresse qui reçoit les rapports de chiffrement (TLS-RPT)
_smtp._tls.fhconsulting.fr "v=TLSRPTv1; rua=mailto:tls-reports@fhconsulting.fr"La politique elle-même est un simple fichier texte, publié en HTTPS à une adresse imposée :
version: STSv1
mode: testing # observation : rapports, sans blocage
mx: *.google.com # serveurs de réception autorisés
max_age: 604800 # consigne mémorisée une semaineComme pour DMARC, on commence en mode testing : les expéditeurs signalent les problèmes sans rien bloquer. Une fois les rapports TLS-RPT propres, on passe en enforce et on change l'identifiant id dans le DNS pour que tous rechargent la consigne.
Une alternative, DANE, repose sur DNSSEC. Elle est plus robuste, mais dépend de votre fournisseur de messagerie : Google ne la propose pas pour ses serveurs. Pour un domaine sous Google Workspace, MTA-STS est la solution.
DNSSEC : l'annuaire certifié
L'annuaire d'origine a le même défaut que l'e-mail : rien ne prouve qu'une réponse est authentique. Un attaquant peut glisser une fausse page dans l'annuaire consulté par un fournisseur d'accès ou un réseau Wi-Fi public, et rediriger vers lui le site ou les mails d'une entreprise.
DNSSEC ajoute un tampon officiel sur chaque page de l'annuaire. Ce tampon est garanti par l'échelon supérieur, le registre du .fr, lui-même garanti par la racine d'Internet.
DNSSEC ne cache rien, ce n'est pas du chiffrement, et il ne protège pas contre une modification faite depuis votre propre compte. Chez la plupart des registrars, dont OVHcloud, il s'active en un clic.
Le détail techniquela chaîne de confiance réelle de fhconsulting.fr
Chaque échelon publie ses clés (DNSKEY) et confie leur empreinte (DS) à l'échelon supérieur. Une erreur de configuration rend le domaine injoignable pour les résolveurs qui valident : lors d'un changement d'hébergeur DNS, on désactive DNSSEC d'abord, on bascule ensuite.
CAA : les serruriers agréés
Les certificats qui sécurisent votre site (le cadenas du navigateur) et votre consigne MTA-STS sont délivrés par des autorités de certification, un peu comme des serruriers qui fabriquent les clés de vos portes. Il en existe des dizaines dans le monde.
Avec un enregistrement CAA, Dupont déclare : « Seuls ces serruriers ont le droit de fabriquer des clés à mon nom. » Les autres sont tenus de refuser.
Côté visiteur, le résultat se voit en cliquant sur le cadenas de la barre d'adresse : la connexion est chiffrée et le certificat valide, quel que soit le navigateur.
Le détail techniqueles enregistrements CAA de fhconsulting.fr
fhconsulting.fr. CAA 0 issue "letsencrypt.org"
fhconsulting.fr. CAA 0 issue "pki.goog"
fhconsulting.fr. CAA 0 issuewild ";"
fhconsulting.fr. CAA 0 iodef "mailto:fhalle@fhconsulting.fr"Deux autorités sont autorisées : Let's Encrypt pour le site hébergé chez OVHcloud, Google Trust Services pour les pages hébergées chez Google. La troisième ligne interdit tout certificat « joker », valable pour n'importe quel sous-domaine ; la dernière indique où signaler une demande refusée. Un clic sur « Certificat valide » dans le navigateur affiche l'émetteur, ici Let's Encrypt.
Avant de publier un CAA, vérifiez quelles autorités émettent réellement vos certificats (par exemple sur crt.sh) : un oubli bloquerait leur renouvellement.
Le compte registrar, socle de tout
La personne qui se connecte à votre compte chez votre registrar (OVHcloud, Gandi, IONOS…) peut tout modifier : SPF, clés DKIM, DMARC, serveurs de messagerie. Ses modifications seraient parfaitement authentiques, tampon DNSSEC compris. Pour une petite entreprise, c'est le risque le plus réaliste.
- Double authentification sur le compte ;
- mot de passe unique, rangé dans un gestionnaire de mots de passe ;
- adresse de secours du compte sur un autre domaine : sinon, perdre le domaine fait perdre la boîte qui permet de récupérer le compte ;
- renouvellement automatique du domaine, pour qu'il ne puisse pas expirer et être racheté ;
- verrouillage de transfert activé.
Toutes les doubles authentifications ne se valent pas : un code par SMS vaut mieux que rien, une clé de sécurité résiste même à l'hameçonnage. J'y consacrerai un article dédié.
En résumé, et par où commencer
| Protection | En une image | Ce qu'elle protège |
|---|---|---|
| SPF | Les bureaux de poste autorisés | D'où vos mails ont le droit de partir |
| DKIM | Le sceau de cire | L'authenticité et l'intégrité du message |
| DMARC | La consigne au guichet, et les rapports | Votre nom ne peut plus être usurpé |
| SRS, ARC | Le concierge qui fait suivre | Les messages transférés (côté intermédiaires) |
| MTA-STS, TLS-RPT | Le camion blindé | Le trajet chiffré des mails que vous recevez |
| DNSSEC | Le tampon sur l'annuaire | L'authenticité de toutes vos consignes |
| CAA | Les serruriers agréés | Vos certificats |
| Compte registrar | Le cadenas de la fiche | Que personne ne modifie votre annuaire |
Les idées reçues à oublier :
- « J'ai un SPF, je suis protégé. » Non : sans DMARC en refus, un fraudeur peut toujours afficher votre nom.
- « DMARC en observation suffit. » C'est une étape ; seul
rejectbloque l'usurpation. - « Ça concerne les grandes entreprises. » Les petites structures sont des cibles privilégiées, justement parce qu'elles sont rarement protégées. Mon étude sur 91 domaines de TPE en donne la mesure : 87 % étaient usurpables. Même les professionnels du numérique ne sont pas épargnés : 3 sur 4 ne protègent pas leur propre messagerie.
- « Mon domaine n'envoie pas de mails, rien à faire. » Au contraire : un domaine non protégé est idéal pour un fraudeur. Il lui faut un SPF vide (
v=spf1 -all) et un DMARC en refus.
- Sécuriser le compte registrar : double authentification, adresse de secours, renouvellement automatique.
- Configurer SPF et DKIM pour tous les outils qui envoient au nom de l'entreprise.
- Publier DMARC avec rapports, l'observer quelques semaines, puis passer en
quarantineet enfin enreject. - Activer DNSSEC, souvent en un clic chez le registrar.
- Publier un CAA listant les autorités réellement utilisées.
- Mettre en place MTA-STS et TLS-RPT pour protéger les messages entrants.
Questions fréquentes
DMARC est-il obligatoire ?
Aucune loi ne l'impose nommément aux entreprises françaises. Mais le RGPD exige une sécurité « adaptée au risque », compte tenu de l'état des connaissances : une protection gratuite et largement recommandée en fait partie. Surtout, les grandes messageries l'exigent désormais des expéditeurs importants, et favorisent les domaines qui le publient.
Que demandent Google, Yahoo et Microsoft ?
Depuis février 2024, Gmail et Yahoo demandent aux expéditeurs de plus de 5 000 messages par jour de publier SPF, DKIM et une politique DMARC, au minimum en p=none, avec un alignement correct ; Gmail applique ces règles avec davantage de rigueur depuis novembre 2025, jusqu'au rejet des messages non conformes. Microsoft impose les mêmes exigences depuis le 5 mai 2025 pour les envois volumineux vers Outlook.com, Hotmail et Live. Les plus petits expéditeurs doivent au moins publier SPF ou DKIM.
Combien de temps pour passer en reject ?
Comptez généralement quelques semaines. On commence en p=none avec une adresse de rapports, on recense et corrige tous les outils légitimes qui envoient en votre nom, puis on passe en quarantine, et enfin en reject quand les rapports ne montrent plus que des envois conformes ou frauduleux.
Mon domaine n'envoie aucun mail, suis-je concerné ?
Oui, et c'est même une cible de choix, puisque personne ne surveille ce qui part en son nom. Publiez un SPF vide (v=spf1 -all) et un DMARC en refus (v=DMARC1; p=reject;). Sur fhconsulting.fr, le sous-domaine mta-sts, qui n'envoie ni ne reçoit de courrier, est ainsi protégé par un SPF vide et un MX nul.
Ces réglages peuvent-ils bloquer mes propres mails ?
Oui, s'ils sont publiés trop vite. Un outil d'envoi oublié dans le SPF, ou non configuré en DKIM, verra ses messages refusés dès que DMARC passe en reject. C'est tout l'intérêt de la phase d'observation et des rapports : on ne durcit qu'une fois l'inventaire terminé.
Comment savoir où en est mon domaine ?
Mon test de messagerie analyse gratuitement les enregistrements publics de votre domaine. Pour un audit complet et un accompagnement jusqu'au reject, prenez rendez-vous : le premier échange de 20 minutes est offert.
Votre domaine est-il protégé ?
Testez-le gratuitement, ou faites le point avec moi : le premier rendez-vous de 20 minutes est offert.
Sources et références : IT-Connect, exigences de Microsoft pour Outlook.com (2025) · Red Sift, application renforcée des règles Gmail (2025) · enregistrements DNS publics de fhconsulting.fr relevés en octobre 2026.