Chiffrement du transport : MTA-STS et les rapports TLS
MTA-STS impose le chiffrement du courrier qui vous est adressé, TLS-RPT vous en rend compte. Comment publier la politique et que faire des constats.
Quand deux serveurs de messagerie se parlent, ils commencent en clair puis se proposent mutuellement de passer au chiffrement. C’est STARTTLS, et il a une faiblesse de conception : l’offre de chiffrer se fait en clair. Quelqu’un placé entre les deux peut la supprimer, et les serveurs, croyant qu’aucun chiffrement n’est possible, poursuivent sans. Les deux côtés pensent avoir fait au mieux.
MTA-STS ferme cette porte. Vous publiez une politique qui dit : le courrier destiné à mon domaine doit arriver chiffré, et voici la liste des serveurs qui ont le droit de le recevoir. Un serveur émetteur qui respecte MTA-STS lit cette politique, la conserve en mémoire, et refuse ensuite de remettre le message si le chiffrement n’est pas possible ou si le serveur en face n’est pas dans la liste. Le second enregistrement, TLS-RPT, demande aux expéditeurs de vous envoyer un rapport quotidien des échecs.
Nous ne testons pas STARTTLS lui-même, ni les certificats de vos serveurs de messagerie : le trafic SMTP sortant est bloqué depuis notre serveur de test. Le rapport indique donc « non mesurable » plutôt que de laisser croire, par son silence, que tout va bien. Ce que nous mesurons ici est ce qui se lit dans le DNS et en HTTPS : l’enregistrement MTA-STS, le fichier de politique, et l’enregistrement TLS-RPT.
À quoi ressemble la configuration
MTA-STS tient en deux pièces qui doivent être cohérentes : un enregistrement DNS qui annonce l’existence d’une politique, et un fichier servi en HTTPS qui la contient.
_mta-sts.exemple.fr. IN TXT "v=STSv1; id=20260916120000"https://mta-sts.exemple.fr/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mx1.mail.ovh.net
mx: mx2.mail.ovh.net
max_age: 604800| Élément | Ce qu’il fait |
|---|---|
id= | Un identifiant de version, généralement un horodatage. Il doit changer à chaque modification du fichier, sinon les expéditeurs gardent l’ancienne politique en mémoire. |
mode: | testing signale sans imposer, enforce impose, none désactive. |
mx: | Un par serveur autorisé. Les caractères génériques sont permis (*.mail.ovh.net). |
max_age: | La durée de conservation en mémoire, en secondes. 604800 vaut une semaine. |
L’enregistrement TLS-RPT est indépendant et beaucoup plus simple :
_smtp._tls.exemple.fr. IN TXT "v=TLSRPTv1; rua=mailto:tls@exemple.fr"Il est utile même sans MTA-STS : les rapports arrivent dès lors que des expéditeurs constatent un problème de chiffrement avec vos serveurs.
Ce qui rend MTA-STS délicat
MTA-STS est le seul de ces enregistrements dont une erreur peut arrêter la remise de votre courrier entrant. Si la politique est en enforce et qu’un de vos serveurs n’y figure pas, un expéditeur qui respecte MTA-STS n’a pas le droit de remettre le message à ce serveur. Il n’essaie pas quand même : il s’arrête. Et vous ne le voyez pas, puisque le message n’arrive jamais.
D’où trois précautions :
- Commencer en
mode: testing. Rien n’est imposé, mais les rapports TLS arrivent et montrent les écarts. - Publier TLS-RPT avant MTA-STS. Sans rapports, la phase de test ne vous apprend rien.
- Relire la liste
mx:à chaque changement chez votre fournisseur de messagerie. C’est la seule partie du fichier qui peut se désynchroniser toute seule.
Comment le mettre en place
Le sous-domaine mta-sts.exemple.fr doit exister, résoudre, et servir le fichier en HTTPS avec un certificat valide. Il n’a pas besoin d’un serveur à lui : un hébergement statique, un sous-domaine de votre site, ou un service de pages suffisent.
- Créez le sous-domaine
mta-sts.exemple.fret faites-le pointer vers un serveur web que vous contrôlez. - Obtenez un certificat valide pour ce nom.
- Déposez le fichier à l’adresse
/.well-known/mta-sts.txt, servi en texte brut. Vérifiez qu’il s’affiche dans un navigateur. - Publiez l’enregistrement TXT
_smtp._tlsavec votre adresse de rapports. - Publiez l’enregistrement TXT
_mta-stsavec uniddaté du jour. - Laissez tourner deux à quatre semaines en
mode: testinget lisez les rapports. - Si aucun écart n’apparaît, passez en
mode: enforceet changez l’id.
| Hébergeur | Ce qu’il faut savoir |
|---|---|
| OVHcloud | Sous-domaine et zone DNS dans Web Cloud ; le fichier se dépose sur votre hébergement web |
| Gandi | Zone DNS dans l’espace Domaines ; Gandi propose un hébergement web simple pour le fichier |
| Infomaniak | Zone DNS et hébergement dans le Manager, certificat automatique |
| o2switch | Sous-domaine dans cPanel, certificat automatique, fichier déposé par le gestionnaire de fichiers |
| LWS | Sous-domaine et zone DNS dans le panneau |
| IONOS France | Sous-domaine et DNS dans le centre de domaines |
| Microsoft 365 et Google Workspace | Les MX à lister sont ceux de votre mandant ; le fichier se dépose ailleurs, chez votre hébergeur web |
Les constats en détail
Plusieurs enregistrements MTA-STS
Plus d’un TXT commençant par v=STSv1 existe sur _mta-sts.
Un seul est permis. Face à plusieurs, un expéditeur ne peut pas déterminer quelle version de politique est en vigueur, et l’indication devient inutilisable. La cause habituelle est un ancien enregistrement resté en place après une mise à jour de l’id.
Ce qu’il faut faire. Gardez celui qui porte l’id le plus récent, supprimez les autres.
MTA-STS en mode test
La politique est en mode: testing.
Ce n’est pas un défaut, c’est une étape. En mode test, rien n’est imposé : les expéditeurs signalent les écarts dans leurs rapports TLS mais remettent le courrier normalement. C’est exactement ce qu’il faut faire au début. Cela devient un problème quand la phase de test dure depuis un an – la protection n’est alors toujours pas active.
Ce qu’il faut faire. Relisez les rapports TLS des dernières semaines. Si aucun échec n’apparaît, passez en mode: enforce et modifiez l’id du fichier pour que les expéditeurs rechargent la politique.
MTA-STS désactivé (mode: none)
La politique porte mode: none.
C’est une désactivation explicite. Le standard la prévoit pour retirer proprement une politique : on publie none, on attend que les max_age en cours expirent, puis on supprime l’ensemble. Trouver none longtemps après, c’est généralement le signe d’une désactivation d’urgence dont personne n’a fait le deuxième temps.
Ce qu’il faut faire. Décidez. Si MTA-STS doit fonctionner, repassez en testing, puis en enforce. Si vous y renoncez, supprimez le fichier de politique et l’enregistrement DNS : un enregistrement qui annonce une politique inactive n’apporte rien.
Validité MTA-STS très courte
La valeur de max_age est inférieure à une journée.
Le max_age détermine combien de temps un expéditeur garde votre politique en mémoire. C’est ce cache qui fait toute la protection : pendant cette durée, un attaquant ne peut plus faire croire que votre domaine n’a pas de politique. Avec quelques heures, la fenêtre d’attaque se rouvre en permanence.
Ce qu’il faut faire. Portez max_age à 604800 secondes, soit une semaine – la valeur usuelle. Le minimum raisonnable est 86400. Une valeur basse se justifie quelques jours pendant la mise en route, pas durablement.
La politique ne cite pas tous les serveurs
Des serveurs présents dans vos enregistrements MX ne figurent pas dans la liste mx: du fichier.
En mode: testing, cela ne bloque rien mais génère des rapports d’échec, et cela annonce ce qui se passerait en enforce : le courrier arrivant sur ces serveurs ne serait plus remis. Le décalage vient presque toujours d’un changement chez le fournisseur de messagerie, sans mise à jour du fichier.
Ce qu’il faut faire. Comparez la liste mx: avec vos enregistrements MX réels, ajoutez les noms manquants, et modifiez l’id pour que la nouvelle version soit chargée. Un caractère générique – *.mail.ovh.net – évite d’avoir à revenir à chaque ajout de serveur.
La politique imposée exclut vos propres serveurs
La politique est en mode: enforce et ne cite pas tous les serveurs de vos enregistrements MX.
C’est le cas le plus grave de cette page. Les expéditeurs qui respectent MTA-STS – Gmail, Microsoft et les autres grands opérateurs en font partie – n’ont pas le droit de remettre le message à un serveur absent de la liste. Ils s’arrêtent. Une partie de votre courrier entrant n’arrive pas, et rien de visible chez vous ne le signale.
Ce qu’il faut faire, tout de suite. Deux issues possibles. La plus rapide : repasser le fichier en mode: testing et changer l’id – la remise reprend normalement le temps que vous corrigiez. La plus propre : ajouter immédiatement les noms MX manquants et changer l’id. Dans les deux cas, la modification n’est effective qu’une fois les caches expirés chez les expéditeurs, ce qui peut prendre jusqu’à la durée de votre max_age.
Enregistrement MTA-STS sans fichier de politique
L’enregistrement DNS annonce une politique, mais le fichier n’est pas accessible à l’adresse prévue.
L’annonce sans le fichier place les expéditeurs dans une situation ambiguë, que certains résolvent en interrompant la remise. Les causes fréquentes : le sous-domaine mta-sts ne résout pas, le certificat HTTPS est expiré, le fichier a disparu lors d’une refonte du site, ou le serveur le renvoie avec une redirection.
Ce qu’il faut faire. Ouvrez https://mta-sts.votre-domaine/.well-known/mta-sts.txt dans un navigateur. Vous devez voir le texte de la politique, sans avertissement de certificat et sans redirection. Si le fichier est durablement indisponible, retirez l’enregistrement DNS en attendant : mieux vaut pas de politique du tout qu’une politique annoncée et introuvable.
TLS-RPT sans adresse de destination
L’enregistrement _smtp._tls existe mais ne contient pas de champ rua=.
Aucun rapport ne vous parvient donc, alors que c’est la seule raison d’être de cet enregistrement. Sans rapports, vous ne saurez pas qu’un expéditeur échoue à vous joindre en chiffré – et vous ne pourrez pas passer MTA-STS en enforce en connaissance de cause.
Ce qu’il faut faire. Ajoutez rua=mailto:tls@exemple.fr, avec une boîte réellement relevée. Les rapports sont des fichiers JSON compressés, peu nombreux : quelques-uns par semaine pour un domaine ordinaire.
Questions fréquentes
MTA-STS protège-t-il aussi le courrier que j’envoie ?
Non. Votre politique porte sur le courrier qui vous est adressé. Pour vos envois, c’est la politique du destinataire qui s’applique, et c’est votre serveur d’envoi qui doit la respecter – une fonction que les grands fournisseurs de messagerie assurent déjà.
Faut-il MTA-STS quand on est chez Microsoft 365 ou Google Workspace ?
C’est utile, oui. Ces opérateurs chiffrent déjà entre eux, mais MTA-STS protège contre un attaquant qui supprimerait l’offre de chiffrement, quel que soit l’expéditeur. Le travail consiste alors surtout à lister correctement les serveurs de votre mandant.
Pourquoi le rapport dit-il « non mesurable » pour STARTTLS ?
Parce que nous ne pouvons pas ouvrir de connexion SMTP sortante depuis notre serveur de test. Nous préférons le dire plutôt que laisser une case vide passer pour un résultat favorable. Pour vérifier STARTTLS et les certificats de vos serveurs, il faut un outil qui se connecte réellement à eux.
TLS-RPT sans MTA-STS, cela a-t-il un sens ?
Oui, et c’est même le bon ordre. Publier TLS-RPT en premier vous donne, sans aucun risque, une vision des problèmes de chiffrement que rencontrent ceux qui vous écrivent. Vous abordez ensuite MTA-STS en sachant à quoi vous attendre.
La vérification e-mail mesure exactement ce que décrit cette page – sur votre propre domaine, en une à trois secondes, sans inscription.
Vérifier un domaine →