Les fournisseurs de services gérés opèrent à l’intersection de l’échelle et de la complexité.

Une erreur de configuration SPF affectant un seul domaine peut créer un problème de délivrabilité. La même erreur intégrée dans une configuration MSP partagée peut affecter des dizaines ou des centaines de domaines clients simultanément.

Un nouveau service d’envoi peut pousser les domaines au-delà de la limite de recherche DNS de SPF. Une migration peut laisser des adresses IP d’envoi légitimes non autorisées. Une dépendance tierce oubliée peut se transformer en permerror SPF. Et un enregistrement SPF aplati manuellement peut devenir silencieusement obsolète à mesure que les fournisseurs modifient leur infrastructure.

Pour les MSP et MSSP, SPF n’est donc pas simplement un enregistrement DNS à configurer lors de l’intégration. C’est une dépendance qui doit rester exacte au fur et à mesure que les environnements clients évoluent.

Ce guide examine cinq échecs de configuration SPF que les MSP devraient détecter avant qu’ils ne deviennent des incidents de délivrabilité à l’échelle du client.

La réussite de SPF ne signifie pas automatiquement que DMARC réussit.

SPF authentifie le domaine RFC5321.MailFrom — généralement représenté par le Return-Path. Pour que SPF satisfasse DMARC, le domaine SPF authentifié doit également s’aligner avec le domaine dans l’en-tête RFC5322.From visible. Alternativement, une signature DKIM valide et alignée peut satisfaire DMARC même lorsque SPF n’est pas validé.

I. 1. Dépassement de la limite de 10 recherches SPF

Ce qui se passe

SPF impose une limite stricte sur les termes nécessitant des requêtes DNS évalués lors d’une vérification SPF.

Selon la RFC 7208, les mécanismes et modificateurs suivants comptent dans la limite :

• include
• a
• mx
• ptr
• exists
• redirect

Les évaluations imbriquées comptent également.

Si l’évaluation SPF dépasse 10 termes nécessitant des requêtes DNS, l’implémentation SPF doit retourner permerror.

Cela devient particulièrement dangereux dans les environnements MSP car un enregistrement SPF qui semble simple peut dépendre de plusieurs enregistrements imbriqués.

Un client pourrait autoriser :

v=spf1 include:spf.msp-example.com include:marketing.example.net include:crm.example.net ~all

Ces trois includes visibles ne représentent pas nécessairement seulement trois recherches SPF. Chaque enregistrement inclus peut contenir des mécanismes supplémentaires nécessitant des requêtes DNS.

Pourquoi les MSP rencontrent ce problème

Le budget de recherche augmente souvent progressivement à mesure que les clients ajoutent :

• Microsoft 365 ou Google Workspace
• plateformes marketing
• systèmes CRM
• plateformes de support technique
• fournisseurs d’e-mails transactionnels
• passerelles de sécurité
• systèmes ERP ou de facturation
• services hérités qui n’ont jamais été supprimés

Un domaine peut fonctionner en toute sécurité pendant des années, puis dépasser la limite SPF immédiatement après l’autorisation d’un expéditeur supplémentaire.

Impact sur la délivrabilité

Un permerror SPF signifie que SPF ne peut pas fournir un résultat authentifié réussi pour ce message.

S’il n’y a pas de signature DKIM alignée valide pour satisfaire DMARC à la place, le message peut échouer DMARC.

L’impact pratique peut inclure :

• permerror SPF apparaissant dans les résultats d’authentification
• échecs DMARC lorsque DKIM ne fournit pas une validation alignée
• placement dans le dossier spam
• rejet selon la politique du destinataire et d’autres signaux
• livraison incohérente entre les fournisseurs de messagerie

Comment les MSP devraient le détecter

Ne comptez pas uniquement les instructions include: visibles dans l’enregistrement SPF de premier niveau.

Évaluez l’arbre de dépendances SPF complet, incluant les éléments imbriqués :

include
a
mx
exists
redirect

Le mécanisme ptr compte également dans la limite, bien que la RFC 7208 en décourage explicitement l’utilisation.

Pour les MSP gérant de grands portefeuilles, la validation des recherches devrait avoir lieu avant chaque modification SPF, et non après l’apparition de problèmes de livraison.

Exemple de scénario d’échec

Un MSP ajoute une nouvelle passerelle de sécurité e-mail à une configuration SPF partagée.

La passerelle introduit plusieurs termes supplémentaires nécessitant des requêtes DNS à travers ses propres dépendances SPF.

Les domaines déjà proches de la limite de 10 termes franchissent le seuil immédiatement.

Rien n’a changé dans les applications des clients. Leurs e-mails continuent de partir normalement. Mais les systèmes de réception évaluant SPF retournent maintenant permerror.

Une seule modification de configuration partagée est devenue un problème d’authentification multi-client.

II. 2. L’infrastructure d’envoi ne correspond plus à SPF

Ce qui se passe

Les MSP centralisent fréquemment les e-mails sortants via :

• relais SMTP
• passerelles e-mail cloud
• plateformes de sécurité
• infrastructure d’e-mails transactionnels
• services d’envoi partagés

Un enregistrement SPF client pourrait autoriser cette infrastructure via un include :

v=spf1 include:spf.msp-example.com ~all

Les problèmes commencent lorsque l’infrastructure change mais que l’autorisation SPF ne change pas.

Les causes typiques incluent :

1. migration vers de nouvelles adresses IP d’envoi ;
2. déplacement entre centres de données ou régions cloud ;
3. remplacement d’un relais SMTP ou d’une passerelle de sécurité ;
4. introduction d’un nouveau fournisseur sortant ;
5. routage d’une partie seulement du trafic du client via la nouvelle infrastructure ; ou
6. conservation de l’ancienne infrastructure autorisée après migration.

Mode de défaillance

SPF évalue si l’IP de connexion est autorisée pour le domaine RFC5321.MailFrom.

Si l’IP d’envoi actuelle n’est pas autorisée par la politique SPF de ce domaine, SPF ne sera pas validé.

S’il n’y a pas non plus de validation DKIM alignée, DMARC échoue.

Cette distinction est importante :

L’échec SPF n’équivaut pas automatiquement à un échec DMARC.

DMARC peut réussir via une validation SPF alignée ou une validation DKIM alignée.

Impact sur la délivrabilité

La dérive d’infrastructure peut créer :

• des échecs SPF d’expéditeurs par ailleurs légitimes
• des échecs DMARC lorsque DKIM est indisponible, cassé ou mal aligné
• une livraison incohérente entre différents systèmes d’envoi
• un filtrage accru
• un rejet par certains systèmes de réception
• des rapports clients indiquant que seules certaines applications ou types de messages échouent

Comment les MSP devraient le détecter

Comparer :

Adresses IP d’envoi observées

contre :

Adresses IP actuellement autorisées par SPF

Les rapports agrégés DMARC sont particulièrement utiles ici car ils révèlent l’infrastructure qui envoie réellement du courrier en utilisant le domaine du client.

Pour un MSP, la question ne devrait pas simplement être :

« L’enregistrement SPF est-il syntaxiquement valide ? »

Elle devrait également être :

« L’enregistrement SPF autorise-t-il l’infrastructure qui envoie réellement du courrier aujourd’hui ? »

III. 3. L’écart d’authentification des sous-domaines

Ce qui se passe

L’une des idées fausses les plus persistantes sur SPF est que la politique SPF d’un domaine parent s’applique automatiquement à ses sous-domaines.

Ce n’est pas le cas.

Un enregistrement SPF publié à :

example.com

n’est pas automatiquement la politique SPF pour :

bounce.example.com
support.example.com
billing.example.com

La politique SPF est évaluée pour le domaine utilisé comme identité SPF — normalement le domaine RFC5321.MailFrom.

Par exemple, si un service envoie en utilisant :

Return-Path: [email protected]

L’évaluation SPF concerne billing.example.com.

La politique SPF à example.com n’est pas automatiquement héritée.

Mode de défaillance

Si le domaine RFC5321.MailFrom n’a pas d’enregistrement SPF applicable, SPF retourne normalement none.

C’est différent de fail, softfail ou permerror.

Parce que SPF n’a pas produit d’identifiant authentifié, il ne peut pas fournir la validation SPF alignée requise pour DMARC.

DMARC peut toujours réussir si le message porte une signature DKIM valide dont le domaine de signature s’aligne avec le domaine From visible.

Pourquoi les MSP rencontrent cela

Les sous-domaines sont fréquemment introduits par des systèmes tiers :

bounce.client.com
mail.client.com
billing.client.com
support.client.com
notifications.client.com

Ils peuvent être utilisés par :

• plateformes de support client
• CRM
• plateformes marketing
• systèmes de facturation
• AWS SES
• fournisseurs d’e-mails transactionnels
• services de notification d’applications

Le domaine racine peut donc avoir un SPF, DKIM et DMARC parfaitement valides tandis qu’un chemin d’envoi séparé utilisant un sous-domaine est incorrectement authentifié.

Comment les MSP devraient le détecter

Identifiez d’abord les domaines réellement utilisés comme domaines RFC5321.MailFrom / Return-Path.

Ensuite, vérifiez SPF pour ces domaines.

Par exemple :

dig TXT bounce.client.com
dig TXT billing.client.com
dig TXT notifications.client.com

La question importante n’est pas simplement de savoir si un sous-domaine existe.

C’est de savoir si ce sous-domaine est utilisé comme identité SPF pour les e-mails sortants et, si oui, si la politique SPF correspondante autorise correctement l’expéditeur.

Exemple de scénario d’échec

Un client introduit une nouvelle plateforme transactionnelle utilisant :

bounce.client.com

comme domaine Return-Path.

Le MSP vérifie SPF sur :

client.com

et suppose que la configuration est complète.

Mais bounce.client.com n’a pas de politique SPF.

SPF ne peut donc pas authentifier cette identité d’envoi. Si la configuration DKIM de la plateforme est également manquante ou mal alignée, DMARC échoue.

La configuration du domaine racine était correcte.

L’identité d’envoi ne l’était pas.

IV. 4. La dépendance SPF tierce qui casse

Ce qui se passe

Les enregistrements SPF modernes dépendent généralement de services tiers :

v=spf1 include:spf.provider-a.example include:spf.provider-b.example ~all

Chaque include: crée une dépendance externe.

Le propriétaire du domaine compte effectivement sur une autre organisation pour maintenir une infrastructure SPF valide.

Les problèmes surviennent lorsque :

1. un fournisseur retire un ancien include SPF ;
2. une organisation migre entre produits ;
3. le domaine référencé disparaît ;
4. le fournisseur publie un enregistrement SPF invalide ;
5. un service hérité est arrêté sans que l’enregistrement SPF du client ne soit mis à jour.

Mode de défaillance

La RFC 7208 définit un comportement spécifique pour include:.

Si l’évaluation du domaine inclus produit none — par exemple parce qu’aucun enregistrement SPF n’existe là — l’évaluation include produit permerror.

Cela signifie qu’une dépendance tierce cassée peut affecter l’évaluation SPF du domaine du client même si personne n’a modifié l’enregistrement DNS du client.

Impact sur la délivrabilité

Une dépendance cassée peut causer :

• permerror SPF
• perte d’une validation SPF alignée pour DMARC
• échec DMARC lorsque DKIM aligné ne réussit pas
• authentification incohérente entre les portefeuilles clients
• problèmes de livraison soudains sans changement DNS local évident

Ceci est particulièrement important pour les MSP car le même include tiers peut apparaître dans de nombreux domaines clients.

Une seule dépendance externe peut donc créer un échec corrélé dans tout le portefeuille.

Comment les MSP devraient le détecter

Les dépendances SPF doivent être surveillées en continu.

Les MSP devraient savoir :

• quels fournisseurs apparaissent dans les enregistrements SPF clients ;
• quels domaines ces fournisseurs requièrent ;
• quels clients dépendent de chaque fournisseur ;
• si ces dépendances se résolvent toujours correctement ; et
• si leur contenu SPF a changé.

Un enregistrement DNS inchangé ne signifie pas que la politique SPF effective est inchangée.

Ses dépendances peuvent avoir changé en dessous.

V. 5. L’aplatissement SPF statique devient obsolète

Ce qui se passe

L’aplatissement SPF est parfois utilisé pour réduire les recherches DNS.

Au lieu de conserver un include tiers :

v=spf1 include:spf.vendor.example ~all

les adresses IP actuelles derrière cet include sont résolues et placées directement dans l’enregistrement SPF :

v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.0/24 ~all

Parce que les mécanismes ip4 et ip6 ne comptent pas dans la limite de 10 recherches DNS de SPF, l’aplatissement peut réduire la pression sur les recherches.

Mais l’aplatissement statique transfère la responsabilité de maintenir ces adresses à jour du fournisseur à l’administrateur du domaine.

Le problème

Les fournisseurs d’e-mails tiers peuvent modifier leur infrastructure d’envoi.

Ils peuvent :

• ajouter des plages IP ;
• supprimer des plages IP ;
• s’étendre dans de nouvelles régions ;
• déplacer l’infrastructure ; ou
• changer de fournisseurs sous-jacents.

Si le MSP a copié les adresses IP du fournisseur il y a six mois et ne les met jamais à jour, l’enregistrement SPF aplati devient un instantané obsolète.

Mode de défaillance

Le courrier provenant d’une IP fournisseur nouvellement introduite peut ne plus correspondre à l’enregistrement SPF aplati.

SPF échoue alors à authentifier ce chemin d’envoi.

Encore une fois, DMARC n’échoue pas nécessairement : une signature DKIM alignée valide peut toujours produire une validation DMARC.

Mais le domaine a perdu l’un de ses chemins d’authentification.

Pourquoi cela importe pour les MSP

L’aplatissement statique peut convertir un problème opérationnel — recherches DNS excessives — en un autre :

synchronisation continue de l’infrastructure d’envoi tierce.

Dans un grand portefeuille client, maintenir manuellement les enregistrements aplatis devient rapidement impraticable.

Meilleure approche opérationnelle

Si l’aplatissement est utilisé, il devrait être accompagné d’une surveillance continue et d’une synchronisation automatisée.

Le MSP devrait être capable de détecter quand la politique SPF faisant autorité d’un fournisseur en amont change et mettre à jour l’autorisation effective en conséquence.

L’aplatissement devrait être traité comme un processus activement géré, et non comme une modification DNS ponctuelle.

Pourquoi les problèmes SPF deviennent plus dangereux à l’échelle MSP

Le protocole SPF sous-jacent est le même qu’une organisation gère un domaine ou mille.

Le risque opérationnel ne l’est pas.

Les MSP introduisent des dépendances partagées :

Modèles SPF partagés
        ↓
Infrastructure d'envoi partagée
        ↓
Services tiers partagés
        ↓
Automatisation DNS partagée
        ↓
Centaines de domaines gérés

Une erreur en haut de cette chaîne peut se propager dans tout le portefeuille.

Cela rend la gouvernance SPF aussi importante que la configuration SPF.

VI. Ce que les MSP devraient documenter

1. Inventaire des dépendances SPF

Maintenez un enregistrement de :

• chaque fournisseur d’e-mails sortants ;
• son autorisation SPF requise ;
• les clients utilisant ce fournisseur ;
• les domaines Return-Path associés ;
• les dépendances SPF imbriquées ; et
• la consommation actuelle de recherches DNS.

Cela permet de comprendre le rayon d’impact d’un changement de fournisseur.

2. Sources d’envoi réelles

La configuration DNS seule ne montre pas tout ce qui utilise le domaine d’un client.

Comparez l’autorisation SPF avec l’infrastructure d’envoi observée à partir de la télémétrie d’authentification et des rapports agrégés DMARC.

Les sources inconnues doivent être étudiées.

Les sources légitimes peuvent nécessiter une autorisation.

Les sources non autorisées peuvent indiquer une usurpation d’identité ou un service non approuvé.

3. Cartographie Return-Path et sous-domaine

Documentez les identités SPF réelles utilisées par chaque service d’envoi.

Par exemple :

Microsoft 365
From: client.com
Return-Path: client.com

Plateforme transactionnelle
From: client.com
Return-Path: bounce.client.com

Plateforme marketing
From: client.com
Return-Path: marketing.client.com

Cela facilite beaucoup le diagnostic des problèmes d’authentification et d’alignement DMARC.

4. Contrôle des modifications SPF

Avant de déployer une modification SPF, validez :

• le total des termes nécessitant des requêtes DNS ;
• les includes imbriqués ;
• l’autorisation des IP d’envoi ;
• les domaines Return-Path ;
• les dépendances tierces ;
• la syntaxe SPF ; et
• l’alignement DMARC attendu.

Pour les configurations partagées, calculez quels domaines clients seront affectés avant le déploiement.

5. Suppression des expéditeurs hérités

Les enregistrements SPF ont tendance à accumuler d’anciens services.

Chaque autorisation inutile :

• augmente la complexité ;
• peut consommer des recherches DNS ;
• élargit l’ensemble de l’infrastructure autorisée à envoyer ; et
• rend le dépannage futur plus difficile.

Le déclassement d’un service devrait inclure la suppression de son autorisation SPF.

SPF n’est qu’une partie de DMARC

SPF ne devrait pas être évalué isolément.

Sous DMARC, le domaine From visible doit s’aligner avec au moins un identifiant authentifié avec succès.

En termes pratiques :

SPF aligné VALIDÉ
        OU
DKIM aligné VALIDÉ
        ↓
     DMARC VALIDÉ

Si aucun ne produit une validation alignée :

Pas de SPF aligné VALIDÉ
        +
Pas de DKIM aligné VALIDÉ
        ↓
     DMARC ÉCHOUÉ

Cette distinction est critique lors du dépannage de la délivrabilité.

Une erreur SPF ne signifie pas automatiquement que DMARC a échoué.

De même, une validation SPF ne signifie pas automatiquement que DMARC a réussi si le domaine SPF authentifié ne s’aligne pas avec le domaine From visible.

Les exigences DMARC actuelles sont définies par la RFC 9989, publiée en mai 2026, qui remplace la spécification DMARC originale dans la RFC 7489.

Comment Skysnag aide les MSP à gérer SPF à grande échelle

Gérer SPF manuellement devient de plus en plus difficile à mesure que le nombre de clients, services d’envoi et dépendances DNS augmente.

La plateforme MSP de Skysnag est conçue pour centraliser et automatiser la gestion de l’authentification des e-mails dans les environnements clients.

VII. Gestion multi-locataire

Gérez les domaines clients via un environnement MSP centralisé plutôt que de dépanner chaque domaine indépendamment.

Cela fournit aux équipes MSP une visibilité au niveau du portefeuille sur la configuration de l’authentification et l’activité d’envoi.

VIII. Découverte automatisée des expéditeurs

Skysnag identifie les sources d’envoi sortantes afin que les MSP puissent comprendre quelle infrastructure utilise réellement les domaines clients.

Cela aide à distinguer les expéditeurs légitimes mais non documentés des sources non autorisées.

IX. Hébergement et optimisation SPF

Skysnag fournit une gestion et une optimisation SPF automatisées conçues pour prévenir les échecs DNS et réduire les risques opérationnels associés au maintien manuel de configurations SPF complexes.

X. Aplatissement SPF et prévention de la dérive

Lorsque l’optimisation SPF nécessite un aplatissement, une gestion continue est essentielle.

Les capacités d’hébergement et d’optimisation SPF de Skysnag incluent un aplatissement automatisé et une prévention de la dérive, réduisant le risque que l’autorisation statique devienne obsolète à mesure que l’infrastructure d’envoi change.

XI. Analyse DMARC centralisée

Les données agrégées DMARC fournissent une visibilité sur les résultats d’authentification à travers les sources d’envoi.

Combinée à une gestion centralisée, cela permet aux MSP d’identifier les problèmes d’authentification sans enquêter manuellement sur les systèmes de messagerie individuels.

XII. Gestion complète de l’authentification des e-mails

SPF n’est qu’un composant de l’authentification moderne des e-mails.

Skysnag permet aux MSP de gérer :

• DMARC
• SPF
• DKIM
• MTA-STS
• TLS-RPT
• BIMI

à partir d’un environnement unifié.

Points clés à retenir

SPF a une limite stricte de 10 recherches DNS.
La dépasser entraîne permerror. Les dépendances SPF imbriquées comptent dans cette limite.

Les politiques SPF n’héritent pas automatiquement des domaines parents.
Les MSP doivent comprendre les domaines RFC5321.MailFrom réels utilisés par les services d’envoi de leurs clients.

Un enregistrement SPF valide peut toujours autoriser la mauvaise infrastructure.
La configuration doit être comparée aux sources d’envoi réelles.

Les includes SPF tiers sont des dépendances externes.
Une modification DNS côté fournisseur peut affecter l’authentification client sans aucune modification de l’enregistrement SPF du client lui-même.

L’aplatissement SPF statique nécessite une maintenance continue.
Les changements d’infrastructure du fournisseur peuvent rendre obsolètes des autorisations IP précédemment correctes.

L’échec SPF n’est pas automatiquement un échec DMARC.
DKIM aligné peut satisfaire indépendamment DMARC.

À l’échelle MSP, la visibilité compte autant que la configuration.
Les modèles et l’infrastructure partagés transforment les erreurs DNS individuelles en risques opérationnels à l’échelle du portefeuille.

XIII. Gérez SPF dans tout votre portefeuille client

Les problèmes SPF deviennent plus difficiles à détecter — et plus coûteux à corriger — à mesure que le nombre de domaines gérés augmente.

Skysnag offre aux MSP et MSSP une gestion centralisée de l’authentification des e-mails, une découverte automatisée des expéditeurs, une optimisation SPF, une visibilité DMARC et une gestion multi-locataire conçue pour l’échelle.

Prévenez la dérive d’authentification avant qu’elle ne devienne un incident de délivrabilité client.

Découvrez Skysnag pour les MSP