Partager via

Configurer SPF pour identifier les sources de courrier valides pour votre domaine Microsoft 365

Conseil

Saviez-vous que vous pouvez essayer gratuitement les fonctionnalités de Microsoft Defender 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.

Sender Policy Framework (SPF) 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 par hameçonnage.

L’objectif principal de SPF est de valider les sources de messagerie pour un domaine. Plus précisément, SPF utilise un enregistrement TXT dans DNS pour identifier les sources de courrier valides pour le domaine. Les systèmes de réception de courrier utilisent l’enregistrement TXT SPF pour vérifier que le courrier électronique provenant de l’adresse de l’expéditeur utilisée lors de la transmission SMTP du message (appelée adresse MAIL FROM, 5321.MailFrom adresse, expéditeur P1 ou expéditeur d’enveloppe) provient d’une source de courrier connue et désignée pour ce domaine.

Par exemple, si votre domaine de messagerie dans Microsoft 365 est contoso.com, vous créez un enregistrement TXT SPF dans DNS pour le domaine contoso.com afin d’identifier Microsoft 365 comme source autorisée de courrier provenant de contoso.com. Les systèmes de messagerie de destination case activée l’enregistrement TXT SPF dans contoso.com pour déterminer si le message provient d’une source autorisée pour contoso.com e-mail.

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

  • Si vous utilisez uniquement le domaine MOERA (Microsoft Online Email Routing Address) pour le courrier électronique (par exemple, contoso.onmicrosoft.com) : vous n’avez rien à faire. L’enregistrement TXT SPF est déjà configuré pour vous. Microsoft est propriétaire du domaine onmicrosoft.com. Nous sommes donc responsables de la création et de la gestion des enregistrements DNS dans ce domaine et sous-domaines. 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) : le processus d’inscription Microsoft 365 vous obligeait déjà à créer ou à modifier l’enregistrement TXT SPF dans DNS pour votre domaine personnalisé afin d’identifier Microsoft 365 en tant que source de messagerie autorisée. Toutefois, vous avez encore plus de travail à faire pour une protection maximale des e-mails :

    • Considérations relatives aux 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 ?.

      • Chaque sous-domaine que vous utilisez pour envoyer des e-mails à partir de Microsoft 365 nécessite son propre enregistrement TXT SPF. Par exemple, l’enregistrement TXT SPF pour contoso.com ne couvre pas marketing.contoso.com ; marketing.contoso.com a besoin de son propre enregistrement TXT SPF.

        Conseil

        Email protection de l’authentification pour les sous-domaines non définis est couverte par DMARC. Tous les sous-domaines (définis ou non) héritent des paramètres DMARC du domaine parent (qui peuvent être remplacés par sous-domaine). Pour plus d’informations, consultez Configurer DMARC pour valider le domaine d’adresse De pour les expéditeurs dans Microsoft 365.

    • 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 SPF pour indiquer qu’aucun e-mail ne doit jamais provenir de ces domaines, comme décrit plus loin dans cet article.

  • SPF seul ne suffit pas. Pour obtenir le meilleur niveau de protection de la messagerie pour vos domaines personnalisés, vous devez également configurer DKIM et DMARC dans le cadre de votre stratégie globale d’authentification de messagerie . Pour plus d’informations, consultez la section Étapes suivantes à la fin de cet article.

    Importante

    Dans les organisations complexes où il est difficile d’identifier toutes les sources de courrier valides pour le domaine, il est important de configurer rapidement la signature DKIM et DMARC (en mode « ne pas agir ») pour le domaine. Un service de création de rapports DMARC est très utile pour identifier les sources de courrier électronique et les défaillances SPF pour le domaine.

Le reste de cet article décrit les enregistrements TXT SPF que vous devez créer pour les domaines personnalisés dans Microsoft 365.

Conseil

Microsoft 365 ne contient aucun portail d’administration ou applet de commande PowerShell pour gérer les enregistrements SPF dans votre domaine. Au lieu de cela, vous créez l’enregistrement TXT SPF 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 la valeur d’enregistrement TXT SPF. 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 SPF

Les enregistrements TXT SPF sont décrits de manière exhaustive dans RFC 7208.

La syntaxe de base de l’enregistrement TX SPF pour un domaine personnalisé dans Microsoft 365 est la suivante :

v=spf1 <valid mail sources> <enforcement rule>

Ou :

v=spf1 [<ip4>|<ip6>:<PublicIPAddress1> <ip4>|<ip6>:<PublicIPAddress2>... <ip4>|<ip6>:<PublicIPAddressN>] [include:<DomainName1> include:<DomainName1>... include:<DomainNameN>] <-all | ~all>

Par exemple :

v=spf1 ip4:192.168.0.10 ip4:192.168.0.12 include:spf.protection.outlook.com -all

  • v=spf1 identifie l’enregistrement TXT en tant qu’enregistrement TXT SPF.

  • Sources de courrier valides : sources de courrier valides spécifiées pour le domaine. Utilise des domaines, des adresses IP ou les deux :

    • Domaines : include: les valeurs spécifient d’autres services ou domaines comme sources valides de courrier provenant du domaine d’origine. Ces valeurs aboutissent finalement à une adresse IP à l’aide de recherches DNS.

      La plupart des organisations Microsoft 365 ont besoin include:spf.protection.outlook.com de l’enregistrement TXT SPF pour le domaine. D’autres services de messagerie tiers nécessitent souvent une valeur supplémentaire include: pour identifier le service en tant que source valide d’e-mail à partir du domaine d’origine.

    • Adresses IP : une valeur d’adresse IP inclut les deux éléments suivants :

      • Valeur ip4: ou ip6: pour identifier le type d’adresse IP.
      • Adresse IP pouvant être résolue publiquement du système de messagerie source. Par exemple :
        • Une adresse IP individuelle (par exemple, 192.168.0.10).
        • Plage d’adresses IP utilisant la notation CIDR (Classless Inter-Domain Routing) (par exemple 192.168.0.1/26). Assurez-vous que la plage n’est pas trop grande ou trop petite.

      Dans Microsoft 365, vous utilisez généralement des adresses IP dans l’enregistrement TXT SPF uniquement si vous avez des serveurs de messagerie locaux qui envoient des messages à partir du domaine Microsoft 365 (par exemple, Exchange Server déploiements hybrides). Certains services de messagerie tiers peuvent également utiliser une plage d’adresses IP au lieu d’une include: valeur dans l’enregistrement TXT SPF.

  • Règle d’application : indique aux systèmes de messagerie de destination ce qu’il faut faire avec les messages provenant de sources qui ne sont pas spécifiées dans l’enregistrement TXT SPF pour le domaine. Les valeurs valides sont les suivantes :

    • -all (échec dur) : les sources non spécifiées dans l’enregistrement TXT SPF ne sont pas autorisées à envoyer des messages pour le domaine. Les messages doivent donc ê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.

      Pour les domaines Microsoft 365, nous recommandons -all (échec difficile), car nous recommandons également DKIM et DMARC pour le domaine. La stratégie DMARC spécifie ce qu’il faut faire aux messages qui échouent à SPF ou DKIM, et les rapports DMARC vous permettent de valider les résultats.

      Conseil

      Comme indiqué précédemment, DMARC configuré avec un service de création de rapports DMARC aide grandement à identifier les sources de messagerie et les défaillances SPF pour le domaine.

    • ~all (échec logiciel) : les sources non spécifiées dans l’enregistrement TXT SPF ne sont probablement pas autorisées à envoyer des messages pour le domaine. Les messages doivent donc ê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.

      Étant donné que nous recommandons également DKIM et DMARC pour les domaines Microsoft 365, les différences entre -all (échec dur) et ~all (échec logiciel) sont efficacement éliminées (DMARC traite l’un ou l’autre résultat comme un échec SPF). DMARC utilise SPF pour confirmer l’alignement des domaines dans les adresses MAIL FROM et From et que le message provient d’une source valide pour le domaine From.

    Conseil

    ?all (neutre) est également disponible pour suggérer aucune action spécifique sur les messages provenant de sources non identifiées. Cette valeur est utilisée pour le test, et nous ne recommandons pas cette valeur dans les environnements de production.

Points importants à retenir :

  • Chaque domaine ou sous-domaine défini dans DNS nécessite un enregistrement TXT SPF, et un seul enregistrement SPF est autorisé par domaine ou sous-domaine. Email protection de l’authentification pour les sous-domaines non définis est mieux gérée par DMARC.
  • Vous ne pouvez pas modifier l’enregistrement TXT SPF existant pour le domaine *.onmicrosoft.com.
  • Lorsque le système de messagerie de destination vérifie les sources de courrier valides dans l’enregistrement SPF, la validation SPF échoue si le case activée nécessite trop de recherches DNS. Pour plus d’informations, consultez la section Résolution des problèmes liés aux enregistrements TXT SPF plus loin dans cet article.

Enregistrements TXT SPF pour les domaines personnalisés dans Microsoft 365

Conseil

Comme mentionné précédemment dans cet article, vous créez l’enregistrement TXT SPF pour un domaine ou un sous-domaine auprès du bureau d’enregistrement de domaines pour le domaine. Aucune configuration d’enregistrement TXT SPF n’est disponible dans Microsoft 365.

  • Scénario : Vous utilisez contoso.com pour le courrier électronique dans Microsoft 365, et Microsoft 365 est la seule source d’e-mails provenant de contoso.com.

    Enregistrement TXT SPF pour contoso.com dans Microsoft 365 et Microsoft 365 Government Community Cloud (GCC) :

    v=spf1 include:spf.protection.outlook.com -all

    Enregistrement TXT SPF pour contoso.com dans Microsoft 365 Government Community Cloud High (GCC High) et Microsoft 365 Department of Defense (DoD) :

    v=spf1 include:spf.protection.office365.us -all

    Enregistrement TXT SPF pour contoso.com dans Microsoft 365 géré par 21Vianet

    v=spf1 include:spf.protection.partner.outlook.cn -all

  • Scénario : vous utilisez contoso.com pour le courrier électronique dans Microsoft 365, et vous avez déjà configuré l’enregistrement TXT SPF dans contoso.com avec toutes les sources d’e-mail du domaine. Vous êtes également propriétaire des domaines contoso.net et contoso.org, mais vous ne les utilisez pas pour les e-mails. Vous souhaitez spécifier que personne n’est autorisé à envoyer des e-mails à partir de contoso.net ou de contoso.org.

    Enregistrement TXT SPF pour contoso.net :

    v=spf1 -all

    Enregistrement TXT SPF pour contoso.org :

    v=spf1 -all

  • Scénario : vous utilisez contoso.com pour le courrier électronique dans Microsoft 365. Vous prévoyez d’envoyer des messages à partir des sources suivantes :

    • Un serveur de messagerie local avec l’adresse de messagerie externe 192.168.0.10. Étant donné que vous avez un contrôle direct sur cette source d’e-mail, nous considérons qu’il est acceptable d’utiliser le serveur pour les expéditeurs du domaine contoso.com.
    • Service de publipostage en bloc Adatum. Étant donné que vous n’avez pas de contrôle direct sur cette source d’e-mail, nous vous recommandons d’utiliser un sous-domaine. Vous devez donc créer marketing.contoso.com à cet effet. Selon la documentation du service Adatum, vous devez ajouter include:servers.adatum.com à l’enregistrement TXT SPF pour votre domaine.

    Enregistrement TXT SPF pour contoso.com :

    v=spf1 ip4:192.168.0.10 include:spf.protection.outlook.com -all

    Enregistrement TXT SPF pour marketing.contoso.com :

    v=spf1 include:servers.adatum.com include:spf.protection.outlook.com -all

Résolution des problèmes liés aux enregistrements TXT SPF

  • Un enregistrement SPF par domaine ou sous-domaine : plusieurs enregistrements TXT SPF pour le même domaine ou sous-domaine provoquent une boucle de recherche DNS qui entraîne l’échec de SPF. Utilisez donc un seul enregistrement SPF par domaine ou sous-domaine.

  • Moins de 10 recherches DNS : lorsque les systèmes de messagerie de destination interrogent l’enregistrement TXT SPF pour obtenir des sources valides pour le domaine d’adresse MAIL FROM, la requête analyse les adresses IP et include: les instructions dans l’enregistrement jusqu’à ce que la source du message (finalement, une adresse IP) corresponde à l’une des sources spécifiées. Si le nombre de recherches DNS (qui peut être différent du nombre de requêtes DNS) est supérieur à 10, le message échoue avec une erreur permanente (également appelée ).permerror Le système de messagerie de destination rejette le message dans un rapport de non-remise (également appelé notification d’échec de remise ou message de rebond) avec l’une des erreurs suivantes :

    • Le message a dépassé le nombre de sauts.
    • Le message a demandé trop de recherches.

    Dans l’enregistrement TXT SPF, les adresses IP individuelles ou les plages d’adresses IP ne provoquent pas de recherche DNS. Chaque include: instruction nécessite au moins une recherche DNS, et d’autres recherches peuvent être nécessaires si la include: valeur pointe vers des ressources imbriquées. En d’autres termes, avoir moins de 10 include: instructions ne garantit pas moins de 10 recherches DNS.

    Gardez également à l’esprit que les systèmes de messagerie de destination évaluent les sources dans l’enregistrement TXT SPF de gauche à droite. L’évaluation s’arrête lorsque la source du message est validée, et aucune autre source n’est vérifiée. Par conséquent, un enregistrement TXT SPF peut contenir suffisamment d’informations pour provoquer plus de 10 recherches DNS, mais la validation de certaines sources de courrier par certaines destinations n’est pas suffisamment approfondie dans l’enregistrement pour entraîner une erreur.

    En plus de préserver la réputation de votre domaine de messagerie main, le fait de ne pas dépasser le nombre de recherches DNS est une autre raison d’utiliser des sous-domaines pour d’autres services de messagerie que vous ne contrôlez pas.

Vous pouvez utiliser des outils en ligne gratuits pour afficher votre enregistrement TXT SPF et d’autres enregistrements DNS pour votre domaine. Certains outils calculent même le nombre de recherches d’enregistrements DNS requises par votre enregistrement TXT SPF.

Étapes suivantes

Comme décrit dans Comment SPF, DKIM et DMARC fonctionnent ensemble pour authentifier les expéditeurs de messages électroniques, SPF seul n’est pas suffisant pour empêcher l’usurpation de votre domaine Microsoft 365. Vous devez également configurer DKIM et DMARC pour une protection optimale. Pour plus d’informations, voir :

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.