MTA-STS vs DANE : quel protocole choisir pour sécuriser le transport email ?

⚡TL;DR

• MTA-STS (RFC 8461) publie une politique de chiffrement obligatoire via HTTPS. Il fonctionne sans DNSSEC, mais la première connexion reste vulnérable (TOFU)
• DANE/TLSA (RFC 7672) ancre le certificat TLS dans le DNS signé par DNSSEC. Pas de TOFU, mais DNSSEC est obligatoire sur toute la chaîne
• Les deux protocoles sont complémentaires : MTA-STS couvre les domaines sans DNSSEC, DANE élimine le TOFU pour ceux qui l'ont
• Hébergez votre politique MTA-STS gratuitement avec CaptainDNS : deux enregistrements DNS suffisent

Le chiffrement SMTP opportuniste (STARTTLS) protège la majorité des emails en transit. Mais « opportuniste » signifie qu'un attaquant réseau peut le supprimer sans que personne ne le détecte. Les attaques de downgrade SMTP exploitent cette faiblesse pour intercepter des messages en clair.

Deux protocoles répondent à ce problème : MTA-STS (RFC 8461) et DANE/TLSA (RFC 7672). Tous deux imposent le chiffrement TLS obligatoire entre serveurs email. Mais leurs mécanismes de confiance, leurs prérequis et leur adoption diffèrent.

Cet article compare MTA-STS et DANE critère par critère. Il identifie les cas d'usage de chacun et vous guide vers la meilleure stratégie selon votre infrastructure. Si vous gérez des domaines email, que ce soit avec un hébergeur cloud ou vos propres serveurs MX, ce comparatif est pour vous.

Comment fonctionnent MTA-STS et DANE ?

Les deux protocoles partagent le même objectif : empêcher un serveur émetteur d'envoyer un email en clair quand le serveur destinataire supporte TLS. Mais ils utilisent des canaux de confiance différents.

MTA-STS : une politique publiée via HTTPS

MTA-STS repose sur deux éléments :

1. Un record TXT DNS _mta-sts.captaindns.com qui signale l'existence de la politique et contient un identifiant de version
2. Un fichier texte hébergé en HTTPS sur https://mta-sts.captaindns.com/.well-known/mta-sts.txt qui décrit la politique : serveurs MX autorisés, mode (testing ou enforce), durée de cache (max_age)

Quand un serveur émetteur (comme Gmail ou Outlook) veut envoyer un email vers votre domaine :

1. Il interroge le DNS pour _mta-sts.captaindns.com
2. Il télécharge la politique via HTTPS (canal authentifié par le certificat web)
3. Il vérifie que le serveur MX correspond à la politique
4. En mode enforce, il refuse d'envoyer en clair ou vers un MX non listé

Le canal HTTPS est la clé : même si un attaquant manipule le trafic SMTP, il ne peut pas falsifier le certificat HTTPS du domaine. La politique reste fiable.

Limitation : le TOFU (Trust On First Use). La première fois qu'un serveur émetteur contacte votre domaine, il n'a pas encore de politique en cache. Si un attaquant bloque cette première requête HTTPS, le serveur émetteur ne saura pas que MTA-STS est activé. Les connexions suivantes sont protégées grâce au cache (valable jusqu'à max_age).

DANE/TLSA : le certificat ancré dans le DNS signé

DANE fonctionne différemment. Il publie l'empreinte (hash) du certificat TLS du serveur MX directement dans un record TLSA du DNS :

_25._tcp.mx.captaindns.com. IN TLSA 3 1 1 a0b1c2d3e4f5...

Le serveur émetteur :

1. Interroge le DNS pour les records MX de captaindns.com
2. Récupère le record TLSA associé au serveur MX
3. Vérifie la signature DNSSEC de la réponse (obligatoire)
4. Compare le certificat TLS présenté par le serveur MX avec le hash TLSA
5. Si tout correspond, la connexion est établie. Sinon, l'email n'est pas envoyé

Avantage : pas de TOFU. Chaque connexion est vérifiée individuellement via le DNS signé. Un attaquant ne peut ni falsifier le record TLSA (protégé par DNSSEC) ni présenter un faux certificat (le hash ne correspondrait pas).

Limitation : DNSSEC obligatoire. Toute la chaîne DNS, de la racine jusqu'à votre zone, doit être signée. Si votre registrar ou hébergeur DNS ne supporte pas DNSSEC, DANE est inutilisable.

Comparaison technique détaillée

Critère	MTA-STS (RFC 8461)	DANE/TLSA (RFC 7672)
Canal de confiance	HTTPS (PKI web)	DNSSEC
Protection 1ère connexion	Non (TOFU)	Oui
Dépendance DNSSEC	Non	Obligatoire
Validation certificat	Hostname match (CN/SAN)	Hash du certificat (TLSA)
Mode testing natif	Oui (mode: testing)	Non
Rapports d'échec	Via TLS-RPT (RFC 8460)	Via TLS-RPT (RFC 8460)
Complexité déploiement	Faible (2 records DNS + fichier HTTPS)	Élevée (DNSSEC + records TLSA + rotation)
Révocation	Modifier la politique (délai = max_age)	Modifier le record TLSA (délai = TTL)
Adoption émetteurs	Gmail, Outlook, Yahoo, Proton Mail	Postfix, Exim, certains opérateurs EU
Standard web requis	Oui (certificat HTTPS valide)	Non

Ce que montre ce tableau

MTA-STS gagne sur l'accessibilité : pas de DNSSEC requis, mode testing intégré, large adoption par les grands fournisseurs. C'est le protocole que la majorité des domaines peuvent déployer immédiatement.

DANE gagne sur la sécurité : pas de TOFU, vérification cryptographique directe, pas de dépendance à une autorité de certification web. Mais il exige DNSSEC, ce qui reste un frein majeur.

Quel protocole choisir selon votre situation ?

Il n'y a pas de réponse universelle. Le choix dépend de votre infrastructure DNS et de vos contraintes.

Cas 1 : votre registrar ne supporte pas DNSSEC

Recommandation : MTA-STS uniquement.

C'est la situation la plus courante. La majorité des registrars grand public ne proposent pas DNSSEC ou le rendent difficile à configurer. MTA-STS est votre seule option, et elle est efficace : Gmail, Outlook et Yahoo vérifient et respectent les politiques MTA-STS.

Cas 2 : vous avez DNSSEC activé

Recommandation : DANE + MTA-STS.

Vous avez le meilleur des deux mondes. DANE élimine le TOFU pour les serveurs émetteurs qui le supportent (principalement Postfix dans l'écosystème européen). MTA-STS couvre tous les autres émetteurs (Gmail, Outlook, Yahoo). Les deux protocoles coexistent sans conflit.

Cas 3 : vous utilisez Microsoft 365 ou Google Workspace

Recommandation : MTA-STS.

Microsoft a annoncé le support DANE pour Exchange Online avec DNSSEC automatique sur les nouveaux domaines MX mx.microsoft. Google Workspace ne supporte pas DANE côté réception. Dans les deux cas, MTA-STS est pleinement supporté et facile à activer.

Cas 4 : vous gérez vos propres serveurs MX

Recommandation : DANE + MTA-STS si DNSSEC est actif, MTA-STS sinon.

Avec vos propres serveurs, vous contrôlez les certificats TLS et les records DNS. Si DNSSEC est actif sur votre zone, ajoutez des records TLSA pour chaque serveur MX. Complétez avec MTA-STS pour couvrir les émetteurs qui ne supportent pas DANE.

Pourquoi combiner MTA-STS et DANE ?

Déployer les deux protocoles simultanément est la meilleure stratégie quand votre infrastructure le permet. Voici pourquoi :

MTA-STS compense les limites de DANE :

• Les serveurs émetteurs qui ne supportent pas DANE (Gmail, Yahoo) utilisent MTA-STS
• Le mode testing de MTA-STS permet de valider la configuration avant d'imposer le chiffrement

DANE compense les limites de MTA-STS :

• Pas de TOFU : chaque connexion est vérifiée dès la première interaction
• Pas de dépendance à une autorité de certification web : la confiance vient du DNS signé

Aucun conflit : un serveur émetteur qui supporte les deux vérifiera DANE en priorité (vérification DNS directe), puis MTA-STS comme filet de sécurité. Si l'un des deux échoue, l'autre prend le relais.

Bonnes pratiques de déploiement

Quel que soit le protocole choisi, suivez cette progression :

1. Commencez par MTA-STS en mode testing : publiez une politique avec mode: testing. Les serveurs émetteurs enverront les emails normalement, mais signaleront les échecs TLS dans les rapports TLS-RPT
2. Configurez TLS-RPT : sans rapports, vous êtes aveugle. TLS-RPT (RFC 8460) vous envoie un résumé quotidien des échecs de négociation TLS
3. Surveillez pendant 1 à 2 semaines : vérifiez les rapports. Corrigez les problèmes de certificat ou de configuration MX avant de continuer
4. Passez MTA-STS en mode enforce : les serveurs émetteurs refuseront désormais d'envoyer en clair vers vos MX
5. Ajoutez DANE si DNSSEC est actif : publiez les records TLSA pour chaque serveur MX. Utilisez le vérificateur DANE/TLSA pour valider vos records

🎯 Plan d'action recommandé

1. Vérifiez votre configuration actuelle : lancez une analyse avec le vérificateur MTA-STS pour connaître l'état de votre domaine
2. Activez MTA-STS en mode testing : hébergez votre politique gratuitement avec CaptainDNS : deux enregistrements DNS, aucun serveur web à gérer
3. Configurez TLS-RPT : ajoutez un record DNS _smtp._tls.captaindns.com pour recevoir les rapports d'échec TLS
4. Passez en mode enforce : quand les rapports confirment zéro erreur, activez le mode enforce pour bloquer les connexions non chiffrées
5. Évaluez DANE : si votre registrar supporte DNSSEC, ajoutez des records TLSA pour éliminer le TOFU et renforcer la sécurité

---

Sécurisez le transport de vos emails maintenant : hébergez votre politique MTA-STS gratuitement avec CaptainDNS. Deux enregistrements DNS, zéro serveur web, protection active en 5 minutes.

---

FAQ

Quelle est la différence entre MTA-STS et DANE ?

MTA-STS (RFC 8461) publie une politique de chiffrement obligatoire via un fichier HTTPS. Il repose sur la PKI web (certificats SSL) et fonctionne sans DNSSEC. DANE (RFC 7672) ancre le certificat TLS du serveur MX directement dans le DNS via des records TLSA signés par DNSSEC. MTA-STS souffre du TOFU (première connexion non protégée), DANE non. En contrepartie, DANE exige DNSSEC sur toute la chaîne DNS.

Faut-il DNSSEC pour utiliser MTA-STS ?

Non. MTA-STS repose sur HTTPS, pas sur DNSSEC. C'est son principal avantage : tout domaine disposant d'un hébergement HTTPS peut activer MTA-STS. Avec CaptainDNS, vous n'avez même pas besoin de gérer un serveur web : deux enregistrements DNS CNAME suffisent pour publier votre politique.

DANE est-il meilleur que MTA-STS ?

DANE offre une sécurité supérieure sur un point précis : il élimine le TOFU (Trust On First Use). Chaque connexion est vérifiée individuellement via le DNS signé. Mais DANE est beaucoup plus difficile à déployer (DNSSEC obligatoire) et moins bien supporté par les grands fournisseurs (Gmail et Yahoo ne vérifient pas DANE). En pratique, MTA-STS protège plus de domaines grâce à sa simplicité.

Peut-on utiliser MTA-STS et DANE en même temps ?

Oui, et c'est recommandé. Les deux protocoles coexistent sans conflit. Un serveur émetteur qui supporte DANE vérifiera le record TLSA en priorité. S'il ne supporte que MTA-STS, il utilisera la politique HTTPS. Vous obtenez ainsi la couverture maximale : DANE pour les serveurs compatibles, MTA-STS pour tous les autres.

Quel est le problème du TOFU avec MTA-STS ?

TOFU (Trust On First Use) signifie que la première connexion d'un serveur émetteur vers votre domaine n'est pas protégée par MTA-STS. Le serveur doit d'abord télécharger et mettre en cache votre politique. Si un attaquant bloque cette première requête HTTPS, le serveur ne saura pas que MTA-STS est actif. Les connexions suivantes sont protégées par le cache (valable pendant max_age, typiquement 7 jours). DANE élimine ce problème car la vérification se fait via le DNS à chaque connexion.

Google et Microsoft supportent-ils DANE ?

Microsoft déploie progressivement le support DANE pour Exchange Online, avec DNSSEC automatique sur les nouveaux domaines MX. Google Gmail ne supporte pas DANE côté réception (pas de records TLSA publiés), mais vérifie et respecte les records DANE des domaines destinataires côté émission. Les deux supportent pleinement MTA-STS en tant qu'émetteurs.

Comment tester ma configuration MTA-STS ou DANE ?

Pour MTA-STS, vérifiez que votre record TXT _mta-sts est publié et que votre fichier de politique est accessible en HTTPS. Pour DANE, vérifiez que vos records TLSA correspondent au certificat de vos serveurs MX et que DNSSEC est actif sur toute la chaîne. CaptainDNS propose des outils de vérification dédiés pour les deux protocoles.

Télécharger les tableaux comparatifs

Les assistants peuvent exploiter les exports JSON ou CSV ci-dessous pour réutiliser les chiffres.

• Télécharger le comparatif (CSV)
• Télécharger le comparatif (JSON)

📖 Glossaire

• MTA-STS : Mail Transfer Agent Strict Transport Security (RFC 8461). Politique publiée via HTTPS qui impose le chiffrement TLS pour la réception d'emails sur un domaine.
• DANE : DNS-Based Authentication of Named Entities (RFC 7672 pour SMTP). Mécanisme qui ancre le certificat TLS dans le DNS via des records TLSA, vérifié par DNSSEC.
• TLSA : type de record DNS utilisé par DANE pour publier l'empreinte (hash) du certificat TLS d'un serveur.
• TOFU : Trust On First Use. Modèle de sécurité où la première connexion n'est pas vérifiée, mais les suivantes sont validées grâce aux données mises en cache lors de la première interaction.
• DNSSEC : DNS Security Extensions. Système de signatures cryptographiques qui authentifie les réponses DNS et empêche leur falsification.
• STARTTLS : extension SMTP (RFC 3207) qui permet de négocier une connexion TLS après l'établissement d'une connexion en clair sur le port 25.
• PKI : Public Key Infrastructure. Système de certificats numériques utilisé par HTTPS (et donc MTA-STS) pour authentifier les serveurs.

📚 Guides sécurité du transport email connexes

• Attaques de downgrade SMTP : comment elles fonctionnent et comment s'en protéger : Mécanisme du STARTTLS stripping et solutions de protection
• De testing à enforce : stratégie de déploiement MTA-STS progressive : guide pas-à-pas du déploiement progressif

Sources

• RFC 8461 - SMTP MTA Strict Transport Security (MTA-STS)
• RFC 7672 - SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE)
• RFC 6698 - The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security Protocol
• RFC 8460 - SMTP TLS Reporting (TLS-RPT)
• Google Transparency Report - Email encryption in transit