MTA-STS : faut-il l’activer et comment éviter de casser le courrier entrant

Ce que MTA-STS fait réellement (et ce qu’il ne fait pas)

MTA-STS (Mail Transfer Agent Strict Transport Security) permet à un domaine récepteur d’indiquer aux MTA expéditeurs : « Quand vous livrez du courrier vers mes hôtes MX, utilisez TLS et validez les certificats ; si vous ne pouvez pas, n’allez pas en clair. » C’est essentiellement HSTS pour SMTP — sauf que SMTP est plus étrange, plus ancien, et a une longue tradition de livraison « au mieux ».

Mécaniquement, MTA-STS consiste en deux éléments :

1. Un enregistrement TXT DNS à _mta-sts.<domain> qui annonce l’« id » de la politique en cours.
2. Un fichier de politique HTTPS à https://mta-sts.<domain>/.well-known/mta-sts.txt décrivant les hôtes MX acceptables et le mode d’application.

Les expéditeurs qui prennent en charge MTA-STS récupèrent périodiquement votre politique via HTTPS, la mettent en cache, puis s’en servent pour décider de livrer, différer ou échouer la livraison lorsque le TLS n’est pas conforme.

Ce dont il vous protège

• Des attaques de dégradation opportuniste du TLS où un attaquant réseau supprime STARTTLS et force SMTP en clair.
• Certains scénarios de mauvais routage où la livraison finit sur un hôte sans certificat valide pour votre domaine.
• Les comportements « on a essayé TLS mais on accepte n’importe quoi » de certains expéditeurs ; MTA-STS les pousse vers une validation stricte pour votre domaine.

Ce dont il ne vous protège pas

• Serveur expéditeur ou récepteur compromis. Si le serveur de mail est compromis, MTA-STS n’aide pas beaucoup.
• Empoisonnement DNS au niveau du propriétaire du domaine. Si votre DNS est compromis, vous pouvez publier des politiques qui vous cassent ou vous redirigent.
• Intégrité du contenu du mail. C’est le domaine de DKIM/DMARC, pas du transport.
• Tous les MITM. MTA-STS s’appuie sur HTTPS et la confiance aux CA ; ce n’est pas équivalent à une authentification ancrée DNSSEC comme DANE.

Une subtilité opérationnelle : MTA-STS n’oblige pas vous à faire quoi que ce soit côté récepteur ; il oblige les expéditeurs à refuser la livraison si votre posture TLS ne correspond pas à ce que vous avez promis. Cela signifie que les échecs MTA-STS ressemblent souvent à « le courrier entrant s’est arrêté aléatoirement pour certains fournisseurs », ce qui est un classique en astreinte.

Une citation à tatouer sur chaque demande de changement : « L’espoir n’est pas une stratégie. » — Gene Kranz. Ce n’est pas spécifique au courriel, mais c’est douloureusement pertinent quand vous publiez « enforce » en espérant que tous les cas limites sont réglés.

Faut-il l’activer ?

Oui, si vous pouvez respecter deux exigences de base de façon cohérente :

• Vos hôtes MX supportent fiablement STARTTLS avec des chiffrements modernes et sans intermédiaires défaillants.
• Vos certificats sont valides, non expirés, correctement chaînés, et correspondent aux noms d’hôte MX déclarés dans votre politique.

Si cela vous semble trivial, tant mieux. Ça devrait l’être. Mais « fiablement » est là où se trouvent les cadavres : délestage TLS sur des load balancers, appliances legacy, MX de secours chez un tiers qui ne correspond pas à votre liste de noms, ou un chemin DR « temporaire » qui est temporaire depuis 2019.

Qui en bénéficie le plus

• Les domaines recevant des mails sensibles : paie, juridique, santé, finances, flux d’authentification clients.
• Organisations avec conformité stricte qui exigent déjà TLS partout et ont besoin d’une posture exécutoire de la part des expéditeurs.
• Ceux qui en ont assez du TLS opportuniste qui est « optionnel jusqu’à ce que ce ne le soit plus ».

Qui doit retarder le passage en « enforce »

• Domaines avec chemins entrants hétérogènes (plusieurs fournisseurs MX, on‑prem + cloud, passerelles legacy).
• Ceux sans automatisation des certificats et surveillance.
• Équipes incapables de répondre à « Que se passe‑t‑il si notre hôte de politique tombe ? » sans organiser une réunion.

Ma recommandation tranchée :

• Activez MTA-STS en mode: testing rapidement (jours), car c’est peu risqué et ça vous donne du signal.
• Restez en testing jusqu’à avoir des preuves : négociations TLS réussies depuis plusieurs réseaux, rotation propre des certificats, et situation de MX de secours clarifiée.
• Passez à mode: enforce uniquement après un test de bascule qui inclut le chemin mail. Si vous n’avez jamais testé une bascule MX en conditions réelles, vous n’avez pas de bascule ; vous avez un conte pour dormir.

Blague n°1 : La sécurité des e‑mails, c’est comme se brosser les dents : tout le monde dit que c’est bien, et beaucoup ne le font qu’après quelque chose de douloureux.

Faits et histoire intéressants (rapide mais utile)

• MTA-STS est une RFC IETF de 2018 (RFC 8461). C’est relativement jeune comparé à SMTP, d’où la grande variété des déploiements.
• SMTP STARTTLS a été normalisé en 2002 (RFC 3207). Pendant des années, la plupart des livraisons étaient « opportunistes » : utiliser TLS si proposé, sinon envoyer en clair.
• MTA-STS a été conçu en partie parce que le stripping de STARTTLS est réel. Ce n’est pas théorique ; des attaquants réseau peuvent altérer les capacités annoncées par le serveur.
• DANE pour SMTP existait auparavant et utilise DNSSEC pour authentifier les clés TLS. MTA-STS a pris la voie pragmatique : HTTPS + CA publiques, car l’adoption de DNSSEC pour le mail reste limitée.
• La politique est récupérée via HTTPS depuis un nom d’hôte fixe (mta-sts.<domain>). C’est pratique mais c’est aussi une dépendance opérationnelle à maintenir.
• Les politiques sont mises en cache par les expéditeurs, ce qui fait que vos erreurs peuvent persister et vos corrections prendre du temps à se propager. « On a réparé » n’est pas la même chose que « les expéditeurs ont invalidé le cache ».
• L’enregistrement DNS contient un « id » que vous incrémentez pour signaler les changements. C’est en pratique un mécanisme d’invalidation de cache pour les expéditeurs.
• TLS-RPT existe en tant que compagnon : un mécanisme de rapport où les expéditeurs peuvent vous signaler les échecs TLS. C’est le plus proche de l’observabilité que vous avez depuis l’extérieur.

Comment le courrier entrant casse avec MTA-STS

MTA-STS ne casse généralement pas le courrier immédiatement quand vous le publiez. La partie nasty est l’échec différé :

• Les expéditeurs récupèrent votre politique selon leur planning.
• Ils la mettent en cache pendant un certain temps.
• Ils ne l’appliquent qu’au moment de livrer chez vous.

Vous pouvez donc publier « enforce » aujourd’hui et découvrir les dégâts demain lorsqu’un expéditeur majeur rafraîchit la politique et refuse soudainement de livrer vers votre MX de secours qui est en réalité une appliance anti‑spam tierce dont le certificat a expiré en mai.

Carte des modes de panne (les suspects habituels)

• Incohérence de la liste MX : votre politique liste mx1.example.com et mx2.example.com, mais votre DNS annonce aussi mx-backup.vendor.net. Certains expéditeurs peuvent l’essayer ; la politique dit « non », et la livraison échoue en mode enforce.
• Échec de la négociation TLS : chiffrements non pris en charge, incompatibilité de version TLS, comportement SNI cassé, ou STARTTLS annoncé mais pas réellement fiable.
• Problèmes de certificat : certificat expiré, mauvais nom d’hôte, chaîne intermédiaire manquante, ou clé RSA trop petite pour les clients modernes.
• Load balancer malveillant : offload TLS qui ne transmet pas correctement le SNI ou présente un certificat par défaut à certains expéditeurs.
• Hôte de politique indisponible : mta-sts.example.com est down ou bloqué. Certains expéditeurs garderont la politique en cache ; d’autres peuvent traiter les échecs de façon différente. Ce n’est pas une dépendance à ignorer.
• Chemin DR inattendu : vous basculez le courrier entrant pendant un incident, mais l’hôte MX DR n’est pas dans la politique ou son certificat n’est pas validable. En enforce, la bascule devient une panne auto‑infligée.

Le thème : MTA-STS vous oblige à aligner ce que vous dîtes (politique) avec ce que vous faites (MX + réalité TLS). Le travail technique est gérable. Le travail organisationnel — inventorier tous les chemins entrants — est là où vous gagnez votre salaire.

Recette de diagnostic rapide

Quand quelqu’un dit « nous ne recevons pas d’e‑mails », vous pouvez passer des heures à débattre DMARC, filtrage anti‑spam et erreur utilisateur. Les pannes MTA-STS ont une odeur distincte : certains expéditeurs échouent, erreurs TLS dans leurs logs, et un changement récent de politique/certificat/DNS.

Première étape : confirmer si MTA-STS est en jeu

1. Vérifiez que l’enregistrement TXT _mta-sts du domaine existe et quel est le id.
2. Récupérez le fichier de politique et confirmez le mode et les motifs MX.
3. Recherchez un bump récent de l’id de politique ou un changement de certificat.

Deuxième étape : valider MX + TLS depuis l’extérieur

1. Résolvez les enregistrements MX et listez tous les hôtes. Comparez avec les lignes mx: de la politique.
2. Testez STARTTLS et la validation des certificats pour chaque hôte MX sur le port 25.
3. Confirmez la chaîne de certificats et que le nom d’hôte correspond à ce que l’expéditeur validera.

Troisième étape : corréler avec les échecs réels de livraison

1. Consultez vos logs SMTP pour tentatives de connexion, négociations STARTTLS et échecs.
2. Cherchez des codes d’alerte TLS, des échecs de handshake, ou « pas de chiffre partagé ».
3. Si vous publiez TLS-RPT, inspectez les rapports pour repérer des motifs : MX spécifique, version TLS précise, expéditeur particulier.

Si vous faites ces trois étapes, vous tomberez généralement sur : « politique trop stricte par rapport à la réalité », « certificat cassé », ou « MX changé sans mise à jour de la politique ». La correction devient alors simple.

Tâches pratiques : commandes, sorties, décisions (12+)

Voici les contrôles que j’exécute réellement quand je suis responsable de la réception. Chaque tâche inclut la commande, un exemple de sortie, ce que cela signifie et la décision à prendre.

Task 1: Check if MTA-STS is published in DNS

cr0x@server:~$ dig +short TXT _mta-sts.example.com
"v=STSv1; id=20260103T1200Z"

Ce que cela signifie : MTA-STS est activé pour example.com, et les expéditeurs mettront en cache la politique indexée par id.

Décision : Si le courrier échoue et que vous avez récemment modifié MX/TLS, vérifiez si le fichier de politique correspond à la réalité. Si vous devez pousser une nouvelle politique, vous devrez incrémenter le id après avoir mis à jour le fichier.

Task 2: Resolve MX records and inventory all inbound targets

cr0x@server:~$ dig +short MX example.com
10 mx1.example.com.
20 mx2.example.com.
50 mx-backup.vendor.net.

Ce que cela signifie : Il y a trois cibles de livraison, y compris un backup fournisseur.

Décision : Assurez‑vous que la politique inclut des motifs couvrant chaque nom d’hôte MX annoncé, ou retirez le MX que vous ne pouvez pas rendre conforme. En enforce, les MX « oubliés » deviennent des pannes.

Task 3: Fetch the MTA-STS policy file over HTTPS

cr0x@server:~$ curl -fsS https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

Ce que cela signifie : Le mode enforce est actif ; seuls mx1 et mx2 sont autorisés.

Décision : Si vous annoncez encore mx-backup.vendor.net en DNS, soit vous l’ajoutez à la politique (s’il peut valider), soit vous le retirez du MX pour éviter que les expéditeurs l’essaient et échouent.

Task 4: Verify the policy host certificate and chain

cr0x@server:~$ echo | openssl s_client -connect mta-sts.example.com:443 -servername mta-sts.example.com -showcerts 2>/dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN = mta-sts.example.com
issuer=C = US, O = Example CA, CN = Example Issuing CA 01
notBefore=Dec  1 00:00:00 2025 GMT
notAfter=Mar  1 23:59:59 2026 GMT

Ce que cela signifie : Le point d’accès HTTPS présente un cert pour le bon nom d’hôte et il n’est pas expiré.

Décision : Si les dates sont erronées ou si CN/SAN ne correspondent pas, corrigez le HTTPS d’abord. Les expéditeurs ne peuvent pas récupérer la politique de façon fiable si cela casse, et certains continueront à faire appliquer la politique mise en cache.

Task 5: Confirm that the policy file is served with HTTP 200 and sane headers

cr0x@server:~$ curl -sSI https://mta-sts.example.com/.well-known/mta-sts.txt | sed -n '1,8p'
HTTP/2 200
content-type: text/plain
cache-control: max-age=300
content-length: 104
date: Fri, 03 Jan 2026 12:15:11 GMT

Ce que cela signifie : Il est accessible et retourne du texte brut. Un cache court est acceptable ; les expéditeurs se basent toujours sur max_age dans la politique.

Décision : Si vous voyez des redirections vers un autre nom d’hôte, des challenges d’auth, ou des codes non‑200, corrigez cela. Restez basique : fichier texte statique, chemin stable, accès public.

Task 6: Validate STARTTLS and certificate verification to each MX

cr0x@server:~$ echo | openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com -verify_return_error 2>/dev/null | egrep -i "Verify return code|subject=|issuer="
subject=CN = mx1.example.com
issuer=C = US, O = Example CA, CN = Example Issuing CA 01
Verify return code: 0 (ok)

Ce que cela signifie : TLS se négocie et le certificat est validé pour mx1.

Décision : Répétez pour chaque MX. Si un MX échoue la validation, corrigez ce MX ou assurez‑vous qu’il n’est pas annoncé/autorisé quand enforce est activé.

Task 7: Check SMTP banner and STARTTLS support

cr0x@server:~$ printf 'EHLO test.example\r\nQUIT\r\n' | nc -w 5 mx2.example.com 25
220 mx2.example.com ESMTP Postfix
250-mx2.example.com
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250-8BITMIME
250-ENHANCEDSTATUSCODES
250 CHUNKING

Ce que cela signifie : Le serveur annonce STARTTLS. Bien.

Décision : Si STARTTLS n’est pas annoncé de façon cohérente (intermittent), vous avez un problème de load balancer ou de variance backend. MTA-STS amplifie cela en échecs de livraison sévères.

Task 8: Detect “default certificate” problems behind a load balancer (SNI)

cr0x@server:~$ echo | openssl s_client -starttls smtp -connect mx1.example.com:25 2>/dev/null | openssl x509 -noout -subject
subject=CN = lb-default.example.net

Ce que cela signifie : Sans SNI, le serveur présente un certificat par défaut qui ne correspond pas à mx1.example.com.

Décision : Beaucoup de MTAs n’envoient pas SNI sur SMTP STARTTLS. Ne comptez pas dessus. Corrigez le frontend pour présenter le certificat correct par défaut pour cet IP:port, ou dédiez des IP d’écoute par nom d’hôte.

Task 9: Confirm TLS versions and ciphers (spot legacy breakage)

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.example.com:25 -tls1_2 -brief /dev/null | egrep -i "Protocol|Ciphersuite|Verification"
Protocol version: TLSv1.2
Ciphersuite: ECDHE-RSA-AES256-GCM-SHA384
Verification: OK

Ce que cela signifie : TLS 1.2 fonctionne et vérifie.

Décision : Si seul TLS 1.0 fonctionne, les expéditeurs modernes peuvent refuser même sans MTA-STS. En enforce, vous exigez une validation stricte, donc modernisez votre pile TLS.

Task 10: Check Postfix TLS settings (receiver side)

cr0x@server:~$ postconf -n | egrep "smtpd_tls|smtpd_tls_security_level|smtpd_tls_cert_file|smtpd_tls_key_file"
smtpd_tls_security_level = may
smtpd_tls_cert_file = /etc/letsencrypt/live/mx1.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mx1.example.com/privkey.pem
smtpd_tls_loglevel = 1

Ce que cela signifie : Le serveur propose TLS (« may »), et vous voyez quel certificat il utilise.

Décision : Assurez‑vous que les chemins de certificat correspondent au nom d’hôte que vous annoncez. Si vous avez plusieurs noms MX sur un même serveur, vous ne pouvez pas présenter différents certificats sans une conception attentive des listeners/IP.

Task 11: Spot TLS failures in mail logs quickly

cr0x@server:~$ sudo grep -E "TLS|SSL|handshake|STARTTLS" /var/log/mail.log | tail -n 8
Jan  3 12:07:51 mx1 postfix/smtpd[18291]: warning: TLS library problem: error:0A000152:SSL routines::unsafe legacy renegotiation disabled
Jan  3 12:08:02 mx1 postfix/smtpd[18302]: warning: TLS library problem: error:0A0000C1:SSL routines::no shared cipher
Jan  3 12:08:15 mx1 postfix/smtpd[18310]: Anonymous TLS connection established from mail-oi1-f172.google.com[209.85.167.172]: TLSv1.3 with cipher TLS_AES_128_GCM_SHA256

Ce que cela signifie : Vous voyez des problèmes de chiffre/handshake avec certains clients, mais des succès avec d’autres. Cela indique une variance de compatibilité.

Décision : Décidez si vous élargissez le support de chiffrements (prudemment) ou si vous acceptez que certains expéditeurs legacy échouent en enforce. Si ces expéditeurs comptent, prévoyez un plan de compatibilité.

Task 12: Confirm policy id and caching behavior (did you bump id?)

cr0x@server:~$ dig +short TXT _mta-sts.example.com
"v=STSv1; id=20260103T1200Z"

Ce que cela signifie : Si vous avez modifié le fichier de politique mais pas l’id, beaucoup d’expéditeurs continueront d’utiliser la politique mise en cache jusqu’à expiration.

Décision : Quand vous changez mode ou les lignes mx, incrémentez id. Traitez‑le comme une version de configuration.

Task 13: Verify TLS-RPT is published (observability from the outside)

cr0x@server:~$ dig +short TXT _smtp._tls.example.com
"v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Ce que cela signifie : Les expéditeurs qui supportent le reporting TLS peuvent vous envoyer des rapports agrégés d’échecs.

Décision : Si vous allez enforce, publiez TLS-RPT et assurez‑vous que la boîte mail est surveillée. Sinon vous volez IFR sans instruments.

Task 14: Check the certificate actually contains the MX hostname in SAN

cr0x@server:~$ echo | openssl s_client -starttls smtp -connect mx2.example.com:25 -servername mx2.example.com 2>/dev/null | openssl x509 -noout -text | sed -n '/Subject Alternative Name/,+1p'
            X509v3 Subject Alternative Name:
                DNS:mx2.example.com, DNS:mx2.internal.example.com

Ce que cela signifie : Le certificat couvre le nom MX public. Bien.

Décision : Si le SAN n’inclut pas le nom MX public, corrigez l’émission du certificat. CN seul ne suffit pas pour beaucoup de validateurs modernes.

Task 15: Confirm the vendor backup MX can do validated TLS (or remove it)

cr0x@server:~$ echo | openssl s_client -starttls smtp -connect mx-backup.vendor.net:25 -verify_return_error 2>/dev/null | egrep -i "subject=|Verify return code"
subject=CN = mx-backup.vendor.net
Verify return code: 0 (ok)

Ce que cela signifie : Le MX du fournisseur supporte TLS validé pour son propre nom d’hôte. C’est nécessaire mais pas suffisant.

Décision : Vous devez décider d’inclure mx-backup.vendor.net dans votre politique MTA-STS. Si vous le gardez en DNS mais l’excluez de la politique en enforce, certaines livraisons échoueront quand les expéditeurs essaieront les MX de priorité inférieure.

Trois mini-histoires d’entreprise issues du terrain

1) L’incident causé par une fausse hypothèse : « Bien sûr que notre MX de secours est OK »

Une entreprise de taille moyenne avait une configuration mail propre : deux hôtes MX en active‑active, certificats automatisés, et un MX « de secours » pointant vers une passerelle d’hygiène tierce avec un numéro de priorité plus élevé. Ce secours était censé mettre en file le courrier si le site primaire tombait.

Ils ont déployé MTA-STS en mode: enforce après une revue sécurité. La politique ne listait que leurs deux MX principaux. L’hypothèse était simple : « Les expéditeurs essaieront le MX primaire d’abord ; le secours n’est qu’un filet de sécurité. »

Puis une fenêtre de maintenance a introduit un problème de routage de courte durée vers une plage d’IP d’un MX primaire depuis la région d’un expéditeur majeur. Pas une panne totale, juste une défaillance partielle de chemin. L’expéditeur a fait ce que SMTP est conçu pour faire : il a essayé les enregistrements MX alternatifs. Le choix suivant fut la passerelle d’hygiène du fournisseur.

En enforce, ce nom d’hôte fournisseur n’était pas autorisé. L’expéditeur a refusé la livraison plutôt que de « dégrader » vers un MX hors politique. Du point de vue de l’entreprise, le courrier entrant a échoué seulement pour certains expéditeurs, pour certains destinataires, pendant une fenêtre qui ne corrélait pas avec leur monitoring.

La correction n’a pas été héroïque. Ils ont dû soit retirer le MX fournisseur du DNS, soit l’inclure dans la politique et vérifier sa posture TLS. La leçon : le comportement de bascule SMTP n’est pas une caractéristique théorique ; c’est ce qui arrive quand Internet a un hoquet.

2) L’optimisation qui a mal tourné : « Mettons tout derrière une seule IP »

Une équipe mail d’entreprise a décidé de simplifier leur bordure : une VIP anycast en front de plusieurs noms MX, un fleet de load balancers, un seul bundle de certificats, moins de règles de firewall. Sur le papier c’était propre. Dans les diagrammes, c’était beau.

En réalité, STARTTLS SMTP ne se comporte pas comme le trafic HTTPS moderne. Certains MTA expéditeurs n’envoient pas SNI. D’autres se comportent de façon incohérente selon les versions. Le load balancer comptait sur le SNI pour choisir le certificat correct par nom d’hôte. Quand le SNI manquait, il servait un certificat par défaut qui ne correspondait pas au nom MX.

Avant MTA-STS, cela causait « certaines sessions TLS échouent, puis la livraison bascule en clair ». Moche, mais le mail arrivait. Après MTA-STS enforce, ces mêmes sessions sont devenues des échecs nets parce que l’expéditeur devait valider les certificats. L’optimisation n’a pas seulement échoué ; elle a échoué bruyamment et de façon sélective.

Ils ont abandonné le design : IP d’écoute dédiées par nom MX public, chacune présentant un certificat correspondant sans compter sur le SNI. Cela a coûté quelques IP supplémentaires et un peu plus de configuration. En retour ils ont obtenu une livraison fiable.

Blague n°2 : Le load balancer promettait « une vitre unique », il a livré « un point unique de tristesse ».

3) La pratique ennuyeuse mais correcte qui a sauvé la mise : « Traitez la politique comme une config avec pipeline de déploiement »

Une société financière a activé MTA-STS en mode testing tôt et y est restée plus longtemps que l’équipe sécurité ne le souhaitait. L’équipe mail a insisté sur des processus ennuyeux : un repo git pour le fichier de politique, revue par les pairs, et un petit job CI qui validait la syntaxe et comparait les entrées MX de la politique avec le DNS en direct.

Ils ont aussi automatisé les contrôles d’expiration des certificats pour chaque nom MX et pour l’hôte de politique. Pas « quelqu’un reçoit un mail 30 jours avant l’expiration », mais du monitoring réel connecté à de l’astreinte en heures ouvrées avec des runbooks clairs.

Quand une migration de datacenter a nécessité de changer les noms MX, ils ont fait une mise en scène : publier les nouveaux MX en parallèle des anciens, mettre à jour la politique MTA-STS pour inclure les deux, incrémenter l’id, attendre les fenêtres de cache, puis supprimer les anciennes entrées. Lent, délibéré, et un peu pénible.

Pendant la migration, un fournisseur a essayé « d’aider » en insérant un relais MX temporaire. Le contrôle CI a signalé que le nouveau MX n’était pas dans la politique et casserait enforce plus tard. Le changement a été intercepté avant d’atteindre le DNS de production.

Rien de dramatique ne s’est produit. C’est le point. En exploitation, le plus grand compliment est « c’était sans histoire », suivi de près par « personne n’a remarqué ».

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: Gmail/Microsoft met en attente la livraison avec des erreurs liées au TLS

Cause racine : Votre MX propose STARTTLS mais présente un certificat invalide (mauvais nom d’hôte, expiré, intermédiaire manquant) ou la négociation échoue de façon intermittente.

Correction : Validez avec openssl s_client -starttls smtp contre chaque MX. Assurez‑vous que le certificat présenté correspond au nom d’hôte MX et que la chaîne est complète. Corrigez le comportement du certificat par défaut du load balancer.

2) Symptom: Seuls certains expéditeurs échouent ; d’autres livrent normalement

Cause racine : Mise en cache de la politique et hétérogénéité des expéditeurs. Certains expéditeurs ont récupéré votre politique et l’appliquent ; d’autres ne l’ont pas encore, ou gèrent les échecs différemment. Alternativement, seuls certains expéditeurs atteignent le MX/IP problématique à cause du routage.

Correction : Identifiez quels expéditeurs échouent, puis reproduisez depuis des réseaux externes. Vérifiez TLS-RPT si disponible. Vérifiez chaque point de terminaison MX, pas seulement celui que vous voyez habituellement dans les logs.

3) Symptom: Le courrier échoue lors d’une bascule/maintenance mais fonctionne normalement

Cause racine : Votre MX DR/de secours n’est pas inclus dans la politique ou ne passe pas la validation TLS stricte.

Correction : Incluez le MX DR dans la politique et maintenez sa posture TLS conforme, ou n’annoncez pas ce MX en DNS. Testez la bascule sous enforce avant d’en avoir besoin.

4) Symptom: Vous avez mis à jour le fichier de politique mais les expéditeurs se comportent comme si c’était l’ancien

Cause racine : Vous avez oublié d’incrémenter l’id TXT DNS, donc les expéditeurs continuent d’utiliser la politique en cache.

Correction : Mettez à jour le fichier de politique, puis incrémentez l’id dans le DNS. Planifiez les délais de cache en fonction de max_age et du comportement des expéditeurs.

5) Symptom: La récupération de la politique échoue (404/redirect/auth) et l’application devient imprévisible

Cause racine : Votre hôte mta-sts est derrière des règles WAF, redirige HTTP→HTTPS incorrectement, nécessite une authentification, bloque certains user agents, ou a une disponibilité intermittente.

Correction : Servez la politique comme un simple fichier statique via HTTPS avec un cert valide. Évitez l’auth, évitez le géo‑blocage, évitez la « créativité ».

6) Symptom: Certains MTA se plaignent de « no shared cipher » ou d’alertes de version TLS

Cause racine : Configuration TLS trop durcie sur votre MX, ou pile TLS ancienne chez l’expéditeur. En enforce, certains expéditeurs échoueront plutôt que de dégrader.

Correction : Définissez des minimums business‑appropriés. Supportez largement TLS 1.2. Gardez des chiffrements modernes mais pas absurdement restrictifs. Surveillez qui échoue et si ces expéditeurs comptent.

7) Symptom: Tout semble correct, mais le courrier entrant échoue encore pour un sous‑ensemble de destinataires

Cause racine : Les enregistrements MX diffèrent par région à cause de DNS split‑horizon, redirection DNS CDN, ou caches résolveurs obsolètes renvoyant d’anciens MX. Votre politique peut ne pas couvrir toutes les variantes.

Correction : Interrogez des résolveurs publics depuis plusieurs régions (ou via votre monitoring). Assurez‑vous que la politique couvre tous les noms MX publics susceptibles d’être retournés.

Listes de contrôle / plan étape par étape (déploiement sûr)

Step 0: Inventory the real inbound mail path

• Listez tous les enregistrements MX (y compris « secours » et passerelles fournisseurs).
• Listez les proxies/load balancers SMTP entrants et comment les certificats sont présentés.
• Listez les scénarios DR/bascule et ce qui change au niveau des MX pendant un incident.

Step 1: Make TLS boring (before you publish enforce)

• Automatisez l’émission/le renouvellement des certificats pour chaque nom MX public.
• Assurez‑vous que la chaîne complète est servie (utilisez fullchain.pem quand nécessaire).
• Confirmez que STARTTLS est proposé de façon cohérente et fonctionne sur tous les backends.
• Évitez de compter sur SMTP SNI pour sélectionner les certificats. Préférez des listeners IP:port dédiés par nom d’hôte si nécessaire.

Step 2: Stand up the policy host correctly

• Fournissez mta-sts.<domain> dans le DNS avec un hébergement stable.
• Servez /.well-known/mta-sts.txt comme fichier statique en texte brut via HTTPS.
• Utilisez un certificat valide et n’empêchez pas l’accès avec des règles WAF qui traitent le monde comme hostile (les expéditeurs sont le monde).

Step 3: Publish MTA-STS in testing mode

Commencez par :

• mode: testing
• Motifs MX qui correspondent à tous vos hôtes MX entrants réels
• max_age réglé sur quelque chose de raisonnable (une semaine est courant ; plus court pendant l’itération initiale peut être raisonnable)

Puis publiez l’enregistrement TXT avec un id clair.

Step 4: Add TLS-RPT and actually read it

• Publiez le TXT _smtp._tls pointant les rapports vers une adresse surveillée.
• Mettez en place une règle de boîte ou une chaîne d’ingestion pour que les rapports ne pourrissent pas.
• Regardez : quel MX échoue, pourquoi (certificat vs handshake vs DNS), et si c’est consistant.

Step 5: Do a failover drill while still in testing

• Simulez la perte du MX primaire (ou un changement de routage) et observez quel MX les expéditeurs choisissent ensuite.
• Confirmez que le chemin alternatif est autorisé par la politique et valide TLS.
• Corrigez les dérives maintenant, pas pendant une panne.

Step 6: Move to enforce with a change window and rollback plan

• Mettez à jour le fichier de politique en mode: enforce.
• Incrémentez l’id dans le DNS.
• Surveillez les logs et TLS-RPT pendant au moins une fenêtre de cache.
• Plan de rollback : revenir en mode: testing et incrémenter l’id à nouveau si vous observez des pannes significatives.

Step 7: Keep it alive (the part everyone forgets)

• Surveillez l’expiration des certificats pour : chaque MX + l’hôte mta-sts.
• Surveillez la disponibilité HTTPS du fichier de politique.
• Traitez les changements de MX comme un changement couplé : DNS + politique + certificats, déployés ensemble.

FAQ

1) Will MTA-STS stop spam?

Non. MTA-STS concerne la sécurité du transport. Il aide à prévenir la dégradation TLS et fait appliquer la validation des certificats. Le contrôle du spam relève principalement de SPF/DKIM/DMARC et du filtrage.

2) Is MTA-STS redundant if we already use STARTTLS?

STARTTLS seul est généralement opportuniste : si TLS échoue, beaucoup d’expéditeurs retombent en clair. MTA-STS indique aux expéditeurs compatibles de ne pas retomber en arrière pour votre domaine.

3) Should we go straight to enforce?

Non, sauf si vous avez validé chaque point de terminaison MX, y compris les chemins DR et fournisseurs, et si vous avez automatisation des certificats et monitoring. Le mode testing est une assurance peu coûteuse.

4) What does the policy id actually do?

C’est un signal de version. Les expéditeurs mettent la politique en cache ; quand l’id change, ils savent qu’ils doivent récupérer une nouvelle politique. Si vous changez la politique sans changer l’id, beaucoup d’expéditeurs ne le remarqueront pas rapidement.

5) Can we list IP addresses in MTA-STS instead of hostnames?

Non. Les politiques MTA-STS correspondent aux noms d’hôte MX (avec motifs exacts ou jokers). C’est une des raisons pour lesquelles le comportement des load balancers et des certificats est si important.

6) What if our MX hostnames are managed by a vendor and change?

Alors vous avez besoin d’un contrat opérationnel : noms d’hôte stables, ou un processus pour mettre à jour la politique et incrémenter l’id de façon fiable. Si le fournisseur ne peut pas garantir la stabilité, le mode enforce devient une source récurrente d’incidents.

7) Does MTA-STS require DNSSEC?

Non. C’est une différence clé avec DANE. MTA-STS s’appuie sur HTTPS et l’écosystème des CA publiques pour l’authenticité de la politique.

8) If our policy host goes down, does mail stop?

Généralement non immédiatement, parce que les expéditeurs mettent la politique en cache. Mais cela crée de l’ambiguïté et des échecs différés. Gardez mta-sts.<domain> hautement disponible ; c’est un petit service à fort rayon d’impact.

9) What max_age should we use?

Des valeurs communes sont de l’ordre de jours à semaines. Des durées plus courtes réduisent la durée pendant laquelle les erreurs persistent mais augmentent la fréquence de fetch. Choisissez quelque chose que vous pouvez supporter opérationnellement, et souvenez‑vous que le cache varie selon les expéditeurs.

10) How do we “roll back” if enforce breaks inbound mail?

Mettez la politique en mode: testing (ou assouplissez temporairement les motifs MX), puis incrémentez l’id DNS. Attendez‑vous à ce que certains expéditeurs continuent d’appliquer la politique en cache jusqu’à leur actualisation.

Conclusion : prochaines étapes à livrer cette semaine

MTA-STS vaut le coup car le TLS opportuniste n’est pas une frontière de sécurité ; c’est une suggestion polie. Mais le mode enforce est une promesse, et l’Internet vous tiendra à cette promesse.

Prochaines étapes pratiques :

1. Inventoriez tous les cibles MX et comparez‑les à la réalité (fournisseurs et chemins DR inclus).
2. Mettez en place l’hôte de politique comme fichier HTTPS statique avec un certificat valide et une disponibilité sans surprise.
3. Publiez MTA-STS en mode testing avec des motifs MX corrects et un max_age raisonnable.
4. Validez STARTTLS + validation des certificats vers chaque MX depuis l’extérieur de votre réseau.
5. Publiez TLS-RPT et routez les rapports vers quelque chose de surveillé.
6. Faites un test de bascule pendant que vous êtes encore en testing. Corrigez ce qui casse. Puis passez en enforce avec un plan de rollback.

Si vous faites cela comme une modification de production — configuration versionnée, endpoints monitorés, bascule répétée — MTA-STS devient l’un des rares gains en sécurité e‑mail qui ne vous punira pas plus tard. Si vous le faites comme une case à cocher, il finira par vous réveiller à 2 h du matin et réclamer un sacrifice.