Comment configurer MTA-STS et TLS-RPT : mettre fin à l'interception des e-mails

Des milliards d'e-mails circulent chaque jour sur Internet, et une grande partie d'entre eux ne sont toujours pas cryptés. Cette ampleur fait des e-mails l'une des cibles les plus attractives pour l'interception, où les messages peuvent être lus ou modifiés pendant leur transit sans que l'expéditeur ou le destinataire ne s'en aperçoivent.

La faiblesse réside dans la manière dont les e-mails sont acheminés. Le protocole SMTP repose sur un chiffrement opportuniste, qui permet aux pirates de supprimer ou de falsifier la commande STARTTLS et de forcer une connexion à revenir au format texte brut. Ces attaques par rétrogradation SMTP ouvrent la voie à l'interception de type « man-in-the-middle », permettant aux pirates de surveiller le trafic, de capturer des contenus sensibles ou de rediriger des messages via des serveurs qu'ils contrôlent.

Nous contacter Réservez une démo

Table des matières

    1. Agent de transfert du courrier - Sûreté des transports (MTA-STS)
    2. Assurer le cryptage avec MTA-STS
    3. Anatomie d'une attaque MITM
    4. Le dossier sur la politique MTA-STS
    5. Comment publier le fichier de stratégie MTA-STS
    6. Enregistrement DNS MTA-STS
    7. Configurer le MTA-STS pour votre domaine
    8. Cdéfis liés au déploiement manuel du protocole MTA-STS
    9. Comment tester et valider votre configuration MTA-STS
    10. Les services MTA-STS hébergés par PowerDMARC
    11. Rapport TLS SMTP (TLS-RPT)
    12. Sécurisation du transport des e-mails avec MTA-STS
    13. Foire aux questions

Le protocole MTA-STS (Mail Transfer Agent-Strict Transport Security) comble cette lacune en exigeant des connexions TLS cryptées entre les serveurs de messagerie expéditeurs et destinataires, et en refusant la livraison lorsqu'un canal sécurisé ne peut être établi. Au lieu d'espérer que le cryptage soit utilisé, le protocole MTA-STS l'impose, ce qui le rend indispensable pour les organisations qui souhaitent mettre en place le protocole MTA-STS dans le cadre de leur stratégie de sécurité des e-mails.

cryptage tls

Agent de transfert du courrier - Sûreté des transports (MTA-STS)

Le protocole MTA-STS, comme son nom l'indique, permet le transport crypté de messages entre deux serveurs de messagerie SMTP. Le protocole MTA-STS spécifie aux serveurs expéditeurs que les e-mails ne doivent être envoyés que via une connexion cryptée TLS et ne doivent en aucun cas être remis si une connexion sécurisée n'est pas établie via la commande STARTTLS. En renforçant la sécurité des e-mails en transit, le protocole MTA-STS contribue à atténuer les attaques de type « Man-In-The-Middle » (MITM), telles que les attaques par rétrogradation SMTP et les attaques par usurpation DNS.

En savoir plus

Assurer le cryptage avec MTA-STS

Les e-mails sont transmis entre les serveurs à l'aide du protocole SMTP, qui prend en charge le chiffrement, mais ne l'impose pas par défaut. Cela crée une faille qui permet aux messages d'être transmis sans protection. MTA-STS comble cette faille en imposant le chiffrement des transmissions, qui devient une obligation plutôt qu'une option.

Pour comprendre comment fonctionne le chiffrement lors de la livraison des e-mails, prenons l'exemple d'un serveur de messagerie qui envoie un message à [email protected]. Le serveur de transfert de courrier (MTA) expéditeur effectue d'abord une requête DNS pour récupérer les enregistrements MX de powerdmarc.com, identifiant ainsi les serveurs de messagerie chargés de recevoir le message. Le MTA expéditeur se connecte ensuite à l'un de ces serveurs et vérifie s'il prend en charge le chiffrement TLS à l'aide de la commande STARTTLS. Si TLS est disponible, l'e-mail est envoyé via une connexion chiffrée. Si ce n'est pas le cas, le serveur expéditeur ne parvient pas à négocier une connexion sécurisée et, sans contrainte, peut se rabattre sur l'envoi du message en texte clair.

MTA-STS modifie ce comportement de livraison en imposant des exigences de sécurité strictes lors des communications entre serveurs :

MTA-STS demande aux serveurs de messagerie d'envoyer les messages uniquement via une connexion cryptée TLS. Si le cryptage ne peut pas être établi, le message n'est pas envoyé. Cela élimine le repli silencieux vers le texte clair qui rend l'interception possible.

Le serveur de messagerie destinataire doit présenter un certificat TLS valide, et le nom de domaine figurant sur ce certificat doit correspondre au domaine défini dans la politique MTA-STS. Cela garantit que le serveur expéditeur communique avec la bonne destination et non avec un hôte usurpant son identité.

Les politiques MTA-STS sont récupérées via HTTPS à partir d'un serveur Web sécurisé. La récupération de la politique via un canal crypté et authentifié empêche les pirates de modifier ou d'usurper les instructions de la politique pendant le transfert.

En appliquant le chiffrement et en validant à la fois les certificats et les instructions de politique, MTA-STS bloque les attaques par rétrogradation SMTP qui reposent sur la suppression ou la modification de la commande STARTTLS. Les serveurs d'envoi n'acceptent plus les solutions de secours non sécurisées lorsqu'une connexion sécurisée devrait exister.

hébergé mta sts services
MTA STS hébergé

Le protocole MTA-STS est mis en œuvre par la publication d'un enregistrement DNS qui demande aux serveurs de messagerie expéditeurs de récupérer un fichier de stratégie à partir d'un sous-domaine désigné. Le fichier de stratégie est accessible via HTTPS, validé à l'aide de certificats TLS et contient les noms d'hôte approuvés des serveurs de messagerie des destinataires. Le protocole demande aux serveurs SMTP expéditeurs d'exiger une connexion cryptée et de vérifier que le domaine indiqué sur le certificat TLS correspond au domaine défini dans le fichier de stratégie. Si le protocole MTA-STS est appliqué, dans le cas où un canal crypté ne peut être négocié, le message n'est pas délivré.

Anatomie d'une attaque MITM

Essentiellement, une attaque MITM a lieu lorsqu'un attaquant remplace ou supprime la commande STARTTLS pour faire basculer la connexion sécurisée vers une connexion non sécurisée, sans cryptage TLS. C'est ce qu'on appelle une attaque de type "downgrade". Après avoir réussi une attaque de niveau inférieur, l'attaquant peut accéder au contenu du courrier électronique et le consulter sans entrave.

Un attaquant MITM peut également remplacer les enregistrements MX dans la réponse à la requête DNS par un serveur de messagerie auquel il a accès et qu'il contrôle. Dans ce cas, l'agent de transfert de courrier livre le courrier électronique au serveur de l'attaquant, lui permettant d'accéder au contenu du courrier électronique et de le modifier. Le courrier électronique peut ensuite être transmis au serveur du destinataire, sans être détecté. C'est ce qu'on appelle une attaque de spoofing DNS.

Attaque par rétrogradation SMTP

Signes avant-coureurs

Les attaques MITM opèrent souvent discrètement, mais certains schémas peuvent indiquer qu'un problème survient lors de la livraison des e-mails. L'un des signes avant-coureurs courants est l'apparition inattendue d'échecs ou de retards de livraison lors de la communication avec des domaines spécifiques, en particulier lorsque ces domaines acceptaient auparavant les messages sans problème. Une augmentation soudaine des échecs de négociation TLS, le repli vers des connexions non chiffrées ou des erreurs STARTTLS répétées peuvent également indiquer une interférence pendant la transmission.

Un autre indicateur est le comportement incohérent du routage du courrier. Les e-mails peuvent sembler passer par des serveurs inconnus, ou les journaux peuvent montrer des connexions à des hôtes qui ne correspondent pas aux enregistrements MX publiés du destinataire prévu. Dans les cas plus avancés, les messages arrivent modifiés, tronqués ou transférés via des systèmes intermédiaires sans explication claire.

La détection repose en grande partie sur la visibilité. La surveillance des journaux de connexion SMTP permet d'identifier les échecs répétés de chiffrement ou les incompatibilités de certificats. TLS-RPT ajoute une couche supplémentaire en fournissant des rapports lorsque les serveurs ne parviennent pas à établir des connexions TLS sécurisées, signalant des problèmes tels que les tentatives de déclassement, les certificats non valides ou les échecs d'application des politiques. 

Tous ces signaux permettent de mettre en évidence les activités MITM qui, autrement, resteraient cachées dans le flux normal des e-mails.

Le dossier sur la politique MTA-STS

Le fichier de stratégie MTA-STS est essentiellement un simple fichier texte, qui se présente comme suit :

version : STSv1
mode : appliquer
mx : mx1.powerdmarc.com
mx : mx2.powerdmarc.com
mx : mx3.powerdmarc.com
max_age : 604800

Note : Le champ de la version doit être inclus au début du fichier texte alors que les autres champs peuvent être incorporés dans n'importe quel ordre.

Le fichier de stratégie utilise des paires clé-valeur, chaque valeur étant encodée sur une ligne distincte dans le fichier texte, comme indiqué ci-dessus. La taille de ce fichier peut atteindre 64 Ko. Le nom du fichier de stratégie doit être mta-sts.txt. Les fichiers de stratégie doivent être mis à jour chaque fois que vous ajoutez ou modifiez des serveurs de messagerie dans votre domaine.

Remarque : si vous réglez le MTA-STS en mode d'exécution, certains courriels peuvent ne pas vous être envoyés. Il est donc conseillé de régler le mode "policy" sur "testing" et d'opter pour un max_age bas afin de s'assurer que tout fonctionne correctement avant de passer en mode "enforce". Nous vous recommandons de configurer TLS-RPT pour votre politique en mode test afin d'être averti si des courriers électroniques sont envoyés en texte clair. 

Politique MTA-STS

Comment publier le fichier de stratégie MTA-STS

Afin de publier le fichier de politique MTA-STS, le serveur web qui héberge votre fichier doit

  • Soutenir HTTPS/SSL

    Le fichier de stratégie doit être hébergé sur un serveur Web compatible HTTPS afin de garantir qu'il soit récupéré en toute sécurité par les serveurs de messagerie.

  • Utilisez un certificat délivré par une autorité de certification de confiance.

    Le certificat du serveur doit être signé et validé par une autorité de certification racine tierce afin que les MTA expéditeurs puissent authentifier la source de la politique.

  • Héberger le fichier sur un sous-domaine mta-sts dédié

    Un serveur Web public doit être configuré avec le sous-domaine mta-sts ajouté à votre domaine, qui est utilisé exclusivement pour publier la politique MTA-STS.

  • Placez le fichier de politique dans le répertoire requis.

    Le fichier de politique doit être nommé mta-sts.txt et publié dans le répertoire .well-known du sous-domaine mta-sts.

  • Assurez-vous que le fichier de politique est accessible au public à l'URL correcte.

    Les MTA expéditeurs doivent pouvoir récupérer le fichier à partir d'un emplacement au format
    https://mta-sts.yourdomain.com/.well-known/mta-sts.txt sans authentification ni redirection.

MTA STS hébergé

Enregistrement DNS MTA-STS

Un enregistrement DNS TXT pour MTA-STS est publié sur le DNS de votre domaine pour spécifier que votre domaine supporte le protocole MTA-STS et pour signaler le rafraîchissement des valeurs mises en cache dans les MTA en cas de modification de la politique. L'enregistrement DNS MTA-STS est placé dans le sous-domaine _mta-sts comme dans : _mta-sts.powerdmarc.com. L'enregistrement TXT doit commencer par v=STSv1, et le "id" peut contenir jusqu'à 32 caractères alphanumériques, inclus de la manière suivante :

 v=STSv1 ; id=30271001S00T000 ;

Remarque : la valeur d'identification de l'enregistrement TXT doit être mise à jour à une nouvelle valeur chaque fois que vous apportez des modifications à la politique. 

L'enregistrement DNS MTA-STS est utilisé pour : 

  • Préciser le support de MTA-STS pour le domaine
  • Indiquez à l'ATM de récupérer la politique sur le HTTPS en cas de modification de la politique

Notez qu'avec l'enregistrement DNS TXT MTA-STS, le fichier de politique peut être stocké par les MTA pendant une période plus longue sans avoir à récupérer la politique à moins qu'elle n'ait été modifiée, tout en effectuant une requête DNS à chaque fois qu'un courriel est reçu pour le domaine.

Configurer le MTA-STS pour votre domaine

Afin d'activer le MTA-STS pour votre domaine, vous devrez le faire :

  • Ajouter un enregistrement DNS de type cname à mta-sts.example.comLe fichier de politique MTA-STS est dirigé vers le serveur web compatible HTTPS qui héberge le fichier de politique MTA-STS.

  • Ajouter un enregistrement DNS de type txt ou cname à _mta-sts.example.com qui précise la prise en charge de MTA-STS pour votre domaine.

  • Configurez un serveur web compatible HTTPS avec un certificat valide pour votre domaine.

  • Activez le rapport SMTP TLS pour votre domaine afin de détecter les problèmes de livraison du courrier électronique dus à des défaillances du cryptage TLS.

icône de recherche d'enregistrements spf powerdmarc

Défis liés au déploiement manuel de MTA-STS

Le déploiement manuel de MTA-STS implique plus que la simple publication d'un enregistrement DNS. Il nécessite la coordination de l'infrastructure Web, des certificats, des politiques et de la maintenance continue, ce qui peut poser plusieurs défis s'il n'est pas géré avec soin.

  • Exigence relative à un serveur Web compatible HTTPS

    Les politiques MTA-STS doivent être hébergées sur un serveur HTTPS accessible au public et doté d'un certificat TLS valide. Cela nécessite de fournir une infrastructure, de configurer correctement le TLS, de renouveler les certificats en temps voulu et de garantir une haute disponibilité.

    Solution : les organisations disposant d'une infrastructure Web limitée peuvent réduire la complexité en utilisant un service MTA-STS hébergé qui gère automatiquement les serveurs et les certificats.

  • Mise à jour continue des dossiers politiques

    Toute modification apportée à la configuration du serveur de messagerie nécessite une mise à jour du fichier de stratégie MTA-STS. Si le fichier est obsolète, les e-mails légitimes risquent de ne pas être remis une fois l'application activée.

    Solution : la gestion centralisée des politiques ou les outils automatisés permettent de garantir que les mises à jour sont appliquées immédiatement et avec précision.

  • Mises à jour des enregistrements DNS et contrôle de version

    L'enregistrement MTA-STS TXT doit être mis à jour avec une nouvelle valeur d'identifiant à chaque modification de la politique. Des mises à jour manquantes ou incorrectes peuvent retarder l'actualisation de la politique et entraîner une application incohérente.

    Solution : l'automatisation réduit le risque d'erreur humaine et garantit la conformité des enregistrements DNS avec les changements de politique.

  • Visibilité limitée sur les échecs de livraison

    Sans TLS-RPT, les problèmes de livraison liés au chiffrement peuvent passer inaperçus. Même avec TLS-RPT activé, les rapports JSON bruts peuvent être difficiles à interpréter sans connaissances spécialisées.

    Solution : les plateformes de reporting qui analysent et visualisent les rapports TLS facilitent la détection des défaillances et permettent de réagir rapidement.

  • Augmentation des frais généraux opérationnels et des efforts de coordination

    Le déploiement manuel nécessite une coordination entre les équipes DNS, e-mail et sécurité, ce qui augmente le risque d'erreurs de configuration et de retards.

    Solution : les équipes doivent évaluer si elles disposent du temps et de l'expertise nécessaires pour maintenir MTA-STS à long terme ou si une approche gérée correspond mieux à leurs priorités opérationnelles.

Comment tester et valider votre configuration MTA-STS

Les tests constituent une étape cruciale avant de passer une politique MTA-STS en mode d'application. Une fois l'application activée, les serveurs d'envoi reçoivent l'instruction de rejeter la livraison des e-mails si une connexion TLS sécurisée ne peut être établie. Sans validation appropriée, les erreurs de configuration peuvent entraîner une perte involontaire de messages, ce qui rend les tests minutieux essentiels pour maintenir une livraison fiable des e-mails.

  • Vérifications de propagation DNS

    Après avoir publié l'enregistrement MTA-STS TXT et les entrées DNS associées, vérifiez qu'ils se résolvent correctement sur les résolveurs DNS publics. Une propagation incomplète ou retardée peut amener les serveurs d'envoi à s'appuyer sur des politiques obsolètes ou mises en cache, ce qui entraîne un comportement incohérent lors de la livraison.

  • Accessibilité des fichiers de politique

    Vérifiez que le fichier de stratégie MTA-STS est accessible via HTTPS à l'emplacement prévu sur le sous-domaine mta-sts. Le fichier doit être accessible sans redirection, exigence d'authentification ou erreur de certificat. Toute interruption de l'accès peut empêcher les serveurs d'envoi de récupérer la stratégie.

  • Vérification de la prise en charge TLS

    Vérifiez que tous les hôtes MX répertoriés dans la politique prennent en charge TLS et présentent des certificats valides conformes aux exigences de la politique. Une négociation TLS réussie garantit que des connexions chiffrées peuvent être établies de manière cohérente une fois l'application activée.

Les services MTA-STS hébergés par PowerDMARC

PowerDMARC vous facilite grandement la vie en gérant tout cela pour vous, complètement en arrière-plan. Une fois que nous vous avons aidé à le mettre en place, vous n'avez même plus besoin d'y penser.

  • Nous vous aidons à publier vos enregistrements de noms en quelques clics

  • Nous prenons la responsabilité de la maintenance du serveur web et de l'hébergement des certificats

  • Grâce à nos services MTA-STS hébergés, le déploiement de votre part est réduit à la simple publication de quelques enregistrements DNS

  • Vous pouvez apporter des modifications à la politique MTA-STS instantanément et facilement, via le tableau de bord de PowerDMARC, sans avoir à modifier manuellement le DNS

  • Les services MTA-STS hébergés par PowerDMARC sont conformes au RFC et prennent en charge les dernières normes TLS

  • De la génération des certificats et du fichier de politique MTA-STS à l'application de la politique, nous vous aidons à éviter les énormes complexités liées à l'adoption du protocole

Rapport TLS SMTP (TLS-RPT)

Afin de sécuriser davantage la connexion entre deux serveurs SMTP communicants et de la chiffrer via TLS, le protocole MTA-STS a été introduit pour imposer le chiffrement et empêcher la livraison d'e-mails en clair lorsqu'une connexion sécurisée ne peut être établie. Cependant, un problème reste sans solution : comment informer les propriétaires de domaines lorsque les serveurs distants rencontrent des problèmes de livraison des e-mails causés par des défaillances TLS. C'est là que TLS-RPT entre en jeu, complétant MTA-STS en fournissant des rapports de diagnostic qui permettent de surveiller et de résoudre les problèmes de communication des serveurs, tels que les certificats TLS expirés, les erreurs de configuration des serveurs de messagerie ou les échecs de négociation TLS.

Les rapports TLS aident à détecter et à répondre aux problèmes de livraison de courrier électronique grâce à un mécanisme de rapport sous la forme de fichiers JSON. Ces fichiers JSON peuvent être compliqués et indéchiffrables pour une personne non technique.

PowerDMARC aide à simplifier les fichiers JSON sous forme de documents simples, complets et lisibles, accompagnés de graphiques et de tableaux pour plus de commodité. Les rapports de diagnostic pour votre domaine sont également affichés sous deux formats sur le tableau de bord PowerDMARC :par résultat et par source d'envoi.

 

powerdmarc tls rpt

Ce que fait TLS-RPT

TLS-RPT est conçu pour signaler les échecs de livraison d'e-mails liés au chiffrement TLS entre les serveurs de messagerie. Son objectif principal est de permettre aux propriétaires de domaines de visualiser les situations dans lesquelles les messages ne peuvent pas être livrés en toute sécurité, ce qui aide à identifier les problèmes qui, autrement, resteraient cachés lors d'une communication SMTP normale.

Grâce à ces rapports, TLS-RPT aide à identifier des problèmes tels que les échecs de négociation TLS entre les serveurs d'envoi et de réception, les certificats TLS expirés ou non valides et les erreurs de configuration de part et d'autre de l'échange de courrier. Ces informations permettent aux administrateurs de localiser précisément les points de rupture du chiffrement et de prendre les mesures correctives qui s'imposent.

Les rapports TLS-RPT sont générés et envoyés par des agents de transfert de courrier conformes, généralement sur une base quotidienne, offrant une visibilité continue sur la santé de la livraison sécurisée des e-mails.

graphiques json

Comment l'activer

TLS-RPT est activé en publiant un enregistrement DNS TXT à l'emplacement _smtp._tls requis pour votre domaine. Cet enregistrement signale la prise en charge des rapports TLS et spécifie la destination où les rapports de diagnostic doivent être envoyés.

L'enregistrement TXT définit une ou plusieurs adresses de rapport, généralement des points de terminaison de messagerie électronique ou HTTPS, que les serveurs de messagerie conformes utilisent pour envoyer des données TLS-RPT. Une fois l'enregistrement en place, le rapport commence automatiquement sans aucune modification du comportement du serveur de messagerie.

TLS-RPT peut être configuré manuellement en ajoutant l'enregistrement TXT directement au DNS ou via des plateformes qui fournissent une configuration basée sur une interface utilisateur. L'utilisation d'une interface gérée simplifie le déploiement en gérant la création et la validation des enregistrements à votre place, réduisant ainsi le risque d'erreurs de syntaxe ou de mauvaise configuration.

En savoir plus

Sécurisation du transport des e-mails avec MTA-STS

Le courrier électronique reste un canal de communication essentiel, mais sans cryptage renforcé, il est vulnérable aux attaques par déclassement et MITM qui peuvent exposer le contenu des messages ou perturber leur acheminement. La protection des e-mails en transit est essentielle pour préserver la confidentialité et maintenir la confiance entre les serveurs de messagerie expéditeurs et destinataires.

MTA-STS renforce le transport des e-mails en exigeant le chiffrement TLS et en refusant la livraison lorsqu'il n'est pas possible d'établir des connexions sécurisées. En supprimant le repli vers une communication non chiffrée, il contribue à garantir que les messages ne sont livrés que par des canaux authentifiés et protégés, améliorant ainsi la cohérence et la fiabilité des échanges entre serveurs.

La réussite de l'adoption du protocole MTA-STS dépend d'une préparation minutieuse. Les politiques doivent être configurées avec précision, l'infrastructure de support doit être validée et la mise en œuvre doit être introduite progressivement après des tests approfondis. Le fait de sauter ces étapes peut entraîner des échecs de livraison imprévus, en particulier lorsque les politiques sont mises en œuvre trop rapidement.

Avant d'activer cette fonctionnalité, les organisations doivent examiner leur niveau de sécurité actuel en matière de messagerie électronique, vérifier que tous les serveurs de messagerie sont prêts pour le protocole TLS et s'assurer que les fichiers DNS et les fichiers de stratégie sont correctement publiés. Une surveillance continue et une validation périodique restent importantes au fil du temps, car les configurations des serveurs changent et les certificats expirent, ce qui permet de garantir que les stratégies MTA-STS continuent à protéger efficacement la livraison des e-mails.

Foire aux questions

Le panneau de contrôle de PowerDMARC vous permet de configurer automatiquement MTA-STS et TLS-RPT pour votre domaine en publiant seulement trois enregistrements CNAME dans le DNS de votre domaine. De l'hébergement des fichiers de politique et des certificats MTAS-STS à la maintenance du serveur web, nous nous occupons de tout en arrière-plan sans que vous ayez à modifier votre DNS. Le déploiement de MTA-STS de votre part avec PowerDMARC est réduit à quelques clics seulement.

Vous pouvez déployer et gérer le MTA-STS pour tous vos domaines à partir de votre compte PowerDMARC, à travers une seule vitre. Si l'un de ces domaines utilise des serveurs de réception de courrier qui ne prennent pas en charge STARTTLS, cela se reflétera dans vos rapports TLS, à condition que vous ayez activé TLS-RPT pour ces domaines.

Il est toujours conseillé de régler votre mode de politique MTA-STS sur testing pendant les phases initiales de déploiement afin de pouvoir surveiller les activités et d'avoir une meilleure visibilité de votre écosystème de messagerie avant de passer à une politique plus agressive comme l'application. Ainsi, même si les courriels ne sont pas envoyés via une connexion cryptée TLS, ils seront toujours envoyés en texte clair. Cependant, assurez-vous d'activer le TLS-RPT pour être averti si cela se produit.

Le TLS-RPT est un mécanisme de signalement complet qui vous permet d'être averti lorsqu'une connexion sécurisée n'a pas pu être établie et que le courrier électronique ne vous a pas été transmis. Cela vous aide à détecter les problèmes de livraison de courrier électronique ou de courrier électronique livré via une connexion non sécurisée afin que vous puissiez les atténuer et les résoudre rapidement.

Vous devez noter que si le MTA-STS garantit que les courriels sont transférés via une connexion cryptée TLS, si une connexion sécurisée n'est pas négociée, le courriel peut ne pas être livré du tout. Ceci est toutefois nécessaire car cela garantit que le courrier électronique n'est pas transmis par un chemin non crypté. Pour éviter de tels problèmes, il est conseillé de mettre en place une politique MTA-STS sur un mode de test et d'activer le TLS-RPT pour votre domaine dans un premier temps, avant de passer au mode d'application MTA-STS. 

Vous pouvez facilement changer votre mode MTA-STS depuis le tableau de bord PowerMTA-STS en sélectionnant le mode de politique désiré et en enregistrant les changements sans avoir à modifier votre DNS.

Vous pouvez désactiver MTA-STS pour votre domaine soit en définissant le mode de stratégie sur « none » (aucun), indiquant ainsi aux MTA que votre domaine ne prend pas en charge le protocole, soit en supprimant votre enregistrement DNS TXT MTA-STS. 

Les enregistrements MX pour le fichier de politique MTA-STS doivent inclure les entrées pour tous les serveurs de courrier électronique de réception utilisés par votre domaine.

Programmez une démo aujourd'hui
powerdmarc, le courrier électronique sécurisé

15 jours d'essaiRéservez une démo