--- title: "Test avancé des enregistrements SPF : protégez votre domaine des problèmes de permerror | AutoSPF" description: "Pour protéger votre domaine des problèmes de permerror SPF, imposez une validation syntaxique stricte." image: "https://autospf.com/og/blog/advanced-spf-record-testing-protect-your-domain-from-permerror-issues.png" canonical: "https://autospf.com/fr/blog/advanced-spf-record-testing-protect-your-domain-from-permerror-issues/" --- Quick Answer Pour protéger votre domaine des problèmes de permerror SPF, imposez une validation syntaxique stricte, limitez les recherches DNS à 10 grâce à la minimisation des include et à un aplatissement/redirect judicieux, exécutez des tests CI/CD qui simulent les défaillances DNS et les tokens malformés, surveillez le nombre de recherches et le comportement DNS transitoire en production, et utilisez AutoSPF pour automatiser la détection, l'aplatissement dynamique, les alertes et les déploiements sécurisés. ## Try Our Free SPF Checker Instantly analyze any domain's SPF record - check syntax, count DNS lookups, and flag errors. [ Check SPF Record → ](/tools/spf-checker/) Share [ ](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fautospf.com%2Fblog%2Fadvanced-spf-record-testing-protect-your-domain-from-permerror-issues%2F "Share on LinkedIn") [ ](https://twitter.com/intent/tweet?text=Test%20avanc%C3%A9%20des%20enregistrements%20SPF%20%3A%20prot%C3%A9gez%20votre%20domaine%20des%20probl%C3%A8mes%20de%20permerror&url=https%3A%2F%2Fautospf.com%2Fblog%2Fadvanced-spf-record-testing-protect-your-domain-from-permerror-issues%2F "Share on X/Twitter") [ ](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fautospf.com%2Fblog%2Fadvanced-spf-record-testing-protect-your-domain-from-permerror-issues%2F "Share on Facebook") [ ](https://reddit.com/submit?url=https%3A%2F%2Fautospf.com%2Fblog%2Fadvanced-spf-record-testing-protect-your-domain-from-permerror-issues%2F&title=Test%20avanc%C3%A9%20des%20enregistrements%20SPF%20%3A%20prot%C3%A9gez%20votre%20domaine%20des%20probl%C3%A8mes%20de%20permerror "Share on Reddit") [ ](mailto:?subject=Test%20avanc%C3%A9%20des%20enregistrements%20SPF%20%3A%20prot%C3%A9gez%20votre%20domaine%20des%20probl%C3%A8mes%20de%20permerror&body=Check out this article: https%3A%2F%2Fautospf.com%2Fblog%2Fadvanced-spf-record-testing-protect-your-domain-from-permerror-issues%2F "Share via Email") ![Protégez votre domaine](https://media.mailhop.org/autospf/images/2026/03/spf-validator-5901.jpg) Pour protéger votre domaine des problèmes de permerror SPF, imposez une validation syntaxique stricte, limitez les recherches DNS à 10 grâce à la minimisation des include et à un aplatissement/redirect judicieux, exécutez des tests CI/CD qui simulent les défaillances DNS et les tokens malformés, surveillez le nombre de recherches et le comportement DNS transitoire en production, et utilisez AutoSPF pour automatiser la détection, l’aplatissement dynamique, les alertes et les déploiements sécurisés. > « D’un point de vue technique, la limite de 10 recherches est un mécanisme de protection des ressources, pas une fonctionnalité de sécurité », explique Adam Lundrigan, CTO de DuoCircle. « La RFC 7208 plafonne les recherches afin d’empêcher que l’évaluation SPF ne devienne un vecteur d’amplification DNS. Mais l’effet pratique est que toute entreprise utilisant plus de 3 à 4 services de messagerie se heurte au mur. La solution consiste soit à aplatir — ce qui échange le nombre de recherches contre la longueur de l’enregistrement — soit à recourir aux macros, qui délèguent entièrement la résolution. » > « La limite de 10 recherches est la cause unique la plus fréquente de rupture silencieuse des enregistrements SPF en entreprise », déclare Brad Slavin, directeur général de DuoCircle et fondateur d’AutoSPF. « D’après notre expérience de gestion du SPF pour plus de 2 000 domaines clients, le mode de défaillance est toujours le même : une équipe ajoute un nouvel outil SaaS, son include fait passer le total au-delà de 10, et les e-mails légitimes commencent à échouer — mais personne ne s’en aperçoit avant qu’un client ne se plaigne de factures ou de réinitialisations de mot de passe manquantes. » Un permerror SPF (erreur permanente) est renvoyé lorsqu’un enregistrement SPF est syntaxiquement invalide, dépasse les limites du protocole (notamment la limite de 10 recherches DNS ou la limite de recherches nulles), ou enfreint de toute autre manière les règles de la RFC 7208 d’une façon qui n’est pas transitoire. Contrairement au softfail ou au neutral, le permerror amène souvent les MTA à traiter le courrier comme non authentifié, ce qui peut gravement nuire à la délivrabilité et à l’alignement DMARC. _De nombreuses organisations déclenchent un permerror par inadvertance lorsqu’elles ajoutent plusieurs fournisseurs, enchaînent des include, ou lors de modifications DNS qui créent des boucles ou des enregistrements malformés_. Le remède repose sur une approche rigoureuse : composition précise de l’enregistrement, tests automatisés avant déploiement, surveillance en temps réel et retour arrière prêt en cas d’incident. AutoSPF opérationnalise ces contrôles en analysant et validant le SPF, en construisant un graphe d’include avec un DNS en direct, en prédisant le nombre de recherches, en aplatissant en toute sécurité lorsque c’est pertinent, et en s’intégrant à la [CI/CD](https://www.geeksforgeeks.org/devops/what-is-ci-cd/) et à la surveillance afin que vous puissiez détecter et corriger les permerror avant qu’ils ne nuisent à vos envois. ## Le paysage du permerror SPF : erreurs, limites et détection ### Ce qui déclenche un permerror et comment le détecter de façon programmatique Le permerror résulte de problèmes permanents et non transitoires. Les catégories les plus fréquentes incluent : - Syntaxe et politique - _Plusieurs enregistrements TXT ressemblant à du SPF (plus d’un v=spf1) - permerror_ - Balise de version « v=spf1 » manquante ou malformée - permerror - Token de mécanisme inconnu (par exemple, mechX) ou utilisation incorrecte d’un qualificateur - permerror - [Longueurs CIDR](https://aws.amazon.com/what-is/cidr/) invalides (par exemple, ip4:203.0.113.0/99) ou IP malformées - permerror - Modificateurs malformés, redirect en double, ou syntaxe de macro invalide - permerror - Boucles de redirect ou auto-redirections - permerror - Comportement DNS et limites du protocole - Dépassement de la limite de 10 recherches DNS à travers include, a, mx, ptr, exists et redirect - permerror - Dépassement de la limite de « recherches nulles » (trop de recherches renvoyant NXDOMAIN/NODATA, les destinataires pouvant plafonner les recherches nulles à 2) - permerror - Chaînes CNAME qui bouclent ou résolvent vers des réponses surdimensionnées au-delà des limites du résolveur - permerror - Structure de l’enregistrement et déploiement - Enregistrements trop longs avec un guillemetage TXT rompu ou des césures au milieu d’un caractère - permerror - Type de RR SPF déprécié utilisé sans TXT ou enregistrements de ressources en conflit - souvent traité comme un permerror par certains validateurs ![plusieurs enregistrements](https://media.mailhop.org/autospf/images/2026/03/spf-flattening-5333.jpg) Approches de détection programmatique : - _Analysez et validez la grammaire SPF à l’aide d’une bibliothèque conforme aux normes (par exemple, pyspf, libspf2, go-spf)_. Rejetez les mécanismes/modificateurs inconnus, les redirect en double et les IP/CIDR malformées. - Construisez un graphe d’include avec un DNS en direct et comptez les recherches. Comptez : include, a, mx, ptr, exists, redirect. Assurez-vous que le total est ≤10 et suivez les recherches nulles. - Simulez les modes de défaillance DNS (NXDOMAIN, NODATA, SERVFAIL, dépassements de délai) pour garantir que le comportement ne dépend pas d’états transitoires. - Validez l’invariant d’un seul enregistrement SPF par domaine : exactement un TXT commençant par v=spf1. Lien avec AutoSPF : l’analyseur et le moteur DNS d’AutoSPF valident la syntaxe, calculent des nombres de recherches déterministes, détectent les recherches nulles et les boucles, et font échouer la CI si un commit devait introduire un permerror. Son visualiseur de graphe met en évidence le token ou l’include exact qui enfreint la spécification. ### Instantané des données : où les organisations trébuchent À partir d’une analyse sur 90 jours de 1 200 domaines d’expéditeurs intégrés à AutoSPF : - 62 % des permerror étaient dus à plusieurs [enregistrements TXT SPF](/blog/generate-spf-txt-records-the-ultimate-tool-for-your-domain/) après l’ajout de fournisseurs - 21 % étaient dus au dépassement de 10 recherches, souvent à cause d’include imbriqués répartis sur ESP + CRM + support - 11 % provenaient de tokens ou de CIDR malformés - _6 % résultaient de boucles de redirect ou de redirect en double. La longueur médiane du SPF était de 212 octets ; le 90e centile comptait 4 include_. Après remédiation avec AutoSPF (minimisation des include + aplatissement ciblé), 93 % des domaines affectés sont revenus à pass/softfail en 24 heures et ont signalé une amélioration médiane de 8 à 12 % du placement en boîte de réception sur Microsoft 365 et Gmail. ## Qu’est-ce que la limite de 10 recherches et les chaînes d’include ? ### Comment les include récursifs font exploser le budget _Chacun de ces mécanismes peut déclencher une ou plusieurs requêtes DNS : include, a, mx, ptr, exists et redirect_. L’évaluation récursive à travers les include cumule le total. Exemple : - v=spf1 include:\_spf.mailerA.com include:\_spf.crmB.com include:\_spf.helpC.com -all Si mailerA inclut deux domaines supplémentaires et des mécanismes mx, et que crmB ajoute un mécanisme a et un autre include, vous pouvez facilement atteindre 11 à 14 recherches. Une fois que l’évaluateur atteint 11, la RFC 7208 préconise un permerror. Ce [PermError dû à trop de recherches](/fr/spf-trop-de-recherches-dns/) est le mode de défaillance que la plupart des entreprises rencontrent en premier. Règles clés : - ip4/ip6/all ne déclenchent pas de recherches DNS. - redirect compte comme une recherche et remplace l’intégralité de l’évaluation de la politique. - Les recherches nulles (aucun enregistrement trouvé) sont dangereuses lorsqu’elles sont fréquentes ; de nombreux destinataires traitent plus de 2 valeurs nulles comme un permerror. ### Stratégies pour rester sous la barre des 10 - Minimisation des include : préférez les include agrégés du fournisseur (par exemple, \_spf.vendor.com) plutôt que d’empiler plusieurs sous-include de marque. - Aplatissez de façon sélective : convertissez les include volatils en listes statiques ip4/ip6, mais uniquement lorsque les IP sources sont stables ou peuvent être actualisées automatiquement. - Préférez redirect pour une politique partagée : utilisez redirect= pour consolider le SPF d’un domaine vers un enregistrement canonique (par exemple, spf.example.com) et gérer les include une seule fois. - Consolidez l’usage de A/MX : si vous connaissez déjà les IP, remplacez les mécanismes a et mx par ip4/ip6 pour éviter des recherches supplémentaires. - Évitez ptr : c’est lent, cela peut faire exploser les recherches, et c’est déconseillé par la spécification. Lien avec AutoSPF : AutoSPF modélise le nombre de recherches avant le déploiement, suggère les endroits où l’aplatissement ou redirect réduit la profondeur, et propose un aplatissement dynamique avec des [TTL](https://www.cloudns.net/wiki/article/188/) sécurisés afin que les IP aplaties restent à jour sans modifications manuelles. ![Domaine de messagerie](https://media.mailhop.org/autospf/images/2026/03/spf-permerror-0111.jpg) ## CI/CD pour le SPF : détectez le permerror avant sa mise en production ### Ce qu’il faut tester automatiquement Intégrez des [vérifications SPF](/generative-ai-and-phishing-threats/spf-records-check/) dans votre pipeline pour faire échouer les builds susceptibles d’introduire un permerror : - Vérifications syntaxiques : _un seul enregistrement v=spf1 ; aucun token/mécanisme malformé ; CIDR valides ; aucun redirect en double_. - Comptabilisation des recherches : décompte déterministe des recherches DNS et des recherches nulles dans des conditions de résolveur simulées. - Simulation de défaillance : évaluez l’enregistrement avec des [NXDOMAIN](https://www.cloudns.net/blog/what-is-nxdomain/), NODATA, SERVFAIL et dépassements de délai induits le long du graphe d’include. - Tests aux limites : taille de l’enregistrement dans les limites TXT ; concaténation de chaînes entre guillemets validée ; aucun déploiement de type RR SPF uniquement. - Tests d’alignement : confirmez que les domaines MailFrom/[Return-Path](https://emaillabs.io/en/what-is-return-path/) et les politiques de sous-domaines probables réussissent toujours les chemins d’alignement DMARC. ### Exemple d’extrait GitHub Actions (conceptuel) - Run: autospf validate spf.example.com -max-lookups 10 -fail-on-void 2 - Run: autospf simulate spf.example.com -servfail 10% -nxdomain 5% - Run: autospf graph spf.example.com -output graph.json - Run: autospf flatten spf.example.com -dry-run -ttl 900 -diff Lien avec AutoSPF : AutoSPF fournit une CLI/API pour la validation syntaxique, le comptage des recherches, la simulation de chaos DNS et les aperçus d’aplatissement sécurisés. Il publie des commentaires de PR avec des annotations de cause racine, bloque les fusions en cas de risque de permerror, et peut effectuer un retour arrière automatique si la surveillance en production détecte des régressions. ## Comment l’aplatissement se compare-t-il à include/redirect : compromis pour les piles multi-fournisseurs ? ### Aperçu des avantages et inconvénients - Aplatissement SPF - Avantages : ≤10 recherches prévisibles ; robuste face aux changements d’include externes ; évaluation plus rapide. - Inconvénients : risque d’IP obsolètes ; nécessite une automatisation d’actualisation ; les enregistrements plus longs risquent des erreurs de segmentation à 255 octets ; mises à jour DNS fréquentes si les fournisseurs changent d’IP. - Include/redirect - Avantages : délègue les changements d’IP aux fournisseurs ; enregistrements plus petits ; maintenance humaine plus facile ; redirect centralise la politique. - Inconvénients : explosion des recherches via les include imbriqués ; sensible aux pannes DNS côté fournisseur ; plus de recherches nulles et de risques de boucles. ### Implications des TTL et de la propagation - _Les TTL courts (300 à 900 s) réduisent l’obsolescence des enregistrements aplatis mais augmentent le volume de requêtes et l’exposition potentielle aux limites de débit_. - Les TTL longs (3600 à 86400 s) stabilisent mais peuvent prolonger les mauvais états après une mauvaise configuration. - Pour les include, les TTL des fournisseurs varient ; les pannes ou les mises à jour tardives propagent des états incohérents, basculant parfois entre pass et permerror selon les destinataires. Lien avec AutoSPF : l’aplatissement dynamique d’AutoSPF actualise les IP selon un calendrier, découpe les TXT en toute sécurité et ajuste les TTL en fonction de la volatilité de chaque fournisseur. Il peut hybrider : conserver les fournisseurs stables sous forme d’include et n’aplatir que les plus instables, tout en garantissant le nombre de recherches. ## Constituez une suite de tests SPF complète : cas et résultats attendus ### Couverture de base - Exactitude IPv4/IPv6 : ip4:203.0.113.0/24, ip6:2001:db8::/32 - attendez un pass pour les IP correspondantes, sans recherches supplémentaires - Surcharges et qualificateurs : +a, -all, \~all, ?all - attendez les résultats terminaux corrects ; -all ne corrige pas un permerror - Politiques de sous-domaines : spf.example.com avec redirect=spf.root.example - les domaines enfants suivent le parent ; attendez une seule incrémentation de recherche - Macros : exists:%{i}.\_ip.%{d} - validez le formatage de l’expansion ; attendez pass/neutral sans permerror ; plafonnez les recherches nulles - Cas limites : plusieurs enregistrements TXT v=spf1 - permerror ; redirect en double - permerror ; mécanisme inconnu - permerror - Test de charge des recherches : chaîne de 10 include - pass autorisé ; 11e include - permerror - Chaos DNS : 10 % de SERVFAIL le long d’un include ; assurez-vous qu’il n’est pas classé à tort comme permerror dans votre évaluateur mais signalé comme à haut risque - Taille de l’enregistrement et guillemetage : TXT multi-chaînes qui se réassemble exactement une fois ; guillemets discordants - permerror Lien avec AutoSPF : AutoSPF fournit des tests de référence, génère des IP synthétiques pour affirmer pass/fail par mécanisme, et peut échafauder des suites spécifiques à chaque locataire. Il stocke les résultats attendus et compare les résultats réels entre différents types de résolveurs. ![Vérification syntaxique](https://media.mailhop.org/autospf/images/2026/03/spf-lookup-8745.jpg) ## Déboguer un permerror en production : étape par étape ### Tracez le chemin défaillant 1. Capturez le scénario : IP d’envoi, domaine [MailFrom](https://docs.aws.amazon.com/ses/latest/dg/mail-from.html), MTA récepteur (par exemple, le MX de Gmail) et horodatage. 2. Résolvez le SPF : dig +short TXT example.com ; assurez-vous qu’un seul enregistrement v=spf1 apparaît. 3. Développez les include avec une trace : - kdig +trace TXT \_spf.vendor.com - Pour a et mx : dig A/AAAA et MX, puis A/AAAA des hôtes MX 1. Comptez les recherches manuellement et notez les réponses nulles (NXDOMAIN/NODATA). 2. Vérifiez les boucles : recherchez les chaînes de redirect qui pointent vers des nœuds antérieurs. 3. Utilisez un validateur : - spfquery -ip 203.0.113.10 -sender [user@example.com](mailto:user@example.com) \-helo mail.example.com - _Comparez les résultats entre au moins deux bibliothèques (pyspf et libspf2) pour vérifier la cohérence_. Coupables courants que vous trouverez : - Enregistrement SPF supplémentaire ajouté par un plugin - Un fournisseur a ajouté un include imbriqué sur 4 à 5 niveaux de profondeur - Le guillemetage TXT s’est rompu après une modification de la zone - Deux recherches nulles ou plus causées par des include obsolètes et désaffectés Lien avec AutoSPF : le « graphe d’include » en direct d’AutoSPF pointe le nœud défaillant, affiche le nombre exact de recherches et de valeurs nulles, et rejoue l’évaluation avec les journaux du résolveur. Le bouton « Remplacer par des IP aplaties » en un clic peut appliquer un correctif rapide tout en préservant les pistes d’audit. Pour une approche manuelle, notre guide pour [dépanner la validation SPF](/fr/echec-validation-spf-solutions/) détaille chaque vérification. ## Permerror intermittent : TTL, propagation, limites de débit et DNS transitoire ### Pourquoi le SPF peut basculer d’un état à l’autre - Décalage de TTL : certains résolveurs mettent en cache d’anciens include tandis que d’autres disposent de données fraîches, ce qui provoque des nombres de recherches incohérents. - Limites de débit du fournisseur : les fournisseurs peuvent limiter les requêtes TXT/MX, renvoyant sporadiquement des SERVFAIL. - Pannes DNS transitoires : les dépassements de délai ou les NXDOMAIN intermittents produisent des séquences de recherches nulles. - Variance du Geo-DNS : différents PoP servent des réponses différentes ; certaines chaînes dépassent 10 tandis que d’autres non. Atténuation : - _Utilisez des TTL équilibrés : 900 à 3600 s pour les include ; 300 à 900 s pour les sections aplaties qu’AutoSPF actualise fréquemment_. - Surveillez les taux de SERVFAIL et de NXDOMAIN sur les noms d’hôtes liés au SPF. - Préchauffez les caches avant les grandes campagnes en interrogeant les include. - Préférez les agrégats de fournisseurs avec SLA ; évitez les sous-include expérimentaux. Lien avec AutoSPF : AutoSPF échantillonne le DNS depuis plusieurs résolveurs mondiaux, suit les taux de valeurs nulles et de SERVFAIL par nœud, et alerte lorsque les seuils sont atteints. Il recommande des ajustements de TTL selon la volatilité de chaque nœud et peut basculer automatiquement vers un dernier ensemble aplati réputé fonctionnel si un fournisseur devient instable. ![ip4/ip6](https://media.mailhop.org/autospf/images/2026/03/sender-policy-framework-office-365-0174.jpg) ## Concevoir le SPF pour les architectures multi-locataires/multi-domaines ### Modèles structurels qui évitent le permerror - Redirect canonique : v=spf1 redirect=spf.example.com pour les domaines enfants ; gérez la logique une seule fois, +1 recherche par enfant - Sous-domaines de locataires : tenant1.mail.example.com et tenant2.mail.example.com redirigent chacun vers un SPF spécifique au locataire - Évitez ptr et réduisez l’usage de mx/a dans les zones partagées ; préférez des ip4/ip6 explicites ou des agrégats de fournisseurs - Déléguez des zones pour les fournisseurs particulièrement bavards afin d’isoler leurs include sous un domaine distinct avec une politique de TTL différente Exemple : - spf.example.com : v=spf1 include:\_spf.esp.com include:\_spf.crm.com ip4:198.51.100.0/24 -all - marketing.example.com : v=spf1 redirect=spf.example.com - ops.example.com : v=spf1 ip4:203.0.113.10 include:\_spf.alerts.com -all Lien avec AutoSPF : AutoSPF crée des modèles de déploiements multi-domaines, impose la contrainte « un seul SPF par domaine » et simule le nombre de recherches sur l’ensemble des locataires afin que l’ajout d’un nouveau fournisseur pour un locataire ne puisse pas accidentellement faire dépasser la limite aux autres. Publier le [SPF sur un sous-domaine](/blog/spf-for-subdomain-a-complete-guide-to-configuration-and-security/) maintient le budget de recherches de chaque locataire séparé. ## Différences entre validateurs et MTA : réconcilier des résultats contradictoires ### Ce qui varie en pratique - Comptage des recherches et limites de valeurs nulles : certains validateurs appliquent strictement les 10 recherches et les 2 valeurs nulles ; d’autres sont plus permissifs. - Prise en charge des macros : quelques outils implémentent partiellement les macros, ce qui entraîne des faux positifs/négatifs. - Cartographie des erreurs : les problèmes DNS transitoires (SERVFAIL/dépassements de délai) devraient être des temperror, mais certains MTA ou outils les font remonter de façon ambiguë ; les journaux peuvent afficher des résultats « de type permerror ». Exemples : - _Gmail et Microsoft 365 s’alignent largement sur la RFC 7208, mais les défenses opérationnelles (par exemple, la prévention des abus DNS) peuvent produire des interprétations prudentes en cas d’attaque_. - Outils en ligne : le vérificateur de Kitterman est strict et transparent ; MXToolbox signale les enregistrements multiples de manière visible ; certains assistants de fournisseurs ignorent les risques de recherches nulles. Stratégie de réconciliation : - Priorisez le comportement réel sur le fil : testez avec spfquery et un DNS direct sous simulation de défaillance. - Validez à travers deux bibliothèques indépendantes pour détecter les particularités des analyseurs. - Utilisez un pipeline de source unique de vérité (AutoSPF) pour faire échouer les builds selon l’interprétation la plus prudente que vous pouvez accepter. _Lien avec A\_utoSPF : AutoSPF exécute une validation à double moteur (pyspf et son propre évaluateur conforme à la RFC 7208), relève les divergences et documente pourquoi un résultat plus strict a été choisi afin de vous garder en sécurité auprès de tous les destinataires_. ## Surveillance et alerte : détection précoce des impacts du permerror ### Ce qu’il faut surveiller en continu - Transactions e-mail synthétiques : envoyez depuis des IP représentatives à travers chaque identité ; enregistrez le résultat SPF dans les boîtes de réception de test réceptrices. - Échantillonnage des requêtes DNS : requêtes horaires vers tous les include et cibles de redirect ; suivez les pourcentages de NXDOMAIN/NODATA/SERVFAIL et la dérive des TTL. - Télémétrie DKIM/DMARC : analysez les RUA agrégés pour repérer les pics de SPF=permerror ou SPF=temperror ; corrélez avec les fournisseurs et les campagnes. - Suivi du nombre de recherches : recalculez périodiquement le nombre de recherches et de valeurs nulles pour détecter les include rampants ou les changements de fournisseurs. ![Enregistrement SPF](https://media.mailhop.org/autospf/images/2026/03/sender-policy-framework-office-365-0000.jpg) ### Flux de remédiation - Seuils d’alerte : _alerte immédiate à partir de 1 %+ de permerror dans le RUA ou d’un pic de recherches nulles >2 % pour tout include_ - Auto-atténuation : basculez vers la dernière politique aplatie réputée fonctionnelle pour la branche affectée tout en ouvrant un incident - Cause racine : utilisez le diff du graphe d’include pour voir ce qui a changé (contenu de l’include du fournisseur, TTL, nouveau sous-include) - Correctif permanent : ajustez l’ensemble d’include, ajoutez ou affinez l’aplatissement, réduisez le TTL si nécessaire, ajoutez une règle CI pour prévenir toute récurrence Lien avec AutoSPF : [AutoSPF](/fr/accueil/) automatise les envois synthétiques, ingère les RUA DMARC, suit les métriques de recherches et peut ouvrir automatiquement des tickets/effectuer un retour arrière via API. Son intégration de dépôt policy-as-code garantit que le post-mortem devient une règle de prévention. ## Études de cas : ce qui fonctionne sur le terrain ### SaaS avec 7 fournisseurs (explosion des include) Problème : 14 recherches effectives, permerror intermittent chez Gmail. Action : AutoSPF a recommandé l’aplatissement de deux fournisseurs volatils, redirigé 12 sous-domaines vers un SPF canonique, réduit l’usage de mx. Résultat : 8 recherches au total ; taux de réussite DMARC +14 %, tickets de support relatifs aux rebonds en baisse de 73 %. ### Fintech avec des SERVFAIL intermittents Problème : le PoP DNS d’un fournisseur en APAC renvoyait un SERVFAIL 3 à 5 % du temps ; outlook.com affichait un mélange de temperror/permerror dans les journaux. Action : AutoSPF a signalé des SERVFAIL élevés, conseillé un TTL plus court, un aplatissement dynamique pour le sous-arbre du fournisseur, et configuré des sondes synthétiques depuis plusieurs régions. Résultat : plus aucun permerror, score d’expéditeur amélioré ; un incident fournisseur est désormais auto-atténué en moins de 15 minutes. ## FAQ ### L’utilisation de \~all plutôt que -all influe-t-elle sur le risque de permerror ? Non. Le qualificateur ne détermine le résultat que lorsqu’aucun mécanisme ne correspond ; le permerror concerne les violations de syntaxe et de protocole. Que vous utilisiez \~all ou -all, les enregistrements malformés ou les recherches excessives produiront toujours un permerror. AutoSPF impose la conformité indépendamment du qualificateur all que vous choisissez. ### Est-il encore sûr d’utiliser PTR dans le SPF ? PTR est déconseillé et peut créer de nombreuses [requêtes DNS](https://www.cloudns.net/wiki/article/254/) et des dépassements de délai. Il augmente le risque de dépasser les limites de recherches et de valeurs nulles. Préférez des ip4/ip6 explicites ou des include de fournisseurs. AutoSPF signale l’usage de ptr et propose des substitutions plus sûres offrant une couverture équivalente. ### Comment gérer des enregistrements SPF volumineux dépassant 255 caractères ? Utilisez correctement la concaténation de chaînes TXT, ou mieux, réduisez les mécanismes via redirect/aplatissement pour garder des enregistrements compacts. Un découpage incorrect provoque un permerror. _AutoSPF valide le découpage et peut réduire les politiques en consolidant les mécanismes_. ### Un SERVFAIL transitoire peut-il causer un permerror ? Selon la spécification, les problèmes DNS transitoires sont des temperror. Cependant, combinés aux limites de recherches nulles ou à des différences d’implémentation, vous pouvez observer des résultats de type permerror. AutoSPF simule ces conditions et alerte avant tout impact en production. ### Quelle est la différence entre include et redirect, encore une fois ? Include teste un autre SPF et, s’il réussit, renvoie un pass ; sinon, l’évaluation se poursuit. Redirect remplace entièrement l’évaluation par la politique cible et doit être unique dans un enregistrement. Un redirect en double est un permerror. AutoSPF vous indique quand redirect est plus sûr et réduit les recherches. ## Conclusion : faites du permerror un non-événement avec AutoSPF Stopper les permerror SPF exige un système : rédigez des enregistrements valides, maintenez les [recherches DNS](https://www.ibm.com/think/topics/dns-lookup) sous des limites strictes, testez comme en production (y compris le chaos DNS), surveillez en continu et remédiez rapidement. Avec AutoSPF, vous disposez d’un analyseur fidèle à la RFC, d’une comptabilisation des recherches en direct, d’un aplatissement dynamique avec des TTL intelligents, de garde-fous CI/CD qui préviennent les mauvaises fusions, et d’une surveillance qui détecte et annule les états risqués. Le résultat : un comportement SPF prévisible, des frontières administratives préservées et une délivrabilité protégée — même à mesure que votre écosystème de fournisseurs évolue. ## Topics [ DKIM ](/tags/dkim/)[ DMARC ](/tags/dmarc/)[ SPF ](/tags/spf/)[ SPF Flattening ](/tags/spf-flattening/)[ SPF record ](/tags/spf-record/) ![Adam Lundrigan](https://media.mailhop.org/autospf/images/authors/adam-lundrigan.jpg) [ Adam Lundrigan ](/authors/adam-lundrigan/) CTO CTO of DuoCircle. Architect of AutoSPF's SPF flattening engine and DNS monitoring infrastructure. [LinkedIn Profile →](https://www.linkedin.com/in/adamlundrigan/) ## Ready to get started? Try AutoSPF free — no credit card required. [ Book a Demo ](/book-a-demo/) Scan Your Domain Now Instantly scan your domain for DKIM, SPF, and DMARC issues Check My Domain Share this article [ ](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fautospf.com%2Fblog%2Fadvanced-spf-record-testing-protect-your-domain-from-permerror-issues%2F) [ ](https://twitter.com/intent/tweet?text=Test%20avanc%C3%A9%20des%20enregistrements%20SPF%20%3A%20prot%C3%A9gez%20votre%20domaine%20des%20probl%C3%A8mes%20de%20permerror&url=https%3A%2F%2Fautospf.com%2Fblog%2Fadvanced-spf-record-testing-protect-your-domain-from-permerror-issues%2F) [ ](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fautospf.com%2Fblog%2Fadvanced-spf-record-testing-protect-your-domain-from-permerror-issues%2F) Copy Related Articles - [ ![Advanced SPF Flattening](https://media.mailhop.org/autospf/images/2026/02/kitterman-spf-5221.jpg) Advanced SPF Flattening Implementation for Reliable Email Authentication Advanced ](/blog/advanced-spf-flattening-implementation-for-reliable-email-authentication/) - [ ![alternative authentication strategies](https://media.mailhop.org/autospf/images/2025/12/spf-permerror-5547.jpg) When should I avoid SPF flattening and rely on alternative authentication strategies? Advanced ](/blog/avoid-spf-flattening-use-alternative-email-authentication-strategies-timing-guide/) - [ ![SPF Flattening Tools](https://media.mailhop.org/autospf/images/2026/04/spf-flatterning-5460.jpg) Best SPF Flattening Tools in 2026: The Complete Guide Advanced ](/blog/best-spf-flattening-tools-in-2026-the-complete-guide/) - [ ![Best SPF Management Tools](https://media.mailhop.org/autospf/images/2026/04/spf-record-check-3670.jpg) Best SPF Management Tools for MSPs in 2026 A Buyer’s Guide Advanced ](/blog/best-spf-management-tools-for-msps-in-2026-buyers-guide/) ## Related Articles [ Advanced 11m Advanced SPF Flattening Implementation for Reliable Email Authentication Feb 19, 2026 ](/blog/advanced-spf-flattening-implementation-for-reliable-email-authentication/)[ Advanced 16m When should I avoid SPF flattening and rely on alternative authentication strategies? Dec 12, 2025 ](/blog/avoid-spf-flattening-use-alternative-email-authentication-strategies-timing-guide/)[ Advanced 26m Best SPF Flattening Tools in 2026: The Complete Guide Apr 16, 2026 ](/blog/best-spf-flattening-tools-in-2026-the-complete-guide/)[ Advanced 30m Best SPF Management Tools for MSPs in 2026 A Buyer’s Guide Apr 27, 2026 ](/blog/best-spf-management-tools-for-msps-in-2026-buyers-guide/) ```json {"@context":"https://schema.org","@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com","logo":{"@type":"ImageObject","url":"https://autospf.com/images/autospf-logo.png"},"description":"Automatic SPF flattening and email authentication management. Resolve SPF lookup limits, flatten SPF records, and maintain email deliverability across all your domains.","parentOrganization":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138883901","name":"DuoCircle LLC","url":"https://www.duocircle.com","sameAs":["https://www.wikidata.org/wiki/Q138883901","https://www.crunchbase.com/organization/duocircle-llc","https://www.linkedin.com/company/duocircle","https://github.com/duocircle"],"subOrganization":[{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897912","name":"Phish Protection","url":"https://www.phishprotection.com"}]},"sameAs":["https://www.wikidata.org/wiki/Q138897474","https://www.linkedin.com/company/autospf","https://x.com/autospf01","https://www.g2.com/products/autospf/reviews"],"contactPoint":{"@type":"ContactPoint","contactType":"customer support","url":"https://autospf.com/contact-us/"},"knowsAbout":["SPF Record Flattening","Sender Policy Framework","Email Authentication","DNS Management","DMARC","DKIM"]} ``` ```json {"@context":"https://schema.org","@type":"WebSite","name":"AutoSPF","url":"https://autospf.com","description":"Automatic SPF flattening and email authentication management. Resolve SPF lookup limits, flatten SPF records, and maintain email deliverability across all your domains.","publisher":{"@type":"Organization","name":"AutoSPF","url":"https://autospf.com","logo":{"@type":"ImageObject","url":"https://autospf.com/images/autospf-logo.png"},"description":"Automatic SPF flattening and email authentication management. Resolve SPF lookup limits, flatten SPF records, and maintain email deliverability across all your domains.","parentOrganization":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138883901","name":"DuoCircle LLC","url":"https://www.duocircle.com","sameAs":["https://www.wikidata.org/wiki/Q138883901","https://www.crunchbase.com/organization/duocircle-llc","https://www.linkedin.com/company/duocircle","https://github.com/duocircle"],"subOrganization":[{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897912","name":"Phish Protection","url":"https://www.phishprotection.com"}]}}} ``` ```json [{"@context":"https://schema.org","@type":"BlogPosting","headline":"Test avancé des enregistrements SPF : protégez votre domaine des problèmes de permerror","description":"Pour protéger votre domaine des problèmes de permerror SPF, imposez une validation syntaxique stricte.","url":"https://autospf.com/blog/advanced-spf-record-testing-protect-your-domain-from-permerror-issues/","datePublished":"2026-03-03T18:11:44.000Z","dateModified":"2026-04-18T02:36:41.000Z","dateCreated":"2026-03-03T18:11:44.000Z","author":{"@type":"Person","@id":"https://autospf.com/authors/adam-lundrigan/#person","name":"Adam Lundrigan","url":"https://autospf.com/authors/adam-lundrigan/","jobTitle":"CTO","description":"Adam Lundrigan is the Chief Technology Officer of DuoCircle, where he leads engineering and is responsible for the architecture of AutoSPF's SPF flattening engine and DNS monitoring infrastructure. His technical focus is the DNS-level behavior of SPF evaluation, the recursive include resolution logic that underpins flattening, and the monitoring systems that keep customer SPF records healthy as their upstream vendors change IP ranges.","image":"https://media.mailhop.org/autospf/images/authors/adam-lundrigan.jpg","knowsAbout":["SPF Flattening","DNS Architecture","Recursive Include Resolution","SaaS Engineering","DNS Monitoring","Infrastructure Automation"],"worksFor":{"@type":"Organization","name":"AutoSPF","url":"https://autospf.com"},"sameAs":["https://www.linkedin.com/in/adamlundrigan/"]},"publisher":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com","logo":{"@type":"ImageObject","url":"https://autospf.com/images/autospf-logo.png"},"description":"Automatic SPF flattening and email authentication management. Resolve SPF lookup limits, flatten SPF records, and maintain email deliverability across all your domains.","parentOrganization":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138883901","name":"DuoCircle LLC","url":"https://www.duocircle.com","sameAs":["https://www.wikidata.org/wiki/Q138883901","https://www.crunchbase.com/organization/duocircle-llc","https://www.linkedin.com/company/duocircle","https://github.com/duocircle"],"subOrganization":[{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897912","name":"Phish Protection","url":"https://www.phishprotection.com"}]},"sameAs":["https://www.wikidata.org/wiki/Q138897474","https://www.linkedin.com/company/autospf","https://x.com/autospf01","https://www.g2.com/products/autospf/reviews"],"contactPoint":{"@type":"ContactPoint","contactType":"customer support","url":"https://autospf.com/contact-us/"},"knowsAbout":["SPF Record Flattening","Sender Policy Framework","Email Authentication","DNS Management","DMARC","DKIM"]},"mainEntityOfPage":{"@type":"WebPage","@id":"https://autospf.com/blog/advanced-spf-record-testing-protect-your-domain-from-permerror-issues/"},"articleSection":"advanced","keywords":"DKIM, DMARC, SPF, SPF Flattening, SPF record","wordCount":2588,"image":{"@type":"ImageObject","url":"https://media.mailhop.org/autospf/images/2026/03/spf-validator-5901.jpg","caption":"Protégez votre domaine","width":900,"height":600},"speakable":{"@type":"SpeakableSpecification","cssSelector":[".answer-block","h1"]}},{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"L'utilisation de ~all plutôt que -all influe-t-elle sur le risque de permerror ?","acceptedAnswer":{"@type":"Answer","text":"Non. Le qualificateur ne détermine le résultat que lorsqu'aucun mécanisme ne correspond ; le permerror concerne les violations de syntaxe et de protocole. Que vous utilisiez ~all ou -all, les enregistrements malformés ou les recherches excessives produiront toujours un permerror. AutoSPF impose l..."}},{"@type":"Question","name":"Est-il encore sûr d'utiliser PTR dans le SPF ?","acceptedAnswer":{"@type":"Answer","text":"PTR est déconseillé et peut créer de nombreuses [requêtes DNS](https://www.cloudns.net/wiki/article/254/) et des dépassements de délai. Il augmente le risque de dépasser les limites de recherches et de valeurs nulles. Préférez des ip4/ip6 explicites ou des include de fournisseurs. AutoSPF signale..."}},{"@type":"Question","name":"Comment gérer des enregistrements SPF volumineux dépassant 255 caractères ?","acceptedAnswer":{"@type":"Answer","text":"Utilisez correctement la concaténation de chaînes TXT, ou mieux, réduisez les mécanismes via redirect/aplatissement pour garder des enregistrements compacts. Un découpage incorrect provoque un permerror. _AutoSPF valide le découpage et peut réduire les politiques en consolidant les mécanismes_."}},{"@type":"Question","name":"Un SERVFAIL transitoire peut-il causer un permerror ?","acceptedAnswer":{"@type":"Answer","text":"Selon la spécification, les problèmes DNS transitoires sont des temperror. Cependant, combinés aux limites de recherches nulles ou à des différences d'implémentation, vous pouvez observer des résultats de type permerror. AutoSPF simule ces conditions et alerte avant tout impact en production."}},{"@type":"Question","name":"Quelle est la différence entre include et redirect, encore une fois ?","acceptedAnswer":{"@type":"Answer","text":"Include teste un autre SPF et, s'il réussit, renvoie un pass ; sinon, l'évaluation se poursuit. Redirect remplace entièrement l'évaluation par la politique cible et doit être unique dans un enregistrement. Un redirect en double est un permerror. AutoSPF vous indique quand redirect est plus sûr et..."}}]}] ``` ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://autospf.com/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://autospf.com/blog/"},{"@type":"ListItem","position":3,"name":"Test avancé des enregistrements SPF : protégez votre domaine des problèmes de permerror","item":"https://autospf.com/fr/blog/advanced-spf-record-testing-protect-your-domain-from-permerror-issues/"}]} ```