Ce qu'est l'aplatissement SPF (et ce qu'il n'est pas)
L'aplatissement SPF consiste à remplacer les mécanismes qui coûtent une recherche DNS (include:, a, mx, redirect=, exists:) par les adresses IP littérales qu'ils résolvent (ip4: / ip6:). Ces mécanismes littéraux coûtent 0 recherche : c'est pourquoi l'aplatissement « fonctionne » sur le papier pour repasser sous la limite.
Le revers est immédiat : l'aplatissement fige une délégation vivante en un instantané statique. Tant que le fournisseur conserve un mécanisme include:, c'est lui qui maintient ses IP à jour. Dès que vous aplatissez, c'est à vous de le faire.
Il faut distinguer deux choses souvent confondues :
- Aplatissement statique : un instantané d'IP gelé, publié tel quel. Il se périme dès qu'un fournisseur change ses adresses.
- SPF dynamique (macros ou hébergé en CNAME) : un enregistrement qui se recalcule ou se met à jour tout seul. Ce n'est pas un aplatissement statique.
Exemple d'enregistrement avant tout traitement, pour captaindns.com :
v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net mx ~all
Une version aplatie remplacerait les include: par des blocs ip4: / ip6:. Mais ce résultat est un instantané figé : il reflète les IP du jour de l'aplatissement, et se dégrade ensuite à chaque changement côté fournisseur. C'est précisément le problème que les sections suivantes détaillent.
Pour la distinction complète entre aplatissement statique et approche dynamique, voir le guide aplatissement SPF et macros.
La limite de 10 recherches DNS et le permerror
La RFC 7208 §4.6.4 plafonne l'évaluation d'un SPF à 10 recherches DNS. Coût par mécanisme :
| Mécanisme | Coût en recherches |
|---|---|
include: | 1 (et plus, récursivement) |
a / mx | 1 chacun |
ptr | 1 (déconseillé par la RFC) |
exists: | 1 |
redirect= | 1 |
ip4: / ip6: / all | 0 |
Au-delà de 10, l'évaluation renvoie un permerror. Ce n'est pas une simple alerte : c'est un double échec. D'un côté, le courrier légitime peut être rejeté ou classé en spam. De l'autre, les usurpateurs ne sont plus bloqués de façon fiable, et l'alignement DMARC casse pour tous les flux qui s'appuyaient sur SPF. Le vérificateur SPF affiche le décompte exact et le statut.
Il existe une seconde limite, souvent oubliée : plus de 2 void lookups (recherches qui ne renvoient aucun enregistrement) déclenchent aussi un permerror. La plupart des vérificateurs l'ignorent ; cet outil compte les void lookups et les signale.
Attention aussi à ne pas confondre deux types de permerror :
- Permerror de recherches : trop de recherches DNS (le cas ci-dessus).
- Permerror de syntaxe : erreur de syntaxe, ou plusieurs enregistrements SPF publiés sur le même domaine.
L'aplatissement ne corrige ni la syntaxe ni la présence de plusieurs SPF. Pour ces cas, le verdict error de l'outil les détecte ; validez avec le contrôle de syntaxe SPF. Pour un diagnostic approfondi du permerror, voir le guide permerror SPF, et pour l'erreur de recherches, le guide corriger too many DNS lookups.
Pourquoi l'aplatissement est risqué : le churn d'IP
Le risque tient à un mécanisme simple : un instantané figé se désynchronise du monde réel. Trois conséquences :
- Faux négatifs : un fournisseur ajoute une nouvelle IP légitime, absente de votre enregistrement figé. Le courrier de cette IP échoue à SPF.
- Surface d'usurpation : une IP désaffectée par le fournisseur reste autorisée dans votre enregistrement. Un tiers qui la récupère peut s'en servir.
- Pannes intermittentes : ces échecs sont difficiles à diagnostiquer, car ils ne touchent qu'une fraction des messages.
Deux repères chiffrés, les seuls vérifiés :
- Cas Mailhardener : après un aplatissement, un fournisseur d'envoi a ajouté une IP d'équilibreur de charge, ce qui a fait échouer à SPF environ 1 message sur 20. C'est un cas réel documenté, pas une statistique générale.
- Télémétrie d'AutoSPF (indicatif, meilleur effort) : un
include:tiers change en médiane environ tous les 11,5 jours ; les cibles IPv6 changent environ 2,1 fois plus souvent que l'IPv4.
S'ajoute le piège de la taille : l'aplatissement résout le problème des recherches mais aggrave la limite de taille (255 caractères par chaîne TXT, 512 octets en UDP, environ 450 à 600 caractères en pratique). L'enregistrement gonfle en dizaines de blocs ip4: / ip6:.
Google Workspace et Microsoft 365 (Exchange Online) publient de larges plages d'IP qui évoluent, ce qui rend un aplatissement statique fragile. L'outil affiche des badges de churn (faible, moyen, élevé) par fournisseur : il s'agit d'un classement éditorial pour guider la décision, pas d'une cadence chiffrée inventée.
Pour mesurer l'impact côté réception, voir le score de délivrabilité.
Les alternatives à essayer avant d'aplatir
Ces options sont ordonnées par risque croissant : commencez par le haut. L'outil présente les mêmes recommandations dans cet ordre.
1. Élaguer d'abord. Supprimez les include: inutilisés ou qui ne passent jamais, retirez ptr (déconseillé par la RFC), supprimez les a et mx redondants, dédupliquez. Cela suffit souvent à repasser sous 10 recherches sans figer aucune IP. Recoupez avec vos données agrégées DMARC pour identifier les sources réellement utilisées.
2. Déléguer par sous-domaine. Affectez un sous-domaine dédié par flux d'envoi, chacun disposant de son propre budget de 10 recherches. Crainte fréquente : « cela casse-t-il DMARC ? » Non : avec un alignement DMARC relâché (aspf=r), le sous-domaine reste aligné. DMARC n'est pas cassé.
3. Utiliser les macros SPF (RFC 7208 §7). Un enregistrement dynamique, sans dette de péremption. Approche avancée, à réserver aux configurations maîtrisées.
4. Passer par un SPF hébergé (CNAME à mise à jour automatique). L'enregistrement reste à jour tout seul. À signaler honnêtement : dépendance au fournisseur et perte de contrôle direct sur le DNS.
5. Déplacer la confiance vers DKIM et DMARC (avec ARC et SRS). C'est la clé conceptuelle : l'aplatissement ne corrige jamais les échecs de transfert ni de liste de diffusion, car SPF teste l'IP de connexion, qui change lors d'un transfert. La robustesse vient de DKIM (qui survit au relais) et de l'alignement DMARC via DKIM, complétés par ARC et SRS.
Quand l'aplatissement est réellement justifié
Le périmètre est étroit. L'aplatissement statique se justifie seulement si toutes ces conditions sont réunies :
- Vous avez déjà élagué l'enregistrement.
- Vous ne pouvez ni déléguer par sous-domaine, ni passer à un SPF hébergé.
- Vous dépassez réellement 10 recherches avec des expéditeurs tous essentiels.
- Vous vous engagez à resynchroniser régulièrement : c'est une dette de maintenance, pas une opération unique.
Même dans ce cas, préférez le dynamique (macros ou hébergé) au statique quand c'est possible. Si vous aplatissez en statique : surveillez l'enregistrement en continu avec le vérificateur SPF, et acceptez le risque de churn décrit plus haut. En une phrase : un aplatissement statique en une fois est une dette, pas une correction.
Comment lire le verdict de l'outil
L'outil renvoie cinq verdicts. À chacun correspond une action :
- ok : aucun besoin d'aplatir, laissez l'enregistrement en l'état.
- at risk : proche de la limite, à surveiller.
- over limit : permerror, à corriger en priorité.
- error : impossible d'aplatir tel quel, corrigez d'abord la syntaxe ou les SPF multiples.
- missing : aucun SPF publié, commencez par en créer un avec le SPF Generator.
La jauge de budget affiche « X / 10 recherches » et « V / 2 void lookups ». Le message de fond reste le même : un verdict vert signifie qu'il faut laisser l'enregistrement tranquille.
FAQ - Questions fréquentes
Q : Qu'est-ce que l'aplatissement SPF et en ai-je vraiment besoin ?
R : L'aplatissement remplace les mécanismes coûteux en recherches (include:, a, mx, redirect=, exists:) par des ip4: / ip6: littéraux. Mais la plupart des enregistrements restent sous 10 recherches et n'ont pas besoin d'être aplatis. Un verdict vert de l'outil signifie : laissez l'enregistrement en l'état.
Q : Comment fonctionne la limite de 10 recherches DNS (RFC 7208) ?
R : La RFC 7208 §4.6.4 plafonne l'évaluation SPF à 10 recherches. Chaque include:, a, mx, ptr, exists: et redirect= compte ; ip4:, ip6: et all ne comptent pas. Au-delà de 10, c'est un permerror. Une seconde limite existe : plus de 2 void lookups déclenchent aussi un permerror.
Q : Comment corriger l'erreur "too many DNS lookups" ou un permerror ?
R : N'aplatissez pas par réflexe. Élaguez d'abord : supprimez les include: inutilisés, retirez ptr, dédupliquez. Cela suffit généralement à repasser sous 10. Envisagez ensuite la délégation par sous-domaine. L'aplatissement vient en dernier. Détails dans le guide corriger too many DNS lookups.
Q : L'aplatissement SPF est-il sûr ?
R : Il comporte un risque réel : un aplatissement statique fige les IP des fournisseurs. Cas documenté par Mailhardener : l'ajout d'une IP d'équilibreur de charge a fait échouer environ 1 message sur 20. Selon la télémétrie d'AutoSPF, un include: tiers change en médiane environ tous les 11,5 jours. Préférez les options dynamiques.
Q : Quelles sont les alternatives à l'aplatissement ?
R : Par risque croissant : élaguer, déléguer par sous-domaine (avec alignement DMARC relâché aspf=r), utiliser des macros SPF, passer par un SPF hébergé en CNAME, puis déplacer la confiance vers DKIM et DMARC. L'aplatissement statique reste l'ultime recours.
Q : L'aplatissement casse-t-il DMARC ou corrige-t-il les échecs de transfert ?
R : Il ne corrige pas les échecs de transfert ni de liste de diffusion, car SPF teste l'IP de connexion, qui change lors d'un transfert. La robustesse DMARC vient de l'alignement DKIM. La délégation par sous-domaine avec aspf=r conserve l'alignement intact.
Q : Aplatissement statique ou SPF hébergé dynamique : quelle différence ?
R : Un aplatissement statique est un instantané d'IP figé qui se périme. Un SPF dynamique (macros ou hébergé en CNAME) se met à jour tout seul. Ne confondez pas les deux.
Q : L'aplatissement a réglé mes recherches mais mon enregistrement est trop long, pourquoi ?
R : La limite de taille (255 caractères par chaîne TXT, 512 octets en UDP) est distincte de la limite de recherches. L'aplatissement échange un problème de recherches contre un problème de taille. La solution : découper l'enregistrement en sous-domaines dédiés.
Q : SPF Flattener, SPF Generator ou SPF Checker : lequel utiliser ?
R : Le SPF Checker diagnostique. Le SPF Generator construit un nouvel enregistrement. Le SPF Flattener est l'optimiseur consultatif de dernier recours : il vous dit d'abord s'il faut aplatir.
Outils complémentaires
| Outil | Utilité |
|---|---|
| SPF Checker | Diagnostiquez votre SPF publié et son décompte de recherches |
| SPF Syntax Check | Validez la syntaxe avant publication, repérez le permerror de syntaxe |
| SPF Generator | Construisez un nouvel enregistrement à partir de vos fournisseurs |
| DMARC Checker | Vérifiez l'alignement DMARC et son interaction avec SPF |
| DMARC Generator | Configurez DMARC pour compléter votre authentification |
| DKIM Checker | Vérifiez DKIM, le pilier de robustesse face aux transferts |
| Mail Tester | Validez l'authentification de bout en bout |
| Mail Domain Check | Audit complet de l'authentification email du domaine |
| Blacklist IP | Contrôlez la réputation d'envoi de vos IP |
| Blacklist de domaine | Contrôlez la réputation de votre domaine |
Ressources utiles
- RFC 7208 - Sender Policy Framework (SPF) : spécification officielle, source de la limite de 10 recherches, des void lookups et des macros.
- RFC 4408 - SPF (ancienne version) : version précédente de la spécification.
- dmarcian - SPF Best Practices : autorité qui a conclu son expérience d'aplatissement et recommande d'autres approches.
- Mailhardener - Do not flatten your SPF record : source du cas documenté (environ 1 message sur 20).
- Google Workspace - configurer et dépanner SPF : guide pour configurer et dépanner SPF avec Google.
- Microsoft 365 - configurer et dépanner SPF : guide pour configurer et dépanner SPF avec Microsoft 365.