Explication de la limite SPF requêtes DNS SPF (et comment y remédier)

Pour bien comprendre les limites SPF , il faut commencer par la limite de 10 requêtes DNS. Si votre SPF génère plus de 10 requêtes DNS, les serveurs de réception renvoient un message «SPF : trop de requêtes DNS », et DMARC considère cela comme un échec cuisant. Cela a pour conséquence que des e-mails légitimes sont rejetés ou envoyés dans le dossier spam sans avertissement.

Cette limite découle de la RFC 7208, qui plafonne SPF à 10 mécanismes d'interrogation DNS par vérification. Le problème est que la plupart des domaines dépassent cette limite sans s'en rendre compte, souvent en raison d'inclusions imbriquées et de services obsolètes.

Dans ce guide, vous découvrirez quels éléments sont pris en compte dans le calcul de la limite, pourquoi SPF peuvent cesser de fonctionner sans signe avant-coureur, et comment résoudre et éviter définitivement les échecs de recherche.

SPF : vérifiez le nombre actuel de requêtes avec notre SPF gratuit

Qu'est-ce que la limite de recherche DNS SPF ?

SPF , définie dans la RFC 7208, limite chaque SPF à un maximum de 10 mécanismes d'interrogation DNS.

En termes simples, chaque fois qu'un serveur de messagerie destinataire vérifie votre SPF et doit effectuer une requête DNS supplémentaire, cela est pris en compte dans cette limite.

Ces requêtes sont déclenchées par des mécanismes tels que :

• inclure
• a
• mx
• ptr
• existe
• rediriger

Dès que la 11e consultation est requise, SPF s'arrête immédiatement et renvoie :

SPF : trop de requêtes DNS

Chaque requête DNS mobilise du temps et des ressources, telles que le processeur, la bande passante et la mémoire, sur le serveur destinataire. En l'absence de limite, un acteur malveillant pourrait créer un SPF comportant des inclusions profondément imbriquées, forçant ainsi les serveurs à effectuer des centaines de requêtes DNS.

Cela transformerait de fait SPF en un vecteur d'attaque par déni de service (DoS).

En imposant une limite stricte de 10 requêtes, la SPF garantit :

• délais de traitement prévisibles des e-mails
• protection contre les abus DNS
• une performance constante sur l'ensemble des systèmes de messagerie 

Quels éléments sont pris en compte dans la limite SPF requêtes DNS SPF ? 

Tous les éléments de votre SPF ne déclenchent pas nécessairement une requête DNS. Savoir ce qui compte et ce qui ne compte pas est le moyen le plus rapide de réduire le nombre de requêtes.

SPF qui comptent et ceux qui ne comptent pas

C'est pourquoi inclure : et les mécanismes sont les principaux facteurs à l'origine SPF , en particulier lorsqu'ils contiennent des recherches imbriquées.

Remplacer les mécanismes nécessitant de nombreuses recherches par des ip4 : ou ip6: (dans la mesure du possible) est l'un des moyens les plus efficaces de rester dans les limites.

Situation courante : les MSP gérant plusieurs SPF pour leurs clients

Les fournisseurs de services gérés ( MSP ) sont souvent confrontés à des problèmes liés SPF lorsque leurs clients utilisent plusieurs plateformes de messagerie. Un client type d'un MSP peut par exemple utiliser Office 365, Mailchimp, Salesforce et HubSpot, chacune de ces plateformes nécessitant des instructions « include » qui peuvent rapidement atteindre la limite de 10 requêtes.

Pourquoi vous atteignez probablement la SPF (inclusions imbriquées)

Votre dossier ne mentionne peut-être que trois ou quatre lignes, lignes, mais vous atteignez tout de même la limite. Voici pourquoi.

v=spf1 inclure : sendgrid.net inclure : _spf.google.com inclure : salesforce.com ~all

À première vue, cela ressemble à trois requêtes DNS, mais SPF ne s'arrête pas là. Elle suit chaque inclusion de manière récursive.

Voici ce qui se passe en réalité :

1. inclure : sendgrid.net → SPF de SendGrid contient 2 include: → 3 recherches au total
2. inclure :_spf.google.com → SPF de Google contient 3 mécanismes supplémentaires → 4 requêtes au total
3. inclure : salesforce.com → SPF de Salesforce contient 3 mécanismes supplémentaires → 4 recherches au total

Total : 11 requêtes DNS

Parmi inclure : que vous ajoutez ne correspond pas à une seule recherche. Il s’agit d’une recherche, plus toutes celles que les SPF . C'est pourquoi la limite est atteinte bien plus rapidement que ne s'y attendent la plupart des propriétaires de domaine, en particulier lorsqu'ils utilisent plusieurs fournisseurs de services de messagerie.

Pourquoi existe-t-il une limite de recherche SPF ?

La limite de 10 requêtes DNS peut sembler restrictive, en particulier pour les entreprises qui font appel à plusieurs fournisseurs de messagerie, mais elle a été mise en place pour des raisons importantes liées à la sécurité et aux performances que les administrateurs et les équipes de sécurité doivent comprendre.

Résumé : La limite de recherche protège l'infrastructure DNS contre les abus tout en garantissant un traitement rapide des e-mails, mais nécessite une gestion rigoureuse SPF .

Prévention des attaques par déni de service

La limite de 10 recherches supplémentaires est imposée afin d'éviter une charge excessive sur le DNS et de prévenir les attaques par déni de service (DoS).

Sans cette limite, un pirate pourrait créer un SPF comportant des centaines d'inclusions imbriquées, obligeant ainsi chaque serveur de messagerie destinataire qui traite un e-mail provenant de ce domaine à effectuer un nombre considérable de requêtes DNS. Cela pourrait saturer les serveurs DNS et nuire aux performances sur l'ensemble d'Internet.

Assurer le traitement rapide des e-mails

Chaque requête DNS effectuée lors d'une SPF ajoute un temps de latence au processus de distribution des e-mails. Si SPF pouvaient faire l'objet d'un nombre illimité de requêtes, le temps nécessaire à SPF pourrait augmenter considérablement, entraînant des délais d'expiration des requêtes DNS et des pannes temporaires des serveurs DNS.

La limite de 10 recherches garantit que SPF peuvent être effectuées rapidement et de manière fiable sans créer de goulots d'étranglement dans la livraison des e-mails.

Maintenir la stabilité du DNS

L'infrastructure DNS est une ressource partagée. Autoriser des requêtes illimitées lors de SPF imposerait une charge excessive aux résolveurs récursifs et aux serveurs de noms faisant autorité, en particulier pour les expéditeurs à fort volume.

Cette limite protège l'écosystème DNS dans son ensemble en maintenant le volume des requêtes SPF à un niveau gérable.

Que se passe-t-il lorsque vous dépassez la limite SPF ?

Le dépassement de la limite SPF n'entraîne pas seulement un simple avertissement. Elle provoque une erreur grave qui peut avoir un impact direct sur la réception de vos e-mails dans la boîte de réception de vos destinataires.

SPF s'arrête à la recherche n° 11

L'évaluation SPF de gauche à droite. Lorsque le serveur destinataire rencontre le 11e mécanisme de requête DNS ou modificateur dans votre SPF , il interrompt immédiatement le traitement de l'enregistrement et renvoie :

SPF : trop de requêtes DNS

Il s'agit d'une erreur SPF permanente, et non d'un échec partiel ou d'un résultat neutre. Le destinataire considère SPF comme non valide, car il ne parvient pas à mener à bien l'authentification.

DMARC considère SPF ) comme un SPF

Dès que SPF une erreur « PermError », DMARC l'interprète comme un SPF . Si SPF était requis pour que DMARC soit validé, le message risque d'échouer complètement à l'authentification DMARC.

Le résultat dépend alors :

• Votre politique DMARC (p=none, quarantineou refus)
• Les règles de filtrage du serveur de réception
• Si la validation DKIM aboutit et si l'alignement est correct

Les e-mails peuvent être rejetés, mis en quarantaine ou envoyés dans le dossier des spams

Lorsque SPF en raison d'une erreur permanente (PermError) :

• Certains fournisseurs peuvent tout simplement rejeter l'e-mail
• D'autres pourraient le classer comme spam ou le mettre quarantine
• Les filtres de sécurité peuvent signaler le message comme suspect ou non authentifié

Cela s'avère particulièrement préjudiciable avec des politiques DMARC plus strictes, telles que quarantine ou p=reject.

Les environnements Microsoft sont particulièrement sensibles à cet égard. Outlook et Exchange Online appliquent de manière stricte les contrôles d'authentification ; par conséquent, SPF peuvent avoir un impact significatif sur la délivrabilité pour les organisations qui envoient des messages à des destinataires Office 365.

Étant donné que SPF évalué de gauche à droite, certains services d'envoi peuvent s'authentifier avec succès avant que la limite de recherches ne soit atteinte, tandis que d'autres échouent plus loin dans la chaîne.

Cela signifie que :

• Certains e-mails semblent s'envoyer normalement
• D'autres échouent à l'authentification de manière inattendue
• Sans les rapports DMARC et les outils SPF , le problème devient difficile à diagnostiquer

C'est pourquoi les problèmes liés aux limites SPF passent souvent inaperçus jusqu'à ce que le taux de délivrabilité baisse ou que les rapports DMARC révèlent des échecs intermittents.

Autres causes de SPF

Le dépassement de la limite de 10 requêtes DNS est la cause la plus courante des SPF , mais ce n'est pas la seule. Des erreurs PermError peuvent également se produire lorsque :

• Plusieurs SPF existent pour le même domaine
• SPF contient des erreurs de syntaxe
• Des mécanismes obsolètes ou non pris en charge sont utilisés
• Circulaire comprennent : les instructions créent des boucles de recherche infinies

N'importe lequel de ces problèmes peut compromettre SPF et nuire à la délivrabilité des e-mails.

Vérifiez votre politique DMARC pour évaluer votre vulnérabilité à l'aide d'un vérificateur d'enregistrements DMARC

N'importe lequel de ces problèmes peut entraîner SPF et à des e-mails non remis. Il est donc important de vérifier régulièrement l'ensemble de votre SPF .

La limite de recherche SPF : l'autre contrainte à laquelle vous pourriez être confronté

La plupart SPF s'arrêtent à la limite des 10 requêtes DNS, mais la RFC 7208 prévoit une deuxième contrainte susceptible de provoquer le même échec, même si le nombre de requêtes est bien inférieur à 10 : la limite des requêtes nuls.

Une recherche infructueuse est une requête DNS qui ne renvoie aucun résultat exploitable.

Cela se produit lorsqu'une recherche renvoie :

• NXDOMAIN (le domaine n'existe pas)
• NOERROR : aucun enregistrement (réponse vide)

La RFC 7208 limite SPF à un maximum de deux requêtes vides par vérification.

Si une troisième recherche infructueuse a lieu, le serveur destinataire renvoie :

SPF

Cela signifie :

Vous pouvez déclencher une SPF même si votre enregistrement fait l'objet de moins de 10 requêtes DNS.

C'est ce qui rend les recherches de vide dangereuses, car elles sont plus difficiles à détecter et sont souvent négligées lors SPF .

Les recherches infructueuses sont généralement dues à SPF obsolètes ou mal configurées :

• inclure : le fait de pointer vers un domaine qui ne dispose plus d'un SPF
• un ou mx mécanismes faisant référence à des domaines sans enregistrements DNS valides
• Fournisseurs de services de messagerie obsolètes ou hors service
• Fautes de frappe dans les noms de domaine au sein SPF

Une seule inclusion obsolète peut entraîner, sans qu'on s'en aperçoive, une recherche infructueuse à chaque SPF .

Voici en quoi la limite de 10 recherches et la limite de recherches nulles diffèrent :

Les deux cas aboutissent au même résultat : une erreur SPF .

Pour éviter les échecs de recherche de valeurs nulles :

• Vérifiez régulièrement votre SPF pour repérer les éléments obsolètes inclure : .
• Supprimez les services que vous n'utilisez plus
• Vérifier que tous les domaines référencés renvoient des enregistrements DNS valides
• Utilisez un SPF qui signale les requêtes vides, et pas seulement le nombre total de requêtes

SPF de PowerDMARC identifie à la fois les requêtes réussies et les requêtes infructueuses, ce qui vous permet de détecter ces erreurs cachées avant qu'elles n'affectent la délivrabilité.

Comment vérifier si votre SPF dépasse la limite

Vérifier si votre SPF dépasse la limite de 10 requêtes DNS est la première étape pour résoudre les problèmes de délivrabilité. Il existe plusieurs façons d'effectuer une vérification SPF et de vérifier votre nombre actuel de requêtes.

Résumé :SPF régulière SPF à l'aide d'outils de diagnostic et d'une validation manuelle permet d'éviter les violations des limites de consultation avant qu'elles n'affectent la délivrabilité des e-mails.

Utilisez un outil SPF .

L'utilisation d'un outil SPF permet de vérifier si un SPF est valide et fonctionne correctement. Ces outils analysent votre SPF , comptabilisent chaque requête DNS, y compris les inclusions imbriquées, et signalent toute erreur ou tout avertissement.

L'outil gratuit de vérification SPF de PowerDMARC vous permet de connaître instantanément le nombre total de requêtes, d'identifier les mécanismes qui génèrent le plus de requêtes et de repérer les erreurs de configuration avant qu'elles n'entraînent des problèmes de livraison.

Suivez manuellement votre SPF

Si vous préférez inspecter vous-même votre SPF , vous pouvez compter manuellement les recherches DNS en parcourant chaque mécanisme de l'enregistrement.

Commencez par l'enregistrement SPF de votre domaine et comptez tous les mécanismes « include », « a », « mx », « ptr », « redirect » et « exists ». Ensuite, pour chaque « include », recherchez SPF du domaine référencé et comptez également les mécanismes à l'origine de cette recherche.

Les inclusions imbriquées s'additionnent rapidement, c'est pourquoi les organisations qui utilisent plusieurs fournisseurs de services de messagerie électronique dépassent souvent la limite sans s'en rendre compte.

Surveiller SPF au fil du temps

SPF ne sont pas statiques. Lorsque vous ajoutez ou supprimez des fournisseurs de messagerie, modifiez vos environnements d'hébergement ou mettez à jour votre infrastructure de messagerie, votre SPF change également. Il est recommandé de valider SPF après avoir effectué des modifications afin de garantir le respect de la limite de 10 requêtes.

La mise en place d'une surveillance continue via la plateforme PowerDMARC vous offre une visibilité permanente sur votre SPF et vous alerte lorsque des modifications font dépasser la limite de votre enregistrement.

Comment corriger et optimiser votre SPF

Si votre SPF dépasse ou approche la limite de 10 recherches DNS, vous pouvez prendre plusieurs mesures pratiques pour réduire le nombre de recherches sans sacrifier la couverture de l'authentification des e-mails.

Résumé :SPF consiste à supprimer les services inutilisés, à remplacer les mécanismes nécessitant de nombreuses recherches par des adresses IP directes et à mettre en place une gestion automatisée pour les infrastructures complexes.

Vérifiez votre SPF actuel et comptez le nombre de requêtes

Commencez par analyser votre SPF à l'aide d'un SPF fiable. Cela vous aidera à déterminer le nombre total de requêtes DNS, y compris les inclusions imbriquées, et à signaler les problèmes tels que les requêtes vides ou les erreurs de configuration. Cela mettra également en évidence les mécanismes qui génèrent le plus de requêtes.

Le comptage manuel est possible, mais souvent imprécis en raison de la récursivité au sein des domaines inclus ; il est donc recommandé d'utiliser un outil dès que possible.

Supprimer les services inutilisés ou inutiles

L'optimisation la plus simple consiste à vérifier votre SPF et à supprimer tous les mécanismes qui font référence à des services que vous n'utilisez plus.

Au fil du temps, les organisations ajoutent des fournisseurs de services de messagerie électronique, des plateformes marketing et des outils tiers à leur SPF , mais oublient de les supprimer lorsqu'ils ne sont plus actifs.

Pour réduire le nombre de recherches nécessaires, les organisations doivent supprimer les services inutilisés de leur SPF . Cela implique également de supprimer SPF par défaut qui ont été ajoutées lors de la configuration initiale, mais qui ne servent plus à rien aujourd'hui.

Évitez ptr et réduisez au minimum les mx ».

Le mécanisme est fortement déconseillé par SPF . Il effectue des recherches DNS inversées pour chaque adresse IP d'origine, ce qui le rend lent, peu fiable et gourmand en ressources. S'il est présent, supprimez-le et remplacez-le par des références directes à l'adresse IP.

Le mécanisme peut également faire grimper le nombre de requêtes. Il résout d'abord les enregistrements MX, puis effectue des requêtes supplémentaires pour chaque serveur de messagerie associé. Si votre infrastructure est stable, remplacez mx par ip4: ou ip6: pour une meilleure efficacité.

Remplacer les mécanismes nécessitant de nombreuses recherches par ip4 ou ip6

Chaque mécanisme « include », « a » et « mx » nécessite au moins une requête DNS. Dans la mesure du possible, remplacez-les par des mécanismes ip4 ou ip6 qui spécifient directement les adresses IP autorisées. L'utilisation de mécanismes ip4 ou ip6 dans SPF ne nécessite pas de recherches supplémentaires et peut aider à respecter la limite de recherches.

Par exemple, si SPF d'un fournisseur de services de messagerie électronique renvoie à un ensemble connu d'adresses IP statiques, vous pouvez répertorier ces adresses IP directement plutôt que d'utiliser une instruction « include » qui déclenche plusieurs recherches DNS.

Utiliser SPF (solution temporaire)

SPF remplace : les mécanismes par leurs adresses IP résolues, réduisant ainsi les requêtes DNS à presque zéro. Pour ramener rapidement votre enregistrement sous la limite, utilisez SPF automatisé, puis validez l'enregistrement mis à jour avant de le publier.

Cela comporte toutefois des inconvénients. Si un fournisseur modifie ses adresses IP et que votre enregistrement n'est pas mis à jour, des e-mails légitimes peuvent échouer SPF. La simplification manuelle nécessite une surveillance et une maintenance constantes.

Utiliser SPF hébergé SPF SPF (solution définitive)

Pour garantir une stabilité à long terme, envisagez une SPF hébergée telle que PowerDMARC. Ces systèmes gèrent votre SPF de manière dynamique à l'aide de macros ou d'une résolution externe, vous assurant ainsi de respecter automatiquement les limites de consultation.

Cette approche permet d'éliminer :

• Mises à jour manuelles en cas de modification des adresses IP des fournisseurs
• Risques liés à des enregistrements obsolètes et simplifiés
• Frais généraux liés à la maintenance courante

Cela s'avère particulièrement utile pour les organisations qui utilisent plusieurs services tiers ou qui gèrent des infrastructures de messagerie complexes.

Évitez le mécanisme ptr

L'utilisation du mécanisme ptr est fortement déconseillée, car elle peut entraîner une augmentation du nombre de recherches nécessaires, ce qui peut causer des problèmes de Permerror.

Le mécanisme ptr effectue une recherche DNS inverse pour chaque adresse IP qui se connecte, ce qui est à la fois lent et peu fiable. SPF elle-même déconseille son utilisation. Si votre SPF inclut actuellement un mécanisme ptr, supprimez-le et remplacez-le par des références IP directes.

Réduire au minimum l'utilisation du mécanisme mx

Éviter d'utiliser le mécanisme MX dans SPF peut permettre de respecter la limite de 10 requêtes DNS. Le mécanisme MX résout d'abord l'enregistrement MX du domaine, puis effectue des requêtes supplémentaires pour déterminer l'adresse IP de chaque serveur de messagerie répertorié.

Si votre domaine comporte plusieurs enregistrements MX, un seul mécanisme « mx » peut nécessiter plusieurs requêtes. Remplacez-le par des entrées ip4 ou ip6 pour vos serveurs de messagerie lorsque cela est possible.

Consolider les déclarations incluses

Si votre SPF comporte plusieurs mécanismes « include » pointant vers des services connexes, vérifiez s'ils peuvent être consolidés.

Certains fournisseurs de services de messagerie électronique partagent des infrastructures qui se chevauchent, ce qui signifie que vous effectuez peut-être des recherches redondantes. Vérifiez chaque inclusion afin de déterminer si elle est toujours nécessaire et si les adresses IP sous-jacentes peuvent être référencées directement.

Valider après chaque modification

Il est essentiel de valider SPF après avoir apporté des modifications afin de garantir le respect de la limite de 10 recherches.

Même une modification mineure, comme l'ajout d'une seule nouvelle balise « include » pour une plateforme marketing, peut faire dépasser la limite de votre enregistrement si elle déclenche des recherches imbriquées. Vérifiez votre enregistrement à l'aide d'un outil SPF après chaque mise à jour pour vous assurer qu'il reste valide.

Aplatissement SPF : qu'est-ce que c'est et quand l'utiliser ?

L'aplatissementSPF est une technique utilisée pour optimiser SPF afin de contourner la limite de 10 requêtes DNS imposée par SPF. C'est l'une des solutions les plus discutées pour les organisations disposant d'infrastructures de messagerie complexes, mais elle comporte des compromis qu'il est important de comprendre.

Pour un guide d'optimisation complet sur la manière d'optimiser votre SPF , consultez notre blog consacré au guide SPF

Comment fonctionne l'aplatissement SPF

L'aplatissement SPF remplace les mécanismes de recherche dans un SPF par leurs adresses IP ou plages CIDR correspondantes, réduisant ainsi le nombre de requêtes DNS nécessaires pour vérifier SPF .

Au lieu d'inclure une référence telle que « include:emailprovider.com » qui déclenche une ou plusieurs recherches DNS, vous résolvez cette référence en adresses IP sous-jacentes et les répertoriez directement dans votre enregistrement à l'aide des mécanismes ip4 ou ip6.

Par exemple, si « include:emailprovider.com » renvoie trois adresses IP, l'aplatissement remplace l'instruction « include » par ces trois entrées IPv4. SPF renvoie désormais le même résultat sans nécessiter de requêtes DNS supplémentaires pour ce fournisseur.

Quand l'aplatissement aide

L'aplatissement d'un SPF peut réduire le nombre de mécanismes et de modificateurs de requêtes DNS afin qu'il soit inférieur à 10. Cela est particulièrement utile lorsque :

• Votre domaine envoie des e-mails via de nombreux services tiers et le nombre d'inclusions dépasse à lui seul les 10.
• Vous avez déjà supprimé les services inutilisés et regroupé ceux qui pouvaient l'être, mais vous dépassez toujours la limite.
• Vous avez besoin d'un moyen rapide de mettre vos dossiers en conformité tout en planifiant une stratégie d'optimisation à plus long terme.

Pourquoi SPF manuel SPF n'est qu'une solution temporaire

SPF peut rapidement faire passer votre enregistrement sous la limite des 10 recherches, mais la simplification manuelle SPF votre SPF n'est pas une solution à long terme, car elle entraîne d'autres risques susceptibles de perturber tout autant la distribution des e-mails.

Risque n° 1 : modification des adresses IP des fournisseurs

La plupart des fournisseurs de messagerie modifient ou élargissent leurs plages d'adresses IP d'envoi sans préavis.

Lorsque vous simplifiez manuellement votre SPF :

• vous configurez ces adresses IP en dur dans votre DNS
• mais votre fournisseur ne cesse d'évoluer en coulisses

Dès que leur liste d'adresses IP change, votre SPF devient obsolète et les e-mails légitimes ne parviennent plus à passer l'authentification.

Risque n° 2 : taille SPF (255 caractères + limites DNS)

La simplification remplace les inclusions comportant plusieurs adresses IP, ce qui peut rapidement alourdir votre SPF .

Cela pose deux problèmes :

• Les enregistrements TXT DNS sont limités à 255 caractères par chaîne
• SPF trop longs peuvent perturber l'analyse ou dépasser les limites du DNS

Tenter de « corriger » les limites de recherche peut entraîner par inadvertance des erreurs de syntaxe ou des problèmes de troncature des enregistrements.

Risque n° 3 : absence de suivi ou de visibilité

Le aplatissement manuel est statique. Il n'existe pas de méthode intégrée pour :

• détecter les changements de plages d'adresses IP
• nombre de recherches de pistes au fil du temps
• vous avertir en cas d'échecs d'authentification

Cela signifie que les problèmes passent souvent inaperçus jusqu'à ce que le taux de délivrabilité baisse.

Risque n° 4 : Charge de maintenance continue

Chaque fois que vous :

• Ajouter un nouveau service de messagerie
• modifier l'infrastructure
• ou si votre fournisseur met à jour les adresses IP

Vous devez recréer et valider manuellement votre SPF .

Pour les équipes qui gèrent plusieurs domaines ou clients, cela devient rapidement ingérable.

Manuel SPF résout le symptôme (limite de recherche), mais pas la complexité sous-jacente (infrastructure dynamique).

C'est là que SPF hébergées entrent en jeu.

Au lieu d'utiliser des adresses IP fixes, des plateformes telles que PowerDMARC gèrent dynamiquement votre SPF à l'aide de macros et de mises à jour automatisées, ce qui vous permet de respecter la limite de requêtes sans avoir à intervenir manuellement en permanence.

Autres limitations à connaître concernant SPF

La limite de 10 requêtes DNS est la SPF la plus connue SPF , mais ce n'est pas la seule. Les propriétaires de domaines doivent connaître ces autres limitations SPF afin d'éviter des échecs d'authentification inattendus.

Résumé : Au-delà de la limite de 10 requêtes, SPF des contraintes concernant le nombre d'enregistrements, la longueur des chaînes de caractères, les requêtes vides et les scénarios de transfert qui affectent l'authentification des e-mails.

Un seul SPF par domaine

SPF exige que chaque domaine ne publie qu'un seul enregistrement SPF .

Si SPF contient plusieurs enregistrements SPF pour un même domaine, cela peut entraîner une SPF , et le serveur destinataire peut rejeter le message ou le traiter de manière incorrecte. Si vous devez autoriser des expéditeurs supplémentaires, ajoutez-les à votre SPF existant plutôt que d'en créer un second.

SPF le chemin de retour, pas l'adresse d'expéditeur.

SPF le domaine dans l'adresse de retour, et non dans le champ « De » lisible par l'utilisateur que voit le destinataire. Cela signifie qu'un pirate peut usurper l'adresse « De » tout en passant SPF utilisant un domaine de retour différent.

DMARC comble cette lacune en exigeant une correspondance ou un alignement entre le domaine du champ « De » lisible par l'utilisateur et le domaine authentifié par SPF

Limite de 255 caractères pour les chaînes de caractères

Bien qu'un SPF puisse contenir plus de 255 caractères au total, un seul enregistrement DNS TXT est limitée à 255 caractères. SPF plus longs doivent être divisés en plusieurs chaînes au sein du même enregistrement TXT.

La plupart des fournisseurs DNS gèrent cela automatiquement, mais des divisions mal configurées peuvent entraîner des erreurs d'analyse.

Limite de recherche nulle

En plus de la limite de 10 requêtes DNS, la SPF limite également le nombre de « requêtes vides », qui sont des requêtes DNS ne renvoyant aucun enregistrement (réponse vide ou réponse NXDOMAIN).

Le dépassement de cette limite, qui est généralement de deux recherches infructueuses, peut également déclencher une erreur SPF .

Aucune protection pour les e-mails transférés

Lorsqu'un e-mail est transféré, l'adresse IP de l'expéditeur est remplacée par celle du serveur de transfert, qui n'est généralement pas mentionnée dans SPF de l'expéditeur d'origine. Cela peut entraîner l'échec SPF pour l'e-mail transféré, même si le message d'origine était légitime.

Bonnes pratiques pour ne pas dépasser la limite SPF

Respecter la limite SPF requêtes DNS imposée par SPF demande une discipline constante. Suivez ces bonnes pratiques pour optimiser votre enregistrement et éviter toute défaillance imprévue :

• Vérifiez votre SPF chaque fois que vous ajoutez ou supprimez une plateforme d'envoi
• Ne publiez jamais plus d'un SPF par domaine
• Évitez le ptr , supprimez-le s'il existe dans votre enregistrement
• Utilisation ip4: et ip6: partout où les plages d'adresses IP sont stables et connues
• Configurez les rapports DMARC pour détecter rapidement SPF intermittents
• Utilisez un système de surveillance automatisée (comme PowerDMARC) pour recevoir des alertes lorsque le nombre de requêtes change
• Envisagez SPF hébergé SPF vous gérez plus de trois ou quatre services d'envoi tiers

Comment SPF hébergé de PowerDMARC SPF d'éviter les échecs SPF  

SPF manuelle SPF devient rapidement ingérable dans les environnements de messagerie modernes. Chaque nouvelle plateforme de messagerie, outil marketing, CRM, service d'assistance ou service cloud peut entraîner SPF recherches imbriquées et d'une charge de maintenance supplémentaire.

SPF manuel SPF peut réduire temporairement le nombre de requêtes, mais cela pose un autre problème : il faut veiller à ce que les adresses IP codées en dur restent exactes à mesure que les fournisseurs mettent à jour leur infrastructure d'envoi.

SPF hébergé de PowerDMARC, ou PowerSPF, résout le problème de gestion sous-jacent en maintenant SPF à jour à mesure que votre infrastructure d'envoi évolue. Contrairement à SPF statique SPF , SPF hébergé gère SPF votre SPF en arrière-plan, aidant ainsi les organisations à rester conformes à la norme RFC 7208 sans avoir à effectuer de maintenance DNS constante.

Grâce à PowerSPF, les entreprises peuvent :

• Mettre à jour automatiquement SPF lorsque les adresses IP des fournisseurs changent
• Utilisez SPF pour respecter la limite de 10 requêtes DNS et les restrictions de longueur des noms DNS
• Effectuez une modification ponctuelle du DNS plutôt que de modifier manuellement SPF à plusieurs reprises
• Gérer SPF complexes impliquant plusieurs fournisseurs, des inclusions imbriquées, des infrastructures régionales et des domaines d'entreprise
• Surveillez SPF , les requêtes infructueuses et les problèmes d'authentification avant qu'ils n'affectent la délivrabilité

Cela s'avère particulièrement utile pour les organisations qui utilisent simultanément des plateformes telles que Microsoft 365, Salesforce, HubSpot, SendGrid, Mailchimp et d'autres services d'envoi tiers, car les inclusions imbriquées peuvent, sans qu'on s'en rende compte, faire dépasser les limites RFC SPF .

Grâce à l'automatisation SPF , la surveillance des requêtes en temps réel, les alertes d'erreur et des outils pour SPF, DKIM, DMARC et BIMI, PowerDMARC aide les organisations à maintenir SPF dans les limites de requêtes et à conserver une configuration d'authentification plus propre.

Pour commencer, vérifiez le nombre SPF avec SPF de PowerDMARC et identifiez les problèmes avant qu'ils n'affectent l'authentification des e-mails.

Foire aux questions

1. Quelle est la limite de requêtes DNS pour SPF ?

SPF , définie dans la RFC 7208, limite chaque SPF à un maximum de 10 mécanismes d'interrogation DNS.

Si votre SPF nécessite plus de 10 requêtes lors de son évaluation, le serveur destinataire renvoie une SPF , qui est considérée comme un échec par DMARC. Cela peut entraîner le rejet de courriels légitimes ou leur transfert vers le dossier des spams.

2. Quels SPF sont pris en compte dans la limite de 10 requêtes ?

Les mécanismes suivants déclenchent des requêtes DNS et sont pris en compte dans le calcul de la limite :

• inclure
• a
• mx
• ptr
• existe
• redirect=

Ceux-ci ne comptent pas :

• ip4, ip6 (adresses IP directes)
• tout (fourre-tout)
• v=spf1 (balise de version)
• La requête DNS initiale visant à récupérer votre SPF

3. Qu'est-ce qu'une SPF ?

Une erreur SPF (erreur permanente) se produit lorsqu'un serveur destinataire ne parvient pas à analyser correctement votre SPF .

La cause la plus fréquente est le dépassement de la limite de 10 requêtes DNS, mais cela peut également être dû à :

• erreurs de syntaxe
• plusieurs SPF
• violations de la limite de recherche
• La circulaire comprend

Dans ce cas, SPF complètement, ce qui peut nuire à la bonne distribution des e-mails.

4. Quelle est la limite de recherche de zones SPF ?

Outre la limite de 10 requêtes, la RFC 7208 limite également les requêtes vides, c'est-à-dire les requêtes DNS qui ne renvoient aucun résultat (NXDOMAIN ou réponses vides).

La limite est fixée à deux recherches infructueuses par SPF .

Si votre SPF déclenche une troisième requête infructueuse, le serveur destinataire renvoie une erreur permanente (PermError), même si le nombre total de requêtes est inférieur à 10.

5. SPF permet-elle de contourner la limite de 10 requêtes ?

Oui, mais seulement pour un temps.

SPF remplace inclure par des adresses IP directes, ce qui réduit les requêtes DNS. Cependant, cela nécessite une maintenance constante, car les fournisseurs de services de messagerie mettent fréquemment à jour leurs plages d'adresses IP.

Si votre fichier de configuration SPF n'est plus à jour, des e-mails légitimes risquent d'échouer SPF .

6. Comment puis-je vérifier le nombre de requêtes DNS générées par mon SPF ?

Vous pouvez utiliser un outil SPF pour analyser votre enregistrement et compter les requêtes DNS, y compris les inclusions imbriquées.

SPF de PowerDMARC indique :

• nombre total de recherches
• nombre de recherches
• quels mécanismes consomment des requêtes

Cela vous permet d'identifier les problèmes avant qu'ils n'affectent la délivrabilité.

7. Quelle est la différence entre SPF et SPF ?

La fonctionnalité « SPF » remplace de manière statique les inclusions par des adresses IP, ce qui réduit le nombre de recherches mais nécessite des mises à jour manuelles.

SPF (utilisées dans SPF hébergées) résolvent dynamiquement SPF lors de l'évaluation, ce qui vous permet de respecter les limites de recherche sans avoir à gérer manuellement les listes d'adresses IP.

Les macros offrent une plus grande évolutivité et sont mieux adaptées aux configurations de messagerie complexes ou impliquant plusieurs fournisseurs.

8. À quelle fréquence dois-je vérifier mon SPF ?

Nous vous recommandons de vérifier votre SPF :

• chaque fois que vous ajoutez ou supprimez un service de messagerie
• à la suite de modifications apportées à l'infrastructure
• au moins une fois par mois

Pour les configurations complexes, il est recommandé d'effectuer une surveillance continue afin de détecter rapidement les problèmes liés aux limites de recherche et de garantir une délivrabilité constante.

• À propos de
• Derniers messages

Ahona Rudra

Expert en sécurité des domaines et des courriels chez PowerDMARC

Ahona est la responsable du marketing chez PowerDMARC, avec plus de 5 ans d'expérience dans l'écriture sur des sujets de cybersécurité, spécialisée dans la sécurité des domaines et des courriels. Ahona est titulaire d'un diplôme de troisième cycle en journalisme et communication, solidifiant sa carrière dans le secteur de la sécurité depuis 2019.

Derniers messages de Ahona Rudra (voir tous)

• Comment les MSP peuvent gérer plus rapidement le DMARC de chaque client grâce au serveur MCP de PowerDMARC - 25 mai 2026
• Comment ajouter une adresse IP à votre SPF (guide étape par étape) - 11 mai 2026
• SPF Avanan : comment configurer, corriger et optimiser votre SPF Check Point Harmony Email - 7 mai 2026