Partage via


Configurer DMARC pour valider le domaine d’adresse De pour les expéditeurs dans Microsoft 365

Conseil

Saviez-vous que vous pouvez essayer gratuitement les fonctionnalités de Microsoft Defender XDR pour Office 365 Plan 2 ? Utilisez la version d’évaluation Defender for Office 365 de 90 jours sur le hub d’essais du portail Microsoft Defender. Découvrez qui peut s’inscrire et les conditions d’essai sur Try Microsoft Defender pour Office 365.

L’authentification, la création de rapports et la conformité des messages basés sur le domaine (DMARC) est une méthode d’authentification par e-mail qui permet de valider les messages envoyés à 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 de hameçonnage.

Vous activez DMARC pour un domaine en créant un enregistrement TXT dans DNS. La validation DMARC d’un e-mail implique les éléments suivants :

  • Vérifiez que les domaines dans les adresses MAIL FROM et FROM s’alignent : SPF et DKIM n’ont pas besoin des domaines dans les adresses e-mail suivantes pour « aligner » (correspondance) :

    • Adresse MAIL FROM : adresse e-mail utilisée dans la transmission du message entre les serveurs de messagerie SMTP. Cette adresse est également appelée 5321.MailFrom adresse, expéditeur P1 ou expéditeur d’enveloppe.
    • Adresse de départ : adresse e-mail dans le champ d’en-tête De affiché en tant qu’expéditeur du message dans les clients de messagerie. Cette adresse est également appelée 5322.From adresse ou expéditeur P2.

    Pour plus d’informations sur la façon dont ces adresses e-mail peuvent être dans différents domaines et utilisées pour l’usurpation d’identité, consultez Pourquoi la messagerie Internet a besoin d’une authentification.

    • DMARC utilise le résultat de SPF pour vérifier les deux conditions suivantes :

      • Le message provient d’une source autorisée pour le domaine utilisé dans l’adresse MAIL FROM (exigence de base de SPF).
      • Les domaines des adresses MAIL FROM et From dans le message sont alignés. Ce résultat nécessite que les sources valides pour le message se trouvent dans le domaine d’adresse De.
    • DMARC utilise le résultat de DKIM pour vérifier que le domaine qui a signé le message (la valeur d= dans un champ d’en-tête DKIM-Signature validé par la valeur du sélecteur s= ) s’aligne sur le domaine dans l’adresse De.

    Un message transmet DMARC si l’un des contrôles SPF ou DKIM décrits réussit. Un message échoue si les deux vérifications SPF ou DKIM décrites échouent.

  • Stratégie DMARC : spécifie ce qu’il faut faire avec les messages qui échouent à DMARC (rejet, mise en quarantaine ou aucune instruction).

  • Rapports DMARC : spécifie où envoyer les rapports agrégés (un résumé périodique des résultats DMARC positifs et négatifs) et les rapports d’investigation (également appelés rapports de défaillance ; résultats d’échec DMARC presque immédiats similaires à un rapport de non-remise ou à un message de rebond).

Avant de commencer, voici ce que vous devez savoir sur DMARC dans Microsoft 365 en fonction de votre domaine de messagerie :

  • Si vous utilisez uniquement le domaine MOERA (Microsoft Online Email Routing Address) pour la messagerie (par exemple, contoso.onmicrosoft.com) : bien que SPF et DKIM soient déjà configurés pour votre domaine *.onmicrosoft.com, vous devez créer l’enregistrement TXT DMARC pour le domaine *.onmicrosoft.com dans le Centre d’administration Microsoft 365. Pour obtenir des instructions, consultez cette section plus loin dans cet article. Pour plus d’informations sur les domaines *.onmicrosoft.com, consultez Pourquoi ai-je un domaine « onmicrosoft.com » ?.

  • Si vous utilisez un ou plusieurs domaines personnalisés pour la messagerie (par exemple, contoso.com) : si ce n’est déjà fait, vous devez configurer SPF pour tous les domaines et sous-domaines personnalisés que vous utilisez pour la messagerie. Vous devez également configurer la signature DKIM à l’aide du domaine ou du sous-domaine personnalisé afin que le domaine utilisé pour signer le message s’aligne sur le domaine dans l’adresse De. Pour obtenir des instructions, consultez les articles suivants :

    Après cela, vous devez également configurer les enregistrements TXT DMARC pour vos domaines personnalisés, comme décrit dans cet article. Vous avez également les considérations suivantes :

    • Sous-domaines :

      • Pour les services de messagerie qui ne sont pas sous votre contrôle direct (par exemple, les services de messagerie en bloc), nous vous recommandons d’utiliser un sous-domaine (par exemple, marketing.contoso.com) au lieu de votre domaine de messagerie main (par exemple, contoso.com). Vous ne souhaitez pas que les problèmes liés au courrier envoyé à partir de ces services de messagerie affectent la réputation du courrier envoyé par les employés de votre domaine de messagerie main. Pour plus d’informations sur l’ajout de sous-domaines, consultez Puis-je ajouter des sous-domaines personnalisés ou plusieurs domaines à Microsoft 365 ?.
      • Contrairement à SPF et DKIM, l’enregistrement TXT DMARC pour un domaine couvre automatiquement tous les sous-domaines (y compris les sous-domaines inexistants) qui n’ont pas leur propre enregistrement TXT DMARC. En d’autres termes, vous pouvez interrompre l’héritage de DMARC sur un sous-domaine en créant un enregistrement TXT DMARC dans ce sous-domaine. Toutefois, chaque sous-domaine nécessite un enregistrement SPF et DKIM pour DMARC.
    • Si vous possédez des domaines inscrits mais inutilisés : si vous possédez des domaines inscrits qui ne sont pas utilisés pour la messagerie ou quoi que ce soit (également appelés domaines parqués), configurez les enregistrements TXT DMARC dans ces domaines pour spécifier qu’aucun e-mail ne doit jamais provenir de ces domaines. Cette directive inclut le domaine *.onmicrosoft.com si vous ne l’utilisez pas pour les e-mails.

  • Les vérifications DMARC pour les messages entrants peuvent avoir besoin d’aide : si vous utilisez un service de messagerie qui modifie les messages en transit avant leur remise dans Microsoft 365, vous pouvez identifier le service en tant que scellant ARC approuvé afin que les messages modifiés n’échouent pas automatiquement aux vérifications DMARC. Pour plus d’informations, consultez la section Étapes suivantes à la fin de cet article.

Le reste de cet article décrit l’enregistrement TXT DMARC que vous devez créer pour les domaines dans Microsoft 365, la meilleure façon de configurer progressivement et en toute sécurité DMARC pour les domaines personnalisés dans Microsoft 365, et comment Microsoft 365 utilise DMARC sur le courrier entrant .

Conseil

Pour créer l’enregistrement TXT DMARC pour votre domaine *.onmicrosoft.com dans le Centre d’administration Microsoft 365, consultez cette section plus loin dans cet article.

Il n’existe aucun portail d’administration ou applet de commande PowerShell dans Microsoft 365 pour vous permettre de gérer les enregistrements TXT DMARC dans vos domaines personnalisés . Au lieu de cela, vous créez l’enregistrement TXT DMARC auprès de votre bureau d’enregistrement de domaines ou du service d’hébergement DNS (souvent la même société).

Nous fournissons des instructions pour créer l’enregistrement TXT de preuve de propriété de domaine pour Microsoft 365 dans de nombreux bureaux d’enregistrement de domaines. Vous pouvez utiliser ces instructions comme point de départ pour créer des enregistrements TXT DMARC. Pour plus d’informations, consultez Ajouter des enregistrements DNS pour connecter votre domaine.

Si vous n’êtes pas familiarisé avec la configuration DNS, contactez votre bureau d’enregistrement de domaines et demandez de l’aide.

Syntaxe des enregistrements TXT DMARC

Les enregistrements TXT DMARC sont décrits de manière exhaustive dans RFC 7489.

La syntaxe de base de l’enregistrement TXT DMARC pour un domaine dans Microsoft 365 est la suivante :

Nom d’hôte : _dmarc
Valeur TXT : v=DMARC1; <DMARC policy>; <Percentage of DMARC failed mail subject to DMARC policy>; <DMARC reports>

Ou

Nom d’hôte : _dmarc
Valeur TXT : v=DMARC1; p=<reject | quarantine | none>; pct=<0-100>; rua=mailto:<DMARCAggregateReportURI>; ruf=mailto:<DMARCForensicReportURI>

Par exemple :

Nom d’hôte : _dmarc
Valeur TXT : v=DMARC1; p=reject; pct=100; rua=mailto:rua@contoso.com; ruf=mailto:ruf@contoso.com

  • La valeur _dmarc du nom d’hôte est obligatoire.

  • v=DMARC1; identifie l’enregistrement TXT en tant qu’enregistrement TXT DMARC.

  • Stratégie DMARC : indique au système de messagerie de destination ce qu’il faut avec les messages qui échouent à DMARC, comme décrit plus haut dans cet article :

    • p=reject: les messages doivent être rejetés. Ce qui arrive réellement au message dépend du système de messagerie de destination, mais les messages sont généralement ignorés.
    • p=quarantine: les messages doivent être acceptés, mais marqués. Ce qui arrive réellement au message dépend du système de messagerie de destination. Par exemple, le message peut être mis en quarantaine en tant que courrier indésirable, remis au dossier Email indésirable ou remis à la boîte de réception avec un identificateur ajouté à l’objet ou au corps du message.
    • p=none: aucune action suggérée pour les messages qui échouent à DMARC. Ce qui arrive au message dépend des fonctionnalités de protection des e-mails dans le système de messagerie de destination. Vous utilisez cette valeur pour tester et optimiser la stratégie DMARC , comme décrit plus loin dans cet article.

    Conseil

    Les messages sortants provenant de domaines dans Microsoft 365 qui échouent aux vérifications DMARC par le service de messagerie de destination sont acheminés via le pool de remise à haut risque pour les messages sortants si la stratégie DMARC pour le domaine est p=reject ou p=quarantine. Il n’existe aucune substitution pour ce comportement.

  • Pourcentage de messages DMARC ayant échoué soumis à la stratégie DMARC : indique au système de messagerie de destination le nombre de messages qui échouent (pourcentage) auxquels la stratégie DMARC est appliquée. Par exemple, pct=100 signifie que tous les messages qui échouent à DMARC obtiennent la stratégie DMARC qui leur est appliquée. Vous utilisez des valeurs inférieures à 100 pour le test et le réglage de la stratégie DMARC , comme décrit plus loin dans cet article. Si vous n’utilisez pct=pas , la valeur par défaut est pct=100.

  • Rapports DMARC :

    • URI du rapport d’agrégation DMARC : la rua=mailto: valeur identifie où envoyer le rapport d’agrégation DMARC. Le rapport d’agrégation a les propriétés suivantes :

      • Les messages électroniques qui contiennent le rapport d’agrégation sont généralement envoyés une fois par jour (le rapport contient les résultats DMARC du jour précédent). La ligne Objet contient le domaine de destination qui a envoyé le rapport (Submitter) et le domaine source pour les résultats DMARC (Domaine de rapport).
      • Les données DMARC se trouve dans une pièce jointe d’e-mail XML qui est probablement compressée par GZIP. Le schéma XML est défini à l’annexe C de la RFC 7489. Le rapport contient les informations suivantes :
        • Adresses IP des serveurs ou services qui envoient des messages à l’aide de votre domaine.
        • Indique si les serveurs ou les services réussissent ou échouent à l’authentification DMARC.
        • Actions effectuées par DMARC sur les messages qui échouent à l’authentification DMARC (en fonction de la stratégie DMARC).

      Conseil

      Les informations contenues dans le rapport d’agrégation peuvent être vastes et difficiles à analyser. Pour mieux comprendre les données, vous pouvez utiliser les options suivantes pour la création de rapports DMARC :

      • Créer une automatisation à l’aide de PowerShell ou de Microsoft Power BI.
      • Utilisez un service externe. Pour obtenir la liste des services, recherchez DMARC dans le catalogue MISA (Microsoft Intelligent Security Association) à l’adresse https://www.microsoft.com/misapartnercatalog. Les services de création de rapports DMARC décrivent toutes les valeurs personnalisées requises dans l’enregistrement TXT DMARC.
    • URI du rapport d’investigation DMARC : la ruf=mailto: valeur identifie où envoyer le rapport DMARC Forensic (également appelé rapport d’échec DMARC). Le rapport est généré et envoyé immédiatement après une défaillance DMARC, comme un rapport de non-remise (également appelé notification d’échec de remise ou message de rebond).

    Conseil

    Vous devez régulièrement consulter les rapports d’agrégation DMARC pour surveiller d’où provient le courrier électronique de vos domaines et pour case activée les échecs DMARC involontaires (faux positifs).

    Les systèmes de messagerie de destination individuels sont chargés de vous renvoyer les rapports DMARC. La quantité et la variété des rapports DMARC varient de la même façon que le volume et la variété du courrier envoyé à partir de votre organization varient. Par exemple, attendez-vous à un volume de courrier inférieur pendant les jours fériés et à un volume de courrier plus élevé pendant les événements de l’organisation. Il est préférable de désigner des personnes spécifiques pour surveiller les rapports DMARC et d’utiliser une boîte aux lettres ou un groupe Microsoft 365 spécifique pour recevoir les rapports DMARC (ne pas remettre les rapports à la boîte aux lettres d’un utilisateur).

Pour plus d’informations sur DMARC, utilisez les ressources suivantes :

Utilisez la Centre d’administration Microsoft 365 pour ajouter des enregistrements TXT DMARC pour les domaines *.onmicrosoft.com dans Microsoft 365

  1. Dans le Centre d’administration Microsoft 365 sur https://admin.microsoft.com, sélectionnez Afficher tous les>domaines de paramètres>. Ou, pour accéder directement à la page Domaines , utilisez https://admin.microsoft.com/Adminportal/Home#/Domains.

  2. Dans la page Domaines, sélectionnez le domaine *.onmicrosoft.com dans la liste en cliquant n’importe où dans la ligne autre que la zone case activée en regard du nom de domaine.

  3. Dans la page des détails du domaine qui s’ouvre, sélectionnez l’onglet Enregistrements DNS .

  4. Sous l’onglet Enregistrements DNS , sélectionnez Ajouter un enregistrement.

  5. Dans le menu volant Ajouter un enregistrement DNS personnalisé qui s’ouvre, configurez les paramètres suivants :

    • Type : vérifiez que TXT (Texte) est sélectionné.

    • Nom TXT : entrez _dmarc.

    • Valeur TXT : entrez v=DMARC1; p=reject.

      Conseil

      Pour spécifier des destinations pour les rapports DMARC Aggregate et DMARC Forensic, utilisez la syntaxe v=DMARC1; p=reject rua=mailto:<emailaddress>; ruf=mailto:<emailaddress>. Par exemple : v=DMARC1; p=reject rua=mailto:rua@contoso.onmicrosoft.com; ruf=mailto:ruf@contoso.onmicrosoft.com.

      Les fournisseurs de rapports DMARC dans le catalogue https://www.microsoft.com/misapartnercatalog MISA sur facilitent l’affichage et l’interprétation des résultats DMARC.

    • TTL : vérifiez que 1 heure est sélectionnée.

    Lorsque vous avez terminé le menu volant Ajouter un enregistrement DNS personnalisé , sélectionnez Enregistrer.

Configurer DMARC pour les domaines personnalisés actifs dans Microsoft 365

Conseil

Comme mentionné précédemment dans cet article, vous devez créer des enregistrements TXT SPF et configurer la signature DKIM pour tous les domaines personnalisés et sous-domaines que vous utilisez pour envoyer des e-mails dans Microsoft 365 avant de configurer DMARC pour les domaines ou sous-domaines personnalisés.

Nous vous recommandons d’adopter une approche progressive de la configuration de DMARC pour vos domaines Microsoft 365. L’objectif est d’accéder à une p=reject stratégie DMARC pour tous vos domaines et sous-domaines personnalisés, mais vous devez tester et vérifier en cours de route pour empêcher les systèmes de messagerie de destination de rejeter les messages de qualité en raison de défaillances DMARC involontaires.

Votre plan de déploiement DMARC doit suivre les étapes suivantes. Commencez par un domaine ou un sous-domaine avec un faible volume de courrier et/ou moins de sources de courrier potentielles (moins de chances que les messages légitimes provenant de sources inconnues soient bloqués) :

  1. Commencez par une stratégie DMARC de p=none et surveillez les résultats pour le domaine. Par exemple :

    Enregistrement TXT DMARC pour marketing.contoso.com :

    Nom d’hôte : _dmarc
    Valeur TXT : v=DMARC1; p=none; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

    Les rapports DMARC Aggregate et DMARC Forensic fournissent les numéros et les sources des messages qui réussissent et échouent aux vérifications DMARC. Vous pouvez voir quelle partie de votre trafic de courrier légitime est ou n’est pas couverte par DMARC, et résoudre les problèmes. Vous pouvez également voir le nombre de messages frauduleux envoyés et d’où ils sont envoyés.

  2. Augmentez la stratégie DMARC et p=quarantine surveillez les résultats du domaine.

    Après avoir passé suffisamment de temps à surveiller les effets de p=none, vous pouvez augmenter la stratégie DMARC sur p=quarantine pour le domaine. Par exemple :

    Enregistrement TXT DMARC pour marketing.contoso.com :

    Nom d’hôte : _dmarc
    Valeur TXT : v=DMARC1; p=quarantine; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

    Vous pouvez également utiliser la pct= valeur pour affecter progressivement davantage de messages et vérifier les résultats. Par exemple, vous pouvez déplacer les incréments suivants :

    • pct=10
    • pct=25
    • pct=50
    • pct=75
    • pct=100
  3. Augmentez la stratégie DMARC et p=reject surveillez les résultats du domaine.

    Après avoir passé suffisamment de temps à surveiller les effets de p=quarantine, vous pouvez augmenter la stratégie DMARC sur p=reject pour le domaine. Par exemple :

    Enregistrement TXT DMARC pour marketing.contoso.com :

    Nom d’hôte : _dmarc
    Valeur TXT : v=DMARC1; p=reject; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

    Vous pouvez également utiliser la pct= valeur pour affecter progressivement davantage de messages et vérifier les résultats.

  4. Répétez les trois étapes précédentes pour les sous-domaines restants d’augmentation du volume et/ou de la complexité, en enregistrant le domaine parent pour la dernière fois.

    Conseil

    Bloquer les e-mails légitimes dans un volume important est inacceptable pour les utilisateurs, mais il est presque inévitable que vous obteniez des faux positifs. Traitez lentement et méthodiquement les problèmes qui sont révélés dans les rapports DMARC. Les fournisseurs de rapports DMARC dans le catalogue https://www.microsoft.com/misapartnercatalog MISA à facilitent l’affichage et l’interprétation des résultats DMARC.

  5. Comme décrit précédemment, les sous-domaines héritent des paramètres d’enregistrement TXT DMARC du domaine parent, qui peuvent être remplacés par un enregistrement TXT DMARC distinct dans le sous-domaine. Lorsque vous avez terminé de configurer DMARC dans un domaine et tous les sous-domaines, et que les paramètres DMARC sont identiques pour le domaine parent et tous les sous-domaines, vous pouvez éliminer les enregistrements TXT DMARC dans les sous-domaines et vous appuyer sur l’enregistrement TXT DMARC unique dans le domaine parent.

Enregistrements TXT DMARC pour les domaines parqués dans Microsoft 365

Conseil

L’enregistrement TXT SPF recommandé pour les domaines parqués qui n’envoient pas de courrier est décrit dans Enregistrements TXT SPF pour les domaines personnalisés dans Microsoft 365. Comme décrit dans Configurer DKIM pour signer les messages à partir de votre domaine Microsoft 365, nous ne recommandons pas les enregistrements CNAME DKIM pour les domaines parqués.

  1. Si vous avez inscrit des domaines dont personne sur Internet ne doit s’attendre à recevoir des messages électroniques, créez l’enregistrement TXT DMARC suivant auprès du bureau d’enregistrement de domaines pour le domaine :

    Nom d’hôte : _dmarc
    Valeur TXT : v=DMARC1; p=reject;

    • La pct= valeur n’est pas incluse, car la valeur par défaut est pct=100.
    • Les rua=mailto: valeurs et ruf=mailto: ne sont sans doute pas nécessaires dans ce scénario, car aucun courrier valide ne doit jamais provenir d’expéditeurs dans le domaine.
  2. Si vous n’utilisez pas le domaine *.onmicrosoft.com pour envoyer des messages, vous devez également ajouter l’enregistrement TXT DMARC pour votre domaine *.onmicrosoft.com.

DMARC pour le courrier entrant dans Microsoft 365

  • Les vérifications DMARC sur les messages entrant dans Microsoft 365 sont affectées par les fonctionnalités suivantes dans Exchange Online Protection (EOP) :

    • Indique si l’intelligence contre l’usurpation d’identité est activée ou désactivée dans la stratégie anti-hameçonnage qui a vérifié le message. La désactivation de l’intelligence contre l’usurpation d’identité désactive la protection implicite contre les vérifications d’authentification composite uniquement.
    • Indique si le paramètre Respecter l’enregistrement DMARC lorsque le message est détecté comme usurpation d’identité est activé ou désactivé dans la stratégie anti-hameçonnage qui a vérifié le message, et les actions spécifiées basées sur la stratégie DMARC du domaine source (p=quarantineou p=reject dans l’enregistrement TXT DMARC).

    Pour plus d’informations, consultez Protection contre l’usurpation d’identité et stratégies DMARC de l’expéditeur.

    Pour afficher les valeurs par défaut de ces paramètres dans les stratégies anti-hameçonnage, case activée les valeurs de paramètre dans le tableau paramètres de stratégie anti-hameçonnage EOP.

  • Microsoft 365 n’envoie pas de rapports d’investigation DMARC (également appelés rapports d’échec DMARC), même s’il existe une adresse valide ruf=mailto: dans l’enregistrement TXT DMARC du domaine source.

  • Microsoft 365 envoie des rapports d’agrégation DMARC à tous les domaines avec une adresse valide rua=mailto: dans les enregistrements TXT DMARC, à condition que l’enregistrement MX du domaine Microsoft 365 pointe directement vers Microsoft 365.

    Si le courrier provenant d’Internet est acheminé via un service ou un appareil tiers avant la remise à Microsoft 365 (l’enregistrement MX pointe ailleurs que Microsoft 365), les rapports d’agrégation DMARC ne sont pas envoyés. Cette limitation inclut les scénarios EOP hybrides ou autonomes où le courrier est remis à l’environnement local avant d’être acheminé vers Microsoft 365 à l’aide d’un connecteur.

    Conseil

    Lorsqu’un service ou un appareil tiers se trouve devant le courrier entrant dans Microsoft 365, le filtrage amélioré pour les connecteurs (également appelé skip listing) identifie correctement la source des messages Internet pour SPF, DKIM (si le service modifie les messages) et la validation DMARC.

Résolution des problèmes liés à DMARC

Vous pouvez utiliser le graphique suivant pour résoudre les problèmes d’authentification DMARC.

Graphique de résolution des problèmes pour DMARC

Étapes suivantes

Pour le courrier entrant dans Microsoft 365, vous devrez peut-être également configurer des scellants ARC approuvés si vous utilisez des services qui modifient les messages en transit avant leur remise à votre organization. Pour plus d’informations, consultez Configurer des scellants ARC approuvés.