Une norme internet très connue qui permet d'améliorer la sécurité des connexions entre les serveurs SMTP (Simple Mail Transfer Protocol) est le SMTP Mail Transfer Agent-Strict Transport Security (MTA-STS). MTA-STS résout les problèmes existants en matière de SMTP en appliquant le cryptage TLS en imposant le cryptage TLS en transit. Le chiffrement est facultatif dans le protocole SMTP, ce qui signifie que les courriels peuvent être envoyés en clair. MTA-STS permet aux fournisseurs de services de messagerie d'appliquer le protocole TLS (Transport Layer Security) pour sécuriser les connexions SMTP et de spécifier si les serveurs SMTP d'envoi doivent refuser de livrer des courriels aux hôtes MX qui ne prennent pas en charge le protocole TLS avec un certificat de serveur fiable. Il a été prouvé qu'il permettait d'atténuer avec succès les attaques par déclassement TLS et les attaques de type Man-In-The-Middle (MITM).
Points clés à retenir
- Le protocole SMTP, qui manquait initialement de sécurité, a été doté d'un cryptage optionnel via STARTTLS, mais il est resté vulnérable aux attaques MITM et aux attaques par dégradation.
- MTA-STS renforce la sécurité du courrier électronique en imposant le cryptage TLS pour les communications de serveur à serveur, empêchant ainsi les retours au texte en clair.
- La mise en œuvre implique un fichier de règles hébergé via HTTPS et un enregistrement DNS, définissant les règles et les serveurs de messagerie de confiance.
- MTA-STS fonctionne en modes (Aucun, Test, Appliquer), ce qui permet de déployer et d'appliquer progressivement les politiques de chiffrement.
- TLS-RPT complète MTA-STS en fournissant des rapports de diagnostic sur les échecs de connexion TLS, ce qui facilite le dépannage et améliore la délivrabilité.
L'histoire et l'origine de MTA-STS
En 1982, le protocole SMTP a été spécifié pour la première fois et ne contenait aucun mécanisme de sécurité au niveau du transport pour sécuriser les communications entre les agents de transfert de courrier. Cependant, en 1999, la commande STARTTLS a été ajoutée au SMTP et a permis le cryptage des courriels entre les serveurs, offrant la possibilité de convertir une connexion non sécurisée en une connexion sécurisée qui est cryptée à l'aide du protocole TLS.
Dans ce cas, vous devez vous demander si SMTP a adopté STARTTLS pour sécuriser les connexions entre les serveurs, pourquoi le passage à MTA-STS était nécessaire et ce qu'il faisait. Nous allons nous pencher sur ces questions dans les sections suivantes de ce blog !
Simplifiez la sécurité avec PowerDMARC !
Qu'est-ce que MTA-STS ? (Mail Transfer Agent Strict Transport Security - Explication)
MTA-STS signifie Mail Transfer Agent - Strict Transport Security (agent de transfert de courrier - sécurité stricte du transport). Il s'agit d'une norme de sécurité qui garantit la transmission sécurisée des courriers électroniques par le biais d'une connexion SMTP cryptée. L'acronyme MTA signifie Message Transfer Agent (agent de transfert de messages), c'est-à-dire un programme qui transfère les messages électroniques entre ordinateurs. L'acronyme STS signifie Strict Transport Security, qui est le protocole utilisé pour mettre en œuvre la norme. Un agent de transfert de courrier (MTA) ou un agent de transfert de message sécurisé (SMTA) compatible avec MTA-STS fonctionne conformément à cette spécification et fournit un canal sécurisé de bout en bout pour l'envoi de courrier électronique sur des réseaux non sécurisés.
Le protocole MTA-STS permet à un client SMTP de vérifier l'identité du serveur et de s'assurer qu'il ne se connecte pas à un imposteur en demandant au serveur de fournir l'empreinte de son certificat lors de la poignée de main TLS. Le client vérifie ensuite le certificat par rapport à un magasin de confiance contenant les certificats de serveurs connus.
Introduction de MTA-STS Email Security
MTA-STS a été introduit pour combler les lacunes en matière de sécurité lors des communications SMTP. En tant que norme de sécurité, MTA-STS garantit la transmission sécurisée des courriers électroniques par le biais d'une connexion SMTP cryptée.
L'acronyme MTA signifie Message Transfer Agent (agent de transfert de messages), c'est-à-dire un programme qui transfère les messages électroniques entre ordinateurs. L'acronyme STS signifie Strict Transport Security, qui est le protocole utilisé pour mettre en œuvre la norme. Un agent de transfert de courrier (MTA) ou un agent de transfert de messages sécurisés (SMTA) compatible avec MTA-STS fonctionne conformément à cette spécification et fournit un canal sécurisé de bout en bout pour l'envoi de courrier électronique sur des réseaux non sécurisés.
Le protocole MTA-STS permet à un client SMTP de vérifier l'identité du serveur et de s'assurer qu'il ne se connecte pas à un imposteur en demandant au serveur de fournir l'empreinte de son certificat lors de la poignée de main TLS. Le client vérifie ensuite le certificat par rapport à un magasin de confiance contenant les certificats de serveurs connus.
Nécessité de passer au chiffrement TLS forcé
STARTTLS n'était pas parfait et n'a pas réussi à résoudre deux problèmes majeurs : le premier étant qu'il s'agit d'une mesure facultative, STARTTLS ne parvient pas à empêcher les attaques de type "man-in-the-middle" (MITM). En effet, un attaquant MITM peut facilement modifier une connexion et empêcher la mise à jour du chiffrement. Le deuxième problème est que même si STARTTLS est mis en œuvre, il n'y a aucun moyen d'authentifier l'identité du serveur d'envoi comme le fait le protocole SMTP ne valident pas les certificats.
Alors que la plupart des courriels sortants sont aujourd'hui sécurisés par Transport Layer Security (TLS) une norme industrielle adoptée même par le courrier électronique grand public, les attaquants peuvent toujours entraver et altérer votre courrier électronique avant même qu'il ne soit crypté. Étant donné que la sécurité a dû être intégrée dans le protocole SMTP pour assurer sa compatibilité ascendante en ajoutant la commande STARTTLS pour lancer le cryptage TLS, si le client ne prend pas en charge le protocole TLS, la communication revient en clair. Ainsi, les courriels en transit peuvent être la proie d'attaques de surveillance omniprésentes telles que MITM, dans lesquelles les cybercriminels peuvent écouter vos messages, modifier et altérer les informations en remplaçant ou en supprimant la commande de cryptage (STARTTLS), ce qui ramène la communication en texte clair. Un attaquant MITM peut simplement remplacer le STARTTLS par une chaîne de caractères inutiles que le client ne parvient pas à identifier. Par conséquent, le client revient facilement à l'envoi du courrier électronique en texte clair. Si vous ne transportez pas vos courriels via une connexion sécurisée, vos données peuvent être compromises, voire modifiées et altérées par un cyber-attaquant.
C'est ici que MTA-STS intervient et résout ce problème, en garantissant un transit sûr pour vos courriels et en atténuant avec succès les attaques MITM. MTA-STS veille à ce que les courriels soient transférés sur une voie cryptée TLS et, si une connexion cryptée ne peut être établie, le courriel n'est pas délivré du tout, au lieu d'être délivré en clair. En outre, les MTA stockent les fichiers de politique MTA-STS, ce qui rend plus difficile pour les attaquants de lancer une attaque par usurpation de nom de domaine (DNS spoofing). attaque par usurpation de nom (DNS spoofing). L'objectif principal est d'améliorer la sécurité au niveau du transport pendant la communication SMTP et de garantir la confidentialité du trafic de courrier électronique. En outre, le cryptage des messages entrants et sortants renforce la sécurité de l'information, en utilisant la cryptographie pour protéger les informations électroniques.
Configurer MTA-STS avec PowerDMARC !
Comment fonctionne le MTA-STS ?
Le protocole MTA-STS est déployé au moyen d'un enregistrement DNS qui spécifie qu'un serveur de messagerie peut récupérer un fichier de politique à partir d'un sous-domaine spécifique. Ce fichier de stratégie est récupéré via HTTPS et authentifié par des certificats, avec la liste des noms des serveurs de messagerie du destinataire. La mise en œuvre de MTA-STS est plus facile du côté du destinataire que du côté de l'expéditeur, car elle doit être prise en charge par le logiciel du serveur de messagerie. Bien que certains serveurs de messagerie prennent en charge MTA-STS, tels que PostFixne le font pas tous. MTA-STS permet aux serveurs d'indiquer qu'ils supportent TLS, ce qui leur permet d'échouer (c'est-à-dire de ne pas envoyer le courrier électronique) si la négociation de la mise à niveau de TLS n'a pas lieu, rendant ainsi impossible une attaque par rétrogradation de TLS.
Les principaux fournisseurs de services de courrier tels que Microsoft, Oath et Google prennent en charge MTA-STS. Le service Gmail de Google a déjà adopté les politiques MTA-STS ces derniers temps. MTA-STS a supprimé les inconvénients de la sécurité des connexions de messagerie en rendant le processus de sécurisation des connexions facile et accessible pour les serveurs de messagerie pris en charge.
Les connexions entre les utilisateurs et les serveurs de messagerie sont généralement protégées et cryptées par le protocole TLS. Toutefois, avant la mise en œuvre de MTA-STS, les connexions entre les serveurs de messagerie n'étaient pas suffisamment sécurisées. Avec la prise de conscience récente de la sécurité du courrier électronique et le soutien des principaux fournisseurs de courrier dans le monde, la majorité des connexions aux serveurs devraient être cryptées dans un avenir proche. En outre, MTA-STS garantit efficacement que les cybercriminels présents sur les réseaux ne sont pas en mesure de lire le contenu des courriels.
Le dossier sur la politique MTA-STS
Le fichier de stratégie MTA-STS est un fichier de configuration MTA-STS en texte clair qui est hébergé sur le serveur web d'un domaine sous une URL HTTPS : Il définit des règles pour établir des connexions sécurisées entre les serveurs de messagerie, appliquer le cryptage TLS et spécifier les actions à entreprendre si une connexion sécurisée ne peut pas être établie.
https://mta-sts.<domain>//.well-known/mta-sts.txt
Structure du fichier de politique MTA-STS
Domaines | Description | Exemple |
version | La version du format de la politique MTA-STS | STS1 |
mode | Le niveau d'application de la politique parmi 3 options disponibles : aucun, test et application | essais |
mx | Une liste des serveurs Mail Exchange (MX) valides du domaine | mail.domain.com |
max-age | Durée en secondes pendant laquelle la politique doit être mise en cache par les serveurs de messagerie externes. | 86400 |
Exemple de politique MTA-STS
version : STSv1
mode : appliquer
mx : mail.example.com
mx : backupmail.example.com
max_age : 86400
Conditions préalables au déploiement de MTA-STS
Avant de commencer l'installation de MTA-STS, vous devez disposer des éléments suivants :
- Un nom de domaine enregistré
- Certificats TLS valides
- Les certificats TLS doivent être émis par une autorité de certification de confiance.
- Les certificats doivent être à jour et ne pas avoir expiré.
- La version 1.2 ou supérieure de TLS doit être utilisée.
- Un enregistrement DNS TXT pour MTA-STS
- Serveur web HTTPS
- Serveur de messagerie configuré pour utiliser TLS
- Nom d'hôte du serveur de messagerie correspondant aux entrées du champ mx de votre fichier de politique.
- Un environnement de test ou un service MTA-STS hébergé pour contrôler les journaux et effectuer les ajustements nécessaires.
Etapes de la mise en place de MTA-STS pour votre domaine
Afin de configurer MTA-STS pour votre domaine, vous pouvez suivre les étapes ci-dessous :
- Vérifiez si votre domaine dispose de configurations MTA-STS existantes. Si vous utilisez Google Workspace pour vos emails, vous pouvez le faire facilement à l'aide de ce guide.
- Créer et publier une stratégie MTA-STS, configurée séparément pour chaque domaine. Le fichier de stratégie MTA-STS définit les serveurs de messagerie compatibles MTA-STS utilisés par ce domaine.
- Après avoir créé votre fichier de politique, vous devez le télécharger sur un serveur web public auquel des serveurs distants peuvent facilement accéder.
- Enfin, créez et publiez votre enregistrement DNS MTA-STS (enregistrement TXT "_mta-sts") pour indiquer aux serveurs de réception que vos courriels doivent être cryptés par TLS pour être considérés comme authentiques et qu'ils ne doivent être autorisés à accéder à la boîte de réception de votre destinataire que si c'est le cas.
Une fois le fichier de stratégie actif, les serveurs de messagerie externes n'autoriseront pas l'accès au courrier électronique sans connexion sécurisée.
3 Modes de politique MTA-STS : Aucun, Tester et Appliquer
Les trois valeurs disponibles pour les modes de stratégie MTA-STS sont les suivantes :
- Aucun: Cette politique annule votre configuration MTA-STS car les serveurs externes considéreront le protocole comme inactif pour le domaine.
- Essais: Dans le cadre de cette politique, les courriels transférés via une connexion non cryptée ne seront pas rejetés. En revanche, si TLS-RPT est activé, vous continuerez à recevoir des rapports TLS sur le chemin de livraison et le comportement des courriels.
- Effectif: Enfin, lorsque la politique d'application est activée, les courriels transférés via une connexion SMTP non cryptée seront rejetés par votre serveur.
Le MTA-STS offre une protection contre :
- Les attaques de dégradation
- Attaques de type "Man-In-The-Middle" (MITM)
- Il résout de nombreux problèmes de sécurité SMTP, notamment les certificats TLS expirés, le manque de prise en charge des protocoles sécurisés et les certificats qui ne sont pas émis par des tiers fiables.
Rapports TLS : Suivi des lacunes en matière de délivrabilité des courriels après la mise en place de MTA-STS
TLS-RPT (Transport Layer Security Reporting) est un protocole permettant aux propriétaires de domaines de recevoir des rapports détaillés sur les défaillances du cryptage TLS dans les communications par courrier électronique. TLS Reporting fonctionne en conjonction avec MTA-STS. Il permet de signaler les problèmes de connectivité TLS rencontrés par les applications qui envoient des courriels et de détecter les mauvaises configurations. Il permet de signaler les problèmes de distribution des courriels qui se produisent lorsqu'un courriel n'est pas chiffré avec TLS. En septembre 2018, la norme a été documentée pour la première fois dans la RFC 8460.
Les principales caractéristiques sont les suivantes :
- Rapports d'erreur: Il fournit des rapports détaillés sur les problèmes de livraison ou les échecs causés par des problèmes TLS tels que des certificats expirés ou des versions TLS obsolètes, et des échecs de cryptage TLS. Dès que vous activez TLS-RPT, les agents de transfert de courrier conformes commencent à envoyer au domaine de messagerie désigné des rapports de diagnostic concernant les problèmes de distribution du courrier électronique entre les serveurs communicants. Les rapports sont généralement envoyés une fois par jour, couvrant et transmettant les politiques MTA-STS observées par les expéditeurs, les statistiques de trafic ainsi que les informations sur les échecs ou les problèmes de livraison du courrier électronique.
- Visibilité: Il vous aide à surveiller les problèmes liés à la mise en œuvre de votre MTA-STS et à la délivrabilité du courrier électronique. TLS-RPT offre une meilleure visibilité sur tous vos canaux de messagerie, ce qui vous permet de mieux comprendre tout ce qui se passe dans votre domaine, y compris les messages qui ne sont pas délivrés.
- Amélioration de la sécurité du courrier électronique: En résolvant les erreurs liées à l'échec des négociations de cryptage TLS, vous pouvez améliorer l'efficacité globale de votre installation MTA-STS et prévenir ainsi plus efficacement les cyberattaques. En outre, il fournit des rapports de diagnostic approfondis qui vous permettent d'identifier et d'aller à la racine du problème de livraison des courriels et de le résoudre sans délai.
Déploiement facile de MTA-STS avec PowerDMARC
MTA-STS nécessite un serveur web HTTPS avec un certificat valide, des enregistrements DNS et une maintenance constante. La mise en œuvre de MTA-STS peut être une tâche ardue qui implique des complexités lors de l'adoption. De la génération de fichiers et d'enregistrements de politiques à la maintenance du serveur web et des certificats d'hébergement, c'est un processus de longue haleine. L'analyseur DMARC analyzer de PowerDMARC vous facilite grandement la vie en gérant tout cela pour vous, en arrière-plan. Une fois que nous vous avons aidé à le mettre en place, vous n'avez plus jamais à y penser.
Avec l'aide de PowerDMARC, vous pouvez déployer MTA-STS hébergé dans votre organisation sans avoir à vous soucier de la gestion de vos certificats publics. Nous vous aidons :
- Publiez vos enregistrements DNS CNAME en quelques clics
- Mettez à jour et optimisez votre enregistrement en un seul clic sans avoir à accéder à vos paramètres DNS.
- Vérifiez la version de votre politique et la validation du certificat
- Détecter les échecs de l'application de la politique MTA-STS
- Hébergez votre fichier texte de politique MTA-STS
- Assumer la responsabilité de la maintenance du serveur web de la politique et de l'hébergement des certificats.
- Détecter plus rapidement les échecs, les réussites et les problèmes de connexion grâce à des rapports simplifiés
- Assurer la conformité aux RFC et la prise en charge des normes TLS les plus récentes
PowerDMARC rend le processus de mise en œuvre de SMTP TLS Reporting (TLS-RPT) facile et rapide. Nous convertissons les fichiers JSON compliqués contenant vos rapports de problèmes de livraison d'emails en documents simples et lisibles (par résultat et par source d'envoi) que vous pouvez facilement comprendre.
Inscrivez-vous dès aujourd'hui pour imposer rapidement l'envoi d'e-mails à votre domaine via une connexion cryptée TLS et sécuriser votre connexion contre les attaques MITM et autres cyber-attaques.
"`
- Qu'est-ce que DMARC ? Un guide simple pour la protection des courriels - 11 juillet 2025
- Comment lire les rapports DMARC : Types, outils et astuces - 10 juillet 2025
- Comment créer et publier un enregistrement DMARC - 3 mars 2025