Configurer MTA-STS pour Microsoft 365 et Google Workspace

⚡TL;DR

• Microsoft 365 utilise le pattern MX *.mail.protection.outlook.com dans la politique MTA-STS ; Google Workspace nécessite les patterns *.google.com et *.googlemail.com
• Le fichier de politique mta-sts.txt doit être hébergé en HTTPS sur le sous-domaine mta-sts de votre domaine, avec un certificat TLS valide
• Cloudflare Pages ou Cloudflare Workers permettent d'héberger gratuitement le fichier de politique avec HTTPS automatique
• Toujours déployer en mode testing avec TLS-RPT actif avant de passer en mode enforce

Vous utilisez Microsoft 365 ou Google Workspace pour vos emails professionnels. Vos serveurs MX sont correctement configurés, SPF, DKIM et DMARC sont en place. Mais le transport entre serveurs SMTP reste vulnérable : sans MTA-STS, un attaquant peut forcer une connexion en clair et intercepter vos messages.

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) résout ce problème en imposant le chiffrement TLS pour la réception d'emails. Le principe est simple : vous publiez un record DNS et un fichier de politique qui déclarent vos serveurs MX autorisés et exigent une connexion TLS valide.

Ce tutoriel vous guide pas à pas pour déployer MTA-STS sur Microsoft 365, Google Workspace et Cloudflare. Chaque section contient les patterns MX exacts, les fichiers de configuration prêts à copier, et les commandes de validation. Si vous découvrez MTA-STS, consultez d'abord notre guide complet MTA-STS pour comprendre le fonctionnement du protocole (voir la section Guides connexes en fin d'article).

Prérequis communs à tous les fournisseurs

Avant de configurer MTA-STS, vérifiez ces trois points pour votre domaine :

1. Certificats TLS valides sur vos MX

Tous vos serveurs MX doivent disposer d'un certificat TLS valide (TLS 1.2 minimum). Avec Microsoft 365 et Google Workspace, c'est le cas par défaut : Microsoft et Google gèrent les certificats de leurs serveurs MX.

2. Accès à votre zone DNS

Vous devez pouvoir créer un enregistrement TXT à _mta-sts.captaindns.com et un enregistrement CNAME ou A pour le sous-domaine mta-sts.captaindns.com.

3. Hébergement HTTPS pour le fichier de politique

Le fichier mta-sts.txt doit être accessible à l'URL exacte https://mta-sts.captaindns.com/.well-known/mta-sts.txt. Vous avez besoin d'un hébergement HTTPS avec un certificat valide pour le sous-domaine mta-sts.

MTA-STS pour Microsoft 365 / Office 365

Le pattern MX Microsoft 365

Microsoft 365 utilise des serveurs MX de la forme captaindns-com.mail.protection.outlook.com. Le pattern wildcard correspondant pour votre politique MTA-STS est :

*.mail.protection.outlook.com

Ce pattern couvre tous les serveurs MX Microsoft 365, y compris les variations régionales et les configurations avec Exchange Online Protection (EOP).

Pour vérifier vos MX Microsoft 365 :

dig MX captaindns.com +short
# Résultat attendu : 0 captaindns-com.mail.protection.outlook.com.

Fichier de politique pour Microsoft 365

Créez le fichier mta-sts.txt avec le contenu suivant :

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

Directive	Valeur	Explication
version	STSv1	Version du protocole
mode	testing	Surveillance sans blocage (phase initiale)
mx	*.mail.protection.outlook.com	Couvre tous les MX Microsoft 365
max_age	86400	Cache de 24h (adapté au testing)

Record DNS pour Microsoft 365

Ajoutez cet enregistrement TXT dans votre zone DNS :

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

Le champ id doit être mis à jour à chaque modification de la politique. Utilisez un horodatage au format YYYYMMDDHHMMSS pour faciliter le suivi.

Microsoft 365 supporte-t-il MTA-STS ?

Microsoft supporte MTA-STS en émission : quand un serveur Microsoft 365 envoie un email, il vérifie la politique MTA-STS du domaine destinataire. Microsoft supporte aussi MTA-STS en réception : vous pouvez publier une politique pour votre domaine hébergé sur Microsoft 365, et les serveurs émetteurs la respecteront.

MTA-STS pour Google Workspace

Les patterns MX Google Workspace

Google Workspace utilise plusieurs serveurs MX avec des noms variés. Les patterns à inclure dans votre politique MTA-STS sont :

*.google.com
*.googlemail.com

Ces deux patterns couvrent l'ensemble des serveurs MX Google Workspace, incluant :

Serveur MX	Priorité
aspmx.l.google.com	1
alt1.aspmx.l.google.com	5
alt2.aspmx.l.google.com	5
alt3.aspmx.l.google.com	10
alt4.aspmx.l.google.com	10

Fichier de politique pour Google Workspace

version: STSv1
mode: testing
mx: *.google.com
mx: *.googlemail.com
max_age: 86400

Notez qu'il faut deux lignes mx : une pour *.google.com et une pour *.googlemail.com. MTA-STS exige que chaque pattern soit déclaré sur une ligne séparée.

Record DNS pour Google Workspace

L'enregistrement DNS est identique dans sa structure :

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

Google Workspace et TLS-RPT

Google est l'un des fournisseurs les plus actifs en matière de TLS-RPT. Si vous activez MTA-STS et TLS-RPT, vous recevrez des rapports détaillés de Google sur les négociations TLS avec votre domaine. Ces rapports sont précieux pour identifier les problèmes avant de passer en mode enforce.

Héberger MTA-STS sur Cloudflare

Le fichier de politique doit être accessible à https://mta-sts.captaindns.com/.well-known/mta-sts.txt. Cloudflare offre deux options gratuites pour l'hébergement.

Option 1 : Cloudflare Pages (recommandé)

Cloudflare Pages est la solution la plus simple. Créez un dépôt avec la structure suivante :

mon-projet-mta-sts/
  .well-known/
    mta-sts.txt

Étapes de déploiement :

1. Créez un dépôt Git (GitHub ou GitLab) avec le fichier .well-known/mta-sts.txt
2. Connectez-le à Cloudflare Pages : Dashboard Cloudflare > Pages > Create a project
3. Configurez le build : Framework preset = None, Build command = (vide), Output directory = /
4. Ajoutez le domaine personnalisé : Settings > Custom domains > mta-sts.captaindns.com
5. Configurez le DNS : Cloudflare crée automatiquement un enregistrement CNAME

Cloudflare Pages fournit un certificat TLS automatique via Let's Encrypt. Aucune configuration supplémentaire n'est nécessaire.

Option 2 : Cloudflare Worker

Pour un contrôle plus fin ou si vous ne souhaitez pas utiliser un dépôt Git, un Cloudflare Worker peut servir le fichier de politique :

export default {
  async fetch(request) {
    const url = new URL(request.url);

    if (url.pathname === '/.well-known/mta-sts.txt') {
      const policy = `version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 86400`;

      return new Response(policy, {
        headers: {
          'Content-Type': 'text/plain; charset=utf-8',
          'Cache-Control': 'public, max-age=3600',
        },
      });
    }

    return new Response('Not Found', { status: 404 });
  },
};

Étapes :

1. Créez un Worker : Dashboard Cloudflare > Workers & Pages > Create application
2. Collez le code ci-dessus (adaptez les lignes mx à votre fournisseur)
3. Ajoutez une route personnalisée : mta-sts.captaindns.com/*
4. Configurez le DNS : Ajoutez un enregistrement AAAA mta-sts pointant vers 100:: (proxied)

Le plan gratuit Cloudflare Workers inclut 100 000 requêtes par jour, largement suffisant pour MTA-STS.

Quel Content-Type utiliser ?

Le fichier de politique doit être servi avec le Content-Type text/plain. La RFC 8461 ne spécifie pas de charset obligatoire, mais text/plain; charset=utf-8 est recommandé pour la compatibilité.

Activer TLS-RPT pour surveiller le déploiement

TLS-RPT (SMTP TLS Reporting, RFC 8460) est le compagnon indispensable de MTA-STS. Il vous envoie des rapports quotidiens sur les succès et échecs de négociation TLS.

Créer le record TLS-RPT

Ajoutez cet enregistrement TXT dans votre zone DNS :

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

Les rapports sont envoyés au format JSON, compressés en gzip, à l'adresse email spécifiée. Vous pouvez aussi utiliser une URL HTTPS pour recevoir les rapports via webhook :

_smtp._tls.captaindns.com. 300 IN TXT "v=TLSRPTv1; rua=https://tls-reports.captaindns.com/v1/report"

Que contiennent les rapports TLS-RPT ?

Chaque rapport couvre une période de 24 heures et inclut :

Information	Description
Domaine de politique	Votre domaine (captaindns.com)
Période du rapport	Date de début et de fin
Organisation émettrice	Google, Microsoft, etc.
Compteur de succès	Nombre de connexions TLS réussies
Compteur d'échecs	Nombre de connexions échouées
Type d'échec	starttls-not-supported, certificate-expired, validation-failure, etc.

Interpréter les rapports

En mode testing, surveillez les rapports pendant 2 à 4 semaines. Si le taux d'échec est nul ou proche de zéro, vous pouvez passer en mode enforce en toute confiance.

Les erreurs les plus courantes dans les rapports :

Erreur	Cause probable	Action
certificate-expired	Certificat TLS expiré sur un MX	Renouveler le certificat
certificate-host-mismatch	Nom d'hôte MX non couvert par le certificat	Vérifier le SAN du certificat
validation-failure	Chaîne de certificat incomplète	Installer les certificats intermédiaires
sts-policy-fetch-error	Fichier mta-sts.txt inaccessible	Vérifier l'hébergement HTTPS
sts-webpki-invalid	Certificat du sous-domaine mta-sts invalide	Renouveler le certificat

Du testing au enforce : plan de migration

Phase 1 : Déploiement initial (semaine 1)

1. Créez le fichier de politique en mode testing avec max_age: 86400
2. Hébergez-le sur Cloudflare Pages ou Workers
3. Publiez le record DNS _mta-sts
4. Activez TLS-RPT
5. Validez avec le vérificateur MTA-STS CaptainDNS

Phase 2 : Surveillance (semaines 2-4)

1. Analysez les rapports TLS-RPT quotidiens
2. Corrigez les erreurs identifiées (certificats, MX non couverts)
3. Vérifiez que le taux de succès TLS atteint 100 %

Phase 3 : Passage en enforce

1. Modifiez le fichier de politique : mode: enforce
2. Augmentez max_age : passez à 604800 (7 jours) puis 2592000 (30 jours)
3. Mettez à jour le champ id du record DNS
4. Continuez à surveiller les rapports TLS-RPT

version: STSv1
mode: enforce
mx: *.mail.protection.outlook.com
max_age: 2592000

Retour d'urgence au mode testing

Si des emails sont rejetés après le passage en enforce :

1. Repassez immédiatement en mode: testing dans le fichier de politique
2. Mettez à jour le champ id du record DNS
3. Les serveurs émetteurs re-téléchargeront la politique et cesseront de rejeter

Le temps de propagation dépend du max_age précédent. C'est pourquoi il est recommandé d'augmenter max_age progressivement.

Plan d'action recommandé

1. Identifiez votre fournisseur email : Vérifiez vos records MX avec dig MX captaindns.com +short
2. Créez le fichier de politique : Utilisez le générateur MTA-STS CaptainDNS avec les patterns MX de votre fournisseur
3. Hébergez la politique : Déployez sur Cloudflare Pages (option la plus simple et gratuite)
4. Publiez les records DNS : Ajoutez _mta-sts (TXT) et _smtp._tls (TLS-RPT)
5. Validez la configuration : Vérifiez avec le vérificateur de syntaxe MTA-STS que la politique est correcte
6. Surveillez pendant 2-4 semaines : Analysez les rapports TLS-RPT avant de passer en enforce

---

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

---

FAQ

Comment configurer MTA-STS pour Microsoft 365 ?

Créez un fichier mta-sts.txt avec la directive mx: *.mail.protection.outlook.com, hébergez-le en HTTPS sur le sous-domaine mta-sts de votre domaine, et publiez un record DNS TXT à _mta-sts avec v=STSv1; id=<horodatage>. Commencez en mode testing avec un max_age de 86400 secondes (24 heures).

Comment configurer MTA-STS pour Google Workspace ?

Le fichier de politique doit contenir deux lignes mx : mx: *.google.com et mx: *.googlemail.com. Ces patterns couvrent tous les serveurs MX Google Workspace (aspmx.l.google.com et ses alternatives). Le reste de la configuration (record DNS, hébergement HTTPS) est identique à Microsoft 365.

Quel pattern MX utiliser pour Office 365 dans la politique MTA-STS ?

Le pattern correct est *.mail.protection.outlook.com. Ce wildcard couvre tous les serveurs MX Microsoft 365, y compris les variantes régionales et Exchange Online Protection. Vérifiez vos MX avec dig MX captaindns.com +short pour confirmer qu'ils correspondent à ce pattern.

Comment héberger le fichier mta-sts.txt sur Cloudflare ?

Deux options : Cloudflare Pages (créez un dépôt Git avec le fichier .well-known/mta-sts.txt et ajoutez le domaine personnalisé mta-sts.captaindns.com) ou Cloudflare Workers (déployez un script qui retourne le contenu de la politique avec le Content-Type text/plain). Les deux options sont gratuites et fournissent un certificat TLS automatique.

Faut-il configurer TLS-RPT en même temps que MTA-STS ?

Oui, fortement recommandé. TLS-RPT (RFC 8460) vous envoie des rapports quotidiens sur les succès et échecs de négociation TLS. Publiez un record DNS TXT à _smtp._tls avec v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com. Sans TLS-RPT, vous n'avez aucune visibilité sur les problèmes de votre déploiement MTA-STS.

MTA-STS fonctionne-t-il avec un Cloudflare Worker gratuit ?

Oui. Le plan gratuit Cloudflare Workers inclut 100 000 requêtes par jour, largement suffisant pour MTA-STS. Les serveurs émetteurs interrogent votre politique de manière occasionnelle (lors du premier envoi et à l'expiration du cache max_age). Un Worker gratuit couvre facilement des millions d'emails par mois.

Microsoft et Google supportent-ils MTA-STS en natif ?

Oui, les deux. Google supporte MTA-STS en émission (il vérifie les politiques des domaines destinataires) et publie des rapports TLS-RPT. Microsoft 365 supporte MTA-STS en émission depuis 2020 et envoie aussi des rapports TLS-RPT. Les deux fournisseurs gèrent les certificats TLS de leurs serveurs MX automatiquement.

Comment vérifier si mon record MTA-STS est valide ?

Utilisez le vérificateur MTA-STS CaptainDNS pour contrôler votre record DNS, le fichier de politique, le certificat TLS du sous-domaine mta-sts et la correspondance entre les patterns MX déclarés et vos MX réels. Vous pouvez aussi vérifier manuellement avec dig TXT _mta-sts.captaindns.com et curl https://mta-sts.captaindns.com/.well-known/mta-sts.txt.

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 sur les succès et échecs de négociation TLS.
• Exchange Online Protection (EOP) : Service de filtrage email de Microsoft 365 qui gère les serveurs MX *.mail.protection.outlook.com.
• Cloudflare Pages : Service d'hébergement de sites statiques de Cloudflare avec HTTPS automatique et déploiement via Git.
• Cloudflare Workers : Plateforme serverless de Cloudflare permettant d'exécuter du JavaScript au plus proche des utilisateurs.
• max_age : Directive de la politique MTA-STS indiquant la durée de mise en cache en secondes.

Guides MTA-STS connexes

• MTA-STS : le guide complet pour sécuriser le transport email
• MTA-STS ne fonctionne pas ? Guide de dépannage complet (à venir)

Sources

• RFC 8461 - SMTP MTA Strict Transport Security (MTA-STS)
• RFC 8460 - SMTP TLS Reporting
• Google Support - Renforcer la sécurité des emails avec MTA-STS et TLS-RPT
• Microsoft Learn - SMTP MTA-STS