MTA-STS et TLS-RPT : ce qu'ils font et si vous en avez besoin

MTA-STS est une politique par laquelle vous indiquez aux serveurs expéditeurs que le courrier vers votre domaine ne peut être livré que par une connexion TLS chiffrée et vérifiée. TLS-RPT est le canal de rapport associé : les expéditeurs vous envoient chaque jour un compte rendu des connexions qui n'ont pas respecté cette politique. Les deux protègent le courrier que vous recevez ; pour le courrier que vous envoyez, il vous faut surtout un serveur d'envoi qui respecte ces politiques chez le destinataire.

Le problème qu'ils résolvent

Le courrier entre serveurs circule depuis des années en grande partie chiffré, via STARTTLS. Mais STARTTLS est opportuniste : le serveur expéditeur demande si le destinataire prend en charge le chiffrement, et si la réponse ne vient pas ou si le certificat est incorrect, il retombe silencieusement sur une connexion non chiffrée. Quelqu'un placé entre les deux serveurs peut filtrer cette question et laisser passer le courrier en clair. MTA-STS supprime cette option de repli : si votre politique est en mode « enforce », un expéditeur qui n'arrive pas à établir le chiffrement ne peut pas livrer le message.

Comment fonctionne MTA-STS

Il se compose de deux parties que vous publiez vous-même :

1. Un enregistrement DNS sur _mta-sts.votredomaine.be avec une version et un identifiant. Vous changez cet identifiant à chaque modification de la politique ; les expéditeurs savent ainsi qu'ils doivent la récupérer à nouveau.
2. Un fichier de politique sur https://mta-sts.votredomaine.be/.well-known/mta-sts.txt. Il contient le mode (none, testing ou enforce), les serveurs de messagerie autorisés à recevoir pour votre domaine, et la durée pendant laquelle un expéditeur peut mémoriser la politique.

Cette seconde partie explique pourquoi MTA-STS passe par HTTPS et pas uniquement par DNS : le certificat de cette page web prouve que la politique vient bien de votre domaine, sans nécessiter DNSSEC. L'alternative, DANE, fait la même chose via DNS mais exige DNSSEC sur votre domaine, ce qui, en pratique, n'est pas activé par défaut chez beaucoup de registrars et d'hébergeurs belges.

Comment fonctionne TLS-RPT

TLS-RPT est un seul enregistrement DNS sur _smtp._tls.votredomaine.be avec une adresse à laquelle vous souhaitez recevoir les rapports. Les expéditeurs qui le prennent en charge (dont les grands fournisseurs) vous envoient alors une fois par jour un compte rendu indiquant, par serveur d'envoi, combien de connexions ont réussi et combien ont échoué, et pourquoi : certificat expiré, nom de serveur non concordant, STARTTLS non proposé, politique impossible à récupérer.

Ce rapport est la raison de commencer par TLS-RPT avant même d'imposer MTA-STS. Il vous dit s'il existe des expéditeurs qui ne pourront plus livrer votre courrier une fois le mode passé en enforce. Comparez avec DMARC : d'abord observer, ensuite durcir. Notre article sur la lecture d'un rapport DMARC explique la démarche ; la logique est la même.

En avez-vous besoin ?

Cela dépend du côté de la connexion que vous regardez.

En tant que destinataire

Si votre domaine reçoit du courrier sensible (dossiers du personnel, données médicales, correspondance juridique, instructions de paiement), MTA-STS est une protection peu coûteuse contre l'interception du courrier en transit. Pour un domaine qui reçoit surtout des newsletters et des confirmations de commande, le gain est plus faible, mais le coût est minime : un enregistrement DNS, un petit fichier statique sur un sous-domaine avec certificat valide, et une boîte pour les rapports.

En tant qu'expéditeur

MTA-STS sur votre propre domaine ne change rien au courrier que vous envoyez. Ce qui compte : le serveur avec lequel vous envoyez doit vérifier et respecter la politique MTA-STS du destinataire, et doit lui-même disposer d'un certificat TLS correct. Si vous envoyez via un relais SMTP, c'est la responsabilité du relais. Renseignez-vous si vous n'êtes pas sûr : un expéditeur qui ignore la politique est refusé chez un destinataire en mode enforce, et vous le voyez alors comme un rebond.

Une marche à suivre pratique

1. Créez l'enregistrement TLS-RPT et laissez les rapports arriver pendant quelques semaines sur une adresse que quelqu'un lit réellement.
2. Publiez la politique MTA-STS en mode testing. Les expéditeurs signalent alors les écarts dans les rapports mais livrent encore normalement.
3. Corrigez ce que vous voyez dans les rapports : le plus souvent un serveur de messagerie absent de la politique, ou un certificat émis pour un autre nom.
4. Passez le mode en enforce et incrémentez l'identifiant dans l'enregistrement DNS.
5. Consultez les rapports chaque mois et vérifiez, à chaque changement de vos serveurs de messagerie, que le fichier de politique est toujours correct.

Celui qui utilise une plateforme de messagerie hébergée trouve les noms de serveurs pour la politique dans les paramètres MX de cette plateforme. Celui qui gère ses propres serveurs doit surveiller leur certificat : un certificat expiré signifie, en mode enforce, que le courrier externe n'arrive plus.

Ce qu'ils ne font pas

MTA-STS ne dit rien sur qui a le droit d'envoyer en votre nom ; pour cela, SPF, DKIM et DMARC restent nécessaires. Il ne protège pas non plus le trajet entre le serveur destinataire et la boîte du lecteur, et il ne chiffre pas le contenu sur le serveur lui-même. Il ferme une faille précise : le repli non chiffré entre deux serveurs de messagerie.

Questions fréquentes

MTA-STS est-il obligatoire ?

Non. C'est une recommandation prise en charge par les grands fournisseurs, pas une condition de livraison. Dans certains secteurs et appels d'offres, il est toutefois de plus en plus souvent demandé.

Puis-je configurer MTA-STS si mon courrier est chez Microsoft 365 ou Google Workspace ?

Oui. Vous publiez vous-même la politique, avec les serveurs MX de cette plateforme. Les deux plateformes disposent de certificats valides sur ces serveurs.

Et si je ne fais qu'envoyer et ne reçois rien sur ce domaine ?

Alors MTA-STS n'a guère de sens pour ce domaine. Consacrez plutôt votre temps à l'authentification et à la délivrabilité ; c'est sur cela que votre courrier sortant est jugé.