Guide MTA-STS — Bloquer les Attaques Downgrade Email (Pas à Pas)

MTA-STS (Mail Transfer Agent Strict Transport Security) represente une avancee majeure dans la securisation du transport email. Ce protocole impose l'utilisation du chiffrement TLS pour les emails entrants.

Alors que STARTTLS offre un chiffrement opportuniste facilement contournable, MTA-STS etablit une politique stricte verifiable.

Qu'est-ce que MTA-STS ?

MTA-STS est un standard (RFC 8461) permettant a un domaine de declarer qu'il supporte le TLS pour la reception d'emails. Les serveurs expediteurs doivent exiger une connexion TLS validee.

Fonctionnement du protocole

La declaration se fait via une combinaison :

• Enregistrement DNS TXT
• Politique hebergee en HTTPS

Resolution d'une faiblesse STARTTLS

Avec MTA-STS, le serveur expediteur :

1. Verifie la politique du domaine destinataire
2. Refuse d'envoyer si le TLS valide n'est pas disponible

Parametres de la politique

La politique MTA-STS definit :

TLS-RPT pour le reporting

Le rapport TLS-RPT associe (RFC 8460) permet aux serveurs expediteurs d'envoyer des rapports sur les succes et echecs de connexion TLS.

Pourquoi Implementer MTA-STS

L'implementation de MTA-STS repond a des enjeux cruciaux de securite.

Protection contre l'interception

Les emails transitant en clair peuvent etre lus par tout acteur ayant acces au reseau. MTA-STS impose un chiffrement de bout en bout du transport.

Prevention des attaques man-in-the-middle

Conformite reglementaire

Les reglementations de protection des donnees exigent des mesures appropriees :

• RGPD
• HIPAA
• Reglementations sectorielles

Le chiffrement du transport email constitue une mesure technique demontrable.

Signal de confiance

L'adoption de MTA-STS signale un engagement serieux envers la protection des communications, differenciateur significatif dans les relations B2B sensibles.

Comment Configurer MTA-STS

La configuration se deroule en plusieurs etapes techniques.

Prerequis

Verifiez avant de commencer :

• Vos serveurs MX supportent TLS
• Les certificats sont valides
• Les connexions TLS fonctionnent vers tous vos MX

Etape 1 : Creer la politique

Creez un fichier texte definissant votre politique :

version: STSv1
mode: testing
mx: mail.votredomaine.com
mx: backup.votredomaine.com
max_age: 604800

Etape 2 : Heberger la politique

Hebergez le fichier sur :

https://mta-sts.votredomaine.com/.well-known/mta-sts.txt

Le sous-domaine doit avoir un certificat SSL valide.

Configuration Nginx

server {
    listen 443 ssl http2;
    server_name mta-sts.votredomaine.com;

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

    location /.well-known/mta-sts.txt {
        root /var/www/mta-sts;
        default_type text/plain;
    }

    # Rediriger tout le reste
    location / {
        return 301 https://votredomaine.com$request_uri;
    }
}

Puis creez le fichier de politique :

sudo mkdir -p /var/www/mta-sts/.well-known
cat <<'EOF' | sudo tee /var/www/mta-sts/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: mail.votredomaine.com
mx: backup.votredomaine.com
max_age: 86400
EOF

Configuration Apache

<VirtualHost *:443>
    ServerName mta-sts.votredomaine.com

    SSLEngine on
    SSLCertificateFile    /etc/letsencrypt/live/mta-sts.votredomaine.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/mta-sts.votredomaine.com/privkey.pem

    DocumentRoot /var/www/mta-sts

    <Directory /var/www/mta-sts/.well-known>
        ForceType text/plain
        Require all granted
    </Directory>
</VirtualHost>

Etape 3 : Publier l'enregistrement DNS

Creez l'enregistrement TXT :

_mta-sts.votredomaine.com  TXT  "v=STSv1; id=20240115"

Etape 4 : Configurer TLS-RPT

Publiez l'enregistrement pour recevoir les rapports :

_smtp._tls.votredomaine.com  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@votredomaine.com"

Etape 5 : Passer en mode enforce

Apres une periode d'observation sans erreur significative, modifiez la politique :

version: STSv1
mode: enforce
mx: mail.votredomaine.com
mx: backup.votredomaine.com
max_age: 604800

N'oubliez pas de mettre a jour l'identifiant DNS.

Bonnes Pratiques MTA-STS

Proceder par etapes

Le mode testing est concu pour observer l'impact sans bloquer d'emails. Analysez les rapports TLS-RPT pendant plusieurs semaines avant de passer en enforce.

Maintenir la coherence

Choisir une duree de cache appropriee

Surveiller les rapports TLS-RPT

Ces rapports revelent les echecs de connexion TLS. Un taux d'echec eleve peut indiquer :

• Problemes de certificat
• Configuration TLS a corriger

Documenter la configuration

Integrez MTA-STS dans vos procedures de changement. Les modifications de MX, certificats ou infrastructure doivent inclure une verification de coherence.

Recapitulatif Complet Pret a Copier

Voici tous les enregistrements DNS et fichiers necessaires en un seul endroit :

Enregistrements DNS

# Enregistrement d'annonce MTA-STS
_mta-sts.votredomaine.com.   IN  TXT  "v=STSv1; id=20260401001"

# Enregistrement TLS-RPT pour le reporting
_smtp._tls.votredomaine.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@votredomaine.com"

Fichier de politique (mta-sts.txt)

version: STSv1
mode: enforce
mx: mail.votredomaine.com
mx: backup.votredomaine.com
max_age: 604800

Diagnostic MTA-STS

Lorsque MTA-STS ne fonctionne pas comme prevu, utilisez ce tableau pour diagnostiquer et corriger les problemes courants :

Monitoring TLS-RPT

TLS-RPT (RFC 8460) est la couche de visibilite de MTA-STS. Sans elle, vous n'avez aucun moyen de savoir si votre politique bloque silencieusement la livraison d'emails.

Fonctionnement de TLS-RPT

Les serveurs de messagerie supportant TLS-RPT envoient des rapports agreges quotidiens au format JSON a l'adresse specifiee dans votre enregistrement DNS _smtp._tls. Ces rapports resume les resultats des connexions TLS sur les dernieres 24 heures.

Exemple complet de rapport TLS-RPT

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-03-31T00:00:00Z",
    "end-datetime": "2026-03-31T23:59:59Z"
  },
  "contact-info": "smtp-tls-reporting@google.com",
  "report-id": "2026-03-31T00:00:00Z_votredomaine.com",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-string": [
          "version: STSv1",
          "mode: enforce",
          "mx: mail.votredomaine.com",
          "mx: backup.votredomaine.com",
          "max_age: 604800"
        ],
        "policy-domain": "votredomaine.com",
        "mx-host": ["mail.votredomaine.com", "backup.votredomaine.com"]
      },
      "summary": {
        "total-successful-session-count": 4521,
        "total-failure-session-count": 3
      },
      "failure-details": [
        {
          "result-type": "certificate-expired",
          "sending-mta-ip": "198.51.100.42",
          "receiving-mx-hostname": "backup.votredomaine.com",
          "receiving-ip": "203.0.113.25",
          "failed-session-count": 3,
          "additional-information": "Certificate expired 2026-03-28"
        }
      ]
    }
  ]
}

Metriques cles a suivre

Surveillez ces metriques dans vos rapports TLS-RPT :

• Taux de succes — total-successful-session-count / (succes + echecs). Objectif : au-dessus de 99,9%
• Tendance des echecs — Un pic soudain indique un probleme de certificat ou de configuration
• Types d'echecs — certificate-expired, certificate-not-trusted, starttls-not-supported, validation-failure
• Serveurs MX affectes — Identifie quel serveur de messagerie precise a le probleme

Traitement des rapports TLS-RPT

Pour les petits deployments, une boite email dediee avec revue manuelle suffit. Pour les environnements de production, automatisez l'analyse :

# Parser un rapport TLS-RPT JSON pour extraire les details d'echec
cat tls-report.json | python3 -c "
import json, sys
report = json.load(sys.stdin)
for policy in report.get('policies', []):
    total = policy['summary']['total-successful-session-count']
    failed = policy['summary']['total-failure-session-count']
    rate = total / (total + failed) * 100 if (total + failed) > 0 else 0
    print(f\"Taux de succes: {rate:.2f}% ({total} ok, {failed} echecs)\")
    for f in policy.get('failure-details', []):
        print(f\"  ECHEC: {f['result-type']} sur {f.get('receiving-mx-hostname', 'inconnu')} ({f['failed-session-count']} sessions)\")
"

Conclusion

MTA-STS eleve significativement la securite du transport de vos emails en imposant un chiffrement TLS verifie. Une implementation progressive du testing vers l'enforce securise vos communications sans risque de disruption.

WizStatus surveille la disponibilite et la validite de votre politique MTA-STS, verifiant la coherence avec vos enregistrements MX et vous alertant de tout probleme.

Guides connexes

• Guide d'Implémentation HSTS — Appliquez la sécurité de transport stricte pour le web en complément du MTA-STS
• Monitoring Authentification Email — Surveillez MTA-STS aux côtés de SPF, DKIM et DMARC
• TLS 1.2 vs TLS 1.3 — Comprenez les versions TLS que MTA-STS impose
• Implémenter une Politique DMARC — Complétez MTA-STS avec le reporting et l'application DMARC