DANE place l’empreinte du certificat de votre serveur de messagerie dans le DNS, sous l’hôte MX auquel elle appartient, et la signe avec DNSSEC pour qu’un serveur émetteur puisse vérifier le certificat sans faire confiance à une autorité de certification publique. C’est une norme achevée, pas un brouillon : la RFC 7672 est sur la voie des normes depuis octobre 2015.
Les quatre fournisseurs de boîtes aux lettres qui décident si la majeure partie de votre courrier arrive ne publient aucun enregistrement TLSA. Nous avons vérifié Gmail, Outlook.com, Yahoo et iCloud le 22 septembre 2026 et n’en avons trouvé aucun. Cela ne rend pas DANE inutile, mais cela décide de ce qu’il faut faire en premier, et la réponse est MTA-STS.
DANE est un enregistrement TLSA sous votre hôte MX, et DNSSEC en est le fondement
Un enregistrement TLSA contient une empreinte du certificat ou de la clé publique que présente votre serveur de messagerie, publiée sous _25._tcp. suivi du nom d’hôte MX. La RFC 6698 a défini le type d’enregistrement en août 2012 ; la RFC 7672 a défini son usage par SMTP en octobre 2015, et la RFC 7671 a ajouté des recommandations opérationnelles le même mois.
L’ancre de confiance est DNSSEC, et ce n’est pas un détail que vous pouvez remettre à plus tard. Un serveur émetteur apprend l’empreinte de votre certificat par le DNS, la réponse doit donc être authentifiée dans le DNS. Sans chaîne signée, quiconque peut altérer la requête peut supprimer l’enregistrement TLSA et l’émetteur retombe sur un TLS non authentifié, c’est-à-dire exactement l’attaque que DANE existe pour empêcher. Un enregistrement TLSA publié dans une zone non signée est un ornement.
C’est aussi pourquoi DANE est une propriété de votre hôte MX et non de votre domaine. L’enregistrement dépend de chaque nom d’hôte de votre ensemble MX, donc un domaine avec trois hôtes MX a besoin de trois jeux d’enregistrements, et chacun d’eux doit rester aligné sur le certificat de cette machine.
Seuls deux des quatre usages de certificat sont autorisés pour SMTP
TLSA comporte un champ d’usage à quatre valeurs, et la section 3.1.3 de la RFC 7672 en écarte la moitié pour le courrier.
| Usage | Nom | Autorisé pour SMTP |
|---|---|---|
| 0 | PKIX-TA | Non |
| 1 | PKIX-EE | Non |
| 2 | DANE-TA | Oui |
| 3 | DANE-EE | Oui |
La raison est dite sans détour dans la RFC : on ne peut pas attendre des MTA clients SMTP qu’ils soient configurés avec un ensemble suffisamment complet d’autorités de certification publiques de confiance. Les usages 0 et 1 demandent au serveur émetteur de valider aussi contre le système des autorités publiques, et un serveur de messagerie n’est pas un navigateur. La spécification indique que le traitement de ces deux usages par le client est indéfini et que les clients peuvent considérer de tels enregistrements comme inutilisables : en publier un revient donc à parier sur l’implémentation d’autrui.
En pratique, le champ se fixe sur une seule forme. Posteo publie cinq enregistrements TLSA par hôte MX, tous en usage 3, sélecteur 1 et type de correspondance 1 : DANE-EE sur la clé publique du titulaire, hachée en SHA-256. C’est 3 1 1, et c’est la forme à reprendre. Le sélecteur 1 compte parce qu’il couvre la clé et non le certificat, si bien que renouveler un certificat avec la même clé ne casse pas l’enregistrement.
Aucun des quatre grands fournisseurs de boîtes aux lettres ne publie TLSA
Nous avons interrogé chaque hôte MX de chacun des domaines ci-dessous à la recherche d’un enregistrement TLSA sous _25._tcp., via Google Public DNS et via Cloudflare DNS, le 22 septembre 2026. Les deux points d’accès ont concordé sur chaque ligne.
| Domaine | TLSA sur ses hôtes MX |
|---|---|
| gmail.com | Aucun |
| outlook.com | Aucun |
| yahoo.com | Aucun |
| icloud.com | Aucun |
| t-online.de | Aucun |
| posteo.de | 5 enregistrements par hôte, tous 3 1 1 |
| mailbox.org | 1 à 2 enregistrements par hôte |
| gmx.net | 2 enregistrements par hôte |
| web.de | 1 enregistrement par hôte |
| freenet.de | 2 enregistrements par hôte |
| protonmail.ch | 2 enregistrements par hôte |
| nic.cz | 1 enregistrement par hôte |
| rijksoverheid.nl | 2 enregistrements par hôte |
Le motif est régional plutôt que technique. Les fournisseurs de boîtes aux lettres allemands et suisses, le registre de domaines tchèque et le gouvernement néerlandais publient TLSA et signent leurs zones. Les quatre fournisseurs dont les décisions de filtrage comptent vraiment pour la plupart des expéditeurs ne le font pas, et t-online.de est l’exception allemande qui montre que ce partage relève du choix de chaque opérateur et non d’une règle nationale.
Exchange Online publie TLSA sur ses hôtes MX récents et pas sur les anciens
Microsoft est le seul grand opérateur qui bouge. Les locataires dont le MX pointe vers le nom d’hôte plus récent mx.microsoft portent quatre enregistrements TLSA, mêlant usage 2 et usage 3, dans une zone signée avec DNSSEC. Nous l’avons observé sur kpn.com et sur sidn.nl, qui résolvent tous deux vers des hôtes sous mx.microsoft.
L’ancien nom d’hôte Exchange Online sous mail.protection.outlook.com ne porte rien, et le nom grand public derrière outlook.com non plus. Savoir si Microsoft prend en charge DANE n’a donc pas de réponse unique : cela dépend du nom d’hôte MX attribué à votre locataire, et cela se vérifie sur votre propre domaine plutôt que dans une annonce.
Un hôte a répondu SERVFAIL, et ce n’est pas la même chose qu’une absence d’enregistrement
Interroger microsoft-com.mail.protection.outlook.com a renvoyé SERVFAIL depuis Google Public DNS et NXDOMAIN depuis Cloudflare DNS. Ce sont deux affirmations différentes, et une seule des deux est une réponse.
Seuls NOERROR et NXDOMAIN vous apprennent quelque chose sur la zone. Un SERVFAIL vous apprend que la requête a échoué, ce qui est un fait sur le résolveur et le chemin, pas sur l’existence d’un enregistrement. Un outil de vérification qui annonce l’absence de DANE face à un SERVFAIL affirme quelque chose qu’il n’a pas mesuré, et le lecteur agit comme si l’opérateur avait choisi de ne rien publier.
C’est pourquoi chaque ligne du tableau ci-dessus a été lue deux fois, via deux résolveurs indépendants, et pourquoi le seul hôte qui s’est contredit lui-même est décrit ici au lieu de recevoir un verdict.
MTA-STS est la politique que vous pouvez publier aujourd’hui sans DNSSEC
MTA-STS résout le même problème avec une autre ancre de confiance. La RFC 8461, publiée en septembre 2018 par des auteurs de Google, Oath, Comcast et Microsoft, place un fichier de politique derrière HTTPS sur un hôte connu et le désigne depuis un enregistrement TXT. L’infrastructure à clés publiques du web authentifie la politique, aucune signature DNSSEC n’est donc requise.
| DANE pour SMTP | MTA-STS | |
|---|---|---|
| Norme | RFC 7672, 2015 | RFC 8461, 2018 |
| Ancre de confiance | DNSSEC | Clés publiques du web sur HTTPS |
| Publié sous forme de | TLSA par hôte MX | Enregistrement TXT et fichier de politique |
| Exige une zone signée | Oui | Non |
| Prise en charge par les grands fournisseurs | Rare | Courante |
Ils ne sont pas rivaux et un domaine peut publier les deux. Si votre zone est signée et que vous exploitez vos propres serveurs de messagerie, DANE est plus solide, car il ne dépend pas du système d’autorités de certification qu’il remplace. Si votre zone n’est pas signée, MTA-STS est le seul des deux que vous puissiez déployer, et c’est celui que les grands fournisseurs respectent.
Que faire, et dans quel ordre
- Vérifiez ce que vos hôtes MX publient déjà, avec notre consultation d’enregistrements MX, avant de décider quoi que ce soit. Sur une plateforme hébergée, la réponse appartient à votre fournisseur, pas à vous.
- Publiez MTA-STS. Cela fonctionne sans DNSSEC, les grands fournisseurs l’appliquent, et c’est le changement qui pèse sur la remise réelle ce trimestre. Notre outil de vérification MTA-STS lit l’enregistrement TXT et le fichier de politique ensemble.
- Publiez TLS-RPT. C’est un seul enregistrement TXT, cela ne change rien à la remise, et c’est ainsi que vous saurez si l’une des deux politiques est respectée. Notre outil de vérification TLS-RPT valide l’enregistrement, y compris l’étiquette de version sensible à la casse qui écarte en silence un enregistrement écrit en minuscules.
- N’ajoutez DANE que si vous signez votre zone et exploitez votre propre MX. Publiez
3 1 1par hôte, et faites tourner l’enregistrement avant le certificat, jamais après. - Ne publiez jamais TLSA dans une zone non signée. Cela n’authentifie rien et vous engage à maintenir un enregistrement aligné sur un certificat sans aucun gain.
Pourquoi nous vérifions MTA-STS et TLS-RPT mais pas DANE
Un verdict DANE exige une décision de confiance DNSSEC, et nos outils s’exécutent dans votre navigateur via DNS-over-HTTPS. Le bit AD d’une réponse DoH est l’affirmation du résolveur selon laquelle il a validé la chaîne, pas la preuve que la chaîne se valide. Afficher un résultat DANE en vert en s’appuyant sur l’affirmation d’un tiers serait précisément le verdict assuré et non mérité que ces outils existent pour éviter, nous n’en proposons donc pas.
Les enregistrements de transport que nous pouvons lire entièrement, nous les lisons entièrement. Tout le reste de votre configuration d’envoi relève d’une autre couche, et notre guide de l’authentification des e-mails explique comment SPF, DKIM et DMARC s’articulent au-dessus. Sur les domaines que nous testons pour le rapport Unspam 2026 sur la délivrabilité des e-mails, 48 % publient une politique DMARC, et c’est le chantier inachevé qui déplace plus de courrier que TLSA n’en déplacera jamais.
Pour voir ce que porte vraiment un message réel à son arrivée, faites un test de spam gratuit.
