Configurer MTA-STS et TLS-RPT pour sécuriser les e-mails

Comment configurer MTA-STS et TLS-RPT pour sécuriser les e-mails

MTA-STS permet à un domaine destinataire d’indiquer aux systèmes expéditeurs quels serveurs de messagerie sont autorisés à recevoir ses messages et que les connexions doivent utiliser un protocole TLS de confiance. TLS-RPT ajoute une fonction de signalement : les expéditeurs participants peuvent vous transmettre des informations sur les échecs de remise liés à TLS et les problèmes de stratégie. Si vous cherchez comment configurer MTA-STS et TLS-RPT pour sécuriser vos e-mails, commencez par vérifier la configuration de votre messagerie entrante, et non par créer un enregistrement DNS.

Ces mécanismes ne remplacent pas SPF, DKIM ni DMARC. Ils concernent une autre étape du parcours : la connexion chiffrée entre les serveurs de messagerie. Une stratégie qui mentionne un ancien hôte MX ou un hôte mal configuré peut perturber la remise des messages. Testez donc l’ensemble de la configuration avant de passer en mode d’application.

1. Vérifiez que votre hébergement de messagerie est prêt

Commencez par examiner les enregistrements MX actuels du domaine. Notez tous les noms d’hôte vers lesquels ils pointent, y compris ceux utilisés pour la sauvegarde ou la remise régionale. Si votre fournisseur gère les e-mails entrants, demandez-lui de confirmer quels noms MX doivent figurer dans une stratégie MTA-STS et si chacun prend en charge TLS avec un certificat valide.

Vérifiez les noms d’hôte, et pas seulement la marque du fournisseur. Un domaine peut avoir des enregistrements MX tels que mx1.mail.example.com et mx2.mail.example.com, alors que son fournisseur exploite également d’autres hôtes qui ne sont pas répertoriés pour ce domaine. Votre stratégie doit couvrir les noms d’hôte MX susceptibles de recevoir les e-mails du domaine.

Vérifiez le certificat et la configuration TLS de chaque hôte répertorié. Le certificat doit être approuvé et valide pour le nom d’hôte MX auquel le système expéditeur se connecte. Un certificat couvrant le site Web du fournisseur, mais pas son serveur de messagerie, ne convient pas.

Renseignez-vous également auprès de votre fournisseur de messagerie sur les changements d’hôtes prévus. Si un nom d’hôte MX doit changer pendant la configuration, attendez d’avoir la liste définitive ou coordonnez la mise à jour de la stratégie avec le fournisseur. Un hôte de remplacement absent de la liste peut entraîner des problèmes de remise lorsqu’un expéditeur a mis en cache une stratégie en mode d’application.

2. Publiez une destination pour les rapports TLS-RPT

Choisissez où les rapports doivent être envoyés avant de publier l’enregistrement DNS. Vous pouvez utiliser une boîte aux lettres capable de recevoir ces rapports ou un service de signalement TLS qui vous fournit une adresse ou une destination HTTPS. Vérifiez que cette destination fait l’objet d’un suivi et que votre système de messagerie acceptera les rapports entrants à cette adresse.

Publiez un enregistrement TXT à l’adresse _smtp._tls.example.com, en remplaçant example.com par votre domaine. Pour une adresse e-mail de destination, utilisez une valeur au format suivant : v=TLSRPTv1; rua=mailto:tls-reports@example.com. Si votre service de signalement fournit une autre destination, utilisez l’URI exact qu’il vous indique. Pour un enregistrement DNS TLS-RPT exemple, cette valeur illustre le format à adapter à votre propre domaine et à votre destination de rapports.

Dans la mesure du possible, utilisez une boîte aux lettres distincte de la boîte de réception habituelle d’une personne. Les rapports TLS peuvent arriver sous forme de pièces jointes structurées. Une boîte dédiée facilite la gestion des droits d’accès, la conservation des messages et leur examen par la personne responsable de la remise des e-mails. Vérifiez les paramètres de stockage et de filtrage avant de publier l’enregistrement.

Les modifications DNS peuvent mettre du temps à se propager, car les résolveurs mettent les enregistrements en cache en fonction de leur TTL. Après avoir publié l’enregistrement, interrogez le service DNS faisant autorité ainsi qu’un résolveur public pour vérifier qu’ils renvoient tous deux la valeur TXT attendue. Une faute de frappe dans le nom de l’enregistrement peut rendre la destination invisible pour les expéditeurs.

3. Hébergez le fichier de stratégie MTA-STS

Placez le fichier de stratégie à l’adresse https://mta-sts.example.com/.well-known/mta-sts.txt, en remplaçant example.com par votre domaine. Le point de terminaison doit être accessible en HTTPS et son certificat doit être valide pour le nom d’hôte mta-sts.example.com. Un fichier placé sur le chemin habituel de la page d’accueil de votre site ne répond pas à cette exigence.

La stratégie est un fichier texte brut. Pour un premier test, utilisez des champs comme ceux-ci :

• version: STSv1
• mode: testing
• mx: mx1.mail.example.com
• mx: mx2.mail.example.com
• max_age: 86400

Remplacez les noms MX d’exemple par les véritables hôtes de réception de votre domaine. La valeur max_age correspond au nombre de secondes pendant lesquelles un expéditeur peut mettre la stratégie en cache ; l’exemple ci-dessus correspond à un jour. Une durée initiale plus courte facilite les modifications d’une stratégie de test, tandis qu’une durée plus longue signifie que les expéditeurs peuvent la conserver plus longtemps.

Utilisez le mode testing avant de passer à l’application. Dans ce mode, les expéditeurs peuvent signaler les échecs liés à la stratégie sans considérer celle-ci comme une obligation de rejeter les e-mails qui ne peuvent pas être remis dans les conditions TLS requises. Testez l’URL depuis l’extérieur de votre réseau et vérifiez qu’elle renvoie le fichier sans exiger de connexion, sans boucle de redirection ni erreur d’application Web.

4. Publiez l’enregistrement de découverte MTA-STS

Les expéditeurs découvrent la stratégie grâce à un enregistrement TXT à l’adresse _mta-sts.example.com. Sa valeur comprend la version et un identifiant de stratégie, par exemple : v=STSv1; id=20261104a. Choisissez un identifiant que vous pourrez retrouver dans votre journal des modifications plutôt que de réutiliser une ancienne valeur.

Modifiez l’identifiant chaque fois que vous publiez une version révisée du fichier de stratégie. Les systèmes expéditeurs sont ainsi informés qu’ils doivent vérifier s’il existe une stratégie mise à jour, au lieu de s’appuyer uniquement sur une copie en cache. Cet identifiant sert à signaler la présence de la stratégie ; il ne remplace ni le fichier ni son hébergement HTTPS.

Ne publiez l’enregistrement qu’une fois le fichier de stratégie accessible à l’URL requise. Interrogez ensuite l’enregistrement TXT et ouvrez l’URL depuis une connexion externe. L’enregistrement DNS et le fichier doivent décrire la même configuration actuelle : un identifiant récent qui pointe vers un fichier manquant ou obsolète correspond tout de même à un déploiement défectueux.

5. Vérifiez la découverte, la stratégie et la couverture des hôtes MX

Pour savoir comment tester une stratégie MTA-STS, vérifiez chaque élément séparément. Interrogez les enregistrements TXT _smtp._tls et _mta-sts, demandez le fichier de stratégie via son URL HTTPS et comparez chaque ligne mx: à vos enregistrements MX actifs. Cette vérification en trois étapes permet de détecter des erreurs qu’une simple recherche DNS ne peut pas révéler.

Vérifiez que la réponse HTTPS utilise un certificat de confiance pour le nom d’hôte MTA-STS et que le fichier contient les champs attendus. Vérifiez ensuite que chaque hôte MX prend en charge TLS et possède un certificat valide pour son nom exact. Si votre fournisseur utilise plusieurs noms MX pour les e-mails entrants, testez-les tous au lieu de supposer que leur configuration de certificat est identique.

Conservez une trace des résultats, notamment des valeurs DNS, de l’identifiant de stratégie, des noms d’hôte MX et de la date de vérification. Cela donnera au prochain administrateur un point de référence utile si des rapports signalent ultérieurement un problème. Pour en savoir plus sur la configuration des e-mails, vous pouvez ajouter le flux RSS du blog YourTrend à la liste de ressources de votre équipe.

6. Examinez les rapports avant d’appliquer la stratégie

Laissez la stratégie en mode test pendant que vous recueillez les retours TLS-RPT et vérifiez le bon fonctionnement normal de la messagerie. Les rapports peuvent révéler que des systèmes expéditeurs ont rencontré un problème de certificat, de négociation TLS ou une incohérence entre les hôtes MX annoncés et la stratégie. Un rapport est un élément à examiner, pas une consigne automatique de modification d’un enregistrement DNS.

Vérifiez la période couverte par le rapport, le domaine concerné par la stratégie et les détails de l’hôte destinataire. Comparez ces informations à votre inventaire MX et à la configuration de votre fournisseur. Si un hôte légitime manque à la liste, mettez à jour le fichier de stratégie et changez l’identifiant de stratégie ; si un certificat est incorrect, demandez au fournisseur de le corriger avant de passer en mode d’application.

Testez également la remise des messages depuis les systèmes de messagerie dont dépend votre organisation, par exemple ceux d’un partenaire commercial ou d’un autre service que vous contrôlez. Vérifiez que les messages arrivent et que vos journaux de messagerie entrante indiquent des connexions TLS réussies. Une boîte de réception des rapports vide ne prouve pas, à elle seule, que tous les expéditeurs ont testé votre stratégie.

Définissez une période d’examen adaptée au volume de vos e-mails et à vos besoins opérationnels. Aucun nombre de jours ne garantit que tous les systèmes expéditeurs apparaîtront dans les rapports ; ne considérez donc pas une durée précise comme une preuve de couverture complète. Consignez les vérifications effectuées et les expéditeurs connus qui ont transmis leurs messages avec succès pendant le test.

7. Appliquez la stratégie, surveillez-la et maintenez la configuration

Lorsque la liste MX, les certificats, la stratégie HTTPS et les résultats des tests sont prêts, remplacez le mode testing par enforce dans la stratégie. Publiez le fichier modifié ainsi qu’un nouvel identifiant _mta-sts. Après la mise à jour, vérifiez les deux éléments depuis l’extérieur de votre réseau, puis continuez à surveiller les rapports TLS-RPT et les journaux de messagerie.

En mode d’application, les systèmes expéditeurs compatibles avec MTA-STS sont censés utiliser TLS et vérifier l’hôte destinataire conformément à la stratégie. S’ils n’y parviennent pas, la remise peut être retardée pendant que l’expéditeur réessaie, plutôt que d’être effectuée via une connexion non protégée. Coordonnez ce changement avec votre fournisseur de messagerie et votre équipe d’assistance afin qu’ils sachent comment diagnostiquer un retard de remise.

Documentez les étapes de maintenance avec l’URL de la stratégie et les enregistrements DNS. Lorsqu’un hôte MX change, mettez à jour la stratégie avant de vous fier au nouvel hôte ; lors du renouvellement d’un certificat, vérifiez les noms d’hôte couverts et la chaîne de confiance. Si le mode d’application révèle un problème, repasser en mode test peut limiter les conséquences de la stratégie. Pensez toutefois à modifier l’identifiant de stratégie et à vérifier que le fichier révisé est correctement servi.

Désignez une personne chargée de consulter la boîte aux lettres ou le service de signalement et de suivre les modifications DNS et de certificats. Si vous publiez des notes opérationnelles ou des mises à jour sur le service de messagerie à l’intention de vos collègues, le flux du blog YourTrend est une autre source qu’ils peuvent suivre. La désignation d’un responsable et la consignation d’une procédure de modification des hôtes MX faciliteront le prochain renouvellement ou la prochaine migration de fournisseur.