Deux serveurs SMTP qui négocient STARTTLS chiffrent leur échange, sauf si l'un des deux ne répond pas correctement à la commande. Dans ce cas, la RFC 3207 prévoit un repli en clair, sans avertissement pour l'expéditeur ni pour le destinataire. C'est le principe même du TLS opportuniste appliqué au mail : chiffrer quand c'est possible, livrer quand même sinon. Un attaquant en position de MITM n'a donc qu'à intercepter la réponse STARTTLS et la remplacer par une erreur pour forcer un repli en clair, une attaque de downgrade documentée depuis des années et toujours praticable sur une part significative du trafic mail mondial.
Après SPF, DKIM et DMARC, qui garantissent l'identité de l'expéditeur, la question suivante est différente : est-ce que le transport lui-même est protégé, et est-ce qu'on le sait quand il ne l'est pas ? Trois mécanismes répondent à ça, et ils ne se substituent pas les uns aux autres.
MTA-STS : une politique HTTPS pour forcer le TLS
MTA Strict Transport Security (RFC 8461) publie une politique de chiffrement obligatoire, mais pas dans le DNS directement : un enregistrement TXT signale son existence, et le contenu réel est récupéré via HTTPS sur https://mta-sts.<domaine>/.well-known/mta-sts.txt.
_mta-sts.example.com. IN TXT "v=STSv1; id=20260811000000Z"
version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800
Le champ mode porte toute la logique. En testing, l'expéditeur applique la politique en observation seule : si le TLS échoue, il livre quand même, mais consigne l'anomalie. En enforce, un MX qui ne présente pas un certificat valide et correspondant au nom déclaré est purement et simplement écarté, le message n'est pas livré en clair. C'est exactement le comportement qui neutralise le downgrade décrit plus haut.
Le point de bascule dépend uniquement de la confiance dans les rapports observés en mode testing. Deux semaines suffisent généralement à couvrir un cycle représentatif d'expéditeurs, avant de passer en enforce.
DANE : la même garantie, via DNSSEC
DNS-Based Authentication of Named Entities pour SMTP (RFC 7672) publie un enregistrement TLSA qui lie un nom de MX à une empreinte de certificat attendue.
_25._tcp.mx1.example.com. IN TLSA 3 1 1 <empreinte-sha256-du-certificat>
L'expéditeur qui supporte DANE valide cette empreinte au moment de la connexion. Si elle ne correspond pas, la livraison est refusée en mode DANE strict, avec la même logique de résistance au downgrade que MTA-STS. La différence tient à la racine de confiance : DANE ne dépend d'aucune autorité de certification, l'enregistrement TLSA lui-même fait foi, à condition que la zone DNS qui le porte soit signée par DNSSEC. Sans DNSSEC, un enregistrement TLSA n'a aucune valeur de sécurité : un attaquant capable d'usurper une réponse DNS peut publier n'importe quelle empreinte.
C'est la raison structurelle pour laquelle le monde du mail s'est scindé en deux camps plutôt que de converger sur un seul mécanisme. DANE demande une chaîne complète, zone signée DNSSEC, résolveur validant côté expéditeur, TLSA correctement publié. Sans ce socle, DANE est simplement inopérant. MTA-STS contourne le problème en s'appuyant sur la confiance HTTPS classique, celle des autorités de certification, ce qui le rend déployable sans toucher au DNS de la zone mail elle-même au-delà d'un TXT.
Le critère de choix, sans détour
Si votre zone est déjà signée DNSSEC et que vous la maintenez proprement, DANE est le mécanisme le plus solide : pas de dépendance à une autorité de certification tierce, pas de fichier HTTPS à héberger et renouveler. C'est la voie retenue par une partie du monde académique et administratif européen, notamment en Allemagne et aux Pays-Bas.
Si votre DNSSEC n'est pas en place, ou si la maintenance de la signature de zone n'est pas un sujet maîtrisé en interne, MTA-STS est la voie réaliste. Il ne demande qu'un enregistrement TXT et un fichier statique servi en HTTPS, deux briques que n'importe quelle infra web maîtrise déjà. Gmail et Outlook.com le supportent tous les deux en réception, ce qui en fait, de fait, le mécanisme au déploiement le plus large aujourd'hui.
Rien n'empêche de déployer les deux en parallèle : ils ne rentrent pas en conflit, chacun ferme la même faille par une racine de confiance différente. Sur une infra qui possède déjà une zone DNSSEC pour d'autres raisons, ne déployer que MTA-STS reviendrait à laisser un actif de sécurité disponible sur la table.
TLS-RPT : le seul retour qu'on ait sur ce qui casse
Sans reporting, une politique en mode enforce ou une validation DANE stricte échoue silencieusement du point de vue de l'expéditeur : le message n'est simplement pas livré, et personne côté domaine receveur n'en sait rien tant qu'un utilisateur ne signale pas une absence de courrier. SMTP TLS Reporting (RFC 8460) referme ce trou en publiant un enregistrement TXT qui indique où envoyer des rapports JSON quotidiens.
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-rpt@example.com"
Chaque rapport agrège, par MTA expéditeur, le nombre de sessions réussies et le détail des échecs : certificat expiré, nom ne correspondant pas au MX, échec de validation TLSA, poignée de main STARTTLS interrompue. C'est la seule télémétrie disponible sur ce trafic, puisque le transport lui-même se négocie sans jamais remonter d'erreur à l'utilisateur final. Sur le terrain, c'est souvent un rapport TLS-RPT qui révèle un certificat expiré trois jours après le renouvellement raté d'un MX secondaire, bien avant qu'un client ne s'en plaigne.
TLS-RPT n'a de sens qu'associé à MTA-STS ou DANE : sans politique déclarée, il n'y a rien à faire respecter, donc rien à signaler en cas d'échec. Les trois mécanismes forment un ensemble cohérent, pas trois options indépendantes.
Ce que ça change en exploitation
Poser MTA-STS ou DANE, c'est transformer un TLS optionnel en TLS garanti pour un domaine donné, et TLS-RPT transforme un échec silencieux en incident visible. Sur une chaîne mail déjà durcie côté Postfix et Dovecot, c'est l'étape suivante logique une fois l'authentification SPF/DKIM/DMARC posée : garantir que le canal lui-même ne se dégrade pas sans qu'on le sache. Ça rejoint directement les bonnes pratiques générales de configuration TLS, version durcie et automatisée pour le protocole SMTP.
Pour une organisation qui revendique la maîtrise réelle de son courrier électronique, au-delà du seul hébergement, l'absence de TLS-RPT revient à opérer un service de messagerie souverain sans jamais vérifier que le chiffrement promis tient réellement la route sur chaque MX de destination.
Sur les infrastructures mail qu'on opère, ce déploiement suit un ordre strict : DNSSEC d'abord si la zone ne l'a pas, TLS-RPT ensuite pour avoir de la visibilité, MTA-STS ou DANE en mode testing pour observer, puis enforce quand les rapports sont propres. Si votre domaine expédie encore en TLS opportuniste pur, sans aucun retour sur les sessions dégradées, on peut poser DNSSEC, MTA-STS et le reporting associé sur votre infrastructure mail.
Sources
- RFC 8461, SMTP MTA Strict Transport Security (MTA-STS) : spécification des modes testing/enforce/none et du fichier de politique HTTPS.
- RFC 7672, SMTP Security via Opportunistic DANE TLS : dépendance de DANE à DNSSEC et modes opportuniste versus obligatoire.
- RFC 8460, SMTP TLS Reporting : format des rapports agrégés JSON et types d'échecs remontés.
- APNIC Blog, Better mail security with DANE for SMTP : retour d'expérience sur le déploiement de DANE et sa complémentarité avec MTA-STS.
