Vous avez peut-être déjà vu un cadenas rouge dans Gmail avec le message “Le fournisseur n’a pas chiffré ce message”. Cela signifie que l’email a transité en clair entre les serveurs, sans chiffrement TLS. En 2026, c’est un signal d’alerte sérieux.

Pourquoi chiffrer les emails en transit

Sans TLS, le contenu d’un email circule en texte clair entre le serveur d’envoi et le serveur de réception. Quiconque intercepte le trafic réseau (attaque man-in-the-middle, FAI compromis, Wi-Fi public) peut :

  • Lire le contenu intégral du message
  • Modifier le message en transit
  • Extraire les pièces jointes, identifiants, liens

Le chiffrement TLS crée un tunnel chiffré entre les deux serveurs SMTP. Même intercepté, le trafic est illisible.

Comment fonctionne STARTTLS

Le protocole SMTP ne chiffre rien par défaut. Le chiffrement est négocié via l’extension STARTTLS :

  1. Le serveur d’envoi se connecte au serveur destinataire sur le port 25
  2. Le serveur destinataire annonce 250-STARTTLS dans sa bannière
  3. Le serveur d’envoi envoie la commande STARTTLS
  4. Les deux serveurs négocient un tunnel TLS (échange de certificats, choix du cipher)
  5. L’email est transmis dans le tunnel chiffré
S: 220 mx.example.com ESMTP
C: EHLO sender.example.com
S: 250-mx.example.com
S: 250-STARTTLS
S: 250 OK
C: STARTTLS
S: 220 Ready to start TLS
[... négociation TLS ...]
C: EHLO sender.example.com
[... envoi de l'email chiffré ...]

TLS opportuniste vs TLS forcé

TLS opportuniste (par défaut)

La plupart des serveurs utilisent le TLS opportuniste : si le serveur destinataire supporte STARTTLS, on chiffre. Sinon, on envoie en clair. C’est mieux que rien, mais vulnérable aux attaques de downgrade : un attaquant peut supprimer l’annonce STARTTLS de la bannière, forçant l’envoi en clair.

TLS forcé

Le serveur d’envoi refuse de transmettre l’email si TLS n’est pas disponible. Plus sécurisé, mais risque de non-délivrance si le destinataire ne supporte pas TLS.

MTA-STS : forcer le TLS proprement

MTA-STS (Mail Transfer Agent Strict Transport Security) résout le problème du TLS opportuniste. C’est l’équivalent de HSTS pour le web, appliqué au SMTP.

Comment ça marche

  1. Le domaine destinataire publie un record DNS TXT :
_mta-sts.example.com TXT "v=STSv1; id=20260524"
  1. Et héberge un fichier de politique sur HTTPS :
https://mta-sts.example.com/.well-known/mta-sts.txt

version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800
  1. Le serveur d’envoi vérifie cette politique et refuse d’envoyer en clair si le mode est enforce

Les modes MTA-STS

ModeComportement
nonePas de politique (désactivé)
testingTLS exigé, mais les échecs sont uniquement reportés (pas de blocage)
enforceTLS exigé, les emails sont rejetés si TLS échoue

Commencez par testing, analysez les rapports, puis passez à enforce.

Vérifiez votre configuration avec le MTA-STS Checker gratuit.

DANE : TLS vérifié par DNSSEC

DANE (DNS-Based Authentication of Named Entities) utilise des records DNS TLSA sécurisés par DNSSEC pour publier l’empreinte du certificat TLS du serveur mail.

Contrairement à MTA-STS, DANE ne nécessite pas d’héberger un fichier HTTPS. Il est plus robuste (protégé par DNSSEC) mais nécessite que le domaine et le résolveur DNS supportent DNSSEC, ce qui limite son adoption.

TLS-RPT : les rapports de chiffrement

TLS-RPT (TLS Reporting) permet de recevoir des rapports sur les échecs de négociation TLS, exactement comme DMARC fournit des rapports sur l’authentification email.

Configuration DNS :

_smtp._tls.example.com TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Les rapports TLS indiquent :

  • Les tentatives de connexion TLS échouées
  • Les problèmes de certificat (expiré, nom invalide)
  • Les échecs de politique MTA-STS ou DANE
  • Les attaques de downgrade détectées

Si vous utilisez Sender Audit, les rapports TLS sont analysés et visualisés automatiquement dans votre dashboard.

Vérifiez votre configuration TLS-RPT avec le TLS-RPT Checker gratuit.

Quel cipher est utilisé ?

Tous les chiffrements TLS ne se valent pas. Les versions modernes utilisent TLS 1.2 ou 1.3 avec des ciphers robustes :

VersionStatut
SSL 2.0 / 3.0Obsolète, vulnérable
TLS 1.0Obsolète depuis 2020
TLS 1.1Obsolète depuis 2020
TLS 1.2Acceptable
TLS 1.3Recommandé (plus rapide, plus sécurisé)

Un audit gratuit vous indique la version TLS et le cipher utilisés pour livrer votre email de test.

Que faire si votre ESP n’utilise pas TLS

  1. Vérifiez : lancez un audit pour voir si TLS est utilisé
  2. Contactez votre ESP : demandez leur roadmap TLS
  3. Changez d’ESP si nécessaire : en 2026, ne pas supporter TLS est rédhibitoire

Les principaux fournisseurs (Google, Microsoft, Yahoo, Apple) pénalisent déjà les emails reçus sans TLS, avec des avertissements visuels pour les destinataires.

Pour aller plus loin