SPF dans Exchange : comment vérifier, publier et corriger SPF dans Exchange

En mai 2025, Microsoft a commencé à rejeter les e-mails provenant d'expéditeurs à fort volume qui ne disposaient pas de SPF, DKIM et DMARC valides. Si votre domaine envoie plus de 5 000 messages par jour vers Outlook.com ou Hotmail.com sans authentification appropriée, ces messages n'atteignent jamais la boîte de réception.

Google et Yahoo ont mis en place des exigences similaires en février 2024. Selon l'équipe chargée de la sécurité des e-mails chez Google, cette première vague de mesures a permis de réduire d'environ 75 % le nombre de messages non authentifiés reçus par les utilisateurs de Gmail.

Selon le rapport IC3 du FBI sur la cybercriminalité, 2023. 

Le problème dans les environnements Exchange, c'est que SPF passent inaperçus. Exchange Online ne vous avertit pas lorsque votre enregistrement ne fonctionne plus. Il n'existe pas de tableau de bord intégré affichant les taux de réussite. La plupart des équipes ne s'en rendent compte que plusieurs semaines plus tard, lorsque les utilisateurs se plaignent que leurs e-mails sont rejetés, ou lorsque le service marketing signale que les taux d'ouverture se sont effondrés.

Ce guide explique comment vérifier votre SPF Exchange à l'aide de quatre méthodes, comment publier l'enregistrement correct pour les configurations Exchange Online, sur site et hybrides, et comment corriger les erreurs SPF les plus courantes SPF (y compris la limite de 10 requêtes qui rend SPF inopérant SPF la plupart des entreprises de taille moyenne), comment Exchange Online évalue réellement SPF arrière-plan, et comment surveiller SPF plutôt que de le vérifier une seule fois puis de l'oublier.

Comment vérifier votre SPF Exchange (étape par étape)

Il existe quatre méthodes fiables pour vérifier votre SPF , de la plus rapide à la plus complète. Utilisez la méthode 1 pour une vérification rapide, et la méthode 4 pour une visibilité opérationnelle continue.

Méthode 1 : Utiliser un outil SPF (la plus rapide)

1. Ouvrez n'importe quel SPF (le SPF de PowerDMARC est gratuit et ne nécessite aucune inscription)
2. Saisissez votre nom de domaine (par exemple, votredomaine.com, sans le préfixe http://) et 
3. Vérifiez le résultat

La recherche renvoie plusieurs résultats SPF . Voici la signification de chaque champ de sortie et les points auxquels vous devez prêter attention lors de leur examen : 

Un enregistrement peut s'analyser correctement et le nombre de résultats peut être de six, mais il se peut tout de même qu'une source d'envoi légitime manque à l'appel. Le SPF valide le contenu du DNS, mais il ne sait pas quelles adresses IP devraient être autorisées.

Méthode 2 : Vérification via le Centre d'administration Microsoft 365

Connectez-vous au Centre d'administration Microsoft 365. Accédez à Paramètres → Domaines → sélectionnez votre domaine → Enregistrements DNS. Dans la section Microsoft Exchange, vérifiez que le statut de l'enregistrement TXT indique « OK ».

Si le statut indique « Entrée non valide », cela signifie que votre SPF est manquant ou qu'il ne contient pas la déclaration requise « include:spf.protection.outlook.com ». C'est le moyen le plus rapide de vérifier SPF quitter le portail d'administration.

Méthode 3 : Vérification via la ligne de commande (nslookup / dig)

Pour le dépannage côté serveur ou lorsque vous ne disposez pas d'un accès via un navigateur, vous pouvez interroger l'enregistrement SPF de votre domaine directement depuis la ligne de commande.

Exécutez l'une des commandes suivantes : 

# Windows

nslookup -type=txt votredomaine.com

# Linux 

/ macOSdig txt votredomaine.com +short

Le résultat renvoie l'enregistrement TXT brut. Recherchez la ligne commençant par v=spf1. Si vous voyez deux lignes de ce type, cela signifie que vous avez plusieurs SPF , ce qui entraîne immédiatement une erreur permanente (PermError). Corrigez ce problème avant toute autre chose.

Méthode 4 : Vérification via les rapports agrégés DMARC (la référence absolue)

Les rapports agrégés fournis par les destinataires, tels que Gmail, Yahoo, Microsoft, Mail.ru et les FAI régionaux, indiquent les taux SPF pour tous les e-mails envoyés par votre domaine, et pas seulement pour un message de test. C'est le seul moyen d'obtenir une vue d'ensemble complète et actualisée de SPF .

Si vous publiez des rapports DMARC avec une balise `rua=`, vous recevez déjà ces rapports. La plupart des entreprises les reçoivent, mais rares sont celles qui les consultent, car le format XML brut est illisible sans une plateforme permettant de l'analyser.

PowerDMARC traite ces rapports quotidiennement et présente des analyses SPF dans un tableau de bord dédié, avec les taux de réussite/échec par source d'envoi, le suivi des requêtes DNS et des alertes lorsqu'un nouvel expéditeur non autorisé apparaît.

Méthode 5 : Vérification via les en-têtes des messages Exchange (validation en conditions réelles)

Pour vérifier comment SPF évalué par un destinataire réel :

• Envoyez un message test depuis votre domaine vers une adresse externe (un compte Gmail personnel fera l'affaire).
• Ouvrez le message et récupérez l'intégralité des en-têtes. Dans Outlook : Fichier → Propriétés → En-têtes Internet. Dans OWA ou Gmail : Afficher la source / Afficher l'original.
• Repérez l'en-tête « Authentication-Results » et identifiez le champ « spf ».

Voici à quoi ressemble l'en-tête en question, avec les annotations :

Résultats de l'authentification : 

spf(l'adresse IP de l'expéditeur est 40.107.22.83)  

smtp.mailfrom=votredomaine.com;  

dkim=pass (la signature a été vérifiée)  

header.d=votredomaine.com;  

dmarc=pass action=none  

header.from=votredomaine.com;  

compauth=pass raison=100

spf indique que l'adresse IP de l'expéditeur a été validée par votre SPF . Si vous voyez spf, spf ou spf, le résultat spécifique vous indique ce qui ne fonctionne pas :

• spf: L'adresse IP de l'expéditeur ne figure pas du tout dans votre SPF .
• spf: L'adresse IP n'est pas autorisée, mais votre enregistrement utilise « ~all » au lieu de « -all ».
• spf: Votre SPF présente un problème structurel (plus de 10 requêtes, enregistrement multiple, erreur de syntaxe).

À quoi ressemble un SPF valide

Comment publier un SPF pour Exchange Online (M365)

La publication d'un SPF pour Exchange Online est simple. C'est toutefois au moment de saisir correctement les informations que la plupart des équipes échouent.

Étape 1 : Identifiez toutes vos sources d'envoi autorisées

Avant de modifier les paramètres DNS, procédez à un audit de tous les systèmes qui envoient des e-mails au nom de votre domaine. La plupart des entreprises sous-estiment cette liste de 30 à 50 %.

• Microsoft 365 / Exchange Online → inclure :spf.protection.outlook.com
• Automatisation du marketing (HubSpot, Mailchimp, Marketo, Pardot) → chacune dispose de son propre module d'intégration
• CRM (Salesforce, Microsoft Dynamics) → consulter SPF du fournisseur
• E-mails transactionnels (SendGrid, Amazon SES, Postmark, Mailgun) → fichiers d'inclusion propres à chaque fournisseur
• Service d'assistance / gestion des tickets (Zendesk, Freshdesk, ServiceNow) → intégrations spécifiques aux fournisseurs
• Ressources humaines / Paie (BambooHR, Gusto, Workday) → Vérifiez si les notifications sont envoyées depuis votre domaine
• Anciens serveurs sur site → IPv4 : avec des adresses IP publiques

Le moyen le plus fiable de découvrir des expéditeurs que vous ne connaissiez pas est les rapports agrégés DMARC. Toutes les sources légitimes (et illégitimes) qui envoient des e-mails depuis votre domaine y apparaissent.

Étape 2 : Créer SPF

Commencez par la balise de version, ajoutez les sources autorisées, puis terminez par le qualificatif.

Exemple simple avec M365 :

v=spf1 

inclure :spf.protection.outlook.com -all

Une entreprise typique de taille moyenne utilisant HubSpot et SendGrid :

v=spf1 

inclure :spf.protection.outlook.com 

inclure :_spf.hubspot.com 

inclure : sendgrid.net -all

Comptez vos requêtes DNS au fur et à mesure de la construction. Chaque mécanisme include:, a:, mx:, ptr: et exists: déclenche une requête. Les mécanismes ip4: et ip6: ne sont pas pris en compte. Les inclusions imbriquées sont également comptabilisées, car include:spf.protection.outlook.com génère en soi 2 à 4 requêtes supplémentaires en interne, à mesure qu’il transite par l’infrastructure de Microsoft.

Étape 3 : Publier l'enregistrement dans le DNS

Le processus de publication varie légèrement selon le fournisseur DNS, mais suit le même schéma :

Paramètres à utiliser systématiquement :

• Type d'enregistrement : TXT
• Hôte / Nom : @ (ou vide, selon le fournisseur)
• TTL : 36 000 (1 heure) pendant la phase de test, puis 86 400 (24 heures) une fois le système stabilisé

Critique : Un seul SPF par domaine. Un deuxième enregistrement TXT de type v=spf1 est une erreur permanente (PermError) qui ne demande qu'à être détectée. Si le processus de provisionnement de votre fournisseur DNS crée automatiquement un enregistrement lorsque vous ajoutez un service, vérifiez immédiatement s'il y a des doublons.

Étape 4 : Vérifier l'enregistrement publié

• Patientez entre 5 et 60 minutes pour que la propagation DNS ait lieu (selon la durée de vie des enregistrements et le fournisseur).
• Répétez la SPF décrite dans la méthode 1 pour vérifier que l'enregistrement est correctement résolu.
• Vérifiez le Centre d'administration M365 (méthode 2). Le statut de l'enregistrement TXT devrait désormais indiquer « OK ».
• Envoyez un message test à une adresse externe et vérifiez que l'en-tête indique bien « spf ».
• Vérifiez que le nombre de requêtes DNS est inférieur à 10.

Si vous préférez ne pas créer le fichier manuellement, le SPF de PowerDMARC génère un enregistrement correctement formaté dès que vous avez répertorié vos sources d'envoi.

SPF les environnements Exchange hybrides : sur site + cloud

Les environnements Exchange hybrides compliquent SPF gestion SPF , car les e-mails peuvent provenir simultanément à la fois de Microsoft 365 et d'une infrastructure sur site. Lors des migrations en particulier, les chemins de circulation du courrier se chevauchent souvent, ce qui peut entraîner SPF silencieux SPF si chaque route sortante n'est pas correctement prise en compte.

Le défi de l'hybridation : deux chemins de messagerie, un seul SPF

Dans un environnement hybride, le courrier sortant peut emprunter trois voies différentes :

• Directement via Exchange Online : pour les boîtes aux lettres hébergées dans M365
• Serveurs Exchange ou Edge Transport sur site : pour les boîtes aux lettres qui se trouvent encore sur site
• Hôtes intelligents ou relais tiers : lorsque le courrier est acheminé en externe avant d'atteindre l'Internet public

Chaque chemin indique au serveur destinataire une adresse IP source différente. SPF tient SPF compte du chemin initialement prévu, car il vérifie uniquement si l'adresse IP qu'il a effectivement reçue est autorisée. Les deux chemins doivent être couverts par un seul SPF , car un seul SPF est autorisé par domaine.

Comment configurer SPF Exchange hybride

Veuillez inclure les deux chemins d'autorisation :

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

Les adresses IP sur site correspondent aux adresses publiques utilisées par votre serveur de messagerie lorsqu'il envoie des messages vers Internet, et non aux adresses internes de la norme RFC 1918. Vérifiez les connecteurs d'envoi de votre serveur Edge Transport ainsi que toutes les règles NAT ou de pare-feu qui déterminent l'adresse IP publique. Si vous disposez d'une redondance géographique ou de plusieurs chemins de sortie, chaque adresse IP publique susceptible d'émettre des messages doit figurer dans l'enregistrement.

SPF la migration (état transitoire)

Une migration par étapes ou une migration avec basculement crée une période pendant laquelle les boîtes aux lettres coexistent aux deux emplacements et où les e-mails peuvent être envoyés par l'un ou l'autre des chemins. SPF couvrir les deux chemins pendant toute la durée de cette période.

• Avant de lancer la migration : Assurez-vous que votre SPF couvre à la fois les entrées IPv4 sur site et inclut :spf.protection.outlook.com.
• Pendant la migration : Conservez les deux autorisations en place. Surveillez les taux SPF via les rapports agrégés DMARC. Si des modifications de routage font passer le courrier par des chemins inattendus, les rapports le signaleront avant les utilisateurs.
• Une fois la migration terminée : Supprimez les entrées IPv4 sur site. Laisser des adresses IP obsolètes dans SPF un risque pour la sécurité. Si ces anciennes adresses IP sont réattribuées par votre FAI ou votre fournisseur de services cloud, le nouveau locataire pourra envoyer des e-mails authentifiés en utilisant votre domaine.

Une erreur courante consiste à supprimer les adresses IP locales pendant la migration sous prétexte que la bascule est « presque terminée ». Il suffit qu'une seule boîte aux lettres continue d'emprunter l'ancien chemin pour que l'authentification des e-mails de cet utilisateur soit compromise.

Sous-domaines dans Exchange : SPF ne s'applique pas SPF

Un point crucial qui pose souvent problème aux organisations hybrides : les sous-domaines n'héritent pas SPF du domaine parent. Si marketing.votredomaine.com envoie des e-mails via un fournisseur de services de messagerie (ESP) distinct, il doit disposer de son propre enregistrement SPF . SPF avec caractères génériques ne sont pas pris en charge par le protocole. Chaque sous-domaine qui envoie des e-mails doit avoir son propre enregistrement v=spf1 publié à la racine de son DNS.

Cela signifie également que l'utilisation de sous-domaines constitue une stratégie efficace pour répartir SPF . Acheminez les e-mails marketing via marketing.votredomaine.com et les e-mails transactionnels via mail.votredomaine.com, de sorte que chaque sous-domaine dispose de son propre quota de 10 requêtes. Cette approche est conforme à la RFC, largement prise en charge par les fournisseurs de services de messagerie (ESP) et couramment utilisée dans les environnements d'entreprise.

Exchange Online vérifie-t-il SPF les e-mails envoyés au sein d'un même tenant ?

Non. Exchange Online traite les messages intra-locataires comme du courrier interne et n'effectue pas SPF . Les messages échangés entre différents locataires, même s'il s'agit d'organisations partenaires de confiance, sont soumis à SPF , car ce courrier emprunte le chemin de routage public.

Pour les organisations disposant de plusieurs domaines au sein d'un même tenant M365, chaque domaine doit disposer de son propre SPF . Le partage d'un enregistrement entre plusieurs domaines via un enregistrement CNAME n'est pas une pratique courante et ne fonctionne pas de manière fiable.

SPF courantes dans Exchange et comment les résoudre

Chaque scénario de dépannage présenté ci-dessous suit le même schéma de diagnostic : symptôme → cause → solution.

Erreur permanente : trop de requêtes DNS

• • Symptôme : SPF une erreur permanente (PermError). Les destinataires peuvent considérer votre e-mail comme indésirable ou le rejeter. L'alignement DMARC échoue.
  • Cause: Plus de 10 requêtes DNS dans votre SPF , y compris les inclusions imbriquées. Il s'agit de SPF la plus courante dans les organisations utilisant plusieurs services SaaS.

• Solution (procédure en 5 étapes) :

• • Étape 1 : Vérifiez votre nombre actuel de recherches à l'aide d'un SPF qui compte de manière récursive les inclusions imbriquées.
  • Étape 2 : Supprimez les inclusions obsolètes pour les services que vous n'utilisez plus.
  • Étape 3 : Remplacer « include: » par « ip4: » lorsque les adresses IP du fournisseur sont stables et documentées.
  • Étape 4 : Transférez les expéditeurs non professionnels à fort volume (marketing, transactions) vers des sous-domaines dotés de leurs propres SPF .
  • Étape 5 : Si vous dépassez toujours les 10, mettez en place SPF ou des macros à l'aide d'un outil tel que PowerSPF pour résoudre automatiquement les inclusions en entrées IPv4 et maintenir l'enregistrement à jour lorsque les fournisseurs changent d'adresse IP.

Exemple avant/après :

Avant (14 consultations : PermError) :

v=spf1 include:spf.protection.outlook.com include:_spf.hubspot.com include:sendgrid.net include:servers.mcsv.net include:_spf.salesforce.com include:zendesk.com include:spf.freshdesk.com a mx -all

Après (7 recherches : en dessous de la limite) :

v=spf1 include:spf.protection.outlook.com include:_spf.hubspot.com include:sendgrid.net ip4:198.2.128.0/24 ip4:192.254.113.0/24 -all# Salesforce et Zendesk ont été déplacés vers mail.votredomaine.com# Freshdesk remplacé par des entrées ip4 simplifiées# mécanismes a et mx supprimés (redondants avec les inclusions explicites)

Plusieurs SPF ont été détectés

• Symptôme : SPF renvoie une erreur « enregistre SPF multiples ». Toutes SPF échouent.
• Cause : Il existe au moins deux enregistrements TXT commençant par v=spf1 pour le même domaine. Cela se produit généralement lorsque le processus de provisionnement d'un fournisseur SaaS crée un deuxième enregistrement à l'insu de l'administrateur.
• Correction : Fusionnez-les en un seul enregistrement. Vous pouvez avoir plusieurs mécanismes « include: » et « ip4: » dans un même enregistrement, mais un seul enregistrement TXT « v=spf1 » par domaine. Supprimez l'entrée redondante.

SPF après l'ajout d'un nouvel outil SaaS

• Symptôme : Les e-mails provenant du nouvel outil ajouté échouent SPF. D'autres expéditeurs peuvent également rencontrer des problèmes si le nouvel ajout fait passer le nombre total de requêtes au-delà de 10.
• Cause : Le service « include: » n'a pas été ajouté au SPF, ou son ajout a dépassé la limite de recherche.
• Solution : Ajoutez l'inclusion, puis vérifiez à nouveau le nombre total de recherches. Si ce nombre dépasse désormais 10, c'est le nombre de recherches, et non l'inclusion elle-même, qui pose problème. Appliquez la procédure en 5 étapes ci-dessus.

SPF dans Hybrid Exchange (adresse IP locale manquante)

• Symptôme : Les e-mails envoyés depuis Exchange sur site échouent SPF, tandis que ceux provenant de M365 le passent.
• Cause : L'adresse IP publique du serveur sur site ne figure pas dans SPF . Ce problème est particulièrement fréquent après une migration partielle, lorsque l'administrateur a mis à jour SPF Exchange Online mais a oublié que le chemin d'accès sur site achemine toujours le courrier.
• Solution : Ajoutez ip4:x.x.x.x pour chaque adresse IP sortante sur site. Si le courrier transite par un serveur Edge Transport, un hôte intelligent ou un relais tiers, l'adresse IP publique de ce relais doit également être incluse.

SPF après la migration vers Exchange Online

• Symptôme : Les e-mails envoyés après la migration échouent SPF .
• Cause : Le DNS pointe toujours vers les anciennes adresses IP sur site ; par exemple :spf.protection.outlook.com n'a pas été ajouté, ou le courrier est acheminé par des chemins inattendus pendant la transition.
• Solution : Vérifiez que SPF inclut à la fois les anciens chemins d'autorisation (sur site) et les nouveaux (Exchange Online) pendant la période de migration. Ne supprimez les anciennes entrées qu'une fois la migration de 100 % des boîtes aux lettres confirmée. Surveillez le processus à l'aide des rapports agrégés DMARC tout au long de la migration. Ceux-ci vous indiquent précisément les chemins empruntés par vos e-mails du point de vue des destinataires.

SPF , mais l'e-mail atterrit dans le dossier spam

• Symptôme : Les en-têtes indiquent « spf », mais le message atterrit dans le dossier des courriers indésirables du destinataire.
• Cause :SPF qu'un signal parmi tant d'autres. La réputation de l'expéditeur, le contenu, le DKIM ou le DMARC peuvent présenter des anomalies. N'importe lequel de ces éléments peut annuler un SPF valide.
• Solution : Vérifiez l'alignement DKIM, la politique DMARC, la réputation de l'expéditeur (statut sur liste noire, ancienneté du domaine, changements récents de volume) et la réputation du contenu/des liens. L'analyseur de domaine de PowerDMARC de PowerDMARC attribue une note pour l'ensemble de ces critères en un seul scan.

SPF pour les e-mails transférés

• Symptôme : Les messages transférés automatiquement, les e-mails provenant de listes de diffusion ou les messages acheminés par des règles de transport échouent SPF.
• Cause : L'adresse IP du serveur de transfert ne figure pas dans SPF de l'expéditeur d'origine. Il s'agit d'une limitation architecturale SPFplutôt que d'une erreur de configuration.
• Solution : Considérer SPF sur les e-mails transférés comme un comportement normal. Assurez-vous que DKIM est correctement configuré pour votre domaine. Les signatures DKIM sont conservées lors du transfert, ce qui permet à DMARC de passer le test d'alignement DKIM même en cas SPF . La fonctionnalité ARC (Authenticated Received Chain) dans Exchange Online préserve en outre les résultats d'authentification tout au long des chaînes de transfert fiables.

Comment Exchange Online traite réellement SPF (la « boîte noire » expliquée)

La plupart des administrateurs Exchange sont confrontés à la même question : comment Exchange Online Protection (EOP) gère-t-il réellement SPF ? Certaines sources affirment qu’un échec total entraîne un rejet automatique. D’autres suggèrent que SPF qu’un indicateur mineur de spam. Voici comment cela fonctionne réellement.

Le pipeline multisignal (SPF qu'une entrée parmi d'autres)

Exchange Online Protection ne prend pas ses décisions de distribution en se basant SPF sur SPF . SPF qu'un élément parmi d'autres dans une évaluation d'authentification globale qui comprend :

• SPF : réussite, échec, échec partiel, neutre, PermError ou TempError
• Résultat DKIM : réussite, échec ou aucun
• Résultat DMARC : dérivé de la comparaison entre SPF DKIM et le domaine indiqué dans l'en-tête « From »
• Réputation de l'expéditeur: réputation de l'adresse IP, réputation du domaine, historique des habitudes d'envoi
• Note SCL (Spam Confidence Level) : note interne de Microsoft allant de -1 (expéditeur fiable) à 9 (spam hautement probable)
• Filtrage de contenu : mots-clés, réputation des URL, analyse des pièces jointes

C'est le résultat global de l'authentification, et non un protocole en particulier, qu'EOP utilise pour déterminer le traitement final du message.

Comment EOP gère chaque SPF

PermError est une erreur grave qu'EOP traite de manière quasi identique à un SPF pur et simple SPF ; elle se répercute sur DMARC, ce qui perturbe complètement l'authentification. C'est pourquoi la limite de 10 requêtes constitue un point de défaillance structurel.

Où consulter SPF dans Exchange

Trois sites, classés par ordre croissant de exhaustivité :

• En-têtes de message (Authentication-Results) : Chaque message traité par EOP est marqué avec spf, ainsi que le domaine et l'adresse IP de l'expéditeur évalués.
• Traçage des messages Exchange : Affiche l'état de livraison, l'adresse IP source, le destinataire et le sort final du message, mais ne met pas en évidence SPF . Si vous vous fiez uniquement à la trace du message pour SPF , vous avancez à l'aveuglette.
• Rapports agrégés DMARC (RUA) : La seule source de données qui montre comment les destinataires du monde entier évaluent votre SPF. Les rapports RUA indiquent les taux SPF et d'échec SPF par adresse IP et par source pour chaque serveur de réception qui traite votre courrier.

Configuration de l'application SPF de la politique SPF dans EOP

Par défaut, Exchange Online intègre SPF dans son score composite, mais ne rejette pas les messages sur SPF . Pour configurer explicitement EOP afin qu'il marque les messages présentantSPF comme spam :

Dans le Centre d'administration d'Exchange Online : accédez à Protection → Filtre anti-spam → Options avancées, puis activez le commutateur «SPF : échec définitif ». Vous pouvez également exécuter la cmdlet PowerShell suivante :

Get-HostedContentFilterPolicy | Where-Object {$_.IsDefault -eq $true} | Set-HostedContentFilterPolicy -MarkAsSpamSpfRecordHardFail On

SPF pratiques SPF pour les environnements Exchange en 2026

• Utilisez l'option -all (échec définitif) comme paramètre par défaut. Associée à DMARC, l'option -all constitue la norme. La seule exception concerne la phase initiale de déploiement, avant que DMARC ne soit opérationnel.
• N'utilisez jamais +all. Cela autorise l'ensemble des internautes à envoyer des messages en votre nom. Si vous trouvez +all dans votre enregistrement, considérez cela comme un incident de sécurité en cours.
• Veillez à toujours inclure spf.protection.outlook.com pour M365, même si le courrier sortant transite par une passerelle tierce. Exchange Online génère des invitations de calendrier, des réponses automatiques, des rapports de non-remise (NDR) et des accusés de lecture qui sont envoyés directement depuis l'infrastructure de Microsoft.
• Vérifiez votre SPF au moins une fois par trimestre. Les fournisseurs de services SaaS modifient leurs plages d'adresses IP. Les équipes marketing adoptent de nouveaux outils sans en informer le service informatique. Les vérifications trimestrielles permettent de détecter les écarts avant qu'ils ne provoquent une erreur permanente (PermError). La surveillance continue via les rapports DMARC permet de détecter les écarts en temps réel.
• Déployez SPF DKIM et DMARC. SPF n'empêche pas l'usurpation du champ « From » de l'en-tête. À lui seul, DKIM ne permet pas de valider l'expéditeur de l'enveloppe. Seule la mise en œuvre de DMARC, qui vérifie la conformité SPF de DKIM avec le domaine indiqué dans le champ « From » de l'en-tête, offre une protection complète.
• Respectez les exigences des principaux destinataires en matière d'expédition. En 2026, Google, Yahoo, Microsoft et Apple exigeront tous que les expéditeurs en masse utilisent SPF DKIM SPF DMARC. La norme PCI DSS v4.0, obligatoire depuis mars 2025, impose explicitement ces trois protocoles comme mesures de protection contre le phishing.

Comment surveiller SPF  

La principale différence entre les organisations ayant «SPF » et celles qui sont réellement protégées par SPF la surveillance. La configuration initiale est la partie la plus simple, mais c'est la détection des défaillances silencieuses au fil des mois qui sépare une authentification des e-mails efficace d'une authentification purement théorique.

Pourquoi SPF ponctuels SPF donnent un faux sentiment de sécurité

SPF changent constamment, car les fournisseurs modifient leurs plages d'adresses IP autorisées, vos chaînes « include: » renvoient vers différentes adresses IP, et l'une d'entre elles peut vous faire dépasser la limite de requêtes. Les équipes ajoutent de nouveaux outils SaaS sans mettre à jour SPF. Les migrations modifient le routage du courrier sortant d'une manière qui n'est pas reflétée dans votre DNS. D'anciennes entrées subsistent pour des services que l'organisation a cessé d'utiliser il y a des années.

À quoi ressemble SPF continue SPF

Quatre composants, chacun répondant à un type de défaillance spécifique :

• Rapports agrégés DMARC collectés quotidiennement auprès de destinataires du monde entier. Ceux-ci présentent SPF par adresse IP et par source pour chaque serveur de réception ayant traité vos e-mails. PowerDMARC les collecte automatiquement et les affiche dans un tableau de bord SPF dédié, avec les taux de réussite/échec par source, le suivi du nombre de requêtes DNS et les courbes de tendance historiques.
• Des alertes automatiques dès que SPF dépassent un seuil, lorsqu'une nouvelle source d'envoi non autorisée apparaît ou lorsqu'une modification du DNS affecte votre enregistrement. Les PowerAlerts de PowerDMARC les transmet par e-mail, Slack ou Discord afin que l'équipe concernée soit informée du problème pendant les heures de bureau.
• SPF automatisé qui se met à jour lorsque des fournisseurs tiers modifient leurs adresses IP. Les résolutions résout les chaînes « include: » en entrées IPv4 et maintient votre enregistrement en permanence sous la limite des 10 requêtes sans modification manuelle du DNS.
• Surveillance des listes noires et de la réputation. Si vos adresses IP d'envoi se retrouvent sur une liste noire, SPF passer, mais la délivrabilité s'en trouve tout de même affectée. La surveillance intégrée de la réputation détecte les défaillances que SPF ne peut pas détecter.

À l'attention des MSP en particulier : lorsqu'un fournisseur modifie sa plage d'adresses IP, vous en êtes informés avant que la messagerie électronique du client ne cesse de fonctionner. 

Le tableau de bord MSP de PowerDMARC permet de SPF de manière centralisée SPF sur l'ensemble des domaines des clients depuis un seul écran, avec des analyses détaillées par client. Cela transforme SPF , qui passe d'une simple gestion réactive des incidents à une gamme de services structurée.

Commencez un essai gratuit de 15 jours pour le tester par vous-même. 

Foire aux questions

Comment puis-je vérifier SPF dans Exchange Online ?

Utilisez un outil SPF tel que le PowerDMARC SPF , saisissez votre domaine et examinez l'enregistrement, la syntaxe et le nombre de requêtes. Vous pouvez également effectuer cette vérification dans le Centre d'administration Microsoft 365, sous Paramètres → Domaines → Enregistrements DNS. Pour la vérification côté destinataire, consultez l'en-tête « Authentication-Results » dans un message test envoyé depuis l'extérieur.

De quel SPF ai-je besoin pour Microsoft 365 ?

Au minimum : v=spf1 include:spf.protection.outlook.com -all. Si vous utilisez d'autres services d'envoi (HubSpot, SendGrid, Salesforce, Zendesk), ajoutez leurs entrées « include » avant « -all ». Veillez à ce que le nombre total de requêtes DNS reste inférieur à 10, y compris les requêtes imbriquées à l'intérieur de chaque entrée « include: ».

Pourquoi SPF -t-il SPF alors que mon enregistrement semble correct ?

Causes courantes : dépassement de la limite de 10 requêtes DNS (PermError), présence de plusieurs SPF sur le même domaine, e-mails transférés (SPF par défaut lors d'un transfert) ou modification par un fournisseur de ses plages d'adresses IP autorisées sans vous en informer. Vérifiez l'en-tête « Authentication-Results » pour connaître le résultat spf spécifique.

Quelle est la différence entre -all et ~all ?

-all (refus catégorique) ordonne aux destinataires de rejeter ou de marquer comme non valides les messages provenant d'adresses IP non autorisées. ~all (refus souple) est plus permissif. En 2026, une fois DMARC déployé, la politique DMARC régira l'application de la règle, quel que soit le qualificatif utilisé. Si vous n'utilisez pas encore DMARC, l'option -all offre une protection nettement plus efficace.

Combien de requêtes DNS le domaine « include:spf.protection.outlook.com » génère-t-il ?

L'inclusion Microsoft compte pour une seule recherche, mais elle entraîne des inclusions imbriquées qui nécessitent environ 2 à 4 recherches supplémentaires. Ce nombre varie en fonction des mises à jour apportées par Microsoft à son infrastructure. Vérifiez toujours à l'aide d'un outil capable de compter de manière récursive les recherches imbriquées.

SPF à empêcher l'usurpation d'adresse e-mail ?

Non. SPF ne suffit pas SPF à empêcher l'usurpation de l'adresse « De : » visible (en-tête « From »). Il ne fait que valider l'expéditeur de l'enveloppe (Return-Path). Une protection complète nécessite le protocole DKIM pour la signature au niveau du message, ainsi que le protocole DMARC pour garantir la conformité. La norme en 2026 consistera à faire fonctionner ces trois protocoles de concert et à les surveiller en permanence.