---
title: "Aplatissement SPF : dépasser la limite de 10 requêtes | AutoSPF"
description: "L"
image: "https://autospf.com/images/og-default.png"
canonical: "https://autospf.com/fr/spf-flattening/"
---

# Aplatissement SPF

L'aplatissement SPF résout les mécanismes include, a et mx de votre enregistrement SPF en leurs adresses IP sous-jacentes, maintenant le nombre de requêtes DNS sous la limite de 10 fixée par la RFC 7208, afin que votre enregistrement reste valide et que les e-mails légitimes continuent de passer l'authentification.

L’aplatissement SPF consiste à résoudre chaque mécanisme de votre enregistrement SPF qui déclenche une requête - `include:`, `a`, `mx`, `ptr`, `exists` et `redirect=` \- jusqu’aux adresses IP concrètes qui se trouvent derrière, puis à publier ces adresses directement sous forme d’entrées `ip4:` et `ip6:`. L’objectif est simple : maintenir votre enregistrement à l’intérieur des limites strictes imposées par les serveurs de réception, afin que les messages légitimes continuent de s’authentifier à mesure que votre infrastructure d’envoi se développe.

Cette page est le point central de tout ce qui concerne l’aplatissement SPF. Elle explique ce qu’est l’aplatissement, pourquoi la limite de 10 requêtes force la main, comment le processus fonctionne étape par étape, et où se situent les véritables compromis et risques. À partir d’ici, vous pouvez approfondir des tâches précises : [comment aplatir un enregistrement SPF](/fr/spf-flattening/how-to-flatten-an-spf-record/), les [meilleurs outils d’aplatissement SPF](/fr/spf-flattening/best-spf-flattening-tools/), la question de savoir si [l’aplatissement SPF affecte DKIM et DMARC](/fr/spf-flattening/does-spf-flattening-affect-dkim-dmarc/), la manière de le faire sur [Cloudflare](/fr/spf-flattening/cloudflare-spf-flattening/), et la comparaison entre l’aplatissement et [l’aplatissement SPF vs les macros](/fr/macros-spf-vs-flattening/).

## Qu’est-ce que l’aplatissement SPF ?

Un enregistrement SPF est un unique enregistrement `TXT`, commençant par `v=spf1`, qui indique aux serveurs de messagerie destinataires quels hôtes sont autorisés à envoyer des e-mails pour votre domaine. Lorsque vous ajoutez un service - un CRM, une plateforme marketing, un service d’assistance, un fournisseur d’e-mails transactionnels - vous ajoutez généralement un `include:` pour celui-ci. Chaque `include:` pointe vers l’enregistrement SPF d’un autre domaine, et le destinataire doit récupérer cet enregistrement au moment de l’évaluation. Ces récupérations sont des requêtes DNS, et elles s’accumulent rapidement.

L’aplatissement SPF prend toutes ces références indirectes et les pré-résout. Au lieu de demander au destinataire de suivre `include:_spf.google.com` à travers des enregistrements `_netblocks` imbriqués, un enregistrement aplati liste simplement les plages d’IP sous-jacentes :

- **Avant :** `v=spf1 include:sendgrid.net include:_spf.google.com a mx -all`
- **Après :** `v=spf1 ip4:149.72.0.0/16 ip4:167.89.0.0/17 ip4:64.233.160.0/19 ip6:2a00:1450:4000::/36 -all`

Au moment de l’évaluation, le destinataire ne parcourt plus les includes de manière récursive et ne résout plus les cibles `A`/`MX` \- il compare simplement l’IP de connexion à vos plages `CIDR` publiées. Cela ramène le nombre de requêtes DNS à l’exécution à pratiquement zéro et garde votre enregistrement léger, rapide et fiable.

> « La limite de 10 requêtes est de loin la raison la plus fréquente pour laquelle les enregistrements SPF des entreprises cessent silencieusement de fonctionner », 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 pousse 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. »

## Pourquoi la limite de 10 requêtes DNS impose l’aplatissement

Selon la [RFC 7208](https://datatracker.ietf.org/doc/html/rfc7208), l’évaluation SPF est plafonnée à **10 requêtes DNS de mécanisme** et **2 requêtes nulles** par vérification. Dépasser l’une ou l’autre limite produit un `PermError` \- un échec permanent qui indique aux serveurs de réception que votre e-mail ne peut pas être authentifié. Le serveur ne réessaie pas, et il n’évalue pas le reste de votre enregistrement. Il s’arrête simplement, et chaque message de votre domaine échoue au SPF.

Le piège, c’est que cette limite reste invisible jusqu’à ce que vous la franchissiez. Une petite entreprise qui envoie via un seul fournisseur ne l’atteindra jamais. Mais les infrastructures de messagerie modernes empilent régulièrement plusieurs ESP, un CRM, un service d’assistance et la messagerie interne - et chacun ajoute une ou plusieurs requêtes. Google Workspace consomme à lui seul environ quatre de vos dix requêtes à travers ses includes imbriqués. Ajoutez Salesforce, Mailchimp, SendGrid et Zendesk et vous pouvez facilement atteindre douze à quinze. La onzième requête n’est jamais évaluée, si bien que le service qui se trouve au-delà de ce point perd silencieusement son autorisation.

Voici quels mécanismes comptent :

| Déclenche une requête DNS         | Ne déclenche **pas** de requête |
| --------------------------------- | ------------------------------- |
| include:example.com               | ip4:x.x.x.x\[/CIDR\]            |
| a, a:example.com                  | ip6:…                           |
| mx, mx:example.com                | all                             |
| ptr (déconseillé par la RFC 7208) |                                 |
| exists:domain                     |                                 |
| redirect=example.com              |                                 |

Comme les mécanismes `ip4:` et `ip6:` ne nécessitent aucune résolution, l’aplatissement échange chaque mécanisme générant une requête contre des mécanismes qui n’en génèrent aucune. C’est là tout le mécanisme par lequel l’aplatissement vous maintient conforme. Un moyen rapide de savoir où vous en êtes aujourd’hui est de passer votre domaine dans le [SPF Checker](/fr/tools/spf-checker/), qui développe chaque include et compte vos requêtes.

## Pourquoi l’aplatissement compte pour la délivrabilité et la sécurité

La limite de 10 requêtes n’est pas qu’une simple note technique - elle se situe directement sur le chemin entre vos e-mails et la boîte de réception.

**Délivrabilité.** DMARC s’appuie sur SPF et DKIM. Si votre enregistrement SPF renvoie un `PermError`, DMARC le traite comme un échec, et les e-mails légitimes peuvent être mis en quarantaine ou rejetés. Depuis 2024, Google, Yahoo et Microsoft exigent des expéditeurs en masse qu’ils s’authentifient avec SPF, DKIM et DMARC, et ils rejettent désormais purement et simplement les messages non conformes plutôt que de les acheminer vers les spams. Ensemble, ces fournisseurs couvrent environ 90 % d’une liste grand public type, si bien qu’un seul enregistrement dépassant la limite peut couper la distribution vers la majeure partie de votre audience d’un seul coup.

**Sécurité.** Lorsque le SPF échoue, les serveurs de réception perdent la capacité de distinguer vos e-mails légitimes des messages usurpés. C’est précisément la faille qu’exploitent le phishing et la compromission de messagerie professionnelle. Maintenir le SPF valide - et sous la limite - préserve le signal d’authentification qui vous distingue d’un attaquant se faisant passer pour votre domaine.

**Gérabilité.** À mesure que votre marque grandit, la liste des plateformes qui envoient en votre nom s’allonge aussi. L’aplatissement condense une chaîne tentaculaire d’includes en une seule liste nette de plages d’IP, facile à lire, à auditer et à appréhender.

## Comment fonctionne l’aplatissement SPF, étape par étape

Qu’il soit réalisé manuellement ou par automatisation, l’aplatissement suit le même pipeline :

1. **Découverte.** Lisez votre enregistrement SPF `TXT` actuel et identifiez chaque mécanisme qui déclenche une requête - `include`, `a`, `mx`, `exists`, `redirect`.
2. **Résolution récursive.** Suivez chaque chaîne d’`include`, en récupérant l’enregistrement SPF de la cible et en récursant jusqu’à ce que tout le contenu en amont soit connu. Résolvez les cibles `a`/`mx` vers leurs enregistrements `A`/`AAAA` pour rassembler les adresses IPv4 et IPv6.
3. **Dédupliquer et compresser.** Fusionnez les plages qui se chevauchent et agrégez les blocs contigus en notation `CIDR` afin que l’enregistrement reste compact.
4. **Publier.** Réécrivez l’enregistrement sous la forme `v=spf1 ip4:… ip6:… -all`, en respectant la limite de 255 caractères par chaîne `TXT` (divisez en plusieurs chaînes concaténées si nécessaire), et mettez à jour votre DNS.
5. **Valider.** Confirmez la syntaxe, vérifiez que le nombre de requêtes est de 0 à 1, et envoyez un e-mail de test pour confirmer `SPF=pass` et `DMARC=pass`.

Pour la procédure complète avec les commandes et les spécificités des fournisseurs DNS, consultez [comment aplatir un enregistrement SPF](/fr/spf-flattening/how-to-flatten-an-spf-record/).

## Le hic : un enregistrement aplati n’est pas une solution définitive

L’aplatissement résout le problème des requêtes, mais il en introduit un nouveau. Lorsque vous remplacez un `include:` dynamique par des IP statiques, vous prenez la responsabilité de maintenir ces IP à jour. Les fournisseurs font constamment tourner leur infrastructure d’envoi, et ils vous préviennent rarement lorsqu’ils le font.

> « L’idée fausse au sujet de l’aplatissement SPF est qu’il s’agit d’une solution définitive », déclare Adam Lundrigan, directeur technique de DuoCircle et architecte du moteur d’aplatissement d’AutoSPF. « Les plages d’IP des fournisseurs changent constamment - Google a fait tourner ses \_netblocks trois fois rien qu’en 2025\. Un enregistrement aplati qui n’est pas automatiquement re-résolu devient obsolète et désautorise silencieusement les expéditeurs légitimes. C’est pourquoi AutoSPF effectue une nouvelle analyse toutes les 15 minutes. »

C’est la chose la plus importante à comprendre au sujet de l’aplatissement. Un enregistrement aplati construit à la main est exact le jour où vous le publiez, puis se périme lentement ensuite. Lorsqu’un fournisseur ajoute une nouvelle plage d’IP, les e-mails provenant de cette plage commencent à échouer au SPF - et comme l’échec est silencieux, vous l’apprenez généralement par une facture rejetée ou une réinitialisation de mot de passe manquée, et non par une alerte. Dans la télémétrie d’AutoSPF sur 1 200 domaines, l’aplatissement a réduit les taux de `PermError` de 93 % et amélioré les taux de réussite DMARC de 7 à 12 % au cours des 30 premiers jours - mais seulement lorsque l’enregistrement était maintenu à jour. Le taux médian de renouvellement des IP des ESP se situe entre 2 et 4 changements par semaine pour les fournisseurs à fort volume.

Les autres compromis à anticiper :

- **Taille de l’enregistrement.** L’aplatissement peut pousser un enregistrement `TXT` vers les limites de taille du DNS. Visez à maintenir les réponses sous environ 1 000 à 1 200 octets pour éviter la fragmentation et la troncature UDP, et préférez des plages `CIDR` agrégées plutôt que l’énumération d’adresses individuelles.
- **Sur-autorisation.** Certains includes autorisent bien plus d’Internet que ce que vous utilisez réellement. Auditer et élaguer avant d’aplatir permet de garder votre surface d’attaque réduite.

## Manuel, scripté ou automatisé ?

Il existe trois façons d’aplatir, avec des profils de risque très différents :

- **Manuel.** Interrogez chaque include pour ses IP actuelles, agrégez-les et publiez à la main. Gratuit et entièrement sous votre contrôle, mais laborieux et sujet à la dérive dès qu’un fournisseur change ses IP. Praticable uniquement pour de petits environnements statiques.
- **Scripté.** Un script Python ou Go récurse les includes, résout les `A`/`MX`, fusionne les plages `CIDR` et pousse vers le DNS via une API selon une planification. Reproductible et auditable, mais vous êtes responsable des cas limites, de la protection contre les boucles et de la fiabilité continue.
- **Service automatisé (dynamique).** Un service hébergé re-résout en continu vos includes, détecte les changements d’IP et republie automatiquement. Cela supprime entièrement la charge de maintenance, au prix d’une dépendance gérée.

Pour toute organisation utilisant des fournisseurs dynamiques comme Google Workspace, Microsoft 365, SendGrid ou Amazon SES, une approche automatisée est fortement recommandée - toute la difficulté de l’aplatissement consiste à suivre le rythme du renouvellement, et c’est exactement ce que gère l’automatisation. Une comparaison complète des options se trouve dans [les meilleurs outils d’aplatissement SPF](/fr/spf-flattening/best-spf-flattening-tools/).

## Où se situe AutoSPF

[Le service d’aplatissement SPF automatique d’AutoSPF](/fr/accueil/) est spécialement conçu pour le problème de maintenance qui rend l’aplatissement risqué. Il découvre et développe vos includes imbriqués, résout les chaînes `A`/`MX`/`AAAA` complètes, déduplique et compresse les plages en blocs `CIDR` minimaux, et publie un enregistrement aplati validé et attentif à la taille qui reste sous la limite de 10 requêtes.

Deux éléments le distinguent :

- **Il effectue une nouvelle analyse toutes les 15 minutes** et met à jour automatiquement votre enregistrement dès que les IP d’un fournisseur en amont changent - de sorte qu’un enregistrement aplati ne se périme jamais silencieusement.
- **Il résout vers exactement les mêmes IP que vos includes** \- pas de plages larges et trop permissives, et pas de sur-autorisation. Votre enregistrement aplati autorise précisément les hôtes que vos véritables includes autorisent, et rien de plus.

En plus de cela, il propose des enregistrements versionnés avec restauration en un clic, une publication canari/de préproduction, et des alertes de dérive lorsque des e-mails arrivent d’IP situées en dehors de votre ensemble aplati actuel. Il s’intègre directement aux principaux fournisseurs DNS, dont Route 53, Cloudflare, Google Cloud DNS et Azure DNS. Avant et après tout changement, vous pouvez confirmer que l’enregistrement se résout proprement avec le [SPF Checker](/fr/tools/spf-checker/).

## L’aplatissement à travers les fournisseurs DNS et à grande échelle

Les mécanismes de l’aplatissement sont les mêmes partout, mais la publication diffère selon la plateforme. Sur Cloudflare, par exemple, vous gérez l’enregistrement `TXT` via le tableau de bord ou l’API et devez respecter son comportement de découpage en chaînes - les détails sont couverts dans [l’aplatissement SPF sur Cloudflare](/fr/spf-flattening/cloudflare-spf-flattening/).

À l’échelle du SaaS - des milliers de locataires, plusieurs flux d’envoi - le modèle gagnant est en couches : segmentez les flux de messagerie sur des sous-domaines (par exemple `mkt.example.com` pour le marketing, `tx.example.com` pour le transactionnel), centralisez la politique avec `redirect=` vers un petit enregistrement canonique, aplatissez entièrement les fournisseurs à fort renouvellement en ensembles `ip4`/`ip6` agrégés, et automatisez le rafraîchissement avec une publication basée sur les différences afin que les enregistrements inchangés ne provoquent jamais de dérive DNS. Déléguer les gros expéditeurs à des sous-domaines garde aussi votre domaine organisationnel léger et simplifie l’alignement DMARC.

## L’aplatissement modifie-t-il DKIM ou DMARC ?

L’aplatissement change uniquement _la façon_ dont les expéditeurs autorisés sont exprimés dans le SPF - `ip4`/`ip6` au lieu d’`include` \- et non l’identité de votre domaine ni vos signatures DKIM. Tant que le SPF aplati est publié sur le domaine utilisé dans votre `MAIL FROM`/`Return-Path`, l’alignement DMARC n’est pas affecté, et en éliminant le `PermError`, il _améliore_ généralement les taux de réussite DMARC lorsque le SPF est l’identifiant aligné. La relation complète, y compris la façon dont DKIM porte souvent l’alignement pour les expéditeurs en masse, est couverte dans [l’aplatissement SPF affecte-t-il DKIM et DMARC](/fr/spf-flattening/does-spf-flattening-affect-dkim-dmarc/).

## Aplatissement vs macros SPF

L’aplatissement traditionnel pré-résout les includes en IP statiques, ce qui explique pourquoi il nécessite un rafraîchissement constant. Les macros SPF empruntent une voie différente : elles utilisent l’expansion dynamique pour qu’un seul enregistrement puisse autoriser un nombre pratiquement illimité d’expéditeurs sans jamais atteindre la limite de 10 requêtes - au prix d’une complexité accrue et d’une prise en charge plus faible par les résolveurs. L’approche qui vous convient dépend de votre infrastructure et de votre appétence pour la maintenance ; l’analyse complète se trouve dans [l’aplatissement SPF vs les macros](/fr/macros-spf-vs-flattening/).

## Foire aux questions

### Qu’est-ce que l’aplatissement SPF en termes simples ?

L’aplatissement SPF est le processus consistant à remplacer les mécanismes `include:`, `a` et `mx` de votre enregistrement SPF par les adresses IP réelles auxquelles ils se résolvent. Cela donne aux serveurs de messagerie destinataires une liste toute prête d’IP autorisées au lieu de les forcer à effectuer des requêtes DNS, ce qui maintient votre enregistrement sous la limite de 10 requêtes définie par la RFC 7208 et prévient les échecs d’authentification.

### Pourquoi l’aplatissement SPF est-il nécessaire ?

L’aplatissement devient nécessaire lorsque votre domaine dépasse le plafond de la spécification SPF de 10 requêtes DNS par évaluation. Une fois cette limite franchie, le SPF renvoie un `PermError` et chaque message de votre domaine échoue à l’authentification, ce qui peut aussi faire échouer DMARC. Comme la plupart des organisations utilisent plusieurs expéditeurs tiers qui ajoutent chacun des includes, les domaines en croissance atteignent rapidement le plafond et ont besoin de l’aplatissement pour rester conformes.

### L’aplatissement SPF améliore-t-il la délivrabilité des e-mails ?

Oui. En éliminant les conditions `PermError` et `TempError` provoquées par un trop grand nombre de requêtes ou des includes en amont lents, l’aplatissement maintient un SPF qui passe de manière fiable. Dans les données clients d’AutoSPF, le passage de 12-18 requêtes à un enregistrement entièrement aplati a réduit de plus de 80 % les échecs DMARC liés au SPF et amélioré le placement en boîte de réception des e-mails marketing de 10 à 15 % lors des pics d’envoi.

### À quelle fréquence un enregistrement SPF aplati doit-il être mis à jour ?

Aussi souvent que vos fournisseurs changent d’IP. Les ESP à fort renouvellement comme SendGrid et Mailchimp justifient des rafraîchissements toutes les 12 à 24 heures, les suites stables comme Google Workspace et Microsoft 365 quotidiennement, et les plages statiques auto-hébergées chaque semaine. Un enregistrement maintenu à la main finit presque toujours par dériver - AutoSPF évite cela en effectuant une nouvelle analyse toutes les 15 minutes et en republiant automatiquement chaque fois qu’une plage en amont change.

### L’aplatissement SPF manuel est-il sûr ?

L’aplatissement manuel n’est sûr que pour les petits environnements statiques où les IP d’envoi changent rarement. Pour tout domaine utilisant des fournisseurs dynamiques, un enregistrement construit à la main se périme dès qu’un fournisseur fait tourner son infrastructure, désautorisant silencieusement les expéditeurs légitimes. L’aplatissement automatisé est fortement recommandé à toute échelle réelle, car suivre le rythme du renouvellement des fournisseurs est la partie difficile.

### Dois-je utiliser `-all` ou `~all` après l’aplatissement ?

Utilisez `-all` (échec strict) lorsque vous êtes certain que votre liste aplatie est complète et activement surveillée, car il donne aux destinataires le signal le plus clair pour rejeter les e-mails usurpés. Utilisez `~all` (échec souple) pendant le déploiement ou tant que vous ajoutez encore fréquemment des expéditeurs. Une bonne pratique consiste à conserver `~all` jusqu’à ce que les rapports DMARC montrent une fenêtre de réussite propre, puis à resserrer vers `-all`.

Rated 5/5 on G2 · Trusted since 2018 

##  Trusted by 50,000+ domains 

### "AutoSPF Flattens SPF Records Seamlessly & Keeps Changes Logged - I am quite pleased with the product"

> It does what it promises to do, and does it very well. I appreciate that it keeps a log of changes made, which prevents many mistakes. A client's SPF record would have way too many lookups, but AutoSPF makes that problem go away. The length of the SPF record is typically not the issue; it's the amount of lookups in the record that are. AutoSPF "flattens" the record, automatically expanding the defined lookups to IP addresses or ranges. And it auto-updates the record when the un-flattened lookups change. 

 PJ 

Peter J.

 President · Small-Business (50 or fewer emp.) 

### "Helped us go beyond capacity"

> AutoSPF did exactly as described, it helped us get past our 10 lookup limit. Afterwards, we hit another limit regarding overall capacity and when contacted, they quickly provided us with a new solution to eliminate capacity issues entirely going forward, so now we can add as many SPF records as needed. They also provided us with a personalized support video explaining their new method in its entirety using our instance as the example. 

 VU 

Verified User

 Financial Services · Mid-Market (51-1000 emp.) 

### "Great service and great support"

> AutoSPF was easy to initially set up on our own and a great cost effective entry into spf flattening. Needed our first support assistance today and got great response including a video demonstrating the issue I was trying to solve, a quick fix, and more detailed followup. 

 GF 

Greg F.

 Mid-Market (51-1000 emp.) 

[Read our reviews on G2 ](https://www.g2.com/products/autospf/reviews)

```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.facebook.com/autospf","https://github.com/duocircle","https://www.g2.com/products/autospf/reviews"],"aggregateRating":{"@type":"AggregateRating","ratingValue":"5.0","reviewCount":"21","bestRating":"5","worstRating":"1","url":"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","Email Deliverability","SPF Lookup Limits"]}
```

```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":"FAQPage","mainEntity":[{"@type":"Question","name":"Qu'est-ce que l'aplatissement SPF en termes simples ?","acceptedAnswer":{"@type":"Answer","text":"L'aplatissement SPF est le processus consistant à remplacer les mécanismes `include:`, `a` et `mx` de votre enregistrement SPF par les adresses IP réelles auxquelles ils se résolvent. Cela donne aux serveurs de messagerie destinataires une liste toute prête d'IP autorisées au lieu de les forcer à effectuer des requêtes DNS, ce qui maintient votre enregistrement sous la limite de 10 requêtes définie par la RFC 7208 et prévient les échecs d'authentification."}},{"@type":"Question","name":"Pourquoi l'aplatissement SPF est-il nécessaire ?","acceptedAnswer":{"@type":"Answer","text":"L'aplatissement devient nécessaire lorsque votre domaine dépasse le plafond de la spécification SPF de 10 requêtes DNS par évaluation. Une fois cette limite franchie, le SPF renvoie un `PermError` et chaque message de votre domaine échoue à l'authentification, ce qui peut aussi faire échouer DMARC. Comme la plupart des organisations utilisent plusieurs expéditeurs tiers qui ajoutent chacun des includes, les domaines en croissance atteignent rapidement le plafond et ont besoin de l'aplatissement pour rester conformes."}},{"@type":"Question","name":"L'aplatissement SPF améliore-t-il la délivrabilité des e-mails ?","acceptedAnswer":{"@type":"Answer","text":"Oui. En éliminant les conditions `PermError` et `TempError` provoquées par un trop grand nombre de requêtes ou des includes en amont lents, l'aplatissement maintient un SPF qui passe de manière fiable. Dans les données clients d'AutoSPF, le passage de 12-18 requêtes à un enregistrement entièrement aplati a réduit de plus de 80 % les échecs DMARC liés au SPF et amélioré le placement en boîte de réception des e-mails marketing de 10 à 15 % lors des pics d'envoi."}},{"@type":"Question","name":"À quelle fréquence un enregistrement SPF aplati doit-il être mis à jour ?","acceptedAnswer":{"@type":"Answer","text":"Aussi souvent que vos fournisseurs changent d'IP. Les ESP à fort renouvellement comme SendGrid et Mailchimp justifient des rafraîchissements toutes les 12 à 24 heures, les suites stables comme Google Workspace et Microsoft 365 quotidiennement, et les plages statiques auto-hébergées chaque semaine. Un enregistrement maintenu à la main finit presque toujours par dériver - AutoSPF évite cela en effectuant une nouvelle analyse toutes les 15 minutes et en republiant automatiquement chaque fois qu'une plage en amont change."}},{"@type":"Question","name":"L'aplatissement SPF manuel est-il sûr ?","acceptedAnswer":{"@type":"Answer","text":"L'aplatissement manuel n'est sûr que pour les petits environnements statiques où les IP d'envoi changent rarement. Pour tout domaine utilisant des fournisseurs dynamiques, un enregistrement construit à la main se périme dès qu'un fournisseur fait tourner son infrastructure, désautorisant silencieusement les expéditeurs légitimes. L'aplatissement automatisé est fortement recommandé à toute échelle réelle, car suivre le rythme du renouvellement des fournisseurs est la partie difficile."}},{"@type":"Question","name":"Dois-je utiliser `-all` ou `~all` après l'aplatissement ?","acceptedAnswer":{"@type":"Answer","text":"Utilisez `-all` (échec strict) lorsque vous êtes certain que votre liste aplatie est complète et activement surveillée, car il donne aux destinataires le signal le plus clair pour rejeter les e-mails usurpés. Utilisez `~all` (échec souple) pendant le déploiement ou tant que vous ajoutez encore fréquemment des expéditeurs. Une bonne pratique consiste à conserver `~all` jusqu'à ce que les rapports DMARC montrent une fenêtre de réussite propre, puis à resserrer vers `-all`."}}]}
```

```json
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://autospf.com/"},{"@type":"ListItem","position":2,"name":"SPF Flattening","item":"https://autospf.com/fr/spf-flattening/"}]}
```

```json
{"@context":"https://schema.org","@type":"Product","name":"AutoSPF","url":"https://autospf.com","aggregateRating":{"@type":"AggregateRating","ratingValue":5,"reviewCount":21,"bestRating":5,"worstRating":1},"review":[{"@type":"Review","reviewRating":{"@type":"Rating","ratingValue":5,"bestRating":5},"author":{"@type":"Person","name":"Peter J.","jobTitle":"President"},"datePublished":"2026-03-10","reviewBody":"It does what it promises to do, and does it very well. I appreciate that it keeps a log of changes made, which prevents many mistakes. A client's SPF record would have way too many lookups, but AutoSPF makes that problem go away. The length of the SPF record is typically not the issue; it's the amount of lookups in the record that are. AutoSPF \"flattens\" the record, automatically expanding the defined lookups to IP addresses or ranges. And it auto-updates the record when the un-flattened lookups change.","name":"AutoSPF Flattens SPF Records Seamlessly & Keeps Changes Logged - I am quite pleased with the product","publisher":{"@type":"Organization","name":"G2","url":"https://www.g2.com"}},{"@type":"Review","reviewRating":{"@type":"Rating","ratingValue":5,"bestRating":5},"author":{"@type":"Person","name":"Verified User","jobTitle":"Financial Services"},"datePublished":"2025-07-31","reviewBody":"AutoSPF did exactly as described, it helped us get past our 10 lookup limit. Afterwards, we hit another limit regarding overall capacity and when contacted, they quickly provided us with a new solution to eliminate capacity issues entirely going forward, so now we can add as many SPF records as needed. They also provided us with a personalized support video explaining their new method in its entirety using our instance as the example.","name":"Helped us go beyond capacity","publisher":{"@type":"Organization","name":"G2","url":"https://www.g2.com"}},{"@type":"Review","reviewRating":{"@type":"Rating","ratingValue":5,"bestRating":5},"author":{"@type":"Person","name":"Greg F."},"datePublished":"2023-07-26","reviewBody":"AutoSPF was easy to initially set up on our own and a great cost effective entry into spf flattening. Needed our first support assistance today and got great response including a video demonstrating the issue I was trying to solve, a quick fix, and more detailed followup.","name":"Great service and great support","publisher":{"@type":"Organization","name":"G2","url":"https://www.g2.com"}}]}
```
