Dernière mise à jour : juillet 2026

En bref : DANE impose une distribution des e-mails chiffrée et authentifiée — mais seulement si le serveur de messagerie destinataire fournit des enregistrements DNSSEC et TLSA. Seuls quelques fournisseurs le peuvent. Cet article montre qui peut faire DANE (Microsoft 365, auto-hébergement), qui ne peut pas (Google Workspace, les hébergeurs mutualisés allemands) — et quelle alternative te reste.

Qu’est-ce que DANE ?

DANE (DNS-based Authentication of Named Entities, RFC 6698) utilise un enregistrement TLSA dans le DNS de ton domaine « pour signaler qu’un domaine et ses serveurs de messagerie prennent en charge DANE ». Un serveur d’envoi vérifie avant la distribution si le certificat TLS du destinataire correspond à l’enregistrement TLSA. Cela rend l’authentification « résistante aux attaques par downgrade et MITM » — l’avantage clé par rapport au chiffrement au mieux (best-effort) de SMTP.

Le prérequis strict : DNSSEC + TLSA au niveau du MX

C’est là que réside le hic qui rend DANE inaccessible à la plupart des utilisateurs. DANE a « des dépendances directes envers DNSSEC » — et « tu ne peux faire confiance aux enregistrements TLSA que si tu actives DNSSEC pour ton domaine ». Concrètement, trois choses sont nécessaires, et chez l’opérateur de ton serveur de messagerie destinataire :

  1. DNSSEC pour la zone (enregistrements DNS signés),
  2. des enregistrements TLSA sous _25._tcp.mail.ton-domaine qui correspondent au certificat du MX,
  3. un MX qui présente exactement ce certificat.

C’est le point décisif : DANE n’est pas un réglage que toi, en tant que client, définis en passant — l’opérateur de tes boîtes mail doit le prendre en charge. Chez un hébergeur mutualisé dont le MX ne publie aucun TLSA, tu ne peux tout simplement pas « configurer » DANE.

Qui peut faire DANE

Microsoft 365 (Exchange Online). Microsoft a rendu SMTP DANE entrant avec DNSSEC disponible en général. L’activation passe par PowerShell, avec le type TLSA recommandé 3 1 1 (DANE-EE) — la documentation de Microsoft insiste sur le fait « que les valeurs du champ d’usage du certificat de 0 ou 1 ne doivent pas être utilisées ». Détails dans notre guide DANE pour Microsoft 365.

Serveurs auto-hébergés (par ex. Mailcow). Si tu exploites ton propre MX, tu as le contrôle total : signe la zone avec DNSSEC, génère TLSA à partir du certificat MX, publie. C’est la voie DANE classique — voir DANE pour Mailcow.

Avec ton propre MX derrière un fournisseur DNS compatible DNSSEC. Certains fournisseurs DNS « peuvent proposer… DNSSEC comme réglage ». Si tu exploites ton propre serveur de messagerie derrière une telle zone, tu peux mettre en œuvre DANE — techniquement, cela correspond à la voie de l’auto-hébergement.

Qui ne peut pas faire DANE (pour toi)

Google Workspace. Google ne publie aucun enregistrement TLSA pour son MX — Google s’appuie sur MTA-STS pour le transport entrant (« authentifié avec un certificat public valide », TLS 1.2+). Pour les domaines Google Workspace, DANE est donc hors sujet ; l’alternative est MTA-STS pour Google Workspace.

Les hébergeurs mutualisés allemands (IONOS, Strato, All-Inkl, Netcup, domainfactory, united-domains, checkdomain). Certains proposent la signature DNSSEC pour ta zone — mais leurs serveurs de messagerie ne publient aucun enregistrement TLSA. Sans TLSA au niveau du MX, pas de DANE. DNSSEC seul (sans TLSA lié à la messagerie) ne fait rien pour la sécurité de transport de tes e-mails.

Quoi utiliser à la place : MTA-STS

Pour tous ceux qui ne peuvent pas mettre en œuvre DANE, MTA-STS est l’alternative pratique. Il atteint le même objectif — une distribution TLS imposée et authentifiée — sans DNSSEC, mais via un fichier de politique servi en HTTPS. Là où cela fonctionne bien (Google, Microsoft, Mailcow) et là où cela devient délicat (hébergeurs mutualisés), nous l’expliquons dans MTA-STS en hébergement mutualisé et les guides individuels pour Google Workspace, Microsoft 365 et Mailcow.

Et dans tous les cas : ajoute TLS-RPT pour recevoir des rapports sur la distribution TLS — que tu finisses par utiliser DANE ou MTA-STS.

Vérifier le résultat

Le scanner MXAudit gratuit te montre si ton domaine est signé avec DNSSEC, si des enregistrements TLSA existent pour ton MX, et où en sont MTA-STS et TLS-RPT — le moyen rapide de voir quelle protection de transport s’applique réellement à ta configuration.

Pour aller plus loin