Configurer des scellants ARC approuvés

l’authentification Email permet de valider les messages envoyés vers et à partir de votre organization Microsoft 365 pour empêcher les expéditeurs usurpés qui sont utilisés dans la compromission de la messagerie professionnelle (BEC), les rançongiciels et d’autres attaques par hameçonnage.

Toutefois, certains services de messagerie légitimes peuvent modifier les messages avant qu’ils ne soient remis à votre organization Microsoft 365. La modification des messages entrants en transit peut et probablement entraîner les échecs d’authentification des e-mails suivants dans Microsoft 365 :

• SPF échoue en raison de la nouvelle source de message (adresse IP).
• DKIM échoue en raison de la modification du contenu.
• DMARC échoue en raison des défaillances SPF et DKIM.

La chaîne de réception authentifiée (ARC) permet de réduire les échecs d’authentification des e-mails entrants dus à la modification des messages par les services de messagerie légitimes. ARC conserve les informations d’authentification par e-mail d’origine au niveau du service de messagerie. Vous pouvez configurer votre organization Microsoft 365 pour approuver le service qui a modifié le message et utiliser ces informations d’origine dans les vérifications d’authentification par e-mail.

Quand utiliser des sealers ARC approuvés

Un organization Microsoft 365 doit identifier les scellants ARC approuvés uniquement lorsque les messages remis aux destinataires Microsoft 365 sont régulièrement affectés de la manière suivante :

• Le service intermédiaire modifie l’en-tête de message ou le contenu de l’e-mail.
• Les modifications de message entraînent l’échec de l’authentification pour d’autres raisons (par exemple, en supprimant les pièces jointes).

Une fois qu’un administrateur a ajouté un scellant ARC approuvé dans le portail Defender, Microsoft 365 utilise les informations d’authentification par e-mail d’origine fournies par le scellant ARC pour valider les messages envoyés via le service dans Microsoft 365.

Conseil

Ajoutez uniquement les services légitimes et requis en tant que scellants ARC approuvés dans votre organization Microsoft 365. L’ajout de services légitimes permet uniquement aux messages affectés de passer des vérifications d’authentification par e-mail et empêche la remise de messages légitimes dans le dossier Courrier indésirable, mis en quarantaine ou rejeté en raison d’échecs d’authentification par e-mail.

Ce qu'il faut savoir avant de commencer

• Vous ouvrez le portail Microsoft Defender à l’adresse https://security.microsoft.com. Pour accéder directement à la page des paramètres d’authentification Email, utilisez https://security.microsoft.com/authentication.

• Pour vous connecter à Exchange Online PowerShell, voir Connexion à Exchange Online PowerShell.

• Vous devez disposer des autorisations pour pouvoir ajouter ou gérer des sealers ARC approuvés. Vous avez le choix parmi les options suivantes :

  • Microsoft Defender XDR le contrôle d’accès en fonction du rôle (RBAC) unifié (si Email & collaboration> les autorisationsDefender pour Office 365 est Actif. Affecte uniquement le portail Defender, et non PowerShell) : Autorisation et paramètres/Paramètres de sécurité/Paramètres de sécurité principaux (gérer) ou Autorisation et paramètres/Paramètres de sécurité/Paramètres de sécurité principaux (lecture) .

  • Exchange Online autorisations : appartenance aux groupes de rôles Gestion de l’organisation ou Administrateur de la sécurité.

  • autorisations Microsoft Entra : appartenance à l’administrateur^* général. Les membres du rôle Administrateur de la sécurité ne peuvent pas accéder aux paramètres d’authentification par e-mail dans le portail Defender.

    Importante

    ^* Microsoft défend fermement le principe des privilèges minimum. L’attribution de comptes uniquement les autorisations minimales nécessaires à l’exécution de leurs tâches permet de réduire les risques de sécurité et renforce la protection globale de votre organization. Administrateur général est un rôle hautement privilégié que vous devez limiter aux scénarios d’urgence ou lorsque vous ne pouvez pas utiliser un autre rôle.

Utiliser le portail Microsoft Defender pour ajouter des scellants ARC approuvés

1. Dans le portail Microsoft Defender à l’adresse https://security.microsoft.com, accédez à Email & stratégies de collaboration>& règles>Stratégies>de menace Email Paramètres d’authentification dans la section >ARC . Ou, pour accéder directement à la page des paramètres d’authentification Email, utilisez https://security.microsoft.com/authentication.

2. Dans la page des paramètres d’authentification Email, vérifiez que l’onglet ARC est sélectionné, puis sélectionnez Ajouter.

   Conseil

   Si les sealers approuvés sont déjà répertoriés sous l’onglet ARC , sélectionnez Modifier.

3. Dans le menu volant Ajouter des scellateurs ARC approuvés qui s’ouvre, entrez le domaine de signature approuvé dans la zone (par exemple, fabrikam.com).

   Le nom de domaine doit correspondre au domaine affiché dans la valeur d dans les en-têtes ARC-Seal et ARC-Message-Signature dans les messages affectés. Utilisez les méthodes suivantes pour afficher l’en-tête de message :

   • Afficher les en-têtes de message Internet dans Outlook.
   • Utilisez l’analyseur d’en-tête de message à l’adresse https://mha.azurewebsites.net.

   Répétez cette étape autant de fois que nécessaire. Pour supprimer une entrée existante, sélectionnez en regard de l’entrée.

   Lorsque vous avez terminé dans le menu volant Ajouter des scellants ARC approuvés , sélectionnez Enregistrer.

Utiliser Exchange Online PowerShell pour ajouter des scellants ARC approuvés

Si vous préférez utiliser PowerShell pour afficher, ajouter ou supprimer des scellants ARC approuvés, connectez-vous à Exchange Online PowerShell pour exécuter les commandes suivantes.

• Affichez les sealers ARC approuvés existants : exécutez la commande suivante pour vérifier quels sealers ARC approuvés sont actuellement configurés dans votre organisation :

  Get-ArcConfig
  

  Si aucun scellant ARC approuvé n’est configuré, la commande ne retourne aucun résultat.

• Ajouter ou supprimer des scellants ARC approuvés

  Pour remplacer les scellants ARC existants par les valeurs que vous spécifiez, utilisez la syntaxe suivante :

  Set-ArcConfig -Identity [TenantId\]Default -ArcTrustedSealers "Domain1","Domain2",..."DomainN"
  

  La valeur TenantId\ n’est pas requise dans votre propre organization, mais uniquement dans les organisations déléguées. Il s’agit d’un GUID visible dans de nombreuses URL du portail d’administration dans Microsoft 365 (la tid= valeur). Par exemple, aaaabbbb-0000-cccc-1111-dddd2222eeeeee.

  Cet exemple configure « cohovineyard.com » et « tailspintoys.com » en tant que seuls scellants ARC approuvés dans le organization.

  Set-ArcConfig -Identity Default -ArcTrustedSealers "cohovineyard.com","tailspintoys.com"
  

  Pour conserver les valeurs existantes, veillez à inclure les scellants ARC que vous souhaitez conserver avec les nouveaux scellants ARC que vous souhaitez ajouter.

  Pour ajouter ou supprimer des sealers ARC sans affecter les autres entrées, consultez les exemples de Set-ArcConfig.

Importante

Le domaine du sealer ARC n’est pas le domaine de votre organization. Il s’agit du domaine de signature du fournisseur qui apparaît dans le d= champ de l’en-tête ARC-Seal. Vérifiez toujours la valeur réelle d= d’un en-tête de message avant de configurer le scellement approuvé.

Configurer des sealers ARC approuvés pour plusieurs fournisseurs

Si votre organisation utilise plusieurs services de messagerie qui ajoutent des sceaux ARC, connectez-vous à Exchange Online PowerShell et ajoutez tous les domaines de fournisseur dans une seule commande.

Importante

Le paramètre -ArcTrustedSealersremplace toutes les entrées existantes. Pour conserver les scellements approuvés existants, incluez-les dans la commande avec les nouveaux domaines que vous souhaitez ajouter.

Attention

Ajoutez uniquement des fournisseurs que vous utilisez activement et auxquels vous faites confiance. L’ajout de scellants ARC inutiles augmente votre surface d’attaque, car un fournisseur compromis peut transmettre des messages usurpés via vos vérifications d’authentification.

Set-ArcConfig -Identity Default -ArcTrustedSealers "Domain1.com","Domain2.com","Domain3.com","Domain4.com"

Rechercher le domaine d’sealer ARC de votre fournisseur

Utilisez les étapes suivantes pour identifier le bon domaine de scellement ARC :

1. Envoyez un e-mail de test via le service intermédiaire à une boîte aux lettres Microsoft 365.
2. Ouvrez les en-têtes de message (dans Outlook :Propriétés> de fichier>En-têtes Internet, ou utilisez l’analyseur d’en-têtes de message).
3. Recherchez ARC-Seal: dans les en-têtes.
4. Notez la d= valeur . Cette valeur est le domaine à ajouter en tant que scellant ARC approuvé.

Valider un scellant ARC approuvé

S’il existe un sceau ARC d’un service avant que le message n’atteigne Microsoft 365, case activée l’en-tête du message pour les derniers en-têtes ARC après la remise du message.

Dans le dernier en-tête ARC-Authentication-Results , recherchez arc=pass et oda=1. Ces valeurs indiquent :

• L’ARC précédent a été vérifié.
• Le scellant ARC précédent est approuvé.
• Le résultat de réussite précédent peut être utilisé pour remplacer l’échec DMARC actuel.

L’exemple suivant montre l’en-tête ARC-Authentication-Results où arc=pass et oda=1 confirment un signataire ARC approuvé :

ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
172.17.17.17) smtp.rcpttodomain=microsoft.com
smtp.mailfrom=sampledoamin.onmicrosoft.com; dmarc=bestguesspass action=none
header.from=sampledoamin.onmicrosoft.com; dkim=none (message not signed);
arc=pass (0 oda=1 ltdi=1
spf=[1,1,smtp.mailfrom=sampledoamin.onmicrosoft.com]
dkim=[1,1,header.d=sampledoamin.onmicrosoft.com]
dmarc=[1,1,header.from=sampledoamin.onmicrosoft.com])

Pour case activée si le résultat ARC a été utilisé pour remplacer une défaillance DMARC, recherchez compauth=pass et reason=130 dans le dernier en-tête Authentication-Results. L’exemple suivant montre un en-tête Authentication-Results où l’authentification composite a réussi grâce à un scelleur ARC approuvé (reason=130) :

Authentication-Results: spf=fail (sender IP is 10.10.10.10)
smtp.mailfrom=contoso.com; dkim=fail (body hash did not verify)
header.d=contoso.com;dmarc=fail action=none
header.from=contoso.com;compauth=pass reason=130

Remarque

Le passage de résultat ARC à partir d’un scellant ARC approuvé peut potentiellement remplacer les défaillances dans SPF, DKIM ou DMARC provoquées par une modification de message pendant le transit. Toutefois, la détermination finale de l’usurpation d’identité est basée sur le résultat de l’authentification composite (CompAuth). Les messages qui échouent à ARC peuvent toujours être remis s’ils passent les évaluations d’authentification SPF, DKIM, DMARC et composite.

Diagrammes de flux de courrier du scellant ARC approuvé

Les diagrammes de cette section comparent le flux de messagerie et l’effet sur les résultats de l’authentification par e-mail avec et sans scelleur ARC approuvé. Dans les deux diagrammes, le organization Microsoft 365 utilise un service de messagerie légitime qui modifie le courrier entrant avant sa remise à Microsoft 365. Cette modification interrompt le flux de messagerie, ce qui peut entraîner des échecs d’authentification par e-mail en modifiant l’adresse IP source et en mettant à jour l’en-tête du message électronique.

Le diagramme du flux de messagerie suivant montre le résultat sans scelleur ARC de confiance :

Le diagramme de flux de messagerie suivant montre le résultat avec un sealer ARC approuvé :

Scénarios d’échec ARC courants

Si ARC ne fonctionne pas comme prévu, utilisez la référence de résolution des problèmes suivante.

Référence rapide : Symptômes d’échec ARC

Le tableau suivant répertorie les symptômes courants de défaillance d’ARC, leurs causes probables et les solutions recommandées.

Symptôme	Cause probable	Résolution
arc=fail dans ARC-Authentication-Results	Domaine de scellement ARC non ajouté comme approuvé ou domaine configuré incorrect.	Vérifiez la d= valeur dans l’en-tête ARC-Seal et ajoutez-la aux scelleurs approuvés.
arc=none dans ARC-Authentication-Results	Le service intermédiaire n’ajoute pas d’en-têtes ARC.	Contactez votre fournisseur pour activer la signature ARC.
oda=0 Malgré arc=pass	Le domaine du sealer ARC ne figure pas dans la liste des sealers approuvés.	Ajoutez le domaine approprié à l’aide de Set-ArcConfig.
compauth=fail reason=000 malgré le sealer approuvé	Échec de la validation de la chaîne ARC (chaîne rompue).	Vérifiez les problèmes d’intégrité de la chaîne (consultez Chaîne ARC rompue).
dmarc=fail et aucun en-tête ARC présent	Le message n’a pas transité par un intermédiaire prenant en charge ARC.	ARC ne peut pas aider. Correction de SPF/DKIM à la source.
Messages mis en quarantaine malgré le passage ARC	Action de stratégie anti-courrier indésirable substituant le résultat ARC.	Passez en revue la stratégie de mise en quarantaine. ARC remplace DMARC uniquement, et non le filtrage du courrier indésirable.

Mauvais domaine de scellement ARC configuré

Problème : vous avez ajouté votre propre domaine (par exemple, contoso.com) au lieu du domaine de scellement ARC du fournisseur.

Les en-têtes du message indiquent le domaine de scellement ARC réel du fournisseur. Vérifiez la valeur d= dans l’en-tête ARC-Seal afin d’identifier le domaine approprié à configurer en tant que scelleur approuvé :

ARC-Seal: i=1; a=rsa-sha256; d=pphosted.com; s=arcselector;
  cv=none; b=<signature>

Toutefois, lorsque vous exécutez Get-ArcConfig dans Exchange Online PowerShell, la sortie indique que votre propre domaine est configuré au lieu du domaine de scellement ARC du fournisseur :

ArcTrustedSealers : {contoso.com}

Résolution : utilisez le domaine de scellement ARC du fournisseur. Par exemple :

Set-ArcConfig -Identity Default -ArcTrustedSealers "pphosted.com"

Le service intermédiaire n’ajoute pas d’en-têtes ARC

Problème : les messages passent par votre passerelle, mais ne contiennent aucun en-tête ARC. Le service intermédiaire ne prend pas en charge ARC ou ARC n’est pas activé.

Diagnostic : recherchez dans les en-têtes de ARC-Seal:message . S’il n’existe aucun en-tête ARC-Seal, l’intermédiaire ne scelle pas.

Résolution : activez la connexion ARC dans la console de gestion de votre fournisseur :

Fournisseur	Comment activer ARC
Proofpoint	Activez ARC dans Email Protection>Email lesparamètres de routage >sortant.
Mimecast	Activer via des stratégiesde>passerelle>d’administration>Définitions>de signature ARC.
Barracuda	ARC est activé par défaut dans Email Gateway Defense. Vérifiez dans Paramètres entrants>Anti-hameçonnage.
Sophos	Activez dans Sophos Central> EmailParamètres>de sécurité>ARC.

Importante

Si votre fournisseur ne prend pas en charge ARC, envisagez d’autres solutions :

• Configurez une règle de flux de messagerie Exchange (règle de transport) pour ignorer le filtrage du courrier indésirable pour les messages provenant des adresses IP du service.
• Ajoutez les adresses IP d’envoi du service à la liste verte des adresses IP du filtre de connexion.
• Utilisez le filtrage amélioré pour les connecteurs (ignorer la liste) pour conserver l’authentification d’origine.

Chaîne ARC rompue (cv=fail)

Problème : La validation de la chaîne ARC indique cv=fail, ce qui signifie qu’un sceau ARC précédent dans la chaîne n’a pas pu être vérifié.

L’exemple suivant montre un en-tête ARC-Seal où cv=fail indique une chaîne ARC rompue :

ARC-Seal: i=2; a=rsa-sha256; d=mimecast.com; s=arc-2018;
  cv=fail; b=<signature>

Cette défaillance a généralement les causes suivantes :

• Un intermédiaire précédent a modifié le message après avoir ajouté son sceau ARC (cassant la chaîne).
• Les problèmes DNS ont empêché la recherche de la clé publique du scellant ARC.
• La clé publique ARC a été pivotée, mais les enregistrements DNS mis en cache n’ont pas expiré.

Résolution : procédez comme suit pour diagnostiquer et corriger la chaîne rompue :

1. Vérifiez la cv= valeur à chaque instance ARC (i=1, i=2, etc.) pour identifier où la chaîne s’est rompue.
2. Vérifiez que la clé publique du scellant ARC est publiée dans DNS. Par exemple, utilisez nslookup -type=TXT arcselector._domainkey.pphosted.com pour interroger l’enregistrement de clé.
3. Si DNS ne retourne aucun résultat, contactez le fournisseur au sujet de sa publication de clé ARC.
4. Si la chaîne s’interrompt entre deux services que vous contrôlez, assurez-vous que les modifications de message se produisent avant le scellement ARC, et non après.

ARC passe, mais les messages sont toujours envoyés au Email indésirable

Problème : la validation ARC réussit (arc=pass, compauth=pass reason=130), mais les messages sont toujours remis au dossier Email indésirable.

Explication : ARC remplace uniquement les échecs d’authentification DMARC. Il ne contourne pas :

• Filtrage du spam (filtrage de contenu).
• Filtrage du courrier électronique en bloc (seuil BCL).
• Actions de stratégie anti-courrier indésirable.
• Actions de règle de flux de messagerie.
• Listes d’expéditeurs approuvés/bloqués.

Diagnostic : Passez en revue l’en-tête pour déterminer si le X-Forefront-Antispam-Report filtrage du courrier indésirable basé sur le contenu a provoqué l’envoi du message à Courrier indésirable indépendamment de ARC :

X-Forefront-Antispam-Report: CIP:10.10.10.10; CTRY:US; LANG:en;
  SFV:SPM; H:mail.fabrikam.com; PTR:mail.fabrikam.com; CAT:SPM;

Si l’une des valeurs CAT:SPM, CAT:HSPM, ou SFV:SPM apparaît, le filtrage de spam (filtrage de contenu) identifie le message comme spam ou spam à haute confiance, ce qui est indépendant de l’ARC.

Résolution : Essayez les options suivantes pour résoudre le filtrage du courrier indésirable :

• Créez une règle de flux de messagerie pour contourner le filtrage du spam pour les messages provenant d’expéditeurs ou d’adresses IP de confiance.
• Ajoutez le domaine de l’expéditeur à une liste verte de stratégie anti-courrier indésirable.
• Envoyez le message en tant que faux positif via le portail Microsoft Defender.

Informations de référence sur les codes de motif CompAuth

Le tableau suivant récapitule les codes de raison d’authentification composite (CompAuth) qui apparaissent dans l’en-tête Authentication-Results .

Code de raison	Description
000	Échec de l’authentification composite du message (échec explicite).
001	Échec de l’authentification composite du message (échec implicite).
002	Le message a un contournement SPF/DKIM explicite qui empêche l’évaluation de l’authentification composite.
010	Le message a été exclu du filtrage DMARC (par exemple, envoyé à soi-même).
1xx	Échec du message DMARC avec l’action déterminée par la stratégie DMARC.
130	Remplacement ARC : authentification composite passée en raison d’un scellant ARC approuvé.
2xx	Authentification composite avec transmission réversible de message (source suspecte).
3xx	L’authentification composite n’est pas vérifiée.
4xx	Message contourné l’authentification composite.

Conseil

Après avoir ajouté ou modifié des scellants ARC approuvés, attendez jusqu’à 30 minutes pour que la configuration prenne effet. Testez avec les nouveaux messages envoyés après cette période.

Étapes suivantes

Vérifiez vos en-têtes ARC avec l’analyseur d’en-têtes de message à l’adresse https://mha.azurewebsites.net.

Configurez SPF, DKIM et DMARC pour votre domaine.

Pour diagnostiquer et corriger les échecs d’authentification par e-mail, consultez Résoudre les problèmes d’authentification par e-mail dans Microsoft 365.