Dernière mise à jour : juillet 2026

En bref : « l’authentification e-mail », ce sont en réalité deux couches. L’une prouve qui a envoyé un message — c’est SPF, DKIM et DMARC. L’autre protège le message en transit — c’est TLS, MTA-STS, DANE et TLS-RPT. Tu veux les deux. Cette page explique comment les briques s’assemblent et te renvoie directement vers le guide de configuration pour ton fournisseur.

SMTP, le protocole qui transporte les e-mails, a été conçu à une époque de confiance mutuelle. Il n’a aucun moyen intégré de prouver qu’un expéditeur est bien celui qu’il prétend être, et aucune garantie intégrée qu’un message voyage chiffré. Tout ce qu’on appelle aujourd’hui « authentification e-mail » est un ensemble de standards ajoutés par-dessus pour combler ces deux lacunes. Comprendre quelle lacune chaque standard comble, c’est tout l’enjeu.

Couche un : qui a envoyé ceci ? (identité)

Trois enregistrements, publiés dans le DNS de ton domaine, permettent à un serveur destinataire de juger si un message vient vraiment de toi.

SPF — quels serveurs peuvent envoyer pour toi

SPF (Sender Policy Framework, RFC 7208) est un enregistrement TXT qui liste les serveurs de messagerie autorisés à envoyer avec ton domaine comme expéditeur. La valeur commence par v=spf1 et se termine par une politique comme ~all ou -all. Le destinataire le consulte à chaque message entrant et vérifie si le serveur qui livre figure sur ta liste. Sans SPF, n’importe qui peut mettre ton domaine dans l’enveloppe « From ». C’est le point de départ le plus simple — vois les guides de configuration SPF pour ton hébergeur.

DKIM — une signature cryptographique

DKIM (DomainKeys Identified Mail, RFC 6376) ajoute une signature numérique à chaque message. Ton serveur de messagerie signe le courrier sortant avec une clé privée ; la clé publique correspondante vit dans ton DNS sous forme d’enregistrement v=DKIM1 sous un sélecteur. Le destinataire vérifie la signature, ce qui prouve deux choses : le message est vraiment passé par ton infrastructure, et il n’a pas été modifié en chemin. Contrairement à SPF, DKIM survit au transfert — la signature voyage avec le message.

DMARC — la politique qui relie le tout

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) est là où SPF et DKIM deviennent utiles. Un enregistrement TXT v=DMARC1 dit aux destinataires quoi faire quand un message échoue aux deux vérifications — p=none (surveiller seulement), p=quarantine (dossier spam) ou p=reject (rejeter). Il demande aussi aux destinataires de t’envoyer des rapports agrégés, pour que tu voies qui envoie en ton nom avant de serrer la vis. Le chemin recommandé est none → quarantine → reject, en lisant les rapports à chaque étape.

Les trois se construisent l’un sur l’autre : SPF et DKIM sont les vérifications, DMARC est le verdict. On approfondit leur articulation dans SPF vs DKIM vs DMARC : comment ils s’articulent.

Couche deux : était-il protégé en transit ? (transport)

Prouver l’identité n’est que la moitié de l’histoire. Un message peut être parfaitement authentifié et quand même être lu ou altéré sur le réseau si la connexion entre serveurs n’est ni chiffrée ni vérifiée.

TLS et STARTTLS — le chiffrement opportuniste

Les serveurs de messagerie modernes proposent STARTTLS, qui élève une connexion SMTP vers une connexion chiffrée. Le hic : par défaut, c’est opportuniste. Si la négociation échoue, ou si un attaquant supprime l’offre STARTTLS, la distribution retombe silencieusement en clair. Le chiffrement a lieu quand il peut, pas quand il doit. Les deux standards suivants transforment « peut » en « doit ».

MTA-STS — imposer TLS via une politique HTTPS

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) publie un fichier de politique via HTTPS qui dit aux serveurs expéditeurs : pour mon domaine, TLS est obligatoire et le certificat doit être valide. Cela ferme la faille de rétrogradation sans exiger DNSSEC, ce qui explique qu’il fonctionne chez presque tous les hébergeurs. C’est le choix pratique pour la plupart des gens — lis MTA-STS en hébergement mutualisé pour savoir qui peut le déployer et qui ne peut pas.

DANE — imposer TLS via DNSSEC

DANE (DNS-Based Authentication of Named Entities, RFC 6698) atteint le même but — un TLS obligatoire et authentifié — mais ancre la confiance dans DNSSEC et un enregistrement TLSA sur ton MX. C’est plus fort, mais seul l’opérateur de ton serveur de messagerie entrant peut le déployer, donc c’est hors de portée de la plupart des clients en hébergement mutualisé. On détaille exactement qui est éligible dans DANE pour l’e-mail : qui peut l’utiliser.

TLS-RPT — savoir quand la distribution échoue

TLS-RPT (SMTP TLS Reporting, RFC 8460) est le canal de retour. Un petit enregistrement TXT contenant TLSRPTv1 demande aux serveurs expéditeurs de t’envoyer des rapports quotidiens sur la distribution TLS vers ton domaine — les succès et, surtout, les échecs. Que tu utilises MTA-STS ou DANE, TLS-RPT est le moyen d’apprendre qu’un truc a cassé, au lieu de l’apprendre par un client mécontent.

La récompense : BIMI

Une fois DMARC en application (p=quarantine ou p=reject), tu peux ajouter BIMI (Brand Indicators for Message Identification). Il affiche ton logo à côté du courrier authentifié dans les boîtes de réception compatibles. BIMI ne fait rien pour la sécurité en soi — c’est la récompense visible du travail d’authentification accompli. Vois les guides de configuration BIMI une fois ton DMARC en application. Le standard est piloté par le BIMI Group.

Comment dérouler tout ça concrètement

Un ordre d’opérations sain :

  1. SPF — publie ou vérifie ton enregistrement. Un enregistrement, une politique.
  2. DKIM — active la signature chez ton fournisseur, publie la clé publique.
  3. DMARC — démarre à p=none et lis les rapports pendant quelques semaines.
  4. Durcis DMARC — passe à quarantine, puis reject, quand les rapports sont propres.
  5. Transport — ajoute MTA-STS (ou DANE si tu es éligible) et TLS-RPT.
  6. BIMI — la touche finale, une fois DMARC en application.

Chaque étape a ses détails propres à chaque fournisseur. Choisis ton hébergeur dans les guides par fournisseur et suis le pas-à-pas.

Vérifier le résultat

Le scanner MXAudit gratuit vérifie tout cela en une passe : syntaxe SPF et nombre de lookups, clés DKIM, ta politique DMARC, plus MTA-STS, DANE, TLS-RPT et BIMI. C’est le moyen le plus rapide de voir laquelle des deux couches tu as réellement couverte — et où sont les trous.

Pour aller plus loin