Fonctionnement de l’authentification BASÉE sur DNS SMTP des entités nommées (DANE)

Le protocole SMTP est le protocole main utilisé pour transférer des messages entre les serveurs de messagerie et n’est pas sécurisé par défaut. Le protocole TLS (Transport Layer Security) a été introduit il y a des années pour prendre en charge la transmission chiffrée de messages via SMTP. Il est couramment utilisé de manière opportuniste plutôt que comme une exigence, laissant une grande partie du trafic d’e-mails en texte clair, vulnérable à l’interception par des acteurs malveillants. En outre, SMTP détermine les adresses IP des serveurs de destination via l’infrastructure DNS publique, qui est susceptible d’usurpation d’identité et d’attaques mitm (Man-in-the-Middle). Cette vulnérabilité a conduit à la création de nombreuses nouvelles normes pour renforcer la sécurité de l’envoi et de la réception des e-mails, l’une de ces normes étant l’authentification dns des entités nommées (DANE).

DANE pour SMTP RFC 7672 utilise la présence d’un enregistrement TLSA (Transport Layer Security Authentication) dans le jeu d’enregistrements DNS d’un domaine pour signaler un domaine et ses serveurs de messagerie prennent en charge DANE. Si aucun enregistrement TLSA n’est présent, la résolution DNS pour le flux de courrier fonctionne comme d’habitude sans aucune tentative de vérification DANE. L’enregistrement TLSA signale en toute sécurité la prise en charge tls et publie la stratégie DANE pour le domaine. Par conséquent, l’envoi de serveurs de messagerie peut correctement authentifier les serveurs de messagerie de réception légitimes à l’aide du DANE SMTP. Cette authentification le rend résistant aux attaques de rétrogradation et MITM. DANE a des dépendances directes sur DNSSEC, qui fonctionne en signant numériquement des enregistrements pour les recherches DNS à l’aide du chiffrement à clé publique. Les vérifications DNSSEC se produisent sur les programmes de résolution DNS récursifs, les serveurs DNS qui effectuent des requêtes DNS pour les clients. DNSSEC garantit que les enregistrements DNS ne sont pas falsifiés et qu’ils sont authentiques.

Une fois que les enregistrements de ressources MX, A/AAAA et DNSSEC d’un domaine sont retournés au programme de résolution récursif DNS en tant qu’authentique DNSSEC, le serveur de messagerie d’envoi demande l’enregistrement TLSA correspondant à l’entrée ou aux entrées de l’hôte MX. Si l’enregistrement TLSA est présent et s’est avéré authentique à l’aide d’un autre case activée DNSSEC, le programme de résolution récursif DNS renvoie l’enregistrement TLSA au serveur de messagerie d’envoi.

Une fois l’enregistrement TLSA authentique reçu, le serveur de messagerie d’envoi établit une connexion SMTP à l’hôte MX associé à l’enregistrement TLSA authentique. Le serveur de messagerie émettrice tente de configurer TLS et de comparer le certificat TLS du serveur avec les données de l’enregistrement TLSA pour vérifier que le serveur de messagerie de destination connecté à l’expéditeur est le serveur de messagerie de réception légitime. Le message est transmis (à l’aide de TLS) si l’authentification réussit. En cas d’échec de l’authentification ou si TLS n’est pas pris en charge par le serveur de destination, Exchange Online réessayez tout le processus de validation en commençant par une requête DNS pour le même domaine de destination au bout de 15 minutes, puis 15 minutes après, puis toutes les heures pendant les 24 heures suivantes. Si l’authentification continue d’échouer après 24 heures de nouvelle tentative, le message expire et une remise avec les détails de l’erreur est générée et envoyée à l’expéditeur.

Quels sont les composants de DANE ?

Enregistrement de ressource TLSA

L’enregistrement TLSA (Tls Authentication) est utilisé pour associer le certificat X.509 ou la valeur de clé publique d’un serveur au nom de domaine qui contient l’enregistrement. Les enregistrements TLSA ne peuvent être approuvés que si DNSSEC est activé sur votre domaine. Si vous utilisez un fournisseur DNS pour héberger votre domaine, le DNSSEC peut être un paramètre proposé lors de la configuration d’un domaine avec celui-ci. Pour en savoir plus sur la signature de zone DNSSEC, visitez ce lien : Vue d’ensemble de DNSSEC | Microsoft Docs.

Exemple d’enregistrement TLSA :

Il existe quatre champs configurables propres au type d’enregistrement TLSA :

Champ d’utilisation du certificat : spécifie comment le serveur de messagerie émettrice doit vérifier le certificat du serveur de messagerie de destination.

Valeur	Acronyme	Description
01	PKIX-TA	Le certificat utilisé est l’autorité de certification publique d’ancre de confiance de la chaîne d’approbation X.509.
11	PKIX-EE	Le certificat vérifié est le serveur de destination ; Les vérifications DNSSEC doivent vérifier son authenticité.
2	DANE-TA	Utilisez la clé privée du serveur de l’arborescence X.509 qui doit être validée par une ancre d’approbation dans la chaîne d’approbation. L’enregistrement TLSA spécifie l’ancre d’approbation à utiliser pour valider les certificats TLS pour le domaine.
3	DANE-EE	Correspondent uniquement au certificat du serveur de destination.

¹ Exchange Online suit les instructions d’implémentation de RFC qui indiquent que les valeurs de champ d’utilisation du certificat de 0 ou 1 ne doivent pas être utilisées lorsque DANE est implémenté avec SMTP. Lorsqu’un enregistrement TLSA dont la valeur de champ Utilisation du certificat est 0 ou 1 est retourné à Exchange Online, Exchange Online le traite comme non utilisable. Si tous les enregistrements TLSA sont jugés inutilisables, Exchange Online n’effectuez pas les étapes de validation DANE pour 0 ou 1 lors de l’envoi de l’e-mail. Au lieu de cela, en raison de la présence d’un enregistrement TLSA, Exchange Online applique l’utilisation de TLS pour l’envoi du courrier électronique, l’envoi de l’e-mail si le serveur de messagerie de destination prend en charge TLS ou la suppression de l’e-mail et la génération d’une notification d’échec de remise si le serveur de messagerie de destination ne prend pas en charge TLS.

Dans l’exemple d’enregistrement TLSA, le champ Utilisation du certificat est défini sur « 3 », de sorte que les données d’association de certificats (« abc123... xyz789') serait mis en correspondance avec le certificat du serveur de destination uniquement.

Champ sélecteur : indique les parties du certificat du serveur de destination qui doivent être vérifiées.

Valeur	Acronyme	Description
0	Cert	Utilisez le certificat complet.
1	SPKI (Informations sur la clé publique de l’objet)	Utilisez la clé publique du certificat et l’algorithme avec lequel la clé publique est identifiée pour utiliser.

Dans l’exemple d’enregistrement TLSA, le champ de sélection est défini sur « 1 » afin que les données d’association de certificats soient mises en correspondance à l’aide de la clé publique du certificat du serveur de destination et de l’algorithme avec lequel la clé publique est identifiée pour utiliser.

Champ type correspondant : indique le format que le certificat est représenté dans l’enregistrement TLSA.

Valeur	Acronyme	Description
0	Complet	Les données de l’enregistrement TSLA sont le certificat complet ou SPKI.
1	SHA-256	Les données de l’enregistrement TSLA sont un hachage SHA-256 du certificat ou du SPKI.
2	SHA-512	Les données de l’enregistrement TSLA sont un hachage SHA-512 du certificat ou du SPKI.

Dans l’exemple d’enregistrement TLSA, le champ Type correspondant est défini sur « 1 », de sorte que les données d’association de certificats sont un hachage SHA-256 des informations de clé publique de l’objet du certificat du serveur de destination.

Données d’association de certificats : spécifie les données de certificat utilisées pour la correspondance avec le certificat du serveur de destination. Ces données dépendent de la valeur du champ sélecteur et de la valeur du type correspondant.

Dans l’exemple d’enregistrement TLSA, les données d’association de certificats sont définies sur abc123. xyz789'. Étant donné que la valeur du champ sélecteur dans l’exemple est définie sur « 1 », elle fait référence à la clé publique du certificat du serveur de destination et à l’algorithme identifié pour être utilisé avec celui-ci. Et comme la valeur du champ Type correspondant dans l’exemple est définie sur « 1 », elle fait référence au hachage SHA-256 des informations de clé publique de l’objet à partir du certificat du serveur de destination.

Quelle est la configuration d’enregistrement TLSA recommandée ?

Selon les conseils d’implémentation RFC pour SMTP DANE, un enregistrement TLSA composé du champ Utilisation du certificat défini sur 3, du champ Sélecteur défini sur 1 et du champ Type de correspondance défini sur 1 est recommandé.

flux de messagerie Exchange Online avec DANE SMTP

Le processus de flux de messagerie pour Exchange Online avec SMTP DANE, indiqué dans l’organigramme ci-dessous, valide la sécurité des enregistrements de domaine et de ressources via DNSSEC, la prise en charge tls sur le serveur de messagerie de destination, et que le certificat du serveur de messagerie de destination correspond à ce qui est attendu en fonction de son enregistrement TLSA associé.

Il existe seulement deux scénarios où une défaillance DANE SMTP entraîne le blocage de l’e-mail :

• Le domaine de destination a signalé la prise en charge de DNSSEC, mais un ou plusieurs enregistrements ont été retournés comme inauthentiques.

• Tous les enregistrements MX pour le domaine de destination ont des enregistrements TLSA et aucun des certificats du serveur de destination ne correspond à ce qui était attendu par les données d’enregistrement TSLA, ou une connexion TLS n’est pas prise en charge par le serveur de destination.

  

Technologies associées

Technologie	Informations complémentaires
L’agent de transfert de courrier : strict transport security (MTA-STS) permet de contrer les attaques de rétrogradation et de man-in-the-middle en fournissant un mécanisme pour définir des stratégies de domaine qui spécifient si le serveur de messagerie de destination prend en charge TLS et ce qu’il faut faire quand TLS ne peut pas être négocié, par exemple arrêter la transmission.	Plus d’informations sur la prise en charge prochaine de Exchange Online pour les MTA-STS entrants et sortants seront publiées plus tard cette année. Exchange Online Transport News de Microsoft Ignite 2020 - Microsoft Tech Community rfc8461 (ietf.org)
Sender Policy Framework (SPF) utilise des informations IP pour s’assurer que les systèmes de messagerie de destination approuvent les messages envoyés à partir de votre domaine personnalisé.	Comment SPF (Sender Policy Framework) empêche l’usurpation d’identité
DomainKeys Identified Mail (DKIM) utilise les informations de certificat X.509 pour garantir que les systèmes de messagerie de destination approuvent les messages sortants envoyés à partir de votre domaine personnalisé.	Utiliser DKIM pour le courrier électronique dans votre domaine personnalisé
L’authentification, la création de rapports et la conformité des messages basés sur le domaine (DMARC) fonctionne avec Sender Policy Framework et DomainKeys Identified Mail pour authentifier les expéditeurs de courrier et garantir que les systèmes de messagerie de destination approuvent les messages envoyés à partir de votre domaine.	Utiliser DMARC pour valider les e-mails et les étapes de configuration

DANE SMTP entrant avec DNSSEC

Configuration requise

Avant de commencer, vérifiez que vous remplissez les conditions préalables suivantes :

1. Vous devez avoir ajouté le domaine en tant que « Domaine accepté » et le domaine status doit être « Sain » dans le Centre Administration Microsoft 365. La documentation suppose que l’enregistrement MX du domaine est défini sur la priorité 0 ou 10 et qu’il n’existe pas d’enregistrement MX secondaire ou de secours. Si vous disposez d’un enregistrement MX de secours, vous devez travailler en étroite collaboration avec votre administrateur Exchange Online pour vous assurer que les modifications sont effectuées correctement.
2. Pour bénéficier des avantages de sécurité complets de la fonctionnalité, vérifiez que vous avez activé DNSSEC pour votre domaine.
3. Vous devez avoir accès à Exchange Online PowerShell et aux autorisations nécessaires pour exécuter les applets de commande décrites dans Exchange Online PowerShell
4. Si le domaine que vous souhaitez sécuriser avec le DANE SMTP entrant avec DNSSEC est référencé dans toutes les configurations smarthost ou dans tous les connecteurs, vous devez basculer vers le nom tenantname.mail.protection.outlook.com smarthost avant de suivre les étapes.

Remarque

Si vous souhaitez activer DNSSEC pour un domaine qui utilise une passerelle tierce, vous pouvez le faire en suivant les étapes 1 à 3, en suivant la note à la fin de l’étape 3 sur les passerelles tierces.

Avertissement

Si vous souhaitez configurer le DANE SMTP entrant avec DNSSEC pour votre « Domaine accepté » et que vos partenaires professionnels utilisent des contoso.comconnecteurs vers votre contoso-com.mail.protection.outlook.com point de terminaison, vous devez travailler avec vos partenaires afin qu’ils mettent à jour leurs connecteurs pour qu’ils référencent le tenantname.onmicrosoft.com point de terminaison ou le tenantname.mail.protection.outlook.com point de terminaison, avant de configurer le DANE SMTP entrant avec DNSSEC. Sinon, la messagerie des connecteurs de vos partenaires commerciaux échoue une fois que vous avez terminé l’activation. Une fois l’activation terminée, vos partenaires peuvent utiliser votre nouveau contoso-com.<random>.mx.microsoft point de terminaison pour rétablir le connecteur d’origine.

Configurer un DANE SMTP entrant avec DNSSEC

Remarque

L’approvisionnement et les mises à jour des enregistrements DNS peuvent prendre un certain temps. Les modifications DNS peuvent prendre plus de temps que prévu pour devenir visibles en raison de plusieurs couches de mise en cache.

Pour configurer le DANE SMTP entrant avec DNSSEC, procédez comme suit :

1. Mettez à jour la durée de vie de votre enregistrement MX existant avec la durée de vie la plus faible possible (mais pas inférieure à 30 secondes). Ensuite, attendez que la durée de vie précédente expire avant de continuer. Par exemple, si la durée de vie de votre enregistrement MX existant était « 3600 secondes » ou « 1 heure » avant de le modifier, vous devez attendre 1 heure avant de passer à l’étape 2.

2. Connectez-vous à Exchange Online PowerShell.

   Avertissement

   Si vous utilisez MTA-STS, vous devez définir votre mode de stratégie sur « test » et mettre à jour l’ID dans l’enregistrement txt MTA-STS. (Vous pouvez utiliser l’heure actuelle au format UTC comme nouvel ID de stratégie.) Ensuite, attendez que le « max_age » de la stratégie expire avant de continuer. Par exemple, si la « max_age » de votre stratégie STS existante était de 3600 secondes ou 1 heure avant de la modifier, vous devez attendre « 1 heure » avant de continuer.

3. Pour le domaine pour lequel vous souhaitez activer SMTP DANE avec DNSSEC, vous devez d’abord activer DNSSEC sur le domaine en exécutant la commande suivante (remplacez « domain » par le nom du domaine choisi, par exemple, contosotest.com) :

   Enable-DnssecForVerifiedDomain -DomainName <DomainName>
   

   Remarque

   L’exécution de cette commande peut prendre quelques minutes.

   Exemple de sortie d’une exécution réussie

   Résultat	DnssecMxValue	ErrorData
   Opération réussie	contosotest-com.o-v1.mx.microsoft

   La réponse de réussite fournit la valeur MX pour le domaine. Cette valeur est le nom vers lequel pointe le nouvel enregistrement MX pour le domaine que vous activez avec DNSSEC. Par exemple : contosotest-com.o-v1.mx.microsoft.

4. Prenez la valeur « DnssecMxValue », accédez au bureau d’enregistrement DNS hébergeant le domaine, ajoutez un nouvel enregistrement MX à l’aide de la valeur retournée à l’étape 3, définissez la durée de vie sur la valeur la plus faible possible (mais pas inférieure à 30 secondes) et définissez la priorité du nouvel enregistrement MX sur 20.

   Remarque

   Si vous utilisez une passerelle de messagerie tierce et que vous souhaitez utiliser cette valeur comme nouvel hôte cible Exchange Online auquel la passerelle de messagerie tierce enverra vos messages entrants, accédez au portail d’administration du tiers, mettez à jour l’hôte intelligent cible que le tiers utilise pour envoyer à Exchange Online, puis validez ce « flux de courrier fonctionnant via le test DNSSEC (Veillez à sélectionner « Validation DNSSEC » pendant l’entrée de test, et non « Validation DANE [y compris DNSSEC]) » dans Microsoft Remote Connectivity Analyzer : Test Input. Si le courrier circule comme prévu, vous n’avez PAS besoin de continuer à suivre les étapes ci-dessous. Si vous souhaitez activer SMTP DANE pour ce domaine, passez à l’étape 7.

   Avertissement

   Si vous utilisez MTA-STS, vérifiez que le mode de stratégie est défini sur « test ». Ensuite, supprimez la ligne mx actuelle contenant les informations d’enregistrement MX héritées et ajoutez le nouveau nom de domaine complet à votre fichier de stratégie MTA-STS en tant que nouvelle ligne mx. Ensuite, mettez à jour l’ID de stratégie dans la stratégie et l’enregistrement TXT MTA-STS (vous pouvez utiliser l’heure actuelle au format UTC comme nouvel ID de stratégie).

5. Vérifiez que le nouveau mx fonctionne via le test SMTP entrant Email (https://testconnectivity.microsoft.com/tests/O365InboundSmtp/input) en développant les étapes de test et en vérifiant que l’échangeur de courrier se terminant par mx.microsoft a été testé avec succès. Vous devrez peut-être réessayer ce test, en fonction de la mise en cache DNS.

   Exemple de sortie de réussite

   

6. Modifiez la priorité du mx hérité pointant vers mail.protection.outlook.com de priorité actuelle à 30 ; modifiez la priorité de l’enregistrement MX créé à l’étape 3 afin qu’il soit défini sur la priorité 0 (priorité la plus élevée).

7. Supprimez l’enregistrement MX hérité se terminant par « mail.protection.outlook.com », « mail.eo.outlook.com » ou « mail.protection.outlook.de ». Ensuite, mettez à jour la durée de vie de l’enregistrement MX se terminant par mx.microsoft sur 3600 secondes. Si vous le souhaitez, vous pouvez vérifier que tout fonctionne comme prévu à l’aide du test DNSSEC (veillez à sélectionner « Validation DNSSEC » pendant l’entrée de test, et non « Validation DANE [y compris DNSSEC]) » dans l’Analyseur de connectivité à distance. Vous devrez peut-être réessayer ce test, en fonction de la mise en cache DNS et des TTL.

   Une fois que les TTL sur l’enregistrement MX hérité ont expiré, une sortie réussie se présente comme suit :

   

8. Exécutez la commande suivante [replace (DomainName) par le nom du domaine choisi, par exemple, contosotest.com] si vous souhaitez activer SMTP DANE pour ce même domaine une fois l’activation DNSSEC terminée :

   Enable-SmtpDaneInbound -DomainName <DomainName>
   

   Résultat	ErrorData
   Opération réussie

9. Vérifiez que l’enregistrement TLSA a été propagé (ce qui peut prendre 15 à 30 minutes) à l’aide d’un outil en ligne de votre choix et de Microsoft Remote Connectivity Analyzer : Test Input.

   Une fois que vous avez terminé l’activation de DNSSEC et que l’enregistrement DANE SMTP (TLSA) a été provisionné par Exchange Online, une sortie réussie s’affiche, comme illustré dans la capture d’écran suivante :

   

   Exchange Online héberge plusieurs enregistrements TLSA pour améliorer la fiabilité des validations DANE SMTP. Il est prévu que la validation de certains enregistrements TLSA échoue. Tant que 1 enregistrement TLSA passe la validation, smtp DANE est configuré correctement et l’e-mail est sécurisé avec SMTP DANE.

   Avertissement

   Si vous utilisez MTA-STS, après avoir vérifié que la stratégie fonctionne et que le courrier est transmis comme prévu, définissez de nouveau le mode de stratégie sur « appliquer » et mettez à jour l’ID dans l’enregistrement txt MTA-STS. (Vous pouvez utiliser l’heure actuelle au format UTC comme nouvel ID de stratégie.)

Limitations

1. Domaines d’inscription viraux ou en libre-service : les domaines qui ont été configurés en tant que « libre-service » ne sont actuellement pas pris en charge avec le DANE SMTP entrant avec DNSSEC.
2. domaines onmicrosoft.com : le domaine « onmicrosoft.com » du locataire n’est actuellement pas pris en charge avec le DANE SMTP entrant avec DNSSEC. Nous étudions la prise en charge du DANE SMTP entrant avec DNSSEC pour les domaines onmicrosoft.com ; toutefois, l’ETA est inconnu.
3. Passerelles tierces : les clients qui utilisent une passerelle de messagerie tierce sur le chemin d’accès entrant (qui accepte les messages pour le locataire, effectue un traitement, puis les transmet à Exchange Online) ne pourront utiliser cette fonctionnalité que pour sécuriser les e-mails relayés à partir de la passerelle tierce vers Exchange Online si la passerelle tierce prend en charge le DANE SMTP avec validation DNSSEC. Les clients de cette configuration doivent configurer le DANE SMTP entrant avec DNSSEC à l’aide d’Exchange PowerShell.
4. Autres intégrations tierces avec le flux de messagerie : il existe des clients pour les passerelles tierces sur le chemin d’accès sortant, où l’e-mail est envoyé au tiers via un connecteur, le tiers effectue un traitement, puis resoumettre à Exchange Online, puis Exchange Online enfin envoie l’e-mail. Ces clients peuvent avoir besoin de travailler avec leur fournisseur tiers lors de l’activation de la fonctionnalité afin qu’il n’y ait aucune interruption. Le relais tiers doit utiliser une recherche DNS lors de l’envoi de l’e-mail à Exchange Online, et utiliser le nouveau nom d’hôte de l’enregistrement MX -> contoso-com.( subdomain).mx.microsoft créé lors de l’activation des fonctionnalités. Le tiers NE DOIT PAS utiliser l’ancien nom d’hôte de l’enregistrement MX :> contoso-com.mail.protection.outlook.com car Exchange Online supprimera l’enregistrement A environ dans les 2 jours (48 heures) après l’activation de la fonctionnalité une fois que nous aurons atteint la disponibilité générale.
5. Domaines entièrement délégués : les domaines hébergés par Microsoft et qui utilisent la délégation NS afin que les serveurs de noms de Microsoft fassent autorité pour le domaine sont pris en charge avec le DANE SMTP entrant avec DNSSEC. Nous avons l’intention de prendre en charge le DANE SMTP entrant avec DNSSEC pour ces domaines ; toutefois, l’ETA est inconnu.

Problèmes de débogage qui se présentent lors de l’activation du DANE SMTP entrant avec DNSSEC

Problèmes liés à Enable/Disable-DnssecForVerifiedDomain et Enable/Disable-SmtpDane Entrant

1. DomainNotFound

   Message (DNSSEC) : « Échec de l’activation/désactivation de DNSSEC en raison de l’contoso.com de domaine qui n’existe pas dans AAD. »
   Messages (SMTP DANE) :
   

   • « L’activation/désactivation du DANE SMTP a échoué en raison de l’contoso.com de domaine qui n’existe pas dans AAD. »
     
   • « L’activation/désactivation du DANE SMTP a échoué en raison du domaine contoso.com introuvable dans la liste des domaines acceptés. »
     Cause : Le domaine fourni n’a pas été trouvé dans la liste des domaines acceptés.
     Action(s) à effectuer : accédez au Centre Administration Microsoft 365 et vérifiez que le domaine a été vérifié auprès du locataire. Si le domaine est sain dans le centre Administration Microsoft 365, accédez au Centre de Administration Exchange et vérifiez que le domaine a été ajouté en tant que « Domaine accepté ».

   DNSSEC

   Résultat	DnssecMxValue	ErrorData
   Erreur		ErrorCode : 'DomainNotFound' ErrorDetails 'DNSSEC activation a échoué...

   SMTP DANE

   Résultat	ErrorData
   Erreur	ErrorCode : 'DomainNotFound' ErrorDetails 'SMTP DANE activation...

2. DnsSecOperationFailed

   Message (DNSSEC) : « Échec de l’activation/désactivation de DNSSEC en raison d’AdditionalErrorDetails. Réessayez l’opération ultérieurement.
   Messages (SMTP DANE) : échec de l’activation/désactivation du DANE SMTP en raison d’AdditionalErrorDetails. Réessayez l’opération ultérieurement.
   Cause : Une tentative de création de la zone DNS et/ou des enregistrements appropriés a échoué.
   Action(s) à effectuer : essayez de réexécuter l’applet de commande.

   DNSSEC

   Résultat	DnssecMxValue	ErrorData
   Erreur		ErrorCode : 'DnssecOperationFailed' ErrorDetails 'DNSSEC activation a échoué...

   SMTP DANE

   Résultat	ErrorData
   Erreur	ErrorCode : 'DnssecOperationFailed' ErrorDetails 'SMTP DANE activation ...

3. PartitionNotFound

   Messages (SMTP DANE) : « L’activation/la désactivation du DANE SMTP a échoué en raison de l’contoso.com de domaine n’ayant pas de partition. »
   Cause : DNSSEC n’est pas activé pour le domaine.
   Action(s) à effectuer : vérifiez que vous utilisez un domaine avec DNSSEC.

   Résultat	ErrorData
   Erreur	ErrorCode : 'PartitionNotFound' ErrorDetails 'SMTP DANE activation

4. DomainNotSupported

   Message (DNSSEC) : « Le domaine spécifié est un domaine onmicrosoft : contoso-com.onmicrosoft.com. »
   Messages (SMTP DANE) : « Le domaine spécifié est un domaine onmicrosoft : contoso-com.onmicrosoft.com. »
   Cause : le domaine est un domaine initial ou MOERA. Ceux-ci ne sont actuellement pas pris en charge.
   Action(s) à effectuer : vérifiez que vous utilisez un domaine qui ne se termine pas par « onmicrosoft.com ».

   DNSSEC

   Résultat	DnssecMxValue	ErrorData
   Erreur		ErrorCode : 'DomainNotSupported' ErrorDetails 'The specified domain ...

   SMTP DANE

   Résultat	ErrorData
   Erreur	ErrorCode : 'DomainNotSupported' ErrorDetails 'The specified domain ...

Problèmes liés aux Get-DnssecStatusForVerifiedDomain

1. Message : « EG001 : Impossible de récupérer la fonctionnalité DNSSEC status pour le domaine [{domaine}]. »
   Cause : Lors de la validation de la configuration du domaine dans Exchange Online, nous avons constaté que le domaine n’a pas été ajouté à Exchange Online. Si vous pensez avoir déjà ajouté ce domaine à Exchange Online, réessayez d’exécuter l’applet de commande, car il peut s’agir d’un problème temporaire.
   Action(s) à effectuer : Réessayez l’applet de commande. Si l’échec persiste, accédez au Centre Administration Microsoft 365 et terminez le processus d’installation de ce domaine.

2. Message : « EG002 : Le domaine [{domaine}] n’est pas un domaine vérifié du organization. »
   Cause : Lors de la validation de la configuration du domaine dans Exchange Online, nous avons constaté que le domaine a été ajouté à Exchange Online mais pas vérifié.
   Action(s) à effectuer : accédez au Centre Administration Microsoft 365 et terminez le processus d’installation et de vérification pour ce domaine.

3. Message : « Une erreur de requête DNS se produit lors de l’obtention d’enregistrements MX pour le domaine [{domaine}] ».
   Cause : Lors de la validation DNS, nous avons reçu un échec DNS générique lors de l’interrogation du domaine.
   Action(s) à effectuer : réessayez d’exécuter l’applet de commande. Vous devrez peut-être examiner votre configuration pour le domaine que vous essayez d’activer avec SMTP DANE avec DNSSEC.

4. Message : « Domaine [{domaine}] introuvable. »
   Cause : Lors de la validation DNS, nous avons reçu un échec NXDOMAIN lors de l’interrogation du domaine.
   Action(s) à effectuer : réessayez d’exécuter l’applet de commande après avoir vérifié la configuration de l’enregistrement MX pour le domaine. La propagation DNS peut prendre jusqu’à 48 heures pour certains fournisseurs DNS.

5. Message : ' ED003 : Domaine [{domaine}] trouvé. Aucun enregistrement MX authentique trouvé.'
   Cause : Lors de la validation DNSSEC, nous n’avons pas pu trouver d’enregistrement MX qui a été résolu en enregistrement A sécurisé par DNSSEC (l’enregistrement A pour la valeur « hostname » de l’enregistrement MX).
   Action(s) à effectuer : réessayez d’exécuter l’applet de commande après avoir vérifié la configuration de l’enregistrement MX pour le domaine. La propagation DNS peut prendre jusqu’à 48 heures pour certains fournisseurs DNS.

6. Message : « EX002 : La valeur de l’enregistrement MX ne correspondait pas à celle attendue. »
   Cause : Lors de la validation MX, nous n’avons pas trouvé d’enregistrement MX qui correspond à celui attendu.
   Action(s) à effectuer : passez en revue vos enregistrements MX dans votre domaine. Vérifiez qu’un enregistrement MX correspond à l’enregistrement attendu qui est généré après l’exécution Enable-DnssecForVerifiedDomain de ou Get-DnssecStatusForVerifiedDomain.

7. Message : « EX003 : La priorité de l’enregistrement MX ne correspondait pas à celle attendue. »
   Cause : Lors de la validation MX, nous avons trouvé l’enregistrement MX attendu, mais sa priorité n’était pas définie sur 0.
   Action(s) à effectuer : définissez votre enregistrement MX (contenant la valeur retournée lors de l’exécution Enable-DnssecForVerifiedDomainou Get-DnssecStatusForVerifiedDomain) sur la priorité 0.

8. Message : « EX004 : Il existe un enregistrement MX différent avec la même préférence que celui attendu. »
   Cause : Lors de la validation MX, nous avons constaté que l’enregistrement MX de priorité la plus élevée n’était pas l’enregistrement MX attendu.
   Action(s) à effectuer : si vous avez déjà effectué les étapes 1 à 4 de Configurer le DANE SMTP entrant avec DNSSEC, effectuez les étapes 5 et 6 en basculant les priorités de vos enregistrements MX afin que le MX attendu soit 0 (priorité la plus élevée), en validant la configuration, puis en supprimant l’enregistrement MX hérité.

9. Message : « EX005 : Il existe un enregistrement MX différent avec une préférence inférieure à celle attendue. »
   Cause : Lors de la validation MX, nous avons trouvé un enregistrement MX pour le domaine qui ne correspond pas à l’enregistrement MX attendu.
   Action(s) à effectuer : si vous avez déjà effectué les étapes 1 à 5 de Configurer le DANE SMTP entrant avec DNSSEC, effectuez l’étape 6 en supprimant l’enregistrement MX hérité.

10. Message : « EX006 : Il existe un enregistrement MX différent avec une préférence supérieure à celle attendue. »
    Cause : Lors de la validation MX, nous avons trouvé un autre enregistrement MX avec une préférence plus élevée que celle attendue.
    Action(s) à effectuer : définissez votre enregistrement MX hérité (se terminant par mail.protection.outlook.com, mail.eo.outlook.com ou mail.protection.outlook.de) sur priorité 20.

11. Message : « EX007 : L’enregistrement MX est introuvable ».
    Cause : Lors de la validation MX, nous n’avons pas trouvé d’enregistrement MX qui correspond à celui attendu.
    Action(s) à effectuer : passez en revue vos enregistrements MX dans votre domaine. Assurez-vous qu’un enregistrement MX correspond à l’enregistrement attendu qui est généré après l’exécution Enable-DnssecForVerifiedDomain de ou Get-DnssecStatusForVerifiedDomain.

12. Message : « EX008 : enregistrement MX correct trouvé, mais avec une préférence inférieure à celle attendue. »
    Cause : Lors de la validation MX, nous avons constaté que l’enregistrement MX attendu avait une priorité incorrecte.
    Action(s) à effectuer : définissez votre enregistrement MX (contenant la valeur retournée lors de l’exécution Enable-DnssecForVerifiedDomain ou Get-DnssecStatusForVerifiedDomain) sur la priorité 0.

13. Message : « EX009 : enregistrement MX correct trouvé, mais avec une préférence plus élevée que prévu. »
    Cause : Lors de la validation MX, nous avons constaté que l’enregistrement MX attendu avait une priorité incorrecte.
    Action(s) à effectuer : définissez votre enregistrement MX (contenant la valeur retournée lors de l’exécution Enable-DnssecForVerifiedDomain ou Get-DnssecStatusForVerifiedDomain) sur la priorité 0.

14. Message : « EX010 : Erreur inconnue lors de la recherche d’enregistrements MX pour le domaine [{domaine}]. »
    Cause : Lors de la validation MX, nous avons rencontré une erreur DNS générique.
    Action(s) à effectuer : réessayez d’exécuter l’applet de commande après avoir vérifié la configuration de l’enregistrement MX pour le domaine. La propagation DNS peut prendre jusqu’à 48 heures pour certains fournisseurs DNS.

15. Message : « EX012 : Enregistrements MX introuvables pour le domaine [{domaine}]. »
    Cause : Lors de la validation MX, nous n’avons pas trouvé d’enregistrement MX qui correspond à celui attendu.
    Action(s) à effectuer : passez en revue vos enregistrements MX dans votre domaine. Assurez-vous qu’un enregistrement MX correspond à l’enregistrement attendu qui est généré après l’exécution Enable-DnssecForVerifiedDomain de ou Get-DnssecStatusForVerifiedDomain.

16. Message : « EX013 : Enregistrement MX attendu inconnu pour le domaine [{domaine}]. »
    Cause : Lors de la validation MX, nous n’avons pas trouvé d’enregistrement MX qui correspond à celui attendu.
    Action(s) à effectuer : passez en revue vos enregistrements MX dans votre domaine. Assurez-vous qu’un enregistrement MX correspond à l’enregistrement attendu qui est généré après l’exécution Enable-DnssecForVerifiedDomain de ou Get-DnssecStatusForVerifiedDomain.

17. Message : « ES001 : Enregistrement MX attendu manquant dans la stratégie alors que le mode est « appliqué » ».
    Cause : Lors de la validation MTA-STS, nous n’avons pas pu trouver la valeur mx correspondant à votre enregistrement attendu.
    Action(s) à effectuer : définissez le mode de votre stratégie MTA-STS à tester. ajoutez ensuite la valeur mxhostname (retournée lors de l’exécution Enable-DnssecForVerifiedDomain ou Get-DnssecStatusForVerifiedDomain) en tant que ligne dans la stratégie MTA-STS.

18. Message : 'ES002 : Aucun enregistrement MX attendu trouvé avec laquelle comparer la stratégie. Activez d’abord la fonctionnalité DNSSEC pour le domaine [{domaine}].
    Cause : MTA-STS a été trouvé, mais l’status DNSSEC du domaine n’était pas disponible.
    Action(s) à effectuer : effectuez les étapes décrites dans Configurer un DANE SMTP entrant avec DNSSEC.

Atténuation des problèmes de flux de courrier avec le DANE SMTP entrant avec DNSSEC

Il existe 3 scénarios clés pour les problèmes de flux de messagerie une fois que le DANE SMTP entrant avec DNSSEC a été activé :

1. Problème lié à l’échec des validations DANE SMTP : pour plus d’informations sur la façon d’atténuer ce problème, consultez Atténuation de l’échec des validations DANE SMTP.
2. Problème d’échec des validations DNSSEC : pour plus d’informations sur la façon d’atténuer ce problème, consultez Atténuation de l’échec des validations DNSSEC.
3. Problème avec la valeur MX : pour plus d’informations sur la façon d’atténuer ce problème, consultez Atténuation des problèmes liés à la valeur MX.

Atténuation de l’échec des validations DANE SMTP

Pour atténuer l’impact des validations DANE SMTP, exécutez la commande suivante :

Disable-SmtpDaneInbound -DomainName <DomainName>

Atténuation de l’échec des validations DNSSEC

1. Pour atténuer l’impact de l’échec des validations DNSSEC, vous devez désactiver DNSSEC sur votre domaine (contoso.com) via votre fournisseur DNS.

   Remarque

   Si la désactivation de DNSSEC ne résout pas le problème, il peut s’agir d’un problème avec votre valeur MX.

2. Une fois que vous avez désactivé DNSSEC sur votre domaine via votre fournisseur DNS, ouvrez un ticket de support auprès de votre fournisseur DNS pour déterminer comment réactiver DNSSEC en toute sécurité pour votre domaine.

Atténuation des problèmes liés à la valeur MX

1. Vérifiez que votre valeur MX correspond à la valeur dans le Centre Administration Microsoft 365 -> Paramètres -> Domaines.

2. Sélectionnez le domaine, sélectionnez Enregistrements DNS, puis exécutez Vérifier l’intégrité.

3. Vérifiez que l’enregistrement MX s’affiche comme OK . Si ce n’est pas le cas, mettez à jour la valeur avec ce qui est fourni dans le centre d’administration.

4. Accédez à votre bureau d’enregistrement DNS et recherchez l’enregistrement MX de votre domaine. La valeur du nom d’hôte sera :

   <MX token>.<subdomain>.mx.microsoft

5. Créez un deuxième enregistrement MX avec la valeur de nom d’hôte suivante et définissez la priorité sur 20 :

   <MX token>.mail.protection.outlook.com

   Remarque

   Remplacez la valeur « MX Token » par le jeton MX de l’enregistrement MX actuel pour votre domaine trouvé à l’étape 4. Par exemple, le jeton MX pour contosotest.com est contosotest-com.

6. Vérifiez que le mx créé à l’étape 5 fonctionne.

   Importante

   L’une des façons de s’assurer que le deuxième enregistrement MX fonctionne consiste à utiliser l’analyseur de connectivité à distance Microsoft.

   1. Entrez le domaine (par exemple, contoso.com) dans le test ; puis sélectionnez Effectuer un test.
   2. Ouvrez étapes de test.
   3. Ouvrez Étapes de test pour tester le flux de courrier SMTP entrant pour le domaine « admin@(domaine) ».
   4. Ouvrez Détails supplémentaires sous Tentative de récupération des enregistrements MX DNS pour le domaine « (domaine) ».
   5. Vérifiez que l’enregistrement MX (jeton MX).mail.protection.outlook.com est sain.

7. Si le flux de messagerie fonctionne avec l’enregistrement MX token.mail.protection.outlook.com MX, exécutez la commande suivante :

   Disable-DnssecForVerifiedDomain -DomainName <DomainName>

8. Supprimez l’enregistrement MX DNSSEC qui correspond aux valeurs ci-dessous :

   <MX token>.<subdomain>.mx.microsoft

9. Vérifiez que l’enregistrement MX que vous avez créé à l’étape 5 est le seul enregistrement MX et qu’il est défini sur la priorité 0 (priorité la plus élevée).

Comment Exchange Online clients peuvent-ils utiliser le DANE SMTP sortant avec DNSSEC ?

En tant que client Exchange Online, vous n’avez rien à faire pour configurer cette sécurité de messagerie améliorée pour votre courrier sortant. Cette sécurité améliorée de la messagerie est quelque chose que nous avons conçu pour vous et elle est ACTIVÉE par défaut pour tous les clients Exchange Online et est utilisée lorsque le domaine de destination annonce la prise en charge de DANE. Pour tirer parti des avantages de l’envoi d’e-mails avec des vérifications DNSSEC et DANE, communiquez à vos partenaires commerciaux avec lesquels vous échangez des e-mails qu’ils doivent implémenter DNSSEC et DANE afin qu’ils puissent recevoir des e-mails en utilisant ces normes.

Résolution des problèmes d’envoi d’e-mails avec SMTP DANE

Actuellement, il existe quatre codes d’erreur pour DANE lors de l’envoi d’e-mails avec Exchange Online. Microsoft met activement à jour cette liste de codes d’erreur. Les erreurs sont visibles dans :

1. Le portail Exchange Administration Center via la vue Détails de la trace des messages.

2. NDRs générés lorsqu’un message n’est pas envoyé en raison d’une défaillance DANE ou DNSSEC.

3. Outil Analyseur de connectivité à distance Microsoft Remote Connectivity Analyzer.

   Code d’échec de remise	Description
   4/5.7.321	starttls-not-supported : le serveur de messagerie de destination doit prendre en charge TLS pour recevoir des messages.
   4/5.7.322	certificate-expired : le certificat du serveur de messagerie de destination a expiré.
   4/5.7.323	tlsa-invalid : la validation DANE du domaine a échoué.
   4/5.7.324	dnssec-invalid : le domaine de destination a retourné des enregistrements DNSSEC non valides.

   Remarque

   Actuellement, lorsqu’un domaine signale qu’il prend en charge DNSSEC mais échoue aux vérifications DNSSEC, Exchange Online ne génère pas l’erreur dnssec-invalid 4/5.7.324. Il génère une erreur DNS générique :

   4/5.4.312 DNS query failed

   Nous travaillons activement pour remédier à cette limitation connue. Si vous recevez cette instruction d’erreur, accédez à Microsoft Remote Connectivity Analyzer et effectuez le test de validation DANE sur le domaine qui a généré l’erreur 4/5.4.312. Les résultats indiquent s’il s’agit d’un problème DNSSEC ou d’un autre problème DNS.

Résolution des problèmes 4/5.7.321 starttls-not-supported

Cette erreur indique généralement un problème avec le serveur de messagerie de destination. Après avoir reçu le message :

1. Vérifiez que l’adresse e-mail de destination a été correctement entrée.
2. Avertissez l’administrateur de la messagerie de destination que vous avez reçu ce code d’erreur afin qu’il puisse déterminer si le serveur de destination est configuré correctement pour recevoir des messages à l’aide du protocole TLS.
3. Réessayez d’envoyer l’e-mail et passez en revue les détails de la trace du message dans le portail Exchange Administration Center.

Résolution des problèmes 4/5.7.322 certificat expiré

Un certificat X.509 valide qui n’a pas expiré doit être présenté au serveur de messagerie d’envoi. Les certificats X.509 doivent être renouvelés après leur expiration, généralement tous les ans. Après avoir reçu le message :

1. Avertissez l’administrateur de l’e-mail de destination que vous avez reçu ce code d’erreur et fournissez la chaîne de code d’erreur.
2. Prévoyez le temps nécessaire au renouvellement du certificat du serveur de destination et à la mise à jour de l’enregistrement TLSA pour référencer le nouveau certificat. Ensuite, réessayez d’envoyer l’e-mail et passez en revue les détails de la trace du message dans le portail Exchange Administration Center.

Résolution des problèmes 4/5.7.323 tlsa-invalid

Ce code d’erreur est lié à une mauvaise configuration d’enregistrement TLSA et ne peut être généré qu’après qu’un enregistrement TLSA d’authentification DNSSEC a été retourné. Il existe de nombreux scénarios lors de la validation DANE qui se produisent après que l’enregistrement a été retourné, ce qui peut entraîner la génération du code. Microsoft travaille activement sur les scénarios couverts par ce code d’erreur, afin que chaque scénario ait un code spécifique. Actuellement, un ou plusieurs de ces scénarios peuvent entraîner la génération du code d’erreur :

1. Le certificat du serveur de messagerie de destination ne correspond pas à ce qui est attendu par l'enregistrement TLSA authentique.
2. L’enregistrement TLSA authentique n’est pas correctement configuré.
3. Le domaine de destination est attaqué.
4. Toute autre défaillance DANE.

Après avoir reçu le message :

1. Avertissez l’administrateur de l’e-mail de destination que vous avez reçu ce code d’erreur et fournissez-lui la chaîne de code d’erreur.
2. Laissez le temps à l’administrateur de l’e-mail de destination de vérifier sa configuration DANE et la validité du certificat de serveur de messagerie. Ensuite, réessayez d’envoyer l’e-mail et passez en revue les détails de la trace du message dans le portail Exchange Administration Center.

Résolution des problèmes 4/5.7.324 dnssec-invalid

Ce code d’erreur est généré lorsque le domaine de destination a indiqué qu’il était DNSSEC-authentic, mais Exchange Online n’a pas pu le vérifier comme DNSSEC-authentic.

Après avoir reçu le message :

1. Avertissez l’administrateur de l’e-mail de destination que vous avez reçu ce code d’erreur et fournissez-lui la chaîne de code d’erreur.
2. Laissez le temps à l’administrateur de l’e-mail de destination d’examiner la configuration DNSSEC de son domaine. Ensuite, réessayez d’envoyer l’e-mail et passez en revue les détails de la trace du message dans le portail Exchange Administration Center.

Résolution des problèmes de réception d’e-mails avec SMTP DANE

Actuellement, il existe deux méthodes qu’un administrateur d’un domaine de réception peut utiliser pour valider et dépanner sa configuration DNSSEC et DANE pour recevoir des e-mails de Exchange Online en utilisant les normes suivantes :

1. Adopter SMTP TLS-RPT (Transport Layer Security Reporting) introduit dans RFC8460
2. Utiliser l’outil Analyseur de connectivité à distance Microsoft Remote Connectivity Analyzer

TLS-RPT https://datatracker.ietf.org/doc/html/rfc8460 est un mécanisme de création de rapports permettant aux expéditeurs de fournir des détails aux administrateurs de domaine de destination sur les réussites et échecs DANE et MTA-STS avec ces domaines de destination respectifs. Pour recevoir des rapports TLS-RPT, vous devez uniquement ajouter un enregistrement TXT dans les enregistrements DNS de votre domaine qui inclut l’adresse e-mail ou l’URI auquel vous souhaitez envoyer les rapports. Exchange Online enverront des rapports TLS-RPT au format JSON.

Les données de la table suivante sont un exemple d’enregistrement :

Type	Nom de domaine	Durée de vie	Enregistrement
TXT	_smtp._tls.microsoft.com	3600	v=TLSRPTv1 ; rua=https://tlsrpt.azurewebsites.net/report

La deuxième méthode consiste à utiliser l’analyseur de connectivité à distance Microsoft Remote Connectivity Analyzer, qui peut effectuer les mêmes vérifications DNSSEC et DANE par rapport à votre configuration DNS que Exchange Online fera lors de l’envoi d’e-mails en dehors du service. Cette méthode est le moyen le plus direct de résoudre les erreurs dans votre configuration pour recevoir des e-mails de Exchange Online en utilisant ces normes.

Lorsque des erreurs sont résolues, les codes d’erreur ci-dessous peuvent être générés :

Code d’échec de remise	Description
4/5.7.321	starttls-not-supported : le serveur de messagerie de destination doit prendre en charge TLS pour recevoir des messages.
4/5.7.322	certificate-expired : le certificat du serveur de messagerie de destination a expiré.
4/5.7.323	tlsa-invalid : la validation DANE du domaine a échoué.
4/5.7.324	dnssec-invalid : le domaine de destination a retourné des enregistrements DNSSEC non valides.

Remarque

Actuellement, lorsqu’un domaine signale qu’il prend en charge DNSSEC mais échoue aux vérifications DNSSEC, Exchange Online ne génère pas l’erreur dnssec-invalid 4/5.7.324. Il génère une erreur DNS générique :

4/5.4.312 DNS query failed

Nous travaillons activement pour remédier à cette limitation connue. Si vous recevez cette instruction d’erreur, accédez à Microsoft Remote Connectivity Analyzer et effectuez le test de validation DANE sur le domaine qui a généré l’erreur 4/5.4.312. Les résultats indiquent s’il s’agit d’un problème DNSSEC ou d’un autre problème DNS.

Résolution des problèmes 4/5.7.321 starttls-not-supported

Remarque

Ces étapes sont destinées aux administrateurs de messagerie pour résoudre les problèmes de réception d’e-mails de Exchange Online à l’aide de SMTP DANE.

Cette erreur indique généralement un problème avec le serveur de messagerie de destination. Serveur de messagerie avec lequel l’Analyseur de connectivité à distance teste la connexion. Il existe généralement deux scénarios qui génèrent ce code :

1. Le serveur de messagerie de destination ne prend pas du tout en charge la communication sécurisée, et une communication simple et non chiffrée doit être utilisée.
2. Le serveur de destination est configuré de manière incorrecte et ignore la commande STARTTLS.

Après avoir reçu le message :

1. Vérifiez l’adresse e-mail.
2. Recherchez l’adresse IP associée à l’instruction d’erreur afin de pouvoir identifier le serveur de messagerie auquel l’instruction est associée.
3. Vérifiez le paramètre de votre serveur de messagerie pour vous assurer qu’il est configuré pour écouter le trafic SMTP (généralement les ports 25 et 587).
4. Patientez quelques minutes, puis réessayez le test avec l’outil Analyseur de connectivité à distance.
5. Si l’échec persiste, essayez de supprimer l’enregistrement TLSA et réexécutez le test avec l’outil Analyseur de connectivité à distance.
6. S’il n’y a pas d’échec, ce message peut indiquer que le serveur de messagerie que vous utilisez pour recevoir des messages ne prend pas en charge STARTTLS et que vous devrez peut-être effectuer une mise à niveau vers un serveur qui le fait pour utiliser DANE.

Résolution des problèmes 4/5.7.322 certificat expiré

Remarque

Ces étapes sont destinées aux administrateurs de messagerie pour résoudre les problèmes de réception d’e-mails de Exchange Online à l’aide de SMTP DANE.

Un certificat X.509 valide qui n’a pas expiré doit être présenté au serveur de messagerie d’envoi. Les certificats X.509 doivent être renouvelés après leur expiration, généralement tous les ans. Après avoir reçu le message :

1. Vérifiez l’adresse IP associée à l’instruction d’erreur afin de pouvoir identifier le serveur de messagerie auquel elle est associée. Recherchez le certificat expiré sur le serveur de messagerie que vous avez identifié.
2. Connectez-vous au site web de votre fournisseur de certificats.
3. Sélectionnez le certificat expiré et suivez les instructions pour renouveler et payer le renouvellement.
4. Une fois que votre fournisseur a vérifié l’achat, vous pouvez télécharger un nouveau certificat.
5. Installez le certificat renouvelé sur le serveur de messagerie associé.
6. Mettez à jour l’enregistrement TLSA associé au serveur de messagerie avec les données du nouveau certificat.
7. Après avoir attendu un laps de temps approprié, réessayez le test avec l’outil Analyseur de connectivité à distance.

Résolution des problèmes 4/5.7.323 tlsa-invalid

Remarque

Ces étapes sont destinées aux administrateurs de messagerie pour résoudre les problèmes de réception d’e-mails de Exchange Online à l’aide de SMTP DANE.

Ce code d’erreur est lié à une mauvaise configuration d’enregistrement TLSA et ne peut être généré qu’après qu’un enregistrement TSLA d’authentification DNSSEC a été retourné. Toutefois, il existe de nombreux scénarios lors de la validation DANE qui se produisent après que l’enregistrement a été retourné et qui peuvent entraîner la génération du code. Microsoft travaille activement sur les scénarios couverts par ce code d’erreur, afin que chaque scénario ait un code spécifique. Actuellement, un ou plusieurs de ces scénarios peuvent entraîner la génération du code d’erreur :

1. L’enregistrement TLSA authentique n’est pas correctement configuré.
2. Le certificat n’est pas encore valide/configuré pour une fenêtre de temps ultérieure.
3. Le domaine de destination fait l’objet d’une attaque.
4. Toute autre défaillance DANE.

Après avoir reçu le message :

1. Vérifiez l’adresse IP associée à l’instruction d’erreur pour identifier le serveur de messagerie auquel elle est associée.
2. Identifiez l’enregistrement TLSA associé au serveur de messagerie identifié.
3. Vérifiez la configuration de l’enregistrement TLSA pour vous assurer qu’il indique à l’expéditeur d’effectuer les vérifications DANE préférées et que les données de certificat correctes ont été incluses dans l’enregistrement TLSA.
   1. Si vous devez effectuer des mises à jour de l’enregistrement en cas de différences, attendez quelques minutes, puis réexécutez le test avec l’outil Analyseur de connectivité à distance.
4. Recherchez le certificat sur le serveur de messagerie identifié.
5. Vérifiez la fenêtre de temps pour laquelle le certificat est valide. S’il est défini pour commencer la validité à une date ultérieure, il doit être renouvelé pour la date actuelle.
   1. Connectez-vous au site web de votre fournisseur de certificats.
   2. Sélectionnez le certificat expiré et suivez les instructions pour renouveler et payer le renouvellement.
   3. Une fois que votre fournisseur a vérifié l’achat, vous pouvez télécharger un nouveau certificat.
   4. Installez le certificat renouvelé sur le serveur de messagerie associé.

Résolution des problèmes 4/5.7.324 dnssec-invalid

Remarque

Ces étapes sont destinées aux administrateurs de messagerie pour résoudre les problèmes de réception d’e-mails de Exchange Online à l’aide de SMTP DANE.

Ce code d’erreur est généré lorsque le domaine de destination a indiqué qu’il est DNSSEC-authentic, mais Exchange Online n’est pas en mesure de le vérifier comme DNSSEC-authentic. Cette section n’est pas complète pour résoudre les problèmes DNSSEC et se concentre sur les scénarios où les domaines ont précédemment passé l’authentification DNSSEC, mais pas maintenant.

Remarque

Ce code d’erreur est également généré si Exchange Online reçoit une réponse SERVFAIL du serveur DNS sur une requête TLSA pour le domaine de destination.

Après avoir reçu le message :

1. Si vous utilisez un fournisseur DNS, par exemple GoDaddy, alertez votre fournisseur DNS de l’erreur afin qu’il puisse travailler sur la résolution des problèmes et la modification de la configuration.
2. Si vous gérez votre propre infrastructure DNSSEC, de nombreuses erreurs de configuration DNSSEC peuvent générer ce message d’erreur. Voici quelques problèmes courants à case activée si votre zone a déjà passé l’authentification DNSSEC :
   1. Chaîne d’approbation rompue, lorsque la zone parente contient un ensemble d’enregistrements DS qui pointent vers un élément qui n’existe pas dans la zone enfant. Ces pointeurs par des enregistrements DS peuvent entraîner la marque de la zone enfant comme fausse en validant les programmes de résolution.
      • Résolvez en examinant les ID de clé RRSIG des domaines enfants et en veillant à ce qu’ils correspondent aux ID de clé dans les enregistrements DS publiés dans la zone parente.
   2. L’enregistrement de ressource RRSIG pour le domaine n’est pas valide, il a expiré ou sa période de validité n’a pas commencé.
      • Résolvez en générant de nouvelles signatures pour le domaine à l’aide d’intervalles de temps valides.

Lorsqu’un e-mail sortant est envoyé, si dnssec est activé dans le domaine de réception, nous interrogeons les enregistrements TLSA associés aux entrées MX dans le domaine. Si aucun enregistrement TLSA n’est publié, la réponse à la recherche TLSA doit être NOERROR (aucun enregistrement de type demandé pour ce domaine) ou NXDOMAIN (il n’existe aucun domaine de ce type). DNSSEC nécessite cette réponse si aucun enregistrement TLSA n’est publié ; sinon, Exchange Online interprète l’absence de réponse comme une erreur SERVFAIL. Conformément à la norme RFC 7672, une réponse SERVFAIL n’est pas fiable ; par conséquent, le domaine de destination échoue à la validation DNSSEC. Cet e-mail est ensuite reporté avec l’erreur suivante :

450 4.7.324 dnssec-invalid: Destination domain returned invalid DNSSEC records

Si l’expéditeur de l’e-mail signale la réception du message

Si vous utilisez un fournisseur DNS, par exemple, GoDaddy, alertez votre fournisseur DNS de l’erreur afin qu’il puisse résoudre les problèmes de réponse DNS. Si vous gérez votre propre infrastructure DNSSEC, il peut s’agir d’un problème avec le serveur DNS lui-même ou avec le réseau.

Forum Aux Questions

En tant que client Exchange Online, puis-je refuser d’utiliser DNSSEC et/ou DANE ?

Nous croyons fermement que DNSSEC et DANE augmenteront considérablement la position de sécurité de notre service et profiteront à tous nos clients. Nous avons travaillé avec diligence au cours de la dernière année pour réduire le risque et la gravité de l’impact potentiel de ce déploiement sur les clients Microsoft 365. Nous allons surveiller et suivre activement le déploiement pour nous assurer que l’impact négatif est réduit au fur et à mesure qu’il se déploie. Pour cette raison, les exceptions au niveau du locataire ou l’exclusion ne seront pas disponibles. Si vous rencontrez des problèmes liés à l’activation de DNSSEC et/ou DANE, les différentes méthodes d’examen des échecs indiquées dans ce document vous aideront à identifier la source de l’erreur. Dans la plupart des cas, le problème concerne la partie de destination externe et vous devez communiquer à ces partenaires commerciaux qu’ils doivent configurer correctement DNSSEC et DANE afin de recevoir des e-mails de Exchange Online en utilisant ces normes.

Quel est le lien entre DNSSEC et DANE ?

DNSSEC ajoute une couche de confiance à la résolution DNS en appliquant l’infrastructure de clé publique pour garantir que les enregistrements retournés en réponse à une requête DNS sont authentiques. DANE garantit que le serveur de messagerie de réception est le serveur de messagerie légitime et attendu pour l’enregistrement MX authentique.

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

DANE et MTA-STS ont le même objectif, mais DANE requiert DNSSEC pour l’authentification DNS, tandis que MTA-STS s’appuie sur des autorités de certification.

Pourquoi le protocole TLS opportuniste n’est-il pas suffisant ?

Tls opportuniste chiffrera la communication entre deux points de terminaison si les deux acceptent de la prendre en charge. Toutefois, même si TLS chiffre la transmission, un domaine peut être usurpé lors de la résolution DNS de sorte qu’il pointe vers le point de terminaison d’un acteur malveillant au lieu du point de terminaison réel pour le domaine. Cette usurpation d’identité est une lacune dans la sécurité de la messagerie qui est résolue en implémentant MTA-STS et/ou SMTP DANE avec DNSSEC.

Pourquoi DNSSEC n’est-il pas suffisant ?

DNSSEC n’est pas entièrement résistant aux attaques de l’intercepteur et aux attaques de passage à une version antérieure (du protocole TLS au texte clair) pour les scénarios de flux de courrier. L’ajout de MTA-STS et DANE avec DNSSEC fournit une méthode de sécurité complète pour contrecarrer les attaques MITM et rétrograder.

Liens supplémentaires

Rechercher et corriger des problèmes après avoir ajouté votre domaine ou des enregistrements DNS

Vue d’ensemble de DNSSEC | Microsoft Docs

Utiliser DMARC pour valider les e-mails et les étapes de configuration - Office 365 | Microsoft Docs

Comment utiliser DKIM pour la messagerie électronique dans votre domaine personnalisé - Office 365 | Microsoft Docs

Comment SPF (Sender Policy Framework) empêche l’usurpation - Office 365 | Microsoft Docs

Exchange Online Transport News de Microsoft Ignite 2020 - Microsoft Tech Community

rfc8461 (ietf.org)