MTA-STS et TLS-RPT : sécuriser SMTP en production — tutoriel 2026

Introduction

Lorsqu’un email quitte votre serveur en direction de Gmail, Outlook ou un MTA tiers, la connexion SMTP passe par STARTTLS — un mécanisme d’élévation vers TLS qui, malheureusement, reste opportuniste par défaut. Cela signifie que si un attaquant se positionne en homme du milieu (MITM) sur le réseau et répond à l’annonce STARTTLS par un message indiquant que TLS n’est pas disponible, la plupart des serveurs SMTP accepteront de renvoyer l’email en clair, sans émettre d’erreur ni d’alerte. Cette attaque, connue sous le nom de STARTTLS downgrade, est documentée et exploitable, notamment dans des contextes où l’infrastructure réseau est peu fiable ou partiellement contrôlée par des tiers.

MTA-STS (Mail Transfer Agent Strict Transport Security), défini dans la RFC 8461, apporte une réponse directe à ce problème. Le protocole permet à un domaine de publier une politique déclarant que tout MTA souhaitant lui livrer des emails doit utiliser TLS, en validant le certificat du serveur de destination, et en refusant catégoriquement la livraison en clair si la connexion chiffrée échoue. Combiné à TLS-RPT (RFC 8460), qui définit le format de rapports JSON envoyés automatiquement par les MTA partenaires lors de chaque échec de connexion TLS, MTA-STS offre à la fois une protection active et une visibilité complète sur la santé du chiffrement entrant de votre domaine.

Ce tutoriel vous guide pas-à-pas dans le déploiement complet de MTA-STS et TLS-RPT pour votre domaine, depuis la publication du fichier de politique sur HTTPS jusqu’au monitoring des rapports JSON, en passant par la transition du mode testing vers le mode enforce. La configuration est illustrée pour Postfix et Mailcow, les deux environnements les plus répandus en auto-hébergement en Afrique de l’Ouest.

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants. Ce tutoriel suppose que votre domaine email est déjà opérationnel et que vous avez accès à la gestion DNS de votre zone. La mise en œuvre complète prend environ 30 minutes, hors propagation DNS (qui peut aller jusqu’à 24 heures).

• Un domaine email actif avec enregistrements MX correctement configurés (vérifiable via dig MX votre-domaine.com).
• Accès à la gestion DNS de votre zone (interface de votre registrar ou serveur DNS autoritaire).
• Un certificat TLS valide sur votre MX — le certificat doit correspondre au hostname du serveur MX et être signé par une CA reconnue (Let’s Encrypt suffit). Un certificat auto-signé bloquera la livraison en mode enforce.
• Un sous-domaine HTTPS accessible : mta-sts.votre-domaine.com doit répondre sur le port 443 avec un certificat valide. C’est ici que sera hébergé le fichier de politique.
• Accès root ou sudo sur votre serveur mail (Postfix ou Mailcow) pour vérifier la configuration TLS.
• Optionnel mais recommandé : une adresse email dédiée à la réception des rapports TLS-RPT (ex. tls-reports@votre-domaine.com).

Étape 1 — Comprendre RFC 8461 et le threat model

Avant de configurer quoi que ce soit, il est essentiel de comprendre précisément ce que MTA-STS protège et ce qu’il ne protège pas. Cette clarté évite des surprises en production et aide à calibrer correctement le niveau d’enforcement.

Le threat model de MTA-STS se concentre sur deux vecteurs d’attaque spécifiques. Le premier est le STARTTLS downgrade : un attaquant MITM qui supprime ou falsifie la réponse 250-STARTTLS de votre serveur pour que l’expéditeur croie que TLS n’est pas supporté et envoie en clair. Le second est le DNS spoofing sur les enregistrements MX : un attaquant qui empoisonne le DNS de l’expéditeur pour pointer ses MX vers un serveur malveillant qui acceptera l’email. MTA-STS contrecarre les deux en forçant la validation du certificat TLS du MX de destination, dont le hostname doit correspondre à ce qui est déclaré dans la politique.

Ce que MTA-STS ne protège pas : il ne chiffre pas les emails au repos, ne garantit pas la confidentialité de bout en bout (c’est le rôle de S/MIME ou PGP), et ne protège pas les connexions SMTP sortantes de votre domaine vers des tiers qui n’ont pas encore adopté MTA-STS. Il s’applique uniquement aux MTA qui livrent des emails vers votre domaine et qui supportent eux-mêmes MTA-STS.

La RFC 8461 définit trois composants obligatoires pour une implémentation valide. D’abord, un fichier de politique (policy file) accessible via HTTPS sur https://mta-sts.votre-domaine.com/.well-known/mta-sts.txt, qui liste les MX autorisés et le mode d’enforcement. Ensuite, un enregistrement DNS TXT sur _mta-sts.votre-domaine.com qui contient un identifiant de version (id) permettant aux expéditeurs de détecter les changements de politique sans re-fetcher le fichier à chaque fois. Enfin, la politique est mise en cache par les MTA expéditeurs pour la durée spécifiée par le champ max_age — ce point a des implications importantes lors des mises à jour de configuration.

Étape 2 — Publier le policy file mta-sts.txt sur HTTPS

Le fichier de politique est le cœur du dispositif MTA-STS. Il doit être servi sur un sous-domaine précis, via HTTPS uniquement (pas de redirection HTTP acceptable), avec le bon Content-Type. Voici comment le mettre en place.

Créez le répertoire .well-known à la racine du vhost mta-sts.votre-domaine.com, puis le fichier mta-sts.txt avec le contenu suivant :

version: STSv1
mode: testing
mx: mail.votre-domaine.com
mx: *.votre-domaine.com
max_age: 86400

Chaque champ a une signification précise selon la RFC 8461. Le champ version doit valoir exactement STSv1 — toute autre valeur rend la politique invalide. Le champ mode peut prendre trois valeurs : none (désactivé, utile pour révoquer une politique existante), testing (les échecs sont signalés mais la livraison en clair est toujours acceptée) et enforce (les échecs bloquent la livraison). Le champ mx liste les patterns de hostname des MX autorisés — vous pouvez en avoir plusieurs, et les wildcards de premier niveau (*.exemple.com) sont acceptés. Enfin, max_age définit en secondes la durée de mise en cache de la politique chez les MTA expéditeurs ; 86 400 secondes (1 jour) en phase de test, puis 604 800 (7 jours) en production sont des valeurs raisonnables.

La configuration Nginx pour servir ce fichier correctement est la suivante :

server {
    listen 443 ssl;
    server_name mta-sts.votre-domaine.com;

    ssl_certificate     /etc/letsencrypt/live/mta-sts.votre-domaine.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mta-sts.votre-domaine.com/privkey.pem;

    root /var/www/mta-sts;

    location /.well-known/mta-sts.txt {
        default_type text/plain;
        add_header Cache-Control "public, max-age=86400";
    }
}

server {
    listen 80;
    server_name mta-sts.votre-domaine.com;
    return 301 https://$host$request_uri;
}

Après avoir créé le fichier et rechargé Nginx (nginx -t && systemctl reload nginx), vérifiez l’accessibilité avec curl -I https://mta-sts.votre-domaine.com/.well-known/mta-sts.txt. La réponse doit afficher HTTP/2 200 et content-type: text/plain. Si vous obtenez un 404 ou une erreur SSL, la politique ne sera pas prise en compte par les MTA expéditeurs, ce qui n’entraîne aucune dégradation (ils livreront normalement) mais invalidera votre déploiement MTA-STS. La RFC 8461 section 3.3 précise que si le fetch du policy file échoue, le MTA expéditeur doit se comporter comme si aucune politique n’existait pour ce domaine.

Étape 3 — DNS TXT _mta-sts.votre-domaine.com

Le fichier de politique seul ne suffit pas — les MTA expéditeurs doivent savoir qu’il existe et détecter ses changements sans le télécharger à chaque envoi. C’est le rôle de l’enregistrement DNS TXT sur _mta-sts.votre-domaine.com.

Ajoutez l’enregistrement TXT suivant dans votre zone DNS :

_mta-sts.votre-domaine.com.  IN  TXT  "v=STSv1; id=20260427T120000Z"

La valeur du champ id est libre dans sa forme mais doit être unique et changer à chaque modification de la politique. La convention recommandée est un timestamp ISO 8601 compact (sans tirets ni deux-points) : 20260427T120000Z représente le 27 avril 2026 à 12h00 UTC. Lorsque vous modifierez le fichier mta-sts.txt (par exemple pour passer de testing à enforce), vous devrez simultanément mettre à jour la valeur du champ id dans le DNS — les MTA expéditeurs qui ont mis en cache l’ancienne politique verront le changement de id et iront refetcher le fichier.

Il est important de comprendre la relation de priorité entre le DNS et le cache. Si un MTA a déjà mis en cache votre politique avec mode: testing et que vous changez le fichier HTTPS pour mode: enforce sans changer l’id DNS, le MTA continuera d’appliquer l’ancienne politique jusqu’à expiration du max_age. C’est pourquoi le changement de id est obligatoire et doit être synchronisé avec la modification du fichier policy. Vérifiez la propagation avec dig TXT _mta-sts.votre-domaine.com depuis plusieurs resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1) avant de considérer le déploiement effectif.

Étape 4 — TLS-RPT pour les rapports d’échec

TLS-RPT (RFC 8460) est le mécanisme de reporting qui complète MTA-STS. Il permet aux MTA expéditeurs — notamment Gmail, Outlook, et les grandes infrastructures de messagerie — d’envoyer automatiquement des rapports JSON détaillant toutes les tentatives de connexion TLS vers votre domaine qui ont échoué, qu’elles soient liées à un problème de certificat, un handshake TLS raté, ou un échec de validation MTA-STS. Sans TLS-RPT, vous seriez aveugle aux problèmes de votre configuration TLS.

TLS-RPT s’active via un enregistrement DNS TXT sur _smtp._tls.votre-domaine.com :

_smtp._tls.votre-domaine.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@votre-domaine.com"

Le champ rua accepte soit une adresse email (mailto:), soit une URL HTTPS vers laquelle les rapports seront POSTés (https://). L’adresse email est la solution la plus simple pour commencer. Les rapports sont envoyés une fois par jour, au format JSON compressé (gzip), et contiennent pour chaque session SMTP : le nom du MTA expéditeur, le timestamp, le type d’échec, le code d’erreur TLS et le hostname de destination qui a posé problème.

Il est recommandé de créer une boîte dédiée tls-reports@votre-domaine.com plutôt que d’utiliser une boîte générique. Les rapports peuvent être volumineux si vous recevez beaucoup d’email, et les conserver séparément facilite l’analyse. Dans la section Étape 7, nous verrons comment parser automatiquement ces rapports JSON pour en extraire des métriques exploitables.

Étape 5 — Tester avec hardenize.com et mxtoolbox

Avant de passer en mode enforce, il est indispensable de valider votre configuration depuis des outils tiers qui simulent exactement ce qu’un MTA expéditeur verrait. Deux outils de référence existent pour cela.

Hardenize (hardenize.com) propose un audit complet de la sécurité email d’un domaine, incluant MTA-STS, TLS-RPT, DMARC, DNSSEC et la qualité TLS du serveur MX. Entrez votre domaine et attendez 2 à 3 minutes : le rapport indique si le policy file est accessible, si le DNS TXT est correctement formaté, si le certificat TLS de votre MX est valide et correspond aux hostnames déclarés dans la politique, et si TLS-RPT est actif. C’est l’outil le plus complet pour un audit pré-enforcement.

MXToolbox (mxtoolbox.com/mta-sts.aspx) propose un test MTA-STS dédié qui vérifie l’enregistrement DNS et le policy file, et affiche les erreurs de syntaxe éventuelles. Il est utile pour un diagnostic rapide mais moins exhaustif que Hardenize sur la validation du certificat TLS.

Lors de vos tests, portez une attention particulière à deux points critiques. Premier point : le hostname dans votre enregistrement mx du policy file doit correspondre exactement au CN ou SAN du certificat TLS présenté par votre serveur MX. Si votre MX est mail.exemple.com mais que le certificat est émis pour exemple.com uniquement, la validation échouera en mode enforce. Second point : si votre serveur MX répond sur plusieurs adresses IP (IPv4 + IPv6), testez la connexion TLS sur chacune — les certificats peuvent différer selon le binding.

Étape 6 — Mode testing → enforce

La transition de testing vers enforce est la phase la plus délicate du déploiement. En mode testing, les MTA expéditeurs qui supportent MTA-STS enverront des rapports TLS-RPT en cas d’échec mais livreront quand même l’email en clair ou via une connexion non-validée. Le passage à enforce signifie que ces MTA refuseront la livraison si TLS ne peut pas être établi correctement selon la politique. Un email dont la livraison échoue en enforce est soit mis en queue chez l’expéditeur (avec nouvelles tentatives pendant quelques jours), soit rejeté définitivement.

La procédure recommandée est la suivante. Laissez le mode testing actif pendant au moins 7 à 14 jours tout en surveillant les rapports TLS-RPT. Si les rapports ne signalent aucun échec (ou uniquement des échecs de MTA anciens qui ne supportent pas TLS — ce qui est acceptable), vous pouvez passer en enforce.

Pour effectuer la transition, modifiez le fichier mta-sts.txt sur votre serveur HTTPS :

version: STSv1
mode: enforce
mx: mail.votre-domaine.com
mx: *.votre-domaine.com
max_age: 604800

Simultanément — et c’est obligatoire — mettez à jour l’identifiant id dans votre enregistrement DNS TXT :

_mta-sts.votre-domaine.com.  IN  TXT  "v=STSv1; id=20260427T180000Z"

Le max_age passe à 604 800 secondes (7 jours) pour réduire la charge de fetch sur les MTA expéditeurs. Notez que cette valeur plus longue signifie également qu’une modification future de la politique mettra jusqu’à 7 jours à être entièrement propagée chez tous les MTA qui ont mis en cache l’ancienne version — sauf si vous changez l’id, qui force le re-fetch immédiat.

Étape 7 — Monitoring des rapports JSON

Une fois TLS-RPT actif, vous allez recevoir des rapports quotidiens sous forme de fichiers JSON compressés (Content-Type : application/tlsrpt+gzip ou application/tlsrpt+json). Voici comment les interpréter et les exploiter automatiquement.

Un rapport TLS-RPT typique ressemble à ceci (format simplifié) :

{
  "organization-name": "Google LLC",
  "date-range": {
    "start-datetime": "2026-04-26T00:00:00Z",
    "end-datetime": "2026-04-26T23:59:59Z"
  },
  "contact-info": "smtp-tls-reporting@google.com",
  "report-id": "2026-04-26T00:00:00Z_votre-domaine.com",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-string": ["version: STSv1", "mode: testing", "mx: mail.votre-domaine.com"],
        "policy-domain": "votre-domaine.com"
      },
      "summary": {
        "total-successful-session-count": 1842,
        "total-failure-session-count": 3
      },
      "failure-details": [
        {
          "result-type": "certificate-expired",
          "sending-mta-ip": "209.85.220.41",
          "receiving-mx-hostname": "mail.votre-domaine.com",
          "failed-session-count": 3
        }
      ]
    }
  ]
}

Les champs clés à surveiller sont total-failure-session-count (toute valeur non nulle mérite investigation) et le tableau failure-details avec le champ result-type. Les types d’échec définis par la RFC 8460 incluent notamment starttls-not-supported (le MX de destination ne supporte pas STARTTLS — souvent un vieux serveur ou un problème de configuration), certificate-host-mismatch (le nom du certificat ne correspond pas au MX déclaré), certificate-expired (certificat expiré — à corriger d’urgence avant le passage en enforce), certificate-not-trusted (CA non reconnue) et sts-policy-fetch-error (le policy file n’était pas accessible au moment du fetch).

Pour automatiser le parsing, voici un script Python minimal qui décompresse et analyse les rapports reçus par email :

import gzip, json, sys

with gzip.open(sys.argv[1], 'rb') as f:
    report = json.loads(f.read())

for policy in report.get('policies', []):
    summary = policy.get('summary', {})
    ok  = summary.get('total-successful-session-count', 0)
    fail = summary.get('total-failure-session-count', 0)
    print(f"Sessions OK: {ok} | Failures: {fail}")
    for detail in policy.get('failure-details', []):
        print(f"  [{detail['result-type']}] {detail['failed-session-count']} sessions — MX: {detail.get('receiving-mx-hostname','?')}")

Appelez ce script avec le chemin vers le fichier .gz reçu en pièce jointe : python3 parse_tlsrpt.py rapport-2026-04-26.json.gz. Sur un serveur en production, intégrez ce parsing dans un cron job qui notifie par email (ou Telegram) dès qu’une valeur total-failure-session-count dépasse un seuil que vous définissez.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Le déploiement de MTA-STS en Afrique de l’Ouest présente des spécificités liées à l’infrastructure locale qui méritent d’être traitées explicitement, plutôt que de supposer un environnement identique à celui d’un datacenter européen.

Mailcow sur VPS local : si vous utilisez Mailcow (la suite auto-hébergée la plus populaire pour les PME dans la région), le sous-domaine mta-sts.votre-domaine.com peut pointer vers le même VPS que votre serveur mail, à condition d’utiliser un vhost Nginx séparé. Mailcow gère son propre Nginx interne — ajoutez un fichier de configuration dans /opt/mailcow-dockerized/data/conf/nginx/ pour le vhost MTA-STS, et redémarrez le container Nginx de Mailcow avec docker compose restart nginx-mailcow. Le certificat Let’s Encrypt pour le sous-domaine sera généré automatiquement par le système ACME intégré de Mailcow si vous ajoutez mta-sts.votre-domaine.com à la liste des domaines dans mailcow.conf (variable ADDITIONAL_SAN).

Postfix classique : sur un serveur Postfix autonome (Debian/Ubuntu), le policy file peut être servi par le même Nginx qui gère votre webmail ou votre site. L’important est que le certificat TLS présenté sur le port 25 de Postfix et celui présenté sur le port 443 du vhost MTA-STS soient tous les deux valides. Vérifiez la configuration TLS de Postfix avec postconf -n | grep tls — les paramètres smtpd_tls_cert_file, smtpd_tls_key_file et smtpd_tls_security_level doivent être présents et pointer vers un certificat valide Let’s Encrypt.

Compatibilité avec Sonatel et Orange CI : les serveurs de messagerie de Sonatel (Sénégal) et d’Orange Côte d’Ivoire utilisent des MTA relativement récents qui supportent STARTTLS. Les entreprises qui reçoivent des emails depuis les adresses @orange.sn, @orange.ci ou les domaines corporate de Sonatel ne devraient pas rencontrer de problème en mode enforce, à condition que le certificat de votre MX soit valide. En revanche, certains petits opérateurs locaux ou ISP régionaux (notamment en zones rurales) utilisent des relais SMTP vieillissants sans STARTTLS. Si votre activité dépend de la réception d’emails depuis ces sources, restez en mode testing et analysez les rapports pendant 30 jours avant de passer en enforce.

Fallback STARTTLS si le MTA destinataire ne supporte pas MTA-STS : il est important de comprendre que MTA-STS est une politique que vous publiez pour les expéditeurs qui vous envoient des emails. Si vous envoyez des emails vers un domaine qui n’a pas déployé MTA-STS (ce qui est encore le cas de la majorité des domaines africains), votre MTA utilisera simplement STARTTLS opportuniste. MTA-STS ne bloque rien dans ce sens. Pour renforcer la sécurité des emails sortants, vous devriez compléter avec DNSSEC + DANE (RFC 7671), mais c’est un sujet pour un autre tutoriel — le support de DANE reste limité chez les grands MTA comme Gmail, qui préfère MTA-STS.

Gestion des coupures réseau : en cas de coupure prolongée (fréquente en Afrique de l’Ouest), si votre serveur HTTPS mta-sts.votre-domaine.com devient inaccessible, les MTA expéditeurs qui ont mis en cache votre politique continueront de l’appliquer pendant toute la durée du max_age. Ceux qui cherchent à fetcher une politique fraîche et n’y parviennent pas se comporteront comme si aucune politique n’existait (RFC 8461 §3.3). C’est une mesure de sécurité réfléchie qui évite de bloquer des emails légitimes en cas d’indisponibilité temporaire de l’infrastructure MTA-STS. Pour les environnements à haute disponibilité, envisagez de servir le policy file depuis un CDN (Cloudflare Pages, BunnyCDN).

Tutoriels frères

• Configurer DMARC pour votre domaine email PME — tutoriel pas-à-pas — déployer la politique DMARC, analyser les rapports RUA/RUF, passer en p=reject
• SPF et DKIM avec Postfix et Mailcow — configuration complète 2026 — aligner SPF, DKIM et en-têtes From pour maximiser la délivrabilité
• BIMI et VMC : afficher votre logo dans Gmail et Outlook — tutoriel 2026 — prérequis DMARC enforce + déploiement SVG BIMI

Pour aller plus loin

• Retour au pilier : Email pro deliverability 2026 : SPF, DKIM, DMARC, MTA-STS, BIMI, ARC
• RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS) — source primaire IETF
• RFC 8460 — SMTP TLS Reporting — source primaire IETF, format complet des rapports JSON
• Hardenize — audit continu de la sécurité email et web de votre domaine
• Tutoriel suivant recommandé dans le cluster : ARC (Authenticated Received Chain) — configurer la chaîne d’authentification pour le forwarding d’emails

FAQ