MTA-STS ne fonctionne pas ? Guide de dépannage complet

Q: Pourquoi ma politique MTA-STS n'est-elle pas récupérée ?

Le fichier mta-sts.txt doit être accessible à l'URL exacte https://mta-sts.captaindns.com/.well-known/mta-sts.txt . Vérifiez que le sous-domaine mta-sts résout correctement (CNAME ou A record), que le certificat TLS est valide, et que le serveur répond avec un code 200 et le Content-Type text/plain . Les redirections HTTP vers HTTPS ne sont pas acceptées par tous les clients.

Q: Que signifie l'erreur 'MX non couvert par la politique' ?

Votre serveur MX réel ne correspond à aucun pattern mx: dans le fichier de politique. Par exemple, si votre MX est captaindns-com.mail.protection.outlook.com mais que la politique contient mx: mail.protection.outlook.com (sans wildcard), le serveur émetteur considère que le MX n'est pas autorisé. Ajoutez le wildcard : mx: *.mail.protection.outlook.com .

Q: Pourquoi le mode enforce bloque-t-il des emails ?

En mode enforce , les serveurs émetteurs rejettent l'envoi si la politique MTA-STS ne peut pas être satisfaite (certificat invalide, MX non couvert, politique inaccessible). Repassez immédiatement en mode testing , mettez à jour le champ id du record DNS, et analysez les rapports TLS-RPT pour identifier la cause exacte avant de revenir en enforce.

Par CaptainDNS
Publié le 9 février 2026

Dépannage MTA-STS : diagnostic et résolution des erreurs courantes

TL;DR

Vérifiez d'abord les trois fondamentaux : record DNS _mta-sts, fichier de politique accessible en HTTPS, et certificat TLS valide sur le sous-domaine mta-sts
L'erreur sts-policy-fetch-error signifie que le fichier mta-sts.txt est inaccessible — vérifiez l'hébergement, le DNS et le certificat du sous-domaine
Les rapports TLS-RPT identifient précisément le type d'échec (certificate-expired, validation-failure, sts-webpki-invalid) pour guider le diagnostic
En cas d'urgence avec le mode enforce, repassez immédiatement en testing et mettez à jour le champ id du record DNS

Vous avez déployé MTA-STS sur votre domaine en suivant toutes les étapes : record DNS publié, fichier de politique hébergé, TLS-RPT activé. Pourtant, les rapports signalent des échecs, le vérificateur affiche des erreurs, ou pire, des emails sont rejetés en mode enforce.

MTA-STS implique plusieurs composants qui doivent fonctionner ensemble : un record DNS TXT, un fichier de politique servi en HTTPS sur un sous-domaine spécifique, des certificats TLS valides, et des patterns MX qui correspondent exactement à vos serveurs. Un seul maillon défaillant suffit à casser la chaîne.

Ce guide de dépannage couvre les erreurs les plus fréquentes, leurs causes et les commandes pour les diagnostiquer. Que vous utilisiez Microsoft 365, Google Workspace ou Cloudflare pour l'hébergement, vous trouverez la solution à votre problème. Si vous n'avez pas encore déployé MTA-STS, consultez d'abord notre guide complet MTA-STS.

Diagnostic rapide : vérifier votre configuration MTA-STS

Avant de chercher un problème spécifique, vérifiez ces trois fondamentaux dans l'ordre. La majorité des problèmes MTA-STS viennent de l'un de ces trois points.

Étape 1 : Vérifier le record DNS _mta-sts

Le record TXT à _mta-sts.captaindns.com doit exister et contenir une valeur valide :

dig TXT _mta-sts.captaindns.com +short
# Résultat attendu : "v=STSv1; id=20260208120000"

Problèmes courants :

Aucun résultat → le record n'existe pas ou n'est pas encore propagé
v=STS1 au lieu de v=STSv1 → faute de frappe dans la version
Absence du champ id → champ obligatoire manquant

Étape 2 : Vérifier le fichier de politique

Le fichier doit être accessible à l'URL exacte https://mta-sts.captaindns.com/.well-known/mta-sts.txt :

curl -v https://mta-sts.captaindns.com/.well-known/mta-sts.txt

Vérifications :

Code HTTP 200 (pas 301, 302, 403 ou 404)
Content-Type text/plain (pas text/html)
Contenu valide avec version: STSv1, mode:, mx: et max_age:
Pas de redirection HTTP → HTTPS (le serveur doit répondre directement en HTTPS)

Étape 3 : Vérifier le certificat TLS

Le sous-domaine mta-sts.captaindns.com doit avoir un certificat TLS valide :

openssl s_client -connect mta-sts.captaindns.com:443 -servername mta-sts.captaindns.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject

Vérifications :

Le certificat n'est pas expiré (notAfter dans le futur)
Le certificat couvre bien mta-sts.captaindns.com (dans le CN ou SAN)
La chaîne de certificats est complète (pas d'erreur unable to verify)

Checklist de diagnostic MTA-STS : record DNS, fichier de politique et certificat TLS

Erreurs courantes et solutions

Erreur "Policy not found" (sts-policy-fetch-error)

C'est l'erreur la plus fréquente dans les rapports TLS-RPT. Elle signifie que le serveur émetteur n'a pas pu récupérer votre fichier de politique.

Cause	Commande de diagnostic	Solution
Fichier absent	`curl -I https://mta-sts.captaindns.com/.well-known/mta-sts.txt`	Créer et héberger le fichier
DNS mal configuré	`dig A mta-sts.captaindns.com +short`	Vérifier le CNAME ou A record
Redirection HTTP	`curl -v http://mta-sts.captaindns.com/.well-known/mta-sts.txt`	Configurer HTTPS directement
Certificat invalide	`curl -vI https://mta-sts.captaindns.com/`	Renouveler ou corriger le certificat
Cloudflare en pause	Vérifier le dashboard Cloudflare	Réactiver le proxy ou le Worker

Erreur "Certificate mismatch" (certificate-host-mismatch)

Le certificat TLS d'un serveur MX ne correspond pas au nom d'hôte MX. Ce n'est pas le certificat du sous-domaine mta-sts, mais celui du serveur MX lui-même.

# Vérifier le certificat d'un serveur MX
openssl s_client -connect captaindns-com.mail.protection.outlook.com:25 -starttls smtp -servername captaindns-com.mail.protection.outlook.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

Avec Microsoft 365 ou Google Workspace : ce problème ne devrait pas se produire car Microsoft et Google gèrent les certificats de leurs MX. Si vous le voyez, vérifiez que vos patterns MX dans la politique correspondent bien à vos MX réels.

Erreur "MX not covered by policy"

Le serveur MX de votre domaine ne correspond à aucun pattern mx: dans le fichier de politique. C'est souvent une erreur de wildcard.

# Lister vos MX
dig MX captaindns.com +short

# Comparer avec la politique
curl -s https://mta-sts.captaindns.com/.well-known/mta-sts.txt | grep "^mx:"

Causes courantes :

Situation	Pattern incorrect	Pattern correct
Microsoft 365	`mx: mail.protection.outlook.com`	`mx: *.mail.protection.outlook.com`
Google Workspace	`mx: *.google.com` (seul)	`mx: .google.com` + `mx: .googlemail.com`
MX personnalisé	Pattern wildcard trop restrictif	Vérifier chaque MX individuellement

Erreur "Certificate expired" (certificate-expired)

Un certificat TLS a expiré sur l'un de vos serveurs MX ou sur le sous-domaine mta-sts.

# Vérifier la date d'expiration du certificat mta-sts
echo | openssl s_client -connect mta-sts.captaindns.com:443 -servername mta-sts.captaindns.com 2>/dev/null | openssl x509 -noout -enddate

Si c'est le sous-domaine mta-sts : renouvelez le certificat via votre hébergeur (Cloudflare le fait automatiquement). Si c'est un serveur MX : avec Microsoft 365 ou Google Workspace, le renouvellement est automatique. Pour un MX auto-hébergé, renouvelez le certificat via Let's Encrypt ou votre autorité de certification.

Erreur "Validation failure" (validation-failure)

La chaîne de certificats est incomplète : le certificat racine ou un certificat intermédiaire manque.

# Tester la chaîne complète
openssl s_client -connect mta-sts.captaindns.com:443 -servername mta-sts.captaindns.com </dev/null 2>&1 | grep "Verify return code"
# Résultat attendu : Verify return code: 0 (ok)

Si le code de retour n'est pas 0, installez les certificats intermédiaires manquants sur votre serveur.

Problèmes spécifiques par fournisseur

Microsoft 365

Problème	Cause	Solution
MX non couvert	Pattern sans wildcard	Utiliser `mx: *.mail.protection.outlook.com`
Rapports TLS-RPT vides	M365 envoie les rapports avec un délai	Attendre 48-72h après activation
Certificat MX en erreur	Rare (géré par Microsoft)	Contacter le support Microsoft

Google Workspace

Problème	Cause	Solution
MX partiellement couverts	Un seul pattern `mx:`	Ajouter `mx: .google.com` ET `mx: .googlemail.com`
Rapports TLS-RPT incomplets	Google agrège sur 24h	Attendre le rapport complet du lendemain
Changement de MX Google	Migration vers de nouveaux MX	Vérifier les MX actuels avec `dig MX`

Cloudflare Pages / Workers

Problème	Cause	Solution
404 sur mta-sts.txt	Mauvais chemin dans le dépôt	Le fichier doit être dans `.well-known/mta-sts.txt`
Certificat TLS absent	Domaine personnalisé non configuré	Ajouter `mta-sts.captaindns.com` dans Custom Domains
Worker ne répond pas	Route mal configurée	Vérifier que la route `mta-sts.captaindns.com/*` est active
Content-Type incorrect	Worker renvoie `text/html`	Forcer `Content-Type: text/plain` dans la Response
DNS non résolu	CNAME manquant	Ajouter le CNAME vers le projet Pages ou l'AAAA `100::` pour Workers

Lire et interpréter les rapports TLS-RPT

Les rapports TLS-RPT envoyés par les fournisseurs email contiennent les détails des échecs TLS. Voici comment les lire.

Structure d'un rapport TLS-RPT

Un rapport JSON typique contient :

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-02-08T00:00:00Z",
    "end-datetime": "2026-02-08T23:59:59Z"
  },
  "policies": [{
    "policy": {
      "policy-type": "sts",
      "policy-domain": "captaindns.com"
    },
    "summary": {
      "total-successful-session-count": 150,
      "total-failure-session-count": 2
    },
    "failure-details": [{
      "result-type": "certificate-host-mismatch",
      "sending-mta-ip": "209.85.220.41",
      "receiving-mx-hostname": "captaindns-com.mail.protection.outlook.com",
      "failed-session-count": 2
    }]
  }]
}

Tableau de correspondance des erreurs TLS-RPT

Code TLS-RPT	Signification	Gravité	Action
`starttls-not-supported`	Le MX ne supporte pas STARTTLS	Critique	Activer TLS sur le serveur MX
`certificate-host-mismatch`	Le certificat ne correspond pas au MX	Haute	Vérifier le SAN du certificat
`certificate-expired`	Certificat expiré	Haute	Renouveler immédiatement
`certificate-not-trusted`	Certificat auto-signé ou CA inconnue	Haute	Utiliser un certificat d'une CA reconnue
`validation-failure`	Chaîne de certificats incomplète	Haute	Installer les certificats intermédiaires
`sts-policy-fetch-error`	Fichier mta-sts.txt inaccessible	Haute	Vérifier l'hébergement
`sts-policy-invalid`	Contenu de la politique invalide	Haute	Corriger la syntaxe
`sts-webpki-invalid`	Certificat du sous-domaine mta-sts invalide	Haute	Renouveler le certificat

Flux de diagnostic des erreurs TLS-RPT : de l'erreur à la solution

Le mode enforce bloque des emails : que faire ?

Si vous êtes passé en mode enforce et que des emails légitimes sont rejetés, agissez immédiatement :

1. Retour d'urgence en mode testing

Modifiez le fichier de politique :

version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 86400

2. Mettre à jour le record DNS

Changez le champ id pour forcer les serveurs émetteurs à re-télécharger la politique :

_mta-sts.captaindns.com. 300 IN TXT "v=STSv1; id=20260208180000"

3. Temps de propagation

Les serveurs émetteurs mettent en cache votre politique pendant la durée du max_age précédent. Si vous aviez max_age: 2592000 (30 jours), certains serveurs pourraient ne pas re-télécharger la politique pendant 30 jours. C'est pourquoi il est recommandé d'augmenter max_age progressivement :

Phase	max_age	Durée	Usage
Testing initial	`86400`	24 heures	Permet un retour rapide
Testing avancé	`604800`	7 jours	Après 2 semaines sans erreur
Enforce prudent	`604800`	7 jours	Premières semaines en enforce
Enforce stable	`2592000`	30 jours	Après 1 mois en enforce sans problème

Commandes de diagnostic essentielles

Voici les commandes à garder sous la main pour diagnostiquer tout problème MTA-STS :

# 1. Vérifier le record DNS MTA-STS
dig TXT _mta-sts.captaindns.com +short

# 2. Vérifier le record TLS-RPT
dig TXT _smtp._tls.captaindns.com +short

# 3. Récupérer le fichier de politique
curl -s https://mta-sts.captaindns.com/.well-known/mta-sts.txt

# 4. Vérifier les headers HTTP du fichier de politique
curl -I https://mta-sts.captaindns.com/.well-known/mta-sts.txt

# 5. Lister les serveurs MX
dig MX captaindns.com +short

# 6. Vérifier le certificat du sous-domaine mta-sts
echo | openssl s_client -connect mta-sts.captaindns.com:443 -servername mta-sts.captaindns.com 2>/dev/null | openssl x509 -noout -dates -subject

# 7. Tester la connexion STARTTLS sur un MX
openssl s_client -connect captaindns-com.mail.protection.outlook.com:25 -starttls smtp -servername captaindns-com.mail.protection.outlook.com </dev/null 2>/dev/null | openssl x509 -noout -dates

Plan d'action recommandé

Identifiez le problème : Utilisez le vérificateur MTA-STS CaptainDNS pour un diagnostic automatique complet
Vérifiez les trois fondamentaux : Record DNS, fichier de politique, certificat TLS (dans cet ordre)
Consultez les rapports TLS-RPT : Le champ result-type vous indique exactement ce qui échoue
Corrigez le problème identifié : Suivez les solutions de la section correspondante ci-dessus
Validez la correction : Utilisez le validateur de syntaxe MTA-STS pour confirmer que la politique est correcte
Surveillez pendant 48h : Vérifiez que les rapports TLS-RPT ne signalent plus l'erreur

Vérifiez votre configuration MTA-STS maintenant : Utilisez notre vérificateur MTA-STS pour diagnostiquer votre domaine en quelques secondes.

FAQ

Pourquoi ma politique MTA-STS n'est-elle pas récupérée ?

Le fichier mta-sts.txt doit être accessible à l'URL exacte https://mta-sts.captaindns.com/.well-known/mta-sts.txt. Vérifiez que le sous-domaine mta-sts résout correctement (CNAME ou A record), que le certificat TLS est valide, et que le serveur répond avec un code 200 et le Content-Type text/plain. Les redirections HTTP vers HTTPS ne sont pas acceptées par tous les clients.

Que signifie l'erreur 'MX non couvert par la politique' ?

Votre serveur MX réel ne correspond à aucun pattern mx: dans le fichier de politique. Par exemple, si votre MX est captaindns-com.mail.protection.outlook.com mais que la politique contient mx: mail.protection.outlook.com (sans wildcard), le serveur émetteur considère que le MX n'est pas autorisé. Ajoutez le wildcard : mx: *.mail.protection.outlook.com.

Comment corriger une erreur de certificat TLS sur MTA-STS ?

Identifiez d'abord quel certificat est en cause. Si c'est le certificat du sous-domaine mta-sts : renouvelez-le via votre hébergeur (Cloudflare le renouvelle automatiquement). Si c'est le certificat d'un serveur MX : avec Microsoft 365 ou Google Workspace, c'est géré automatiquement. Pour un MX auto-hébergé, vérifiez la chaîne de certificats complète et la date d'expiration.

Pourquoi le mode enforce bloque-t-il des emails ?

En mode enforce, les serveurs émetteurs rejettent l'envoi si la politique MTA-STS ne peut pas être satisfaite (certificat invalide, MX non couvert, politique inaccessible). Repassez immédiatement en mode testing, mettez à jour le champ id du record DNS, et analysez les rapports TLS-RPT pour identifier la cause exacte avant de revenir en enforce.

Comment revenir en mode testing en urgence ?

Modifiez le fichier mta-sts.txt en remplaçant mode: enforce par mode: testing. Mettez ensuite à jour le champ id du record DNS TXT _mta-sts avec un nouvel horodatage. Les serveurs émetteurs re-téléchargeront la politique et cesseront de rejeter les emails. Le délai dépend du max_age précédent.

Comment lire un rapport TLS-RPT ?

Les rapports TLS-RPT sont des fichiers JSON envoyés quotidiennement à l'adresse spécifiée dans votre record _smtp._tls. Le champ result-type indique le type d'erreur (certificate-expired, sts-policy-fetch-error, etc.), receiving-mx-hostname identifie le serveur MX concerné, et failed-session-count donne le nombre d'échecs.

MTA-STS ne fonctionne pas avec Cloudflare Workers : que vérifier ?

Vérifiez que la route mta-sts.captaindns.com/* est configurée dans le Worker, que le DNS contient un enregistrement AAAA mta-sts pointant vers 100:: (proxied), et que le Worker retourne le Content-Type text/plain; charset=utf-8. Testez avec curl -I https://mta-sts.captaindns.com/.well-known/mta-sts.txt pour confirmer le code 200 et les headers.

Combien de temps faut-il attendre avant que les corrections prennent effet ?

Les serveurs émetteurs mettent en cache votre politique pendant la durée du max_age. Si vous aviez max_age: 86400 (24h), la correction sera effective en 24h maximum. Si vous aviez max_age: 2592000 (30 jours), certains serveurs pourraient ne pas voir la correction pendant 30 jours. C'est pourquoi il est recommandé de garder un max_age court en phase de test.

Glossaire

MTA-STS : Mail Transfer Agent Strict Transport Security. Standard RFC 8461 imposant le chiffrement TLS pour la réception d'emails.
TLS-RPT : SMTP TLS Reporting (RFC 8460). Mécanisme de rapport quotidien sur les succès et échecs de négociation TLS.
sts-policy-fetch-error : Code d'erreur TLS-RPT indiquant que le fichier de politique mta-sts.txt n'a pas pu être récupéré par le serveur émetteur.
max_age : Directive de la politique MTA-STS indiquant la durée de mise en cache en secondes. Détermine le délai de propagation des modifications.
STARTTLS : Extension SMTP permettant de chiffrer la connexion entre serveurs email. MTA-STS impose son utilisation avec un certificat valide.