Que contient « SPF » ? Comment l'utiliser en toute sécurité dans votre dossier « SPF » ?

Réponse rapide : Le mécanisme « SPF » (inclusion de domaine) permet au propriétaire d’un domaine d’autoriser un expéditeur tiers en référençant l’enregistrement « SPF » de cet expéditeur dans son propre enregistrement DNS TXT. Lorsqu’un serveur destinataire évalue votre enregistrement « SPF » et rencontre une instruction «include», il récupère et évalue l’enregistrement « SPF » du domaine référencé dans le cadre de la vérification. Étant donné que chaque instruction «include» déclenche au moins une requête DNS supplémentaire, vous devez limiter le nombre total de mécanismes de requête DNS à 10 au maximum pour éviter une erreur «PermError».

Votre enregistrement « SPF » indique aux serveurs de messagerie destinataires quelles sources sont autorisées à envoyer des e-mails au nom de votre domaine. Dès que votre organisation commence à utiliser des plateformes tierces pour le marketing, les messages transactionnels, les mises à jour CRM ou les e-mails d’assistance, la gestion des enregistrements « SPF » devient plus difficile à assurer manuellement. C’est là que le mécanisme d’inclusion « SPF » s’avère utile.

Ce guide explique en détail ce que sont les inclusions « SPF », comment elles fonctionnent et comment gérer plusieurs inclusions sans compromettre votre historique. Il aborde également la manière de rester en conformité avec DMARC, afin que vos e-mails parviennent systématiquement dans la boîte de réception.

Qui doit comprendre le concept d’« SPF » ?

SPF parmi lesquelles figurent les questions les plus importantes pour les équipes informatiques, les administrateurs système, les conseillers en cybersécurité et fournisseurs de services gérés (MSP) gérant des domaines qui envoient des e-mails via plusieurs services tiers. Si votre organisation utilise des plateformes telles qu’un CRM, un service d’assistance, un outil d’automatisation du marketing, un fournisseur d’e-mails transactionnels ou un service de messagerie dans le cloud, votre enregistrement « SPF » dépend probablement d’un ou plusieurs mécanismes d’inclusion.

• Les équipes informatiques et de sécurité d'entreprise chargées de gérer plusieurs plateformes SaaS, des expéditeurs régionaux ou des portefeuilles de domaines
• Administrateurs système chargés des enregistrements DNS et de la délivrabilité des e-mails
• Les MSP et MSSP qui gèrent les protocoles SPF et DMARC sur plusieurs domaines de clients
• Conseillers en cybersécurité dans les secteurs réglementés tels que la finance, la santé, le commerce de détail et le secteur public

Qu'est-ce qu'un SPF ?

Un enregistrement « SPF », ou un enregistrement Sender Policy Framework , est un enregistrement TXT DNS qui répertorie tous les serveurs et adresses IP autorisés à envoyer des e-mails au nom d’un domaine particulier. Lorsqu’un e-mail arrive, le serveur de messagerie destinataire vérifie les enregistrements DNS de l’expéditeur afin de s’assurer que l’e-mail provient d’une source autorisée. Si l’adresse IP de l’expéditeur correspond à une entrée de l’enregistrement, l’ SPF est validée. Dans le cas contraire, l’ SPF échoue.

Ce que les dossiers d'SPF s ne peuvent pas faire à eux seuls

SPF sont fondamentaux, mais ils présentent des limites qu'il convient de bien comprendre :

• Il vérifie l'identité de l'expéditeur de l'enveloppe, et non l'adresse « De » visible que les destinataires voient réellement
• Cela ne fonctionne pas lors du le transfert d'e-mails, ce qui fait que les e-mails transférés échouent souvent SPF même lorsque l'expéditeur d'origine est légitime
• Cela ne suffit pas à empêcher l'usurpation de domaine au niveau de l'en-tête « From », qui est la cible de la plupart des attaques de phishing

C'est pourquoi le protocole « SPF » fonctionne mieux lorsqu'il s'inscrit dans le cadre d'une configuration d'authentification plus large qui inclut également DKIM et DMARC. La configuration conjointe de ces trois protocoles offre le niveau de protection le plus élevé pour les e-mails.

Que comprend l'SPF ?

Si les enregistrements « SPF » constituent le règlement définissant qui est autorisé à envoyer des e-mails depuis votre domaine, le mécanisme « SPF » vous permet d’intégrer les règles définies par un tiers. Il permet au propriétaire d’un domaine de déléguer l’autorisation d’envoi à un autre domaine en référençant l’enregistrement « SPF » de ce dernier au sein de son propre domaine. Au lieu de répertorier manuellement chaque adresse IP utilisée par un service de messagerie tiers, vous incluez son domaine, et le serveur destinataire récupère et évalue son enregistrement « SPF » comme s’il faisait partie du vôtre.

Pourquoi l'instruction « ` SPF ` » inclut « `exists` »

De nos jours, l’envoi d’e-mails s’effectue rarement à partir d’un seul serveur. Pour les équipes informatiques et de sécurité des entreprises, la complexité de l’ SPF augmente généralement à mesure que de nouveaux outils SaaS, des plateformes marketing régionales, des CRM, des services d’assistance et des services d’e-mails transactionnels viennent s’ajouter au fil du temps. Chaque nouvel expéditeur doit être correctement autorisé, surveillé en permanence et rester dans la limite de 10 requêtes DNS imposée par SPFafin d’éviter les échecs d’authentification et les problèmes de délivrabilité.

Le mécanisme « include » d’ SPF s résout ce problème en vous permettant de référencer directement l’enregistrement « SPF » du service tiers. Lorsque le serveur destinataire évalue votre enregistrement « SPF » et rencontre une instruction « include », il récupère et résout l’enregistrement TXT « SPF » de ce domaine externe dans le cadre du processus de validation. Si la politique « SPF » du domaine inclus renvoie un résultat positif pour l’adresse IP de l’expéditeur, le mécanisme « include » est validé et l’évaluation « SPF » peut aboutir pour cet expéditeur. Dans le cas contraire, le serveur destinataire poursuit l’évaluation du reste de votre enregistrement « SPF ».

À quoi ressemble concrètement le contenu d’ SPF

Une instruction SPF de base se présente comme suit :

Dans cet exemple, le serveur destinataire recherche l'enregistrement « SPF » associé à thirdpartydomain.com et l'évalue conjointement avec le reste de vos enregistrements. Si l'adresse IP de l'expéditeur est autorisée dans cet enregistrement, l'e-mail passe l'étape « SPF » pour votre domaine. Le mécanisme d'inclusion est indispensable pour les domaines qui externalisent l'envoi d'e-mails ou font appel à plusieurs fournisseurs, car l'alternative consisterait à répertorier manuellement chaque adresse IP utilisée par chaque service, ce qui est peu pratique et source d'erreurs.

Comment fonctionne le mécanisme SPF ?

Comprendre le mécanisme SPF d'un point de vue technique vous aide à éviter les erreurs de configuration qui entraînent SPF silencieux SPF . Voici ce qui se passe lorsqu'un serveur destinataire évalue un SPF contenant des instructions d'inclusion.

Le processus SPF du SPF

1. Lorsqu'un e-mail arrive sur un serveur de messagerie destinataire, celui-ci extrait le domaine de l'adresse « MAIL FROM » et effectue une recherche DNS pour récupérer l’enregistrement TXT « SPF » de ce domaine. Il lit ensuite l’enregistrement de gauche à droite, en évaluant chaque mécanisme jusqu’à ce qu’il trouve une correspondance ou qu’il atteigne la fin. Lorsqu’il rencontre une instruction « include » :
2. Le serveur destinataire effectue une requête DNS supplémentaire afin de récupérer l'enregistrement TXT « SPF » du domaine concerné.
3. Il vérifie l'enregistrement « SPF » du domaine concerné par rapport à l'adresse IP de l'expéditeur.
4. Si la politique « SPF » du domaine inclus renvoie un résultat « pass » pour l'adresse IP de l'expéditeur, le mécanisme d'inclusion s'applique et l'évaluation « SPF » peut aboutir à un résultat positif pour cet expéditeur.
5. Si aucune correspondance n'est trouvée, le serveur poursuit l'évaluation des mécanismes restants dans l'enregistrement d'origine.

Comment les requêtes sont-elles prises en compte dans la limite de recherche DNS ?

Chaque instruction « include » dans un enregistrement « SPF » déclenche au moins une requête DNS supplémentaire. Cela a son importance, car la validation de SPF est limitée à un maximum de dix requêtes DNS par vérification. Chaque instruction « include », ainsi que les mécanismes tels que « mx » et « a », sont pris en compte dans cette limite. Si l'enregistrement « SPF » du domaine inclus contient lui-même d'autres instructions « include », celles-ci sont également prises en compte, créant ainsi une chaîne de requêtes qui peut rapidement s'accumuler.

Le dépassement de la limite de dix requêtes entraîne le renvoi d'une erreur « PermError » par SPF , que les serveurs destinataires traitent comme une SPF échec. Cela peut entraîner le rejet des e-mails ou leur classement dans les dossiers de spam, même lorsque la source d'envoi est tout à fait légitime.

Syntaxe SPF : comment rédiger correctement une instruction « SPF

Il est impératif de respecter la syntaxe. Une seule erreur dans votre SPF syntaxe de l'enregistrement peut entraîner l'échec de l'enregistrement dans son intégralité, quelle que soit la qualité de la configuration du reste du système.

La structure de base d'un SPF

• v=spf1 déclare la version de l'SPF et doit figurer au début de chaque enregistrement TXT SPF
• mécanismes définissent les sources d'envoi autorisées, qui peuvent inclure des adresses IP, des domaines via la directive « include », des enregistrements MX, etc.
• « all » est le mécanisme de récupération générale qui détermine ce qu’il advient des e-mails qui ne correspondent à aucune source répertoriée

SPF Aperçu des qualifications

Comment rédiger correctement une instruction « include » dans SPF

La syntaxe correcte d'une instruction « include » est « include:domain.com ». Notez qu'il n'y a pas d'espace entre « include » et les deux-points. Un espace entraînerait une erreur de syntaxe. Voici un exemple complet d'enregistrement « SPF » comportant plusieurs inclusions :

• sendgrid.net et mailchimp.com sont autorisés en tant qu'expéditeurs tiers via la balise « include »
• 192.168.1.1 est une adresse IP autorisée individuellement
• ~« all » correspond à un « softfail », ce qui signifie que les e-mails provenant de sources non autorisées sont signalés mais ne sont pas rejetés d'emblée

Liste de contrôle : comment ajouter en toute sécurité une nouvelle inclusion « SPF »

1. Identifiez le nouveau service d'envoi et vérifiez le domaine d'inclusion fourni par le fournisseur.
2. Récupérez votre enregistrement TXT « SPF » actuel à l'aide d'un SPF outil de recherche.
3. Comptez le nombre total de requêtes DNS, y compris les requêtes imbriquées dans les enregistrements inclus.
4. Ajoutez le nouveau mécanisme « include: » à votre enregistrement TXT « single SPF ».
5. Vérifier la syntaxe à l'aide d'un SPF générateur d'enregistrements ou un outil de recherche.
6. Publiez l'enregistrement mis à jour et testez les résultats de l'authentification à l'aide des en-têtes des e-mails.
7. Surveillez les rapports DMARC afin de vérifier que le nouvel expéditeur respecte bien l'alignement « SPF ».

SPF « Include » ou « Redirect » : quelle est la différence ?

Le mécanisme « include » et le modificateur « redirect » font tous deux référence à l'enregistrement « SPF » d'un autre domaine, mais leur comportement est très différent. Utiliser l'un à la place de l'autre est une erreur de configuration courante qui peut entraîner, sans que l'on s'en aperçoive, une défaillance de l'authentification.

Le mécanisme « include » autorise les expéditeurs répertoriés dans l'enregistrement « SPF » d'un autre domaine, tout en permettant à votre enregistrement « SPF » de contenir des mécanismes supplémentaires. Le modificateur « redirect », en revanche, indique au serveur destinataire d'utiliser l'enregistrement « SPF » d'un autre domaine comme politique complète pour votre domaine, en remplaçant tout le reste de votre enregistrement.

Erreur courante

Utilisation simultanée des modificateurs « include » et « redirect » dans un même enregistrement. Le modificateur « redirect » est ignoré dès lors qu'un mécanisme « all » apparaît dans l'enregistrement ; par conséquent, ces deux modificateurs ne se combinent pas comme on pourrait s'y attendre. Pour la plupart des configurations à expéditeurs multiples, « include » est le choix approprié et « redirect » est totalement omis.

Erreurs de syntaxe courantes à éviter

• La publication de plusieurs enregistrements TXT « SPF » pour un même domaine entraîne une erreur « PermError », car les serveurs destinataires ne parviennent pas à déterminer quelle politique appliquer.
• Ajouter un espace après les deux points dans une instruction d'inclusion
• Utilisation de qualificatifs incorrects ou de mécanismes qui s'opposent les uns aux autres
• Oublier de terminer l'enregistrement avec un mécanisme complet

Un générateur d'SPF s permet de créer une correctement formatée à partir de zéro. Vous pouvez également soumettre votre existante à un outil de vérification d'SPF s afin de détecter les erreurs avant qu'elles n'entraînent des problèmes de délivrabilité.

SPF Comparaison des mécanismes : « include » par rapport à « a », « mx », « ip4 », « ip6 » et « all »

Avant de modifier un enregistrement DNS de type TXT, il est utile de comprendre quel mécanisme d'SPF utiliser et dans quelles circonstances. Chaque mécanisme répond à un objectif différent et a un impact différent sur le nombre de requêtes DNS.

SPF Règles d'inclusion multiples et limites de recherche DNS

L'utilisation de plusieurs inclusions de fichiers « SPF » est courante et souvent nécessaire, mais elle introduit une complexité qui doit être gérée avec soin. Voici ce que vous devez savoir sur la gestion d'un SPF enregistrement comportant plusieurs inclusions.

Pourquoi faut-il utiliser plusieurs inclusions ?

La plupart des entreprises utilisent plusieurs plateformes pour envoyer leurs e-mails. Une configuration type comprend un serveur de messagerie principal pour les e-mails internes et sortants, un service de messagerie transactionnelle pour les confirmations de commande et les notifications, une plateforme marketing pour les newsletters et les campagnes, ainsi qu’un outil CRM ou de support client pour les communications avec la clientèle. Chacune de ces plateformes doit être autorisée dans votre enregistrement « SPF », et la manière la plus pratique d’y parvenir consiste à utiliser des instructions « include » faisant référence à l’enregistrement « SPF » de chaque fournisseur.

Pourquoi les MSP doivent surveiller de près l'SPF , notamment

Pour les MSP et les MSSP, les problèmes liés aux « SPF » se propagent rapidement dans les environnements des clients. Un client peut ajouter un nouvel outil de marketing par e-mail, un autre changer de CRM, et un troisième publier sans le savoir plusieurs enregistrements « SPF ». En l’absence de visibilité centralisée, ces changements ne donnent souvent lieu à des tickets d’assistance qu’une fois que la délivrabilité des e-mails commence à poser problème. Une plateforme centralisée de gestion de l’ SPF et du DMARC aide les MSP à identifier les enregistrements corrompus, les « includes » inutilisés, les risques liés aux limites de recherche et les échecs d’authentification sur l’ensemble des domaines clients à partir d’un seul tableau de bord, réduisant ainsi le dépannage réactif.

Pourquoi l'inclusion de plusieurs éléments « SPF » peut dépasser la limite de 10 recherches

Chaque instruction « include » déclenche au moins une requête DNS, et certains enregistrements d’ SPF s tiers contiennent eux-mêmes d’autres instructions « include », ce qui ajoute encore davantage de requêtes. Lorsque vous avez autorisé quatre ou cinq plateformes, vous pouvez déjà approcher, voire dépasser, la limite de dix requêtes. Lorsque cette limite est dépassée, le serveur destinataire renvoie une erreur « PermError » et considère l’e-mail comme un SPF échec d’authentification.

Exemple : comment le nombre de « visible includes » peut dépasser 10 recherches au total

Trois inclusions visibles peuvent facilement se traduire par plus de dix requêtes au total, si l'on tient compte des inclusions imbriquées au sein des enregistrements référencés.

Combien d'« SPF » un enregistrement « SPF » peut-il contenir ?

Il n'y a pas de limite stricte quant au nombre d'instructions `include` que vous pouvez écrire dans un enregistrement ` SPF `. Cependant, l'ensemble des mécanismes d'interrogation DNS, y compris `include`, `a`, `mx`, `exists` et `redirect`, ne doit pas déclencher plus de 10 requêtes DNS au total lors de l'évaluation. Cette limite inclut les requêtes imbriquées au sein des enregistrements inclus.

En pratique, la plupart des domaines peuvent utiliser sans risque entre trois et cinq instructions « include » avant d’atteindre la limite, selon le nombre de recherches imbriquées déclenchées par chaque enregistrement référencé. L’ajout d’une sixième ou septième instruction « include » pour un fournisseur dont l’enregistrement « SPF » contient plusieurs instructions « include » imbriquées peut faire passer le total au-delà de 10 et provoquer une erreur « PermError », même si l’enregistrement visible semble court. Un SPF outil d’aplatissement compte le nombre total de recherches et résout les chaînes d’`include` avant que vous ne publiiez toute modification d’enregistrement.

Comment respecter la limite de requêtes DNS

• Vérifiez votre SPF actuel et comptez le nombre total de requêtes DNS qu'il déclenche, y compris les requêtes imbriquées au sein des enregistrements inclus
• Supprimez toutes les instructions d'inclusion relatives aux services que vous n'utilisez plus
• Dans la mesure du possible, remplacez les mécanismes d'inclusion par des entrées IPv4 ou IPv6 directes pour les services dont les plages d'adresses IP sont statiques et clairement documentées
• Utilisation SPF de l'aplatissement pour résoudre automatiquement les chaînes d’inclusion et les remplacer par des adresses IP directes, ce qui réduit le nombre total de recherches
• Vérifiez votre dossier chaque fois que vous ajoutez ou supprimez une plateforme d'envoi

Un SPF par domaine, systématiquement

Une règle essentielle qui s'applique quel que soit le nombre d'inclusions que vous gérez : ne publiez jamais plus d'un enregistrement TXT « SPF » pour un même domaine ou sous-domaine. La présence de plusieurs enregistrements « SPF » provoque une erreur « PermError » de type «SPF », car les serveurs destinataires ne peuvent pas déterminer quelle politique appliquer ; tout doit donc être regroupé en un seul enregistrement. Si vous envoyez des e-mails à partir de sous-domaines, chaque sous-domaine doit disposer de son propre enregistrement TXT « SPF ».

SPF Inclure des exemples de configurations courantes pour l'envoi d'e-mails

Les exemples suivants illustrent la syntaxe correcte d’inclusion d’ SPF s pour des configurations multiplateformes courantes. Vérifiez toujours le domaine d’inclusion exact dans la documentation de votre fournisseur avant la publication, et validez tout nouvel enregistrement à l’aide d’une SPF outil de recherche d’enregistrements avant de les publier sur le DNS.

Un seul fournisseur de messagerie uniquement

Fournisseur de messagerie et service d'e-mails transactionnels

Fournisseur de messagerie, plateforme marketing et CRM (surveillez le nombre de recherches)

Exemples non valides

Deux enregistrements qui vont échouer, avec la raison suivante :

Erreurs courantes SPF et comment les éviter

SPF Les enregistrements « includes » sont puissants, mais ne pardonnent aucune erreur. Une seule erreur de configuration peut entraîner des échecs d’authentification sur l’ensemble de votre flux de messagerie, et le plus frustrant, c’est que bon nombre de ces erreurs ne génèrent pas de message d’erreur évident. Que vous configuriez un enregistrement « SPF » pour la première fois ou que vous procédiez à l’audit d’un enregistrement existant, voici les erreurs à surveiller.

SPF Résultats de l'évaluation : Réussite, Échec, Échec partiel, Neutre, Erreur temporaire et Erreur permanente

Comprendre la signification de chaque résultat de la commande « SPF » vous aide à diagnostiquer rapidement les échecs d'authentification. Le tableau ci-dessous répertorie tous les résultats qu'un serveur destinataire peut renvoyer après avoir évalué un enregistrement « SPF ».

SPF et conformité DMARC

SPF Ces éléments ne fonctionnent pas de manière isolée. La manière dont vous les configurez a un impact direct sur votre conformité DMARC, et il est essentiel de bien comprendre la relation entre les deux pour garantir une délivrabilité constante.

Pour les secteurs réglementés tels que la finance, la santé, l'éducation, le commerce de détail et le secteur public, SPF , le respect des règles de base ne se limite pas à une simple question de délivrabilité. Il répond à des exigences plus larges en matière d'authentification des e-mails liées à règles d’expédition de Google et Yahoo, aux attentes de Microsoft en matière d’authentification, la norme PCI DSS, aux contrôles de sécurité conformes au RGPD et aux programmes internes de gestion des risques.

Comment SPF au DMARC

DMARC s'appuie sur les protocoles SPF DKIM pour permettre aux propriétaires de domaines de contrôler la manière dont leurs e-mails sont traités en cas d'échec de l'authentification. Pour qu'un e-mail soit conforme à DMARC, au moins l'une des conditions suivantes doit être remplie :

• SPF et le domaine de l'enveloppe correspond au domaine de l'expéditeur
• Le contrôle DKIM est validé et le domaine de signature DKIM correspond au domaine « De »

Cela signifie que même un enregistrement « SPF » correctement configuré, avec toutes les inclusions requises, n'est pas suffisant à lui seul. L'alignement « SPF » doit également être validé, ce qui signifie que le domaine figurant dans le chemin de retour doit correspondre au domaine « From » conformément à vos paramètres d'alignement DMARC.

Comment SPF influe sur l'alignement

Lorsqu’un expéditeur tiers utilise son propre domaine dans le chemin de retour, son champ « include » peut figurer dans votre enregistrement « SPF » et l’adresse « SPF » peut techniquement être considérée comme valide pour son domaine, mais elle ne correspondra pas à votre domaine « From ». Dans ce scénario, le contrôle « SPF » de DMARC échouera tout de même. Configurez le service tiers pour qu’il utilise un chemin de retour personnalisé sous votre domaine, ou assurez-vous que l’alignement DKIM est essentiel.

Pourquoi un indice de protection solaire ( SPF ne suffit pas

SPF, DKIM et DMARC sont conçus pour fonctionner ensemble en tant que pilier de la sécurité des e-mails . L'SPF e la source d'envoi mais ne fonctionne plus en cas de transfert. DKIM signe le message lui-même et résiste au transfert. DMARC relie les deux et vous offre une visibilité et un contrôle sur ce qui se passe en cas d'échec de l'un ou l'autre. La configuration de ces trois protocoles est le seul moyen de mettre en place un système d'authentification des e-mails résilient.

Configuration de DMARC en parallèle avec SPF

Si vos fichiers « SPF » sont correctement configurés mais que vous n'avez pas encore déployé DMARC, la mise en place de DMARC est la prochaine étape logique. Commencez par une politique de type p=none pour surveiller vos flux d'e-mails sans affecter leur délivrabilité, puis passez à « quarantine » et « reject » à mesure que votre confiance dans votre configuration d'authentification s'accroît.

Gérez les inclusions « SPF » et l'alignement DMARC avec PowerDMARC

SPF La gestion des inclusions devient complexe lorsque votre organisation utilise plusieurs expéditeurs tiers répartis entre différents services, domaines et régions. Une simple inclusion inutilisée, une chaîne de recherche imbriquée ou un domaine de chemin de retour mal aligné peut entraîner des échecs d'authentification difficiles à détecter manuellement.

PowerDMARC offre aux équipes informatiques, aux responsables de la sécurité et aux prestataires de services gérés (MSP) une visibilité centralisée sur les résultats relatifs à l'SPF, au DKIM et au DMARC pour l'ensemble des sources d'envoi. Grâce à gestion automatisée de l’ SPF , les rapports DMARCet SPF des analyses, des services d’authentification hébergés et une assistance d’experts, les équipes peuvent éviter les échecs liés aux limites de requêtes d’ SPF , identifier les expéditeurs non autorisés et garantir la conformité tout en réduisant la charge liée au DNS.

Les entreprises utilisent PowerDMARC pour centraliser la gestion de l'SPF , surveiller les échecs d'authentification et identifier les sources d'envoi non autorisées avant qu'elles n'affectent la délivrabilité.

Réservez une démo

Foire aux questions

Combien d'inclusions « SPF » puis-je avoir ?

Il n'y a pas de limite fixe pour les instructions « include », mais l'ensemble des mécanismes de requête DNS ne doit pas dépasser 10 recherches, en comptant les recherches imbriquées dans les enregistrements référencés. La plupart des domaines peuvent gérer sans problème trois à cinq instructions « include » avant qu'un aplatissement ne soit nécessaire.

Quelle est la différence entre « include » et « redirect » ?

La commande « include » ajoute les expéditeurs d'un autre domaine tout en conservant vos propres mécanismes actifs. La commande « redirect » remplace l'intégralité de votre politique par l'enregistrement d'un autre domaine. La commande « redirect » est ignorée si un mécanisme « all » est présent ; les deux ne se combinent donc pas.

Pourquoi mon test « SPF » est-il réussi alors que le test DMARC échoue toujours ?

SPF peut passer pour le domaine d'un expéditeur tiers tout en ne correspondant pas à votre domaine « De ». DMARC exige cette correspondance ; vous devez donc configurer un chemin de retour personnalisé sous votre domaine ou recourir à l'alignement DKIM comme solution de secours.

Quelles sont les causes d'une erreur « PermError » liée à l'SPF ?

Trois causes courantes : le dépassement de la limite de 10 requêtes, la publication de plusieurs enregistrements « SPF » pour un même domaine, ou une erreur de syntaxe telle qu'un espace après « include: ». Ces trois problèmes entraînent l'échec de la vérification « SPF » pour tous les expéditeurs jusqu'à ce qu'ils soient corrigés.

Puis-je avoir un seul enregistrement « SPF » pour plusieurs sous-domaines ?

Non. Chaque sous-domaine émetteur doit disposer de son propre enregistrement TXT « SPF ». L'enregistrement du domaine parent ne s'applique pas aux sous-domaines ; par conséquent, les e-mails provenant d'un sous-domaine non configuré échouent SPF.

Comment puis-je réduire le nombre de requêtes « SPF » ?

Supprimez les inclusions relatives aux services inutilisés, remplacez les expéditeurs à adresse IP statique par des entrées IPv4 ou IPv6 directes, et utilisez l'aplatissement des adresses SPF pour résoudre les chaînes d'inclusion en adresses IP directes. Effectuez un audit chaque fois qu'une plateforme d'envoi est ajoutée ou supprimée.

L'ajout d'un fichier d'inclusion a-t-il un effet immédiat sur les e-mails ?

Uniquement une fois la propagation DNS effectuée, ce qui peut prendre jusqu'à 48 heures. Vérifiez l'enregistrement à l'aide d'un outil de recherche avant de le publier, puis assurez-vous que le nouvel expéditeur respecte l'alignement « SPF » dans vos rapports DMARC.

• À propos de
• Derniers messages

Yunes Tarada

Expert en sécurité des domaines et des e-mails chez PowerDMARC

Yunes est chef d'équipe des opérations chez PowerDMARC et possède des connaissances approfondies en matière d'authentification et de sécurité des courriels. Yunes est certifié Microsoft Azure Administrator Associate et possède des certifications CompTIA A+ et bien d'autres encore.

Derniers messages de Yunes Tarada (voir tous)

• Guide de configuration de TinkMail : DKIM, DMARC et SPF - 19 août 2026
• Guide de configuration de DKIM, DMARC et de l'SPF dans PandaDoc - 19 août 2026
• Guide de configuration de Moloni DKIM, DMARC et « SPF » - 18 août 2026