SPF valide le serveur, DKIM signe le message, DMARC seul vérifie le nom affiché à l’écran. Sans le troisième, les deux premiers laissent passer une usurpation parfaitement crédible.
SPF publie dans le DNS la liste des serveurs autorisés à envoyer du courrier pour un domaine, et vérifie l’adresse d’enveloppe. DKIM ajoute au message une signature cryptographique que le destinataire contrôle avec une clé publique, elle aussi dans le DNS. Ni l’un ni l’autre ne regarde l’adresse affichée à l’écran. DMARC comble ce trou en exigeant qu’au moins une des deux vérifications réussisse et porte sur le même domaine que le champ From, puis indique quoi faire en cas d’échec. Les trois ensemble, pas l’un des trois.
Un comptable reçoit un message de son directeur. Le nom est le bon, l’adresse affichée est la bonne, la signature en bas de page est la bonne. Le message demande de modifier les coordonnées bancaires d’un fournisseur avant le virement de fin de mois. Rien, dans la fenêtre du logiciel de messagerie, ne permet de voir que ce courriel n’est jamais passé par les serveurs de l’entreprise.
Cette usurpation ne demande aucune compétence particulière. Elle exploite un choix de conception des années 1980 : le protocole d’acheminement du courrier n’a jamais prévu de vérifier l’identité de l’expéditeur. Trois mécanismes ont été ajoutés par-dessus, à vingt ans d’intervalle, pour combler ce trou. Ils ne font pas le même travail, et deux d’entre eux ne regardent même pas l’adresse que vous voyez à l’écran.
Quand un serveur en contacte un autre pour lui remettre un message, il annonce simplement une adresse d’expéditeur et une adresse de destinataire. Aucun mot de passe, aucun certificat, aucune preuve. Le serveur de réception accepte le dépôt comme une boîte aux lettres accepte une enveloppe glissée par un inconnu. Ce fonctionnement, détaillé dans le trajet complet d’un courriel, rend le système remarquablement résistant aux pannes et totalement incapable de prouver une origine.
Pire, il y a deux adresses d’expéditeur dans un même message. Celle de l’enveloppe, utilisée pendant la transmission et pour renvoyer les avis d’échec. Et celle du champ From, à l’intérieur du message, la seule que votre logiciel affiche. Rien n’impose qu’elles correspondent, et les envois légitimes exploitent d’ailleurs cet écart en permanence.
Retenez cette dissociation : elle est la clé de tout ce qui suit. Les deux premiers mécanismes portent sur l’enveloppe ou sur la signature technique, jamais sur l’affichage. Seul le troisième s’intéresse au nom que lit un humain.
SPF tient dans une ligne de texte déposée dans le DNS du domaine. Cette ligne commence par v=spf1 et énumère les émetteurs légitimes : des adresses IP, des plages, et surtout des renvois vers les listes publiées par les prestataires que l’organisation utilise, routeur de lettres d’information, logiciel de facturation, hébergeur. Elle se termine par une instruction sur le sort des autres.
-all demande le rejet de tout ce qui n’est pas dans la liste. ~all se contente de signaler un doute. Beaucoup de domaines restent bloqués des années sur la seconde forme, par crainte de couper un envoi oublié, ce qui vide le mécanisme d’une bonne part de son intérêt.
Deuxième limite, beaucoup plus grave : SPF évalue le domaine de l’enveloppe. Un escroc qui utilise son propre domaine dans l’enveloppe, dûment déclaré dans son propre enregistrement SPF, obtient une validation impeccable, tout en affichant l’adresse d’une banque dans le champ visible. SPF a fait son travail. Le lecteur, lui, voit la banque.
DKIM adopte une approche différente. Le serveur d’envoi calcule une empreinte du corps du message et une signature portant sur une sélection d’en-têtes, avec une clé privée que lui seul détient. Le résultat est ajouté au message sous forme d’un en-tête DKIM-Signature, qui indique le domaine signataire et un sélecteur.
Le destinataire lit ce sélecteur, va chercher la clé publique correspondante dans le DNS du domaine signataire, sous la forme selecteur._domainkey.exemple.fr, et vérifie. C’est exactement la logique de cryptographie asymétrique que l’on retrouve dans les certificats HTTPS ou dans les clés d’accès : une clé secrète qui signe, une clé publique qui vérifie.
L’avantage décisif de DKIM est qu’il voyage avec le message. Un transfert, un passage par une liste de diffusion, un relais interne ne cassent rien tant que les en-têtes signés et le corps ne sont pas modifiés. Le sélecteur permet en outre de faire coexister plusieurs clés, une par prestataire, et de les renouveler sans interruption.
Mais DKIM souffre de la même cécité que SPF : il prouve qu’un domaine a signé, pas que ce domaine est celui qui s’affiche. Une signature valide d’un domaine obscur ne dit rien sur le nom écrit dans le champ From.
DMARC n’apporte aucune vérification nouvelle. Il ajoute une exigence et une consigne.
L’exigence s’appelle l’alignement : pour qu’un message soit considéré comme authentifié, il faut qu’au moins une des deux vérifications précédentes réussisse et qu’elle porte sur le même domaine que celui affiché dans le champ From. Un SPF valide pour un domaine sans rapport avec l’affichage ne compte plus. C’est cette seule ligne de logique qui transforme deux mécanismes techniques en protection contre l’usurpation.
La consigne est publiée dans un enregistrement DNS nommé _dmarc suivi du domaine. Elle prend l’une de trois valeurs, et indique une adresse à laquelle envoyer les rapports.
| SPF | DKIM | DMARC | |
|---|---|---|---|
| Ce qui est vérifié | L’adresse IP du serveur émetteur | Une signature cryptographique du message | L’alignement avec le nom affiché |
| Où vit la configuration | Un enregistrement DNS du domaine | Une clé publique dans le DNS, une signature dans le message | Un enregistrement DNS nommé _dmarc |
| Quel domaine est évalué | Celui de l’enveloppe | Celui déclaré dans la signature | Celui du champ From, le seul visible |
| Ce qui le casse | Tout transfert ou réémission | Toute modification du corps ou d’un en-tête signé | L’échec simultané des deux autres, ou leur non-alignement |
| Ce qu’il ne fait pas | Protéger le nom affiché | Protéger le nom affiché | Vérifier quoi que ce soit par lui-même |
Le point douloureux du déploiement tient en une phrase : SPF ne survit pas à la réémission.
Quand une adresse professionnelle renvoie automatiquement le courrier vers une adresse personnelle, le second serveur réémet le message depuis sa propre adresse IP, qui ne figure évidemment pas dans l’enregistrement SPF du domaine d’origine. La vérification échoue. Les listes de diffusion posent le problème inverse pour DKIM : beaucoup ajoutent un préfixe dans l’objet ou un pied de page de désinscription, ce qui modifie le contenu signé et invalide la signature.
Deux réponses existent. La réécriture de l’enveloppe par le relais, qui remplace l’adresse de retour par une adresse du relais lui-même et rétablit SPF. Et la chaîne d’authentification ARC, par laquelle un relais atteste avoir vu une authentification valide avant son intervention, à charge pour le destinataire final de faire confiance à ce relais. Aucune des deux n’est universelle, ce qui explique qu’un passage en rejet strict casse toujours quelques usages anciens.
La confusion la plus coûteuse consiste à croire qu’un domaine bien configuré rend l’hameçonnage impossible. Il rend impossible un seul scénario, l’usurpation exacte du domaine officiel. Trois autres restent entièrement ouverts.
Le domaine ressemblant. L’escroc dépose votre-banque-securite.example, ou remplace un caractère par un autre visuellement proche, et configure lui-même SPF, DKIM et DMARC. Son message est authentifié, au sens strict, et affiche un nom trompeur. Savoir lire un nom de domaine caractère par caractère reste la seule parade.
Le nom d’affichage. Un message peut afficher « Service client » comme nom, et une adresse quelconque derrière. Sur téléphone, la plupart des applications n’affichent que le nom et masquent l’adresse. C’est le ressort du faux conseiller bancaire et de la plupart des faux messages de livraison.
Le compte légitime piraté. Un attaquant qui prend le contrôle d’une boîte réelle envoie depuis les vrais serveurs, avec la vraie signature. Toutes les vérifications passent. C’est le scénario le plus fréquent dans la fraude au virement, et la seule défense est ailleurs : une double authentification sur les boîtes sensibles, et un contrôle en double pour toute modification de coordonnées bancaires. Pour reconnaître ces mises en scène, notre quiz de reconnaissance d’arnaque reprend les signaux de pression et de prétexte.
Le durcissement se fait par paliers, jamais d’un coup. La séquence ci-dessous est celle que recommande la rédaction pour une petite structure, et elle s’étale sur deux à trois mois.
Pour une association ou une TPE, cette configuration fait partie du socle minimal, au même titre que les sauvegardes et les mises à jour : elle est détaillée dans le socle de sécurité d’une petite structure. Elle ne coûte rien d’autre que du temps, puisqu’il s’agit uniquement de lignes dans une zone DNS.
Le tournant date de février 2024. Google et Yahoo ont imposé aux expéditeurs qui dépassent quelques milliers de messages par jour vers leurs boîtes trois obligations simultanées : authentifier le domaine par SPF et DKIM, publier un enregistrement DMARC, et proposer une désinscription en un clic normalisée. Un service de messagerie grand public majeur a suivi en 2025 avec des exigences comparables.
Le seuil paraît élevé. Il ne l’est pas : une association de quatre mille adhérents qui envoie sa lettre mensuelle le franchit en une soirée. La conséquence pratique est qu’un domaine non authentifié n’est plus seulement suspect, il est de moins en moins acheminé, quel que soit le soin apporté au contenu du message.
Ce mouvement en entraîne un autre : l’affichage d’un logo vérifié à côté de l’expéditeur, proposé par plusieurs opérateurs, suppose un DMARC en quarantaine ou en rejet. L’authentification devient ainsi visible pour l’utilisateur final, après quinze ans passés strictement en coulisses. Elle s’accompagne d’une autre exploitation du courriel, la mesure d’ouverture par pixel de suivi, qui répond à une logique commerciale et non de sécurité.
Deux questions suffisent, et elles ne se posent pas dans l’ordre où on les pose d’habitude.
D’abord : le domaine affiché est-il exactement le bon, caractère par caractère, sans mot ajouté ni tiret surnuméraire ? Un message parfaitement authentifié pour un mauvais domaine reste un message frauduleux, et c’est aujourd’hui le scénario dominant.
Ensuite : la ligne d’authentification ajoutée par votre propre fournisseur dit-elle « pass » pour DMARC, et non seulement pour SPF ? Un SPF valide sans alignement DMARC ne prouve rien sur l’identité affichée.
Enfin, et cette règle survit à toutes les configurations : une demande d’argent ou de changement de coordonnées bancaires se vérifie par un canal indépendant, sur un numéro que vous détenez déjà. Aucune authentification de domaine ne protège d’un compte légitime tombé entre de mauvaises mains, comme le rappelle le mécanisme général de l’hameçonnage.
Les trois, et dans cet ordre. SPF seul autorise des serveurs mais ne protège pas le nom affiché. DKIM seul prouve qu’un domaine a signé, sans dire ce qu’il faut faire des messages non signés. DMARC seul ne vérifie rien : il s’appuie sur les résultats des deux autres. Publier DMARC sans SPF ni DKIM correctement déployés revient à demander le rejet de son propre courrier. La séquence sûre est : SPF, puis DKIM, puis DMARC en observation, puis durcissement.
Oui, et c’est même le cas le plus simple. Un domaine qui n’émet jamais publie un SPF qui n’autorise aucun serveur et un DMARC en rejet strict. Cela ferme la porte aux faussaires qui aiment utiliser des domaines dormants, souvent des noms de réservation ou des variantes déposées à titre défensif. Beaucoup d’organisations protègent leur domaine principal et oublient les dizaines de domaines secondaires qu’elles ont déposés, qui deviennent alors le maillon exploité.
Parce que chaque serveur de réception décide seul. DMARC publie une consigne, il ne l’impose pas : un opérateur peut appliquer le rejet demandé, le remplacer par un classement en indésirable, ou l’ignorer. S’y ajoutent la réputation de votre adresse IP d’envoi et l’historique de votre domaine auprès de ce destinataire précis. Un message identique peut donc être livré d’un côté et écarté de l’autre. Le trajet complet est détaillé dans notre article sur la circulation d’un courriel.
Non. L’authentification prouve que le domaine qui apparaît est bien celui qui a envoyé, rien de plus. Un escroc qui dépose un domaine ressemblant et le configure proprement obtient une authentification parfaite pour un message frauduleux. Un compte légitime piraté envoie aussi des messages parfaitement authentifiés. Ces vérifications éliminent l’usurpation pure du domaine officiel, elles ne jugent ni le contenu ni l’intention.
Les rapports agrégés sont des fichiers envoyés quotidiennement par les grands opérateurs à l’adresse déclarée dans l’enregistrement. Ils recensent, par adresse IP d’envoi, le volume de messages et le résultat des vérifications. C’est le seul moyen de découvrir les services qui envoient en votre nom sans que vous le sachiez : outil de facturation, logiciel de billetterie, prestataire de paie. On les lit avec un analyseur, le format brut étant illisible à l’œil nu.
Les liens ci-dessus renvoient vers les textes et les organismes cités. Les dates de consultation sont celles de la dernière relecture, le 13 septembre 2026.
Dans ce thème
Dans la rubrique
Adresse IP, DNS, wifi, fibre, 5G, cookies : le réseau démonté pièce par pièce.