DANE/TLSA : le guide complet pour authentifier les certificats email par DNS
Par CaptainDNS
Publié le 21 février 2026
- DANE lie les certificats TLS aux noms de domaine via des enregistrements DNS TLSA signés par DNSSEC, éliminant la dépendance aux autorités de certification
- L'usage DANE-EE avec SPKI et SHA-256 (
3 1 1) est le gold standard pour sécuriser SMTP - DNSSEC est un prérequis absolu : sans zone signée, les enregistrements TLSA sont ignorés
- DANE et MTA-STS sont complémentaires : DANE vérifie le certificat via DNS, MTA-STS impose TLS via HTTPS
- TLS-RPT (RFC 8460) permet de surveiller les échecs DANE en production et d'anticiper les problèmes de rotation
En 2026, plus de 95 % des emails reçus par Gmail transitent via TLS (Google Transparency Report). Pourtant, ce chiffrement reste opportuniste : le serveur émetteur ne vérifie ni l'identité du serveur destinataire ni l'authenticité du certificat. Un attaquant positionné sur le réseau peut intercepter la connexion, présenter un faux certificat et lire vos messages sans déclencher la moindre alerte.
DANE (DNS-based Authentication of Named Entities) résout ce problème en publiant directement dans le DNS les informations de certificat attendues. Le serveur émetteur consulte l'enregistrement TLSA, vérifie que le certificat présenté correspond, et refuse la connexion en cas de divergence. La clé : DNSSEC signe cette information, garantissant qu'elle n'a pas été falsifiée.
Ce guide couvre le fonctionnement de DANE, l'anatomie d'un enregistrement TLSA, les usages recommandés pour l'email, le déploiement étape par étape, la complémentarité avec MTA-STS et la surveillance via TLS-RPT. Il s'adresse aux administrateurs email, ingénieurs infrastructure et DevOps qui gèrent des serveurs de messagerie.
Comment fonctionne DANE ?
Le problème du TLS opportuniste
SMTP a été conçu en 1982 sans aucun chiffrement. STARTTLS a été ajouté en 2002 (RFC 3207) pour permettre aux serveurs de négocier une connexion TLS. Mais cette négociation est opportuniste : si le serveur distant ne supporte pas TLS, le message part en clair. Pire, un attaquant peut supprimer la commande STARTTLS de la réponse SMTP (attaque downgrade) et forcer l'envoi sans chiffrement.
Même quand TLS est négocié, le serveur émetteur ne vérifie pas le certificat par défaut. Il accepte n'importe quel certificat, y compris un certificat auto-signé présenté par un attaquant. Le chiffrement existe, mais l'authentification manque.
DANE : le certificat dans le DNS
DANE inverse la logique. Au lieu de faire confiance à une autorité de certification (CA) externe, le propriétaire du domaine publie dans le DNS l'empreinte du certificat que son serveur doit présenter. Le serveur émetteur :
- Résout le MX du domaine destinataire
- Cherche l'enregistrement TLSA associé au serveur MX
- Vérifie la signature DNSSEC de la réponse
- Établit la connexion TLS et compare le certificat présenté à l'empreinte TLSA
- Refuse la connexion si le certificat ne correspond pas
La chaîne de confiance DNSSEC
DANE sans DNSSEC n'a aucune valeur. Sans zone signée, un attaquant pourrait falsifier l'enregistrement TLSA et présenter sa propre empreinte de certificat. Or, selon l'APNIC, moins de 40 % des domaines valident DNSSEC en 2026, ce qui limite encore l'adoption de DANE. La chaîne de confiance va de la racine DNS jusqu'à l'enregistrement TLSA :
. (racine) → com. → captaindns.com. → _25._tcp.mail.captaindns.com. TLSA
Chaque maillon est signé par la zone parente. Si un seul maillon est brisé (zone non signée, signature expirée), la validation DNSSEC échoue et l'enregistrement TLSA est ignoré.
Anatomie d'un enregistrement TLSA
Un enregistrement TLSA se compose de quatre champs :
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 a0b1c2d3e4f5...
Le nom suit la convention _port._protocole.hostname. Pour un serveur SMTP sur le port 25, c'est _25._tcp.mail.captaindns.com.
Usage (champ 1) : que vérifier ?
| Valeur | Nom | Description |
|---|---|---|
| 0 | PKIX-TA | Vérifie le certificat CA + la chaîne CA classique |
| 1 | PKIX-EE | Vérifie le certificat serveur + la chaîne CA classique |
| 2 | DANE-TA | Vérifie le certificat CA, sans exiger la chaîne CA classique |
| 3 | DANE-EE | Vérifie le certificat serveur directement, sans CA |
Selector (champ 2) : quelle partie du certificat ?
| Valeur | Nom | Description |
|---|---|---|
| 0 | Cert | Certificat complet (DER) |
| 1 | SPKI | Clé publique uniquement (SubjectPublicKeyInfo) |
SPKI (1) est recommandé : la clé publique ne change pas quand vous renouvelez le certificat avec la même paire de clés. Cela simplifie la rotation.
Matching type (champ 3) : format des données
| Valeur | Nom | Description |
|---|---|---|
| 0 | Full | Données brutes complètes |
| 1 | SHA-256 | Hash SHA-256 (32 octets, 64 caractères hex) |
| 2 | SHA-512 | Hash SHA-512 (64 octets, 128 caractères hex) |
SHA-256 (1) est le standard : compact, résistant aux collisions, supporté partout.
Quel usage TLSA choisir ?
DANE-EE (usage 3) : le choix recommandé pour SMTP
La RFC 7672 (section 3.1) recommande DANE-EE pour le mail. La combinaison 3 1 1 (DANE-EE + SPKI + SHA-256) est le gold standard :
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 a0b1c2d3e4f5...
Avantages de DANE-EE :
- Pas de dépendance aux CA : vous contrôlez entièrement la confiance
- Certificats auto-signés acceptés : la CA n'a pas besoin d'être reconnue
- Rotation simplifiée : avec SPKI, le hash ne change pas si vous conservez la même clé
- Pas de vérification de la chaîne : seul le certificat end-entity compte
DANE-TA (usage 2) : quand utiliser la CA ?
DANE-TA (2 0 1 ou 2 1 1) est utile quand vous gérez plusieurs serveurs signés par la même CA interne. Au lieu de publier un TLSA par serveur, vous publiez l'empreinte de la CA et tous les certificats signés par elle sont acceptés.
Inconvénient : si la CA est compromise, tous les serveurs sont compromis.
PKIX-EE et PKIX-TA (usages 1 et 0) : cas particuliers
Ces usages combinent la vérification DANE avec la validation CA classique. Ils sont rarement utilisés pour SMTP car ils ajoutent de la complexité sans bénéfice clair par rapport à DANE-EE.
DANE pour l'email : RFC 7672
La RFC 7672, publiée en octobre 2015, adapte DANE spécifiquement au contexte SMTP. Elle définit comment un serveur émetteur doit résoudre et valider les enregistrements TLSA des serveurs MX. Quelques spécificités :
STARTTLS et le port 25
Pour l'email, DANE s'applique sur le port 25 avec STARTTLS (pas sur le port 465 avec TLS implicite). Le serveur émetteur initie une connexion SMTP classique, envoie EHLO, reçoit la commande 250-STARTTLS, puis négocie TLS. C'est à ce moment qu'il compare le certificat présenté à l'enregistrement TLSA.
Nommage TLSA pour les serveurs MX
Le nom de l'enregistrement TLSA est construit à partir du hostname MX, pas du domaine de l'email :
# Email destiné à user@captaindns.com
# MX de captaindns.com → mail.captaindns.com
# TLSA → _25._tcp.mail.captaindns.com
Si le domaine a plusieurs MX, chaque MX doit avoir son propre enregistrement TLSA.
Résolution : du domaine au certificat
Le flux complet pour un email vers user@captaindns.com :
- Résoudre
captaindns.com→ MX →mail.captaindns.com(valider DNSSEC) - Résoudre
_25._tcp.mail.captaindns.com→ TLSA (valider DNSSEC) - Résoudre
mail.captaindns.com→ A/AAAA (valider DNSSEC) - Connexion TCP → SMTP → STARTTLS → Vérifier le certificat contre TLSA
- Si le certificat correspond : livrer. Sinon : refuser.
Déployer DANE en 6 étapes
1. Activer DNSSEC sur votre zone
C'est le prérequis absolu. Contactez votre registrar ou votre hébergeur DNS pour activer DNSSEC. Vérifiez que la chaîne de confiance est complète avec un outil comme dig +dnssec ou le vérificateur DNSSEC CaptainDNS. Si vous partez de zéro, notre guide pas-a-pas DNSSEC par registrar détaille la procédure pour Cloudflare, OVHcloud, GoDaddy et d'autres.
2. Générer l'enregistrement TLSA
Utilisez le générateur DANE/TLSA pour créer votre enregistrement. Fournissez votre certificat PEM ou laissez l'outil le récupérer via STARTTLS. Choisissez la combinaison 3 1 1 (DANE-EE, SPKI, SHA-256).
3. Publier dans le DNS
Ajoutez l'enregistrement dans votre zone :
_25._tcp.mail.captaindns.com. 3600 IN TLSA 3 1 1 a0b1c2d3e4f5678901234567890abcdef0123456789abcdef0123456789abcdef
4. Vérifier la configuration
Après propagation (respectez le TTL), validez que tout est en place : enregistrement TLSA résolu, DNSSEC valide, certificat correspondant. L'inspecteur en fin d'article permet ce contrôle en quelques secondes.
5. Activer TLS-RPT
Publiez un enregistrement TLS-RPT pour recevoir les rapports d'échecs :
_smtp._tls.captaindns.com. 300 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"
6. Planifier la rotation des certificats
C'est le point critique. La majorité des incidents DANE en production viennent d'un renouvellement de certificat sans mise a jour du TLSA. Quand vous renouvelez votre certificat :
- Avec la même clé (selector SPKI) : le hash ne change pas, rien a faire dans le DNS
- Avec une nouvelle clé : publiez le nouveau TLSA avant de déployer le nouveau certificat. Gardez les deux enregistrements pendant au moins 2x le TTL du TLSA (ex. TTL de 3600s = attendre 2h minimum)
- Automatisez : intégrez la vérification TLSA dans votre pipeline de renouvellement (certbot hook, CI/CD)
DANE et MTA-STS : complémentarité, pas concurrence
DANE et MTA-STS protègent tous les deux contre les attaques sur le transport SMTP, mais par des mécanismes différents. Notre guide complet MTA-STS détaille le second volet.
| Critère | DANE | MTA-STS |
|---|---|---|
| Canal d'authentification | DNSSEC (DNS signé) | HTTPS (CA classique) |
| Prérequis | DNSSEC actif sur la zone | Serveur HTTPS + certificat valide |
| Certificats auto-signés | Acceptés (DANE-EE) | Refusés |
| Résistance a la compromission CA | Oui | Non |
| Mode test natif | Non | Oui (mode: testing) |
| Complexité de déploiement | Moyenne (DNSSEC requis) | Faible (fichier texte + DNS TXT) |
La stratégie idéale : les deux
Déployer DANE et MTA-STS simultanément couvre les deux cas :
- Les serveurs qui supportent DANE utilisent la vérification TLSA
- Les serveurs qui ne supportent que MTA-STS utilisent la politique HTTPS
- Les serveurs qui supportent les deux ont une double protection
Surveiller DANE avec TLS-RPT
TLS-RPT (RFC 8460) est le compagnon indispensable de DANE en production. Sans TLS-RPT, un renouvellement de certificat qui casse la correspondance TLSA passe inaperçu pendant des jours.
Les rapports JSON quotidiens incluent les codes d'échec spécifiques a DANE :
| Code d'échec | Signification | Action corrective |
|---|---|---|
dane-required | Pas de TLSA valide trouvé | Vérifier la publication et la propagation DNS |
tlsa-invalid | Enregistrement TLSA mal formé | Régénérer avec le bon format (usage, selector, matching type) |
dnssec-invalid | Validation DNSSEC échouée | Vérifier les signatures RRSIG et la chaîne DS |
dane-policy-failure | Certificat != empreinte TLSA | Mettre a jour le TLSA ou revenir au certificat précédent |
Consultez notre guide complet TLS-RPT pour la mise en place et l'interprétation des rapports.
Plan d'action recommandé
| Etape | Action | Critère de validation |
|---|---|---|
| 1 | Vérifiez votre DNSSEC | Chaîne de confiance complète (DS au TLD, RRSIG valides) |
| 2 | Choisissez l'usage 3 1 1 | DANE-EE + SPKI + SHA-256 |
| 3 | Générez et publiez le TLSA | Enregistrement résolu et cohérent avec le certificat actuel |
| 4 | Validez avec l'inspecteur | TLSA + DNSSEC + correspondance certificat confirmés |
| 5 | Activez TLS-RPT | Rapports reçus sous 24-48h après publication |
| 6 | Documentez la rotation | Procédure écrite pour le renouvellement certificat + mise a jour TLSA |
Vérifiez votre configuration DANE maintenant : Utilisez notre inspecteur DANE/TLSA pour analyser la configuration DANE de votre domaine en quelques secondes. Besoin de créer un enregistrement ? Le générateur DANE/TLSA produit un enregistrement TLSA prêt à publier.
FAQ
Qu'est-ce que DANE et comment ça fonctionne ?
DANE (DNS-based Authentication of Named Entities) est un standard internet (RFC 6698) qui permet de publier dans le DNS les informations de certificat TLS attendues pour un serveur. Le serveur émetteur consulte l'enregistrement TLSA, vérifie la signature DNSSEC, puis compare le certificat présenté par le serveur à l'empreinte publiée. Si le certificat ne correspond pas, la connexion est refusée.
Quelle est la différence entre DANE et MTA-STS ?
DANE utilise DNSSEC et les enregistrements TLSA pour authentifier les certificats. MTA-STS utilise HTTPS et les autorités de certification. DANE offre une sécurité supérieure (pas de dépendance aux CA) mais nécessite DNSSEC. MTA-STS est plus simple à déployer. Les deux mécanismes sont complémentaires et peuvent coexister sur le même domaine.
DNSSEC est-il obligatoire pour DANE ?
Oui, DNSSEC est un prérequis absolu. Sans zone signée, les enregistrements TLSA ne sont pas fiables car un attaquant pourrait les falsifier. Les serveurs émetteurs conformes à la RFC 7672 ignorent les TLSA dont la chaîne DNSSEC n'est pas valide.
Quel usage TLSA choisir pour l'email ?
La RFC 7672 recommande DANE-EE (usage 3) avec SPKI (selector 1) et SHA-256 (matching type 1), soit la combinaison 3 1 1. C'est le gold standard pour SMTP : pas de dépendance aux CA, rotation simplifiée avec SPKI, et compatibilité maximale.
DANE fonctionne-t-il avec Let's Encrypt ?
Oui, DANE fonctionne avec Let's Encrypt. Avec DANE-EE et le selector SPKI (3 1 1), le hash ne change pas tant que vous renouvelez le certificat avec la même clé privée. Let's Encrypt renouvelle tous les 90 jours, mais si vous conservez la clé, le TLSA reste valide. Si vous régénérez la clé, publiez le nouveau TLSA avant le déploiement du certificat.
Quels fournisseurs email supportent DANE ?
Les principaux fournisseurs supportant DANE en émission (vérification DANE sortante) incluent Postfix, Gmail (vérification partielle), et plusieurs FAI européens. Microsoft a annoncé le support DANE pour Exchange Online. En réception, tout serveur avec DNSSEC et un TLSA publié est compatible. L'adoption reste plus forte en Europe (Allemagne, Pays-Bas) qu'aux États-Unis.
Comment surveiller les échecs DANE en production ?
Activez TLS-RPT (RFC 8460) en publiant un enregistrement DNS _smtp._tls avec une adresse de réception. Les serveurs émetteurs enverront des rapports JSON quotidiens détaillant les échecs DANE : certificat non correspondant, DNSSEC invalide, TLSA manquant. Sans TLS-RPT, les échecs passent inaperçus.
Glossaire
- DANE : DNS-based Authentication of Named Entities. Standard RFC 6698 qui permet de publier dans le DNS les certificats TLS attendus pour un service.
- TLSA : Type d'enregistrement DNS (RFC 6698) qui associe un certificat TLS ou une clé publique a un nom de domaine et un port.
- DNSSEC : DNS Security Extensions (RFC 4033). Couche de signatures cryptographiques qui garantit l'authenticité et l'intégrité des réponses DNS.
- DANE-EE : Usage TLSA 3. Vérifie directement le certificat end-entity du serveur, sans passer par une autorité de certification.
- SPKI : SubjectPublicKeyInfo. Selector TLSA 1 qui cible la clé publique du certificat plutôt que le certificat complet.
- MTA-STS : Mail Transfer Agent Strict Transport Security (RFC 8461). Impose le chiffrement TLS pour la réception d'emails via une politique HTTPS.
- TLS-RPT : SMTP TLS Reporting (RFC 8460). Mécanisme de rapport sur les succès et échecs de négociation TLS.
Sources
- RFC 6698 - The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
- RFC 7672 - SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)
- RFC 8460 - SMTP TLS Reporting
- Microsoft - SMTP DNS-Based Authentication of Named Entities (DANE)
- APNIC - DNSSEC deployment statistics
