# Comment configurer MTA-STS et TLS-RPT pour mon domaine ? > MTA-STS demande un TXT sur _mta-sts, un fichier de politique en HTTPS sur mta-sts.yourdomain et un TXT TLS-RPT pour les rapports. - URL: https://postelva.com/fr/guides/mta-sts-setup/ - Dernière mise à jour: 2026-11-12 - Éditeur: Postelva (https://postelva.com) MTA-STS indique aux autres serveurs de messagerie de ne vous livrer que via un TLS vérifié. Il demande deux enregistrements DNS et un petit fichier sur un hébergeur web. **Réponse rapide — Comment configurer MTA-STS et TLS-RPT ?** Publiez un enregistrement TXT à _mta-sts.yourdomain avec v=STSv1 et un id, servez un fichier de politique à https://mta-sts.yourdomain/.well-known/mta-sts.txt avec un certificat valide, et ajoutez un enregistrement TXT à _smtp._tls pour les rapports TLS-RPT (RFC 8461 et RFC 8460). **Postelva** héberge les enregistrements DNS ; le fichier de politique nécessite un hébergeur web en HTTPS. ## Les quatre éléments d'une configuration MTA-STS et TLS-RPT *Noms et formats issus de la RFC 8461 et de la RFC 8460, lus le 12 novembre 2026.* | Élément | Où | Contenu | Hébergé chez | | --- | --- | --- | --- | | Enregistrement MTA-STS | TXT à _mta-sts.example.com | v=STSv1; id=20261112T000000Z | Votre DNS (DNS gratuit chez Postelva) | | Nom d'hôte web | A, AAAA ou CNAME à mta-sts.example.com | Pointe vers un serveur web | Votre DNS | | Fichier de politique | https://mta-sts.example.com/.well-known/mta-sts.txt | version, mode, lignes mx, max_age | Un hébergeur web en HTTPS avec un certificat valide | | Enregistrement TLS-RPT | TXT à _smtp._tls.example.com | v=TLSRPTv1; rua=mailto:tlsrpt@example.com | Votre DNS | ## Configurer MTA-STS en six étapes 1. **Lister vos hôtes MX** — La politique doit nommer les hôtes de messagerie de votre fournisseur. Proton Mail utilise mail.protonmail.ch et mailsec.protonmail.ch, Mailbox.org utilise mxext1 à mxext4.mailbox.org. 2. **Configurer le nom d'hôte web** — Dans l'éditeur DNS, ajoutez un enregistrement pour mta-sts qui pointe vers un serveur web que vous contrôlez, et obtenez un certificat valide pour mta-sts.yourdomain. 3. **Publier le fichier de politique en mode testing** — Créez le fichier mta-sts.txt dans le dossier .well-known, avec mode: testing et un max_age court. 4. **Ajouter l'enregistrement TXT _mta-sts** — Publiez v=STSv1; id= suivi d'une valeur unique, comme la date et l'heure. 5. **Ajouter l'enregistrement TLS-RPT** — Publiez l'enregistrement TXT à _smtp._tls avec une adresse mailto dans rua, et lisez les rapports quotidiens. 6. **Passer en enforce** — Quand les rapports ne montrent aucun échec pour vos propres hôtes MX, passez le mode à enforce, augmentez max_age et mettez à jour l'id. *Enregistrements DNS et fichier de politique (mode testing)* ```dns ; DNS records _mta-sts.example.com. IN TXT "v=STSv1; id=20261112T000000Z" _smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com" mta-sts.example.com. IN CNAME webhost.example.net. ; File served at https://mta-sts.example.com/.well-known/mta-sts.txt version: STSv1 mode: testing mx: mail.protonmail.ch mx: mailsec.protonmail.ch max_age: 86400 ``` ## Que protège MTA-STS ? **MTA-STS permet à un domaine de messagerie de déclarer qu'il prend en charge TLS et que les expéditeurs doivent refuser de livrer à tout hôte MX qui ne peut pas présenter de certificat valide.** La RFC 8461, une Proposed Standard de septembre 2018, le définit. Sans lui, le chiffrement de serveur à serveur est opportuniste : un expéditeur tente STARTTLS et, si un attaquant le supprime, envoie le message en clair. Avec une politique en mode enforce, un expéditeur compatible MTA-STS récupère votre politique, vérifie que l'hôte MX figure dans la liste mx et exige une connexion TLS valide avec un certificat correspondant. Si une vérification échoue, le message attend et n'est pas livré par un canal moins sûr. Il ne protège que le courrier entrant, et uniquement pour les expéditeurs qui l'implémentent. Il n'authentifie pas les messages : c'est le rôle des enregistrements décrits dans [SPF, DKIM et DMARC : les différences](https://postelva.com/fr/spf-vs-dkim-vs-dmarc/ "SPF vs DKIM vs DMARC: what is the difference?"). ## Que contient le fichier de politique ? **Le fichier de politique est un fichier texte brut de lignes clé: valeur avec la version, le mode, les motifs MX autorisés et une durée de vie en secondes.** La RFC 8461 définit ces champs. version doit valoir STSv1. mode est enforce (les expéditeurs ne doivent pas livrer aux hôtes qui échouent aux vérifications), testing (la livraison peut avoir lieu, et les expéditeurs compatibles TLS-RPT envoient des rapports d'échec) ou none (comme si aucune politique n'existait). Chaque ligne mx désigne un hôte en entier, par exemple mail.protonmail.ch, ou utilise un joker sur l'étiquette la plus à gauche, comme *.example.net. max_age est un nombre de secondes, au plus 31,557,600, et la RFC indique qu'il devrait typiquement être de plusieurs semaines ou plus. Son exemple utilise 604800, soit une semaine. Le fichier doit être servi en HTTPS à mta-sts.yourdomain avec un certificat valable pour ce nom. Seule une réponse HTTP 200 compte et les redirections ne doivent pas être suivies, ce qui exclut la redirection d'URL, un service qui répond par une redirection. Le fichier doit être envoyé en text/plain. Utilisez un petit hébergeur web ou un hébergeur de pages statiques que vous contrôlez. Les lignes mx doivent correspondre aux enregistrements de votre fournisseur, tels que listés dans [ce qu'est un enregistrement MX](https://postelva.com/fr/what-is-an-mx-record/ "What is an MX record?"). ## Que sont l'id et l'ordre de mise à jour ? **L'id dans l'enregistrement TXT est une étiquette de 1 à 32 lettres et chiffres qui doit changer à chaque modification de la politique, pour que les expéditeurs sachent qu'ils doivent récupérer à nouveau le fichier.** La RFC 8461 précise qu'il identifie une instance de politique et qu'il n'existe aucun ordre entre les id : un horodatage date-heure convient donc bien. Mettez à jour dans cet ordre : publiez d'abord le nouveau fichier de politique, puis changez l'id. Un expéditeur qui verrait le nouvel id avant le nouveau fichier remettrait l'ancienne politique en cache. Quand vous changez de fournisseur e-mail, les hôtes MX changent aussi : modifiez donc les lignes mx avant de changer les enregistrements MX, gardez les anciens hôtes dans la liste pendant la migration et incrémentez l'id. Une ligne mx oubliée en mode enforce empêche les e-mails d'arriver, et le guide de migration [comment migrer son e-mail vers un nouveau fournisseur](https://postelva.com/fr/guides/move-email-provider-without-downtime/ "How to move email to a new provider without losing mail") donne l'ordre sûr pour le reste. ## Qu'est-ce que TLS-RPT et que contiennent les rapports ? **TLS-RPT est un format de rapport, la RFC 8460, dans lequel les serveurs expéditeurs vous indiquent chaque jour combien de connexions TLS vers votre domaine ont réussi ou échoué.** Vous publiez un enregistrement TXT à _smtp._tls.yourdomain avec v=TLSRPTv1 et un champ rua contenant une adresse mailto: ou https:. Les rapports envoyés par mailto doivent porter une signature DKIM valide du domaine émetteur du rapport. Chaque rapport est un document JSON couvrant une journée UTC. Il nomme la politique appliquée (MTA-STS, DANE ou aucune), compte les sessions réussies et échouées, et indique le type d'échec, comme certificate-expired ou starttls-not-supported, avec les adresses IP d'envoi et de réception. C'est ainsi que vous apprenez qu'un certificat a expiré ou qu'une ligne mx contient une faute de frappe, avant de passer en enforce. Considérez les premières semaines comme la période d'essai recommandée pour [DMARC](https://postelva.com/fr/guides/dmarc-setup/ "How to set up DMARC: p=none to p=reject"). ## Ai-je besoin de MTA-STS pour un domaine e-mail personnel ? **Non : MTA-STS est un durcissement facultatif, et les règles des grands expéditeurs ne l'exigent pas.** Google, Yahoo et Microsoft demandent SPF, DKIM et DMARC aux expéditeurs en masse et ne citent pas MTA-STS. Pour un domaine personnel chez Proton Mail, Fastmail ou Mailbox.org, la configuration ne vaut la peine que si vous acceptez l'entretien d'un hébergeur web et d'un certificat. Les fournisseurs diffèrent. Selon la lecture par Postelva, le 12 novembre 2026, des listes de configuration DNS de 4 fournisseurs (Proton Mail, Tuta, Mailbox.org et Fastmail), 1 indique un enregistrement MTA-STS dans sa propre configuration (Tuta, un CNAME), et les pages d'aide lues pour les trois autres n'en documentent aucun. La configuration complète représente 3 enregistrements DNS et 1 fichier. Vérifiez chacun avec les commandes de [comment vérifier les enregistrements MX, SPF, DKIM et DMARC](https://postelva.com/fr/guides/check-email-dns-records/ "How to check MX, SPF, DKIM and DMARC records") : dig TXT _mta-sts.example.com +short et dig TXT _smtp._tls.example.com +short. Une définition citable : MTA-STS est la politique qui rend TLS obligatoire quand d'autres serveurs livrent du courrier à votre domaine, et TLS-RPT est le rapport quotidien qui vous signale quand cela échoue. ## Questions sur MTA-STS et TLS-RPT ### Puis-je héberger le fichier de politique MTA-STS chez mon fournisseur DNS ? Pas sur un hébergeur DNS seul : le fichier nécessite un serveur web répondant en HTTPS à mta-sts.yourdomain. La redirection d'URL ne fonctionne pas, car les redirections ne doivent pas être suivies. ### Quel max_age dois-je utiliser ? La RFC 8461 indique que la valeur va typiquement de quelques semaines à plus, avec 604800 secondes (une semaine) dans son exemple. Commencez par une valeur courte en mode testing et augmentez-la quand les rapports sont propres. ### MTA-STS est-il la même chose que DANE ? Non. Les deux protègent le TLS de serveur à serveur, mais DANE repose sur DNSSEC et les enregistrements TLSA, tandis que MTA-STS repose sur un fichier de politique en HTTPS. TLS-RPT fournit des rapports pour les deux. ### Que se passe-t-il si mon certificat expire en mode enforce ? Les expéditeurs compatibles MTA-STS cessent de livrer à vos hôtes quand le certificat d'un hôte MX échoue, et les e-mails attendent dans leur file. Il en va de même pour une ligne mx manquante : surveillez donc TLS-RPT. ### Dois-je utiliser le mode enforce ? Non. Le mode testing vous donne déjà des rapports, et le mode none désactive la politique. **En résumé** - MTA-STS (RFC 8461) rend TLS obligatoire pour le courrier livré à votre domaine. - Configuration : un enregistrement TXT à _mta-sts, un fichier de politique HTTPS à mta-sts.yourdomain/.well-known/mta-sts.txt et un enregistrement TXT à _smtp._tls pour TLS-RPT (RFC 8460). - La politique indique le mode (enforce, testing, none), les hôtes mx et max_age, au plus 31,557,600 secondes. - Les redirections ne doivent pas être suivies : la redirection d'URL ne peut donc pas servir le fichier. - Changez l'id à chaque modification de la politique ; mettez d'abord à jour le fichier, puis l'enregistrement TXT. - Commencez en mode testing et lisez les rapports TLS-RPT avant de passer en enforce. - Postelva héberge gratuitement les enregistrements DNS ; un .com coûte 12,49 $US/an par an. ## Sources 1. [RFC 8461, SMTP MTA Strict Transport Security (MTA-STS)](https://www.rfc-editor.org/rfc/rfc8461.html) — RFC Editor (consulté le 2026-11-12) 2. [RFC 8460, SMTP TLS Reporting](https://www.rfc-editor.org/rfc/rfc8460.html) — RFC Editor (consulté le 2026-11-12) 3. [Consignes aux expéditeurs d'e-mails](https://support.google.com/a/answer/81126) — Google Workspace Admin Help (consulté le 2026-11-12) 4. [Domaine personnalisé et protection contre l'usurpation](https://proton.me/support/anti-spoofing-custom-domain) — Proton (consulté le 2026-11-12) --- Postelva: Postelva enregistre des noms de domaine pour l'e-mail privé — l'adresse que vous gardez quand vous changez de fournisseur — payés en crypto et sans KYC : pas de pièce d'identité, seulement un e-mail vérifié par domaine. Le service est exploité par DomaineGoat LLC, société enregistrée au Panama ; les domaines sont enregistrés via son partenaire registraire accrédité par l'ICANN. Un .com coûte 12,49 $US/an, le même prix chaque année.