MTA-STS Checker gratuit

Pourquoi vérifier votre MTA-STS

Le transport SMTP utilise TLS de façon opportuniste : si le chiffrement échoue, la connexion bascule en clair sans alerte. Un attaquant en position de man-in-the-middle peut donc supprimer la bannière STARTTLS et forcer la transmission de vos emails en texte lisible.

MTA-STS (RFC 8461) corrige cette faille. Il publie une politique HTTPS signée par PKI qui demande aux MTAs émetteurs de refuser toute connexion sans TLS valide. C'est la couche manquante pour fermer la porte au downgrade et au spoofing TLS.

Vérifier votre configuration avant de la passer en enforce est essentiel :

• Politique cassée → les emails légitimes peuvent être bloqués
• Patterns MX incomplets → certains serveurs restent vulnérables
• Certificat expiré → la politique devient invalide, les MTAs émetteurs reviennent à TLS opportuniste

Cas d'usage courants :

• Après publication → confirmer que DNS, politique HTTPS et TLS sont cohérents
• Avant mode: enforce → s'assurer qu'aucun MX légitime n'est exclu
• Audit de sécurité → valider la protection contre le downgrade TLS

Comment utiliser ce checker en 3 étapes

Étape 1 : entrer le domaine à analyser

Saisissez le domaine exactement comme il apparaît dans vos adresses email :

• captaindns.com (domaine principal)
• marketing.captaindns.com (sous-domaine si vous envoyez depuis un sous-domaine)

L'outil interroge automatiquement _mta-sts.domaine, récupère le fichier https://mta-sts.domaine/.well-known/mta-sts.txt et compare les patterns aux enregistrements MX.

Étape 2 : analyser les résultats

Le checker affiche :

Étape 3 : corriger les problèmes flaggés

Les résultats sont classés par gravité :

• Critique → la politique est inutilisable, les MTAs émetteurs l'ignorent
• Avertissement → fonctionne, mais expose à un risque ou à une protection partielle
• Info → bonne pratique non bloquante

Corrigez le DNS ou le fichier de politique, attendez la propagation, puis relancez le checker.

Qu'est-ce que MTA-STS ?

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) est un mécanisme qui :

1. Publie une politique HTTPS indiquant quels hôtes MX acceptent TLS
2. Force le chiffrement TLS entre MTAs émetteurs et récepteurs
3. Bloque les attaques de downgrade qui suppriment STARTTLS

L'architecture s'appuie sur trois éléments combinés :

Exemple d'enregistrement DNS :

_mta-sts.captaindns.com. IN TXT "v=STSv1; id=20260501T000000Z"

Exemple de politique :

version: STSv1
mode: enforce
mx: mail.captaindns.com
mx: *.mail.captaindns.com
max_age: 604800

Différence avec DANE : MTA-STS s'appuie sur la PKI publique (autorités de certification), DANE s'appuie sur DNSSEC et les enregistrements TLSA. Les deux mécanismes sont compatibles et peuvent être déployés ensemble.

Ce que vérifie le checker

Sept dimensions sont analysées en parallèle pour produire un score 0-100 :

Enregistrement DNS publié

Récupération du fichier de politique

Syntaxe de la politique

Couverture des serveurs MX

Tous les MX résolus pour le domaine doivent correspondre à au moins un pattern :

• Correspondance directe : mx: mail.captaindns.com couvre mail.captaindns.com
• Wildcard limité à un label : *.mail.captaindns.com couvre eu.mail.captaindns.com mais pas mail.captaindns.com

Validité du certificat TLS

Le sous-domaine mta-sts.domaine est sondé en HTTPS :

• Certificat non expiré
• Nom d'hôte présent dans SAN
• Chaîne complète jusqu'à une CA reconnue
• Version TLS récente (1.2 minimum)

Cohérence DNS et politique

L'ID DNS et l'ID de la politique servie doivent correspondre. Un décalage indique une mise à jour partielle dangereuse pour le cache des MTAs émetteurs.

Présence de TLS-RPT

Le checker signale l'absence d'enregistrement _smtp._tls (TLS-RPT, RFC 8460). Sans TLS-RPT, vous ne saurez jamais si la politique provoque des échecs de livraison silencieux.

Diagnostics courants et solutions

Politique inaccessible (policy_fetch_failed)

Cause : le sous-domaine mta-sts.domaine ne répond pas, ne sert pas HTTPS, ou retourne une erreur HTTP.

Solutions :

1. Vérifier que mta-sts.domaine résout en DNS (A ou CNAME)
2. Confirmer qu'un certificat TLS valide est servi (Let's Encrypt, autocert, etc.)
3. Confirmer que /.well-known/mta-sts.txt retourne 200 OK en text/plain

Certificat TLS invalide (cert_invalid)

Cause : certificat expiré, auto-signé, nom d'hôte non couvert par le SAN, ou chaîne incomplète.

Solutions :

1. Renouveler le certificat avant expiration
2. Inclure mta-sts.domaine dans le SAN
3. Servir la chaîne intermédiaire complète

Enregistrement DNS absent (missing_record)

Cause : aucun TXT n'existe sur _mta-sts.domaine.

Solution : publier

_mta-sts.captaindns.com. IN TXT "v=STSv1; id=20260501T000000Z"

Politique désactivée (mode_none)

Cause : mode: none indique que MTA-STS est annoncé mais sans effet.

Solution : passer en mode: testing après publication initiale, puis en mode: enforce quand TLS-RPT est propre.

Couverture MX incomplète (mx_partial_match)

Cause : un ou plusieurs MX résolus ne correspondent à aucun pattern de la politique.

Solution : lister explicitement chaque hôte MX ou utiliser un wildcard plus large adapté à votre infrastructure.

Absence de TLS-RPT (tls_rpt_missing)

Cause : aucun enregistrement _smtp._tls.domaine n'est publié.

Solution : publier

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

Progression testing vers enforce

Phase 1 : publication initiale en mode testing

version: STSv1
mode: testing
mx: mail.captaindns.com
max_age: 86400

• Les MTAs émetteurs signalent les échecs TLS via TLS-RPT sans bloquer la livraison
• Maintenez max_age court (1 à 7 jours) pour itérer rapidement
• Collectez les rapports TLS-RPT pendant 2 à 4 semaines

Phase 2 : stabilisation et observation

Pendant cette période, vérifiez :

• Aucun MX légitime exclu (TLS-RPT signalerait des échecs mx-mismatch)
• Aucun problème de certificat sur les hôtes MX (TLS-RPT signalerait certificate-not-trusted)
• Aucun MTA émetteur en difficulté (rapports vides ou nuls)

Phase 3 : passage en mode enforce

version: STSv1
mode: enforce
mx: mail.captaindns.com
max_age: 604800

• Allongez max_age (7 jours minimum, jusqu'à 1 an)
• Surveillez TLS-RPT en continu : les échecs deviennent désormais des non-livraisons
• Préparez un plan de rollback (revenir en testing rapidement si besoin)

Pièges fréquents :

• max_age trop court → les MTAs émetteurs re-fetchent la politique trop souvent, charge inutile
• max_age trop long → un changement de MX prend des semaines à se propager
• Patterns MX incomplets → certains emails légitimes sont rejetés silencieusement

MTA-STS vs DANE

Les deux mécanismes protègent le transport SMTP contre les attaques de downgrade, mais avec des approches différentes.

Quand choisir MTA-STS : vous n'avez pas DNSSEC, ou vous voulez une mise en œuvre rapide avec un effort opérationnel minimal.

Quand choisir DANE : votre domaine est déjà signé DNSSEC et vous voulez la garantie supplémentaire du pinning cryptographique.

Les deux sont compatibles et peuvent être déployés en parallèle. Les MTAs émetteurs choisissent celui qu'ils savent gérer.

Outils complémentaires et ressources

Ressources :

• MTA-STS : le guide complet pour sécuriser le transport de vos emails
• Guide de dépannage MTA-STS
• Passer MTA-STS de testing à enforce
• MTA-STS vs DANE : comparatif
• TLS-RPT : le guide complet
• RFC 8461 - SMTP MTA Strict Transport Security
• RFC 8460 - SMTP TLS Reporting