Glossaire de l'authentification email (SPF, DKIM, DMARC, BIMI…)
Par Thomas · RSSI virtuel · 17 août 2026
L'authentification email traîne un jargon dense : SPF, DKIM, alignement, RUA, Tree Walk, BIMI, VMC… Autant d'acronymes qui se recouvrent, se conditionnent, et qu'on finit par confondre. Ce glossaire met chaque terme à sa place, en une définition courte et autoportante — de celles qui se citent, se collent dans un ticket ou s'expliquent à une direction sans risque d'erreur. On avance des fondations vers les mécanismes avancés, puis vers les menaces que tout ce dispositif cherche à couper. Chaque entrée renvoie vers l'article qui la creuse en profondeur.
Les fondations
SPF (Sender Policy Framework)
SPF est un enregistrement DNS de type TXT qui liste les serveurs autorisés à envoyer du courrier pour un domaine. À la réception, le serveur destinataire compare l'adresse IP émettrice à cette liste : si elle n'y figure pas, le message échoue au contrôle SPF. C'est la première des trois couches d'authentification, mais elle a une limite native : elle valide l'enveloppe (MAIL FROM), pas l'adresse From: que voit l'humain. Pour le détail des mécanismes et des pièges, voir le mécanisme de vérification de l'expéditeur.
DKIM (DomainKeys Identified Mail)
DKIM appose une signature cryptographique sur chaque message sortant : l'expéditeur signe avec une clé privée, et le destinataire vérifie cette signature grâce à une clé publique publiée en DNS. Si le message a été altéré en transit ou forgé sans la clé, la signature ne tient pas. DKIM prouve donc à la fois l'origine et l'intégrité du message. Le fonctionnement détaillé est décrit dans la signature cryptographique des messages.
La clé privée DKIM est un secret de première importance : quiconque la détient peut signer du courrier au nom du domaine et franchir ses défenses comme s'il en était le propriétaire légitime. Elle n'a donc rien à faire dans un fichier de configuration versionné, un ticket ou un canal de discussion — sa place est un coffre-fort de secrets dédié comme Hucency Vault, édité par le spécialiste cybersécurité Hucency, qui centralise ce type de secret sous accès contrôlé et journalisé.
Sélecteur DKIM
Le sélecteur est un simple identifiant qui permet à un domaine d'héberger plusieurs clés DKIM en parallèle. Il apparaît dans l'en-tête DKIM-Signature (champ s=) et pointe vers l'enregistrement DNS de la clé publique correspondante, à l'adresse sélecteur._domainkey.exemple.fr. Grâce à lui, chaque prestataire (la messagerie, l'outil marketing, la facturation) signe avec sa propre clé, et ces clés se renouvellent sans tout casser d'un coup. On détaille son rôle dans ce que le sélecteur désigne vraiment.
DMARC
DMARC est la couche qui relie SPF et DKIM au domaine visible du champ From: et dit aux destinataires quoi faire en cas d'échec. C'est un enregistrement DNS (v=DMARC1) qui définit une politique — ne rien faire, mettre en quarantaine, ou rejeter — et demande des rapports. Sans DMARC, SPF et DKIM protègent des identifiants techniques que l'utilisateur ne voit jamais ; DMARC est ce qui protège enfin l'adresse affichée. Les principes complets sont dans les fondamentaux, expliqués sans jargon.
Alignement (alignment)
L'alignement est le cœur de DMARC : il exige que le domaine validé par SPF ou DKIM corresponde au domaine du From: visible. Un message peut très bien passer SPF et DKIM sur des domaines techniques d'un tiers tout en usurpant l'adresse affichée ; l'alignement ferme cette faille en imposant la concordance. DMARC réussit dès qu'au moins un des deux (SPF ou DKIM) est aligné. Le mécanisme est disséqué dans SPF, DKIM et DMARC expliqués ensemble.
Politique (p=none / quarantine / reject)
La balise p d'un enregistrement DMARC dicte le sort des messages non authentifiés. p=none observe sans agir (les messages usurpés passent, mais les rapports arrivent) ; p=quarantine les range en indésirables ; p=reject les bloque à la porte. Seul p=reject protège réellement un domaine — p=none n'est qu'une étape de diagnostic, pas une destination. Le choix entre les deux paliers d'application est traité dans quarantine ou reject.
Les rapports
RUA (rapport agrégé)
Les rapports RUA sont des synthèses XML quotidiennes que les destinataires renvoient à l'adresse déclarée dans la balise rua=. Ils recensent, par source d'envoi, les volumes de courrier et les résultats SPF/DKIM/DMARC — sans jamais exposer le contenu des messages. C'est le radar du domaine : ils révèlent qui émet en son nom, légitimement ou non, et guident la montée vers p=reject. Leur lecture est expliquée dans comprendre les rapports agrégés DMARC.
RUF (rapport d'échec)
Les rapports RUF (ou forensiques) sont envoyés au fil de l'eau, message par message, quand un e-mail échoue à l'authentification. Ils sont bien plus détaillés que les RUA — jusqu'à inclure des en-têtes et des fragments du message — ce qui pose de sérieuses questions de vie privée, au point que la plupart des destinataires ne les émettent plus. La différence de nature entre les deux canaux est développée dans la comparaison des deux types de rapport.
DMARCbis et les nouveautés
DMARCbis
DMARCbis est la révision de DMARC publiée en 2026, qui remplace la RFC 7489 d'origine (2015) et fait passer le protocole sur la voie officielle des standards. Même principe, même identifiant v=DMARC1 : ce n'est pas une rupture, mais un texte réécrit avec de nouvelles balises (np, t) et un mécanisme d'attribution de domaine plus robuste. Les enregistrements déjà publiés restent valides. Ce qui change vraiment est détaillé dans la révision de la norme.
Balise np
La balise np fixe la politique appliquée aux sous-domaines qui n'existent pas. C'est une cible d'usurpation classique : un attaquant peut forger facture.exemple.fr même si ce sous-domaine n'a jamais été créé, car rien ne le protège par défaut. Poser np=reject ferme cette porte sans aucun risque pour le courrier légitime, puisque ces sous-domaines n'émettent rien. Son fonctionnement est décrit dans la balise np de DMARC.
Balise t
La balise t remplace l'ancien pct et introduit un mode test binaire : t=y signale une politique en cours d'expérimentation, que les destinataires ne doivent pas encore appliquer strictement. Elle sert à observer l'effet d'un durcissement avant de l'activer pour de bon, en s'appuyant sur les rapports plutôt que sur un pourcentage aléatoire de messages. Son usage est expliqué dans la balise t de DMARC.
DNS Tree Walk
Le DNS Tree Walk est le mécanisme qui, dans DMARCbis, détermine le domaine organisationnel par une suite de requêtes DNS de proche en proche (huit au maximum), en remontant l'arbre des noms. Il remplace la Public Suffix List, une liste externe maintenue à la main dont DMARC dépendait auparavant. Résultat : plus de prévisibilité, aucune dépendance à un fichier tiers. Le parcours exact est détaillé dans le DNS Tree Walk expliqué.
Domaine organisationnel
Le domaine organisationnel est le domaine « racine » sous lequel vivent les sous-domaines — par exemple ma-banque.fr pour mail.ma-banque.fr. DMARC s'appuie sur cette notion pour deux choses : décider si SPF ou DKIM est aligné (alignement relâché), et savoir quelle politique de sous-domaine (sp) s'applique. La façon dont DMARCbis le calcule désormais — via le Tree Walk plutôt que via une liste — est au cœur de ce qui change dans DMARCbis.
Transport et traçabilité
MTA-STS
MTA-STS (Mail Transfer Agent Strict Transport Security) force le chiffrement TLS du transport entre serveurs de messagerie et empêche qu'un attaquant fasse retomber la connexion en clair. La politique se publie via un enregistrement DNS et un fichier servi en HTTPS, et exige que le courrier entrant arrive uniquement sur une connexion chiffrée et authentifiée. C'est le complément « transport » de l'authentification « contenu » qu'assurent SPF, DKIM et DMARC. Sa mise en place est décrite dans le chiffrement de transport, expliqué.
TLS-RPT
TLS-RPT (TLS Reporting) est le canal de rapport associé à MTA-STS : il demande aux serveurs distants de signaler les échecs de négociation TLS rencontrés en livrant du courrier. Une adresse se déclare dans un enregistrement DNS _smtp._tls, et les synthèses reçues révèlent les problèmes de chiffrement avant qu'ils ne dégradent silencieusement la sécurité du transport. Le détail est dans les rapports de transport, expliqués.
ARC (Authenticated Received Chain)
ARC préserve le résultat d'authentification d'un message lorsqu'il transite par un intermédiaire — une liste de diffusion, un service de transfert — qui modifie légitimement le contenu et casserait sinon SPF et DKIM. Chaque relais ARC-conforme signe une « chaîne » attestant que l'authentification était valide à son arrivée, ce qui permet au destinataire final d'en tenir compte. ARC ne remplace pas DMARC ; il évite que des flux légitimes indirects soient rejetés à tort.
BIMI et l'affichage de marque
BIMI (Brand Indicators for Message Identification)
BIMI affiche le logo de la marque à côté de ses messages dans les boîtes de réception qui le supportent (Gmail, Yahoo, Apple Mail…). C'est la récompense visible d'un domaine bien tenu : BIMI n'est accordé qu'aux domaines en p=quarantine ou p=reject, ce qui en fait un signal de confiance autant qu'un levier marketing. Le dispositif repose sur un enregistrement DNS pointant vers le logo au format SVG. La mise en place complète est dans poser le logo côté Gmail.
VMC (Verified Mark Certificate)
Le VMC est un certificat qui prouve la détention légitime du logo affiché via BIMI. Émis par une autorité de certification après vérification de la marque déposée, il est exigé par Gmail et d'autres pour afficher le logo. C'est la pièce qui empêche un fraudeur d'usurper l'identité visuelle d'une marque connue. Son rôle et son coût sont détaillés dans le certificat VMC pour BIMI.
CMC (Common Mark Certificate)
Le CMC est une alternative plus accessible au VMC, destinée aux logos qui ne sont pas des marques déposées (par exemple une administration ou une organisation sans marque enregistrée). Il permet d'afficher un logo via BIMI sans passer par le dépôt de marque exigé pour un VMC, moyennant d'autres formes de vérification. Les cas où il s'applique sont exposés dans le logo sans certificat.
Les menaces
Spoofing (usurpation)
Le spoofing consiste à falsifier l'adresse d'expéditeur d'un e-mail pour faire croire qu'il vient d'une organisation donnée. Techniquement trivial — l'adresse From: n'est qu'un champ texte librement modifiable — c'est la menace fondamentale que SPF, DKIM et surtout DMARC existent pour neutraliser. Tant qu'un domaine n'est pas en p=reject, n'importe qui peut envoyer du courrier sous son nom. Les mécanismes et les parades sont détaillés dans qu'est-ce que l'usurpation d'email.
Phishing (hameçonnage)
Le phishing est une attaque qui manipule la victime pour lui soutirer des identifiants, un paiement ou une action sensible, souvent au moyen d'un e-mail se faisant passer pour une source de confiance. L'usurpation de domaine est son carburant le plus efficace : un message qui semble vraiment venir de la banque ou de l'employeur de la victime fait tomber toutes ses défenses. Couper l'usurpation à la source réduit d'autant la surface d'attaque, comme l'explique prévenir le phishing sur un domaine.
BEC (fraude au président)
Le BEC (Business Email Compromise), ou fraude au président, cible une organisation en se faisant passer pour un dirigeant ou un fournisseur afin d'ordonner un virement frauduleux ou une fuite de données. C'est l'une des fraudes les plus coûteuses, car elle joue sur l'autorité et l'urgence plutôt que sur une faille technique — mais l'usurpation d'un domaine légitime la rend redoutablement crédible. Le mode opératoire et les défenses sont détaillés dans la fraude au président (BEC).
Par où commencer
Ce glossaire décrit un dispositif ; le mettre en place commence toujours par un état des lieux. La façon la plus rapide de savoir où en est un domaine — quelle politique DMARC, quel alignement SPF/DKIM, quelles sources émettent en son nom — est de le passer dans un analyseur DMARC gratuit. Le verdict sur la posture actuelle tombe immédiatement, et se compare ensuite à celle du secteur dans l'Observatoire DMARC.
Transformer ce diagnostic en action — nommer chaque source, générer le DNS à publier, franchir chaque palier de p=none jusqu'à p=reject sans casser un seul flux légitime — est exactement ce que Thomas, le RSSI virtuel, automatise. Analyser un domaine gratuitement · explorer l'Observatoire · commencer avec Thomas.
Guides liés
- Atteindre p=reject sans casser ses emails
Un chemin progressif et sûr de la surveillance DMARC (p=none) à l'application complète (p=reject) — sans bloquer un seul message légitime.
- Checklist d'éligibilité : un domaine est-il prêt à passer p=reject ?
Sept conditions à réunir avant de durcir DMARC de p=none à p=reject : la checklist d'éligibilité pour appliquer sans bloquer un email légitime.
- p=quarantine ou p=reject : lequel choisir ?
p=quarantine ou p=reject : ce que chaque politique DMARC fait vraiment au courrier en échec, et les critères qui tranchent entre risque et protection.
À 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.