E-mail : les inclusions SPF sont un désordre — comment simplifier sans casser la délivrabilité

Pourquoi les inclusions SPF deviennent un bazar (et pourquoi ça compte)

SPF est simple en esprit : publier quels hôtes sont autorisés à envoyer du courrier pour un domaine. Le problème vient de la façon dont SPF exprime cette simplicité : un langage de politique qui peut déclencher des requêtes DNS lors de l’évaluation, et un plafond strict sur leur nombre autorisé.

Ce plafond est au centre de la plupart des douleurs SPF : la « limite de 10 recherches DNS ». Si l’évaluation SPF nécessite plus de 10 recherches DNS, les évaluateurs doivent renvoyer permerror (erreur permanente), et beaucoup de récepteurs considèrent cela comme « cette politique est cassée, donc nous serons sceptiques ». Sceptique est le terme poli de l’e-mail pour « votre message va faire un tour panoramique vers la boîte de réception, si jamais il arrive ».

Voici pourquoi les inclusions se transforment en bazar :

• Les inclusions sont transitives. Chaque include: peut lui-même inclure d’autres enregistrements SPF, chacun déclenchant d’autres recherches. Vous ne contrôlez pas ce que votre fournisseur ajoute plus tard.
• Les inclusions cachent du travail. Votre enregistrement SPF paraît court, mais la politique effective peut être une petite novella de DNS.
• Les tiers changent fréquemment. Les fournisseurs modifient leur infrastructure. Leur SPF change. Parfois ils ajoutent des inclusions imbriquées. Vous héritez de leur complexité.
• Vous continuez à ajouter des émetteurs. Personne ne supprime les anciens outils. Ils « mettent juste les campagnes en pause ». Ce qui signifie en entreprise : « on reviendra dans 18 mois ».

Opérationnellement, SPF est un problème de graphe de dépendances. Pas un problème de chaîne. Traitez-le comme la gestion des dépendances : inventaire, verrouillez vos exigences, réduisez les dépendances optionnelles, et surveillez la dérive.

Une petite blague, pour nettoyer le palais : les enregistrements SPF sont comme les discussions de groupe : chaque nouveau « include » semble inoffensif jusqu’à ce que votre téléphone prenne feu.

À quoi ressemble réellement « casser la livraison »

Vous n’obtenez rarement une panne nette. Vous subissez une lente hémorragie :

• Les nouvelles inscriptions cessent de recevoir les e-mails de vérification chez certains FAI.
• Les e-mails commerciaux atterrissent dans le spam « tout d’un coup » (traduction : cela fait des semaines que ça s’aggrave).
• Les rapports DMARC montrent une augmentation des échecs SPF provenant de sources légitimes que vous aviez oubliées.
• Les tickets de support arrivent avec des codes de rebond qui varient selon le récepteur et selon son humeur.

SPF n’est pas le seul signal utilisé par les récepteurs, mais c’est l’un des fondamentaux. S’il est cassé, tout le reste doit travailler plus dur. Et en e-mail, « plus dur » signifie « moins fiable ».

Faits intéressants et petite histoire

Six à dix points de contexte courts, parce que comprendre d’où vient SPF rend le bazar actuel… inévitable.

1. SPF précède la prolifération moderne d’e-mails cloud. Il a été conçu quand « vos serveurs de sortie » étaient un ensemble petit et plutôt statique.
2. La limite de 10 recherches est délibérée. C’est une garde anti-abus et anti-DoS : les récepteurs ne devraient pas être forcés à un travail DNS sans bornes par message.
3. « Include » est effectivement un saut conditionnel. include: dit « si l’expéditeur passe cette autre politique, traitez-la comme un pass ici ». Ce n’est pas juste une fusion de listes.
4. SPF vérifie le domaine de l’enveloppe (MAIL FROM), pas l’en-tête From: Cela surprend encore en 2026, et c’est pourquoi DMARC existe pour relier les identités.
5. SPF peut échouer pour les transferts (forwarding). Le renvoi classique casse souvent SPF parce que l’hôte de transfert n’est pas autorisé par le SPF du domaine d’origine.
6. Les récepteurs divergent sur les comportements en bordure. La spécification est claire sur beaucoup de points, mais le traitement réel de permerror, temperror et des réponses DNS ambiguës varie.
7. Le TTL DNS est un levier opérationnel. Des TTL courts vous aident à déployer des changements rapidement, mais augmentent le trafic DNS ; des TTL longs font durer les erreurs.
8. L’« aplatissement SPF » est devenu une niche. Parce que les chaînes d’inclusions des fournisseurs devenaient trop profondes, des gens ont commencé à pré-résoudre les inclusions en IP concrètes—parfois sûr, parfois non.
9. SPF est largement déployé parce que c’est peu coûteux. Publier un enregistrement TXT est plus simple que gérer des clés (DKIM) ou imposer l’alignement (DMARC), donc SPF devient souvent le « premier et unique » contrôle.

Un modèle mental : comment SPF s’évalue réellement

Quand un récepteur évalue SPF, il exécute un petit programme : il commence avec le domaine dans l’enveloppe SMTP (MAIL FROM) et demande au DNS la politique SPF de ce domaine (généralement via un enregistrement TXT commençant par v=spf1). Ensuite il vérifie les mécanismes de gauche à droite jusqu’à ce que l’un corresponde et renvoie un résultat.

Les mécanismes importants pour les inclusions

• include: oblige l’évaluateur à récupérer et évaluer le SPF du domaine inclus. Cela coûte des recherches DNS (au moins une requête TXT, plus ce que l’enregistrement inclus déclenche).
• a et mx peuvent aussi déclencher des recherches. Si votre enregistrement utilise mx, l’évaluation SPF doit interroger MX, puis résoudre A/AAAA pour chaque cible MX.
• exists déclenche des recherches, et peut être abusé. Traitez-le comme suspect sauf si vous avez une très bonne raison.
• ptr est obsolète pour de bonnes raisons (performances et spoofing). Si vous l’avez encore, vous portez une dette historique avec intérêt.
• ip4/ip6 sont « gratuits » du point de vue du comptage des recherches DNS. Ils ne nécessitent pas de recherches lors de l’évaluation. Ils peuvent toutefois être coûteux à maintenir opérationnellement.
• redirect= est comme « remplace ma politique entière par celle de cet autre domaine ». Utile pour centraliser le SPF des sous-domaines.

Pourquoi la limite de recherches mord plus fort que prévu

La limite compte certains mécanismes et modificateurs qui provoquent des requêtes DNS : include, a, mx, ptr, exists, et redirect. Ce qui ressemble à « une inclusion » peut être « une inclusion plus cinq MX plus huit résolutions A/AAAA ».

De plus, l’évaluation SPF peut impliquer à la fois des recherches A et AAAA. Même si vous n’utilisez pas IPv6 intentionnellement, votre DNS peut publier des enregistrements AAAA ou votre fournisseur peut le faire, et certains évaluateurs interrogeront les deux.

Opinion : si vous ne pouvez pas expliquer le nombre de recherches de votre enregistrement SPF sur un tableau blanc de mémoire, vous ne le maîtrisez pas. Vous le louez au hasard.

Une citation sur la fiabilité (paraphrasée)

Idée paraphrasée (Werner Vogels, AWS) : « Concevez pour que la défaillance soit attendue, et construisez des systèmes qui continuent à fonctionner quand des parties tombent en panne. » Les inclusions SPF sont des parties.

Playbook de diagnostic rapide

Voici ce que vous faites quand la délivrabilité est en feu et que quelqu’un vient de coller un message de rebond dans Slack.

Première étape : identifier quelle identité échoue

1. Vérifiez le domaine MAIL FROM / Return-Path dans les en-têtes du message défaillant (ou la configuration du système d’envoi). SPF évalue cela, pas le From visible.
2. Confirmez l’IP d’envoi à partir des en-têtes Received ou des logs de votre MTA.
3. Demandez-vous : s’agit-il d’un nouvel émetteur ou d’un chemin transféré ? Un nouvel émetteur suggère un manque dans l’inventaire SPF ; un transfert suggère que SPF échouera par conception et vous devrez vous appuyer sur DKIM/DMARC.

Deuxième étape : déterminer s’il s’agit d’une « mauvaise politique » ou d’une « politique cassée »

1. Interrogez l’enregistrement TXT SPF et confirmez qu’il y a exactement une politique SPF pour ce domaine.
2. Comptez les recherches DNS (ou au moins identifiez la profondeur de la chaîne d’inclusions). Si vous êtes proche ou au-dessus de 10, supposez un permerror sur le terrain.
3. Vérifiez les problèmes DNS : NXDOMAIN, SERVFAIL, timeouts, ou surprises de split-horizon.

Troisième étape : choisissez l’atténuation la moins risquée

1. Si la limite de recherches est le problème : retirez les inclusions non essentielles, ou déplacez un émetteur sur un sous-domaine avec son propre SPF, ou autorisez temporairement une plage IP concrète avec ip4/ip6 (avec un ticket strict pour la supprimer ensuite).
2. Si l’IP de l’émetteur manque simplement : ajoutez l’autorisation correcte, mais seulement après avoir vérifié que le système envoie vraiment avec le domaine d’enveloppe en question.
3. Si c’est une rupture due au transfert : ne « réparez » pas SPF en autorisant le forwarder ; c’est du whack-a-mole. Utilisez DKIM/DMARC et/ou ARC si applicable.

Une règle : n’« optimisez » pas pendant que vous diagnostiquez. Stabilisez d’abord, puis simplifiez.

Tâches pratiques : commandes, sorties et décisions

Ce sont des tâches d’opérateur réelles. Chacune inclut une commande, une sortie d’exemple, ce que cela signifie, et la décision suivante. Exécutez-les depuis un hôte Linux avec des outils standards. Si vous ne disposez pas de ces outils, installez-les sur une machine de saut, pas sur vos serveurs de mail en plein incident.

Task 1: Fetch the SPF record (and see if you have multiple)

cr0x@server:~$ dig +short TXT example.com
"v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"
"google-site-verification=abc123"

Ce que cela signifie : Il y a exactement une chaîne de politique SPF (celle commençant par v=spf1). Bien.

Décision : Si vous voyez plus d’une chaîne v=spf1 retournée, vous devez consolider ; plusieurs enregistrements SPF causent souvent permerror.

Task 2: Confirm the envelope-from domain in a message (local MTA)

cr0x@server:~$ postcat -q 1A2B3C4D | sed -n '1,40p'
*** ENVELOPE RECORDS ***
message_arrival_time: Tue Jan  2 12:01:09 2026
original_recipient: user@example.net
sender: bounce@mailer.example.com
*** MESSAGE CONTENTS ***
Return-Path: <bounce@mailer.example.com>
From: "Example Billing" <billing@example.com>
To: user@example.net
Subject: Invoice

Ce que cela signifie : SPF sera évalué pour mailer.example.com (Return-Path / sender), pas pour example.com visible dans From.

Décision : Auditez le SPF pour le domaine d’enveloppe qui envoie réellement, pas celui que le marketing pense utiliser.

Task 3: Get a quick SPF validation signal via OpenSSL (SMTP banner sanity)

cr0x@server:~$ openssl s_client -starttls smtp -crlf -connect mx1.receiver.net:25 </dev/null | sed -n '1,15p'
CONNECTED(00000003)
depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=R3
verify return:1
depth=0 CN=mx1.receiver.net
verify return:1
250 mx1.receiver.net ESMTP ready

Ce que cela signifie : Pas SPF directement, mais vous confirmez que vous pouvez atteindre un récepteur et que la négociation TLS n’est pas le vrai problème lors des tests.

Décision : Si la connectivité/TLS échoue, réparez cela avant d’accuser SPF. Les « pannes » de délivrabilité commencent parfois par votre réseau.

Task 4: Inspect SPF includes recursively (basic)

cr0x@server:~$ dig +short TXT _spf.google.com
"v=spf1 ip4:74.125.0.0/16 ip4:173.194.0.0/16 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

Ce que cela signifie : Cette seule inclusion se développe en trois inclusions supplémentaires plus plusieurs plages IP.

Décision : Commencez à construire un arbre d’inclusions et un compte de recherches. Si vous incluez déjà deux grands fournisseurs, vous êtes probablement proche de la limite.

Task 5: Count how many SPF strings exist (guard against accidental duplication)

cr0x@server:~$ dig +short TXT example.com | grep -c "v=spf1"
1

Ce que cela signifie : Un enregistrement SPF. Parfait.

Décision : Si la sortie est 2 ou plus, consolidez en un seul. Supprimez les doublons. Ne tentez pas de « répartir » SPF sur plusieurs enregistrements ; SPF ne fonctionne pas ainsi.

Task 6: Check if a subdomain already has its own SPF record

cr0x@server:~$ dig +short TXT mailer.example.com
"v=spf1 include:spf.vendor-mail.com -all"

Ce que cela signifie : Le fournisseur prend déjà en charge l’envoi depuis un sous-domaine délégué avec SPF séparé.

Décision : Préférez déplacer les envois des fournisseurs vers leur propre sous-domaine SPF plutôt que d’alourdir le domaine apex.

Task 7: Find MX records (and realize mx can cost you lookups)

cr0x@server:~$ dig +short MX example.com
10 mx01.mailhost.example.net.
20 mx02.mailhost.example.net.

Ce que cela signifie : Si votre enregistrement SPF utilise mx, l’évaluation peut résoudre ces noms et leurs enregistrements A/AAAA. C’est plusieurs recherches.

Décision : Évitez mx dans SPF sauf si vous envoyez réellement depuis vos MX entrants (rare aujourd’hui).

Task 8: Resolve A and AAAA for MX targets (lookup budgeting)

cr0x@server:~$ dig +short A mx01.mailhost.example.net
203.0.113.10
203.0.113.11

cr0x@server:~$ dig +short AAAA mx01.mailhost.example.net
2001:db8:10::10

Ce que cela signifie : Plusieurs adresses signifient un travail de résolution supplémentaire pour les évaluateurs. Certains interrogeront à la fois A et AAAA.

Décision : Si vous prévoyez d’utiliser mx ou a dans SPF, envisagez des ip4/ip6 explicites pour la prévisibilité (avec un plan de maintenance).

Task 9: Measure DNS response time and detect flaky resolution

cr0x@server:~$ dig example.com TXT +stats | tail -n 5
;; Query time: 142 msec
;; SERVER: 10.0.0.53#53(10.0.0.53) (UDP)
;; WHEN: Tue Jan  2 12:20:11 UTC 2026
;; MSG SIZE  rcvd: 232

Ce que cela signifie : 142 ms n’est pas terrible, mais si vos inclusions nécessitent beaucoup de recherches, la latence se cumule. Si vous voyez des secondes, vous avez un problème DNS.

Décision : Si le DNS est lent ou défaillant, l’évaluation SPF devient peu fiable. Corrigez la santé DNS (serveurs autoritaires, résolveurs, timeouts) avant de « simplifier » le SPF.

Task 10: Check authoritative vs recursive answers (split-horizon traps)

cr0x@server:~$ dig @ns1.example-dns.net example.com TXT +norecurse +short
"v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"

Ce que cela signifie : Vous voyez ce que publie le serveur autoritaire. Si cela diffère de la réponse de votre résolveur interne, vous avez du DNS split-horizon ou des problèmes de cache.

Décision : Assurez-vous que l’enregistrement public autoritaire est correct ; les récepteurs utilisent le DNS public, pas votre vue interne.

Task 11: Spot a broken include target (NXDOMAIN/SERVFAIL)

cr0x@server:~$ dig +short TXT spf.dead-vendor.example

Ce que cela signifie : Une sortie vide signifie généralement NXDOMAIN ou pas de TXT. Cette inclusion échouera à l’évaluation selon le comportement du récepteur et l’interprétation de la spec.

Décision : Supprimez les inclusions mortes immédiatement. Si vous avez encore besoin de cet émetteur, remplacez l’inclusion par leur domaine supporté actuel ou par des IP explicites.

Task 12: Detect oversize SPF TXT strings (DNS limits and quoting)

cr0x@server:~$ dig +short TXT example.com | awk 'length($0) {print length($0), $0}'
92 "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"
33 "google-site-verification=abc123"

Ce que cela signifie : Les enregistrements TXT peuvent être divisés en plusieurs chaînes entre guillemets par les serveurs DNS ; certains outils et humains gèrent mal cela. Les enregistrements SPF volumineux peuvent aussi dépasser des limites pratiques et être malformés.

Décision : Gardez le SPF compact. Si vous approchez des limites de taille ou voyez des chaînes divisées, c’est un signe : simplifiez par l’architecture, pas en entassant du texte.

Task 13: Validate that a given IP would pass SPF (local check with spfquery)

cr0x@server:~$ spfquery -ip 198.51.100.77 -sender bounce@mailer.example.com -helo mailer.example.com
pass

Ce que cela signifie : Pour ce domaine d’enveloppe et cette IP, SPF devrait passer.

Décision : Si cela échoue, corrigez le SPF ou la configuration de l’émetteur. Si cela passe localement mais échoue chez les récepteurs, suspectez la propagation DNS, les limites de recherche, ou des différences de résolveur.

Task 14: Check DMARC alignment clues (to avoid “fixing” the wrong layer)

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc@reports.example.com; adkim=s; aspf=s"

Ce que cela signifie : L’alignement strict est requis pour DKIM et SPF. Si votre domaine d’enveloppe diffère du domaine From, SPF peut passer mais ne pas être aligné.

Décision : En simplifiant SPF, gardez l’architecture d’identité à l’esprit : alignez les émetteurs sur le sous-domaine correct ou assurez l’alignement DKIM.

Task 15: Check recent mail logs for “SPF permerror” patterns (Postfix example)

cr0x@server:~$ sudo grep -i "spf" /var/log/mail.log | tail -n 8
Jan  2 12:12:41 mx postfix/smtpd[22191]: warning: SPF: permerror (too many DNS lookups) identity=mailfrom; client-ip=198.51.100.77; helo=mailer.example.com; envelope-from=bounce@mailer.example.com; receiver=mx
Jan  2 12:13:02 mx postfix/smtpd[22191]: warning: SPF: fail identity=mailfrom; client-ip=203.0.113.55; envelope-from=noreply@example.com

Ce que cela signifie : Vous avez à la fois une rupture de la limite de recherches et un échec simple pour une autre identité. Deux problèmes différents, même semaine. Classique.

Décision : Priorisez permerror d’abord ; il peut ruiner la délivrabilité même pour le trafic légitime. Ensuite traitez les émetteurs manquants individuellement.

Task 16: Verify TXT changes propagate (watch TTL and caching)

cr0x@server:~$ dig example.com TXT +noall +answer
example.com.  300 IN TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"

Ce que cela signifie : Le TTL est 300 secondes (5 minutes). C’est adapté aux incidents.

Décision : Pour des migrations planifiées, abaissez le TTL un jour à l’avance si possible. Pour des opérations stables, augmentez-le pour réduire la charge des résolveurs et améliorer le taux de cache.

Stratégies de simplification qui ne cassent pas la production

L’objectif n’est pas « un SPF court ». L’objectif est un « SPF prévisible qui reste sous les limites, survit aux changements des fournisseurs, et correspond à la façon dont vos mails circulent réellement ». La brièveté en est un effet secondaire.

1) Cessez de traiter le domaine apex comme un tiroir fourre-tout

Placez les expéditeurs tiers sur des sous-domaines chaque fois que possible. C’est le mouvement le plus rentable. Exemples :

• mailer.example.com pour l’automatisation marketing
• support.example.com pour le ticketing
• notify.example.com pour les notifications produit

Puis publiez des enregistrements SPF séparés par sous-domaine. Votre SPF apex reste mince : seulement l’infrastructure qui envoie réellement des mails en tant que @example.com.

Inconvénient : Vous devez vous assurer que les domaines affichés dans From et DKIM s’alignent avec votre politique DMARC, sinon vous corrigerez SPF et échouerez toujours DMARC.

2) Préférez redirect= pour la cohérence entre une flotte de sous-domaines

Si vous possédez de nombreux sous-domaines qui doivent partager le même SPF, centralisez-le :

• v=spf1 redirect=_spf.example.com
• Puis définissez la vraie politique sur _spf.example.com

Cela ne réduit pas magiquement les recherches, mais réduit les erreurs administratives. C’est une simplification du plan de contrôle, pas du plan de données.

3) Soyez impitoyable pour supprimer les expéditeurs obsolètes

La plupart des organisations gardent des inclusions pour des fournisseurs qu’elles n’utilisent plus depuis des années. Les inclusions vous coûtent du budget de recherches et augmentent le périmètre des changements fournisseurs.

Mouvement opérationnel : exigez un « propriétaire » pour chaque inclusion avec une réattestation trimestrielle. Pas de propriétaire, pas d’inclusion.

4) Évitez les mécanismes mx et a sauf si vous les entendez vraiment

mx dans SPF est un truc hérité classique : « s’il peut recevoir du mail pour nous, il peut envoyer pour nous ». Dans les environnements modernes, entrant et sortant sont séparés. Utiliser mx dans SPF autorise souvent des hôtes qui ne devraient jamais envoyer en votre nom.

Recommandation : Si vous avez une petite plage de sortie stable, utilisez des ip4/ip6 explicites. Si vous ne l’avez pas, utilisez des sous-domaines et des inclusions fournisseurs. N’utilisez pas mx comme raccourci paresseux.

5) Aplatissement : utile, risqué, parfois nécessaire

« Aplatir » signifie remplacer des inclusions par les plages IP résultantes (ip4/ip6) afin que l’évaluation SPF n’ait pas à faire autant de recherches DNS. Cela peut être efficace pour rester sous la limite de 10 recherches.

Mais l’aplatissement a des bords tranchants :

• Les plages IP des fournisseurs peuvent changer sans préavis. Votre enregistrement aplati devient obsolète et vous échouez pour du courrier légitime.
• Les longues listes d’IP rendent les enregistrements TXT volumineux et plus sujets aux erreurs lors de l’édition.
• Vous pouvez accidentellement autoriser plus que prévu si vous aplatissez trop largement.

Quand l’aplatissement est acceptable : pour des expéditeurs ayant des plages IP publiées et stables et un processus de contrôle de changements de votre côté pour les rafraîchir régulièrement. Traitez cela comme la mise à jour de règles de pare-feu : planifiée, révisée et surveillée.

Deuxième petite blague : Aplatir le SPF, c’est comme préparer des repas à l’avance : ça vous fait gagner du temps pendant la semaine, jusqu’à ce que vous l’oubliiez dans le frigo et que ça devienne un projet scientifique.

6) Faites du SPF un produit : versionnez, testez et validez en staging

Les changements SPF doivent passer par la même discipline que la configuration de production :

• Gardez l’enregistrement dans git (en tant que texte, plus un commentaire d’explication dans le dépôt).
• Ayez un banc d’essai qui compte les recherches et valide la syntaxe.
• Utilisez un déploiement progressif via un TTL réduit, puis déployez, puis surveillez les rapports DMARC et les motifs de rebonds.

7) Alignez l’architecture d’identité sur DMARC, pas contre

Les équipes tentent souvent de réparer la délivrabilité en bourrant plus de choses dans SPF, alors que le vrai problème est le décalage d’identité. Si votre politique DMARC est stricte, vous devez soit :

• SPF passe et s’aligne (le domaine d’enveloppe s’aligne avec le domaine From), ou
• DKIM passe et s’aligne (le d= du DKIM s’aligne avec le From)

Cela vous pousse fréquemment vers « chaque émetteur utilise son propre sous-domaine, avec DKIM aligné », ce qui réduit aussi la complexité SPF à l’apex. Drôle comme une bonne architecture résout plusieurs problèmes.

Trois mini-histoires d’entreprise depuis les tranchées SPF

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise SaaS de taille moyenne envoyait du courrier depuis trois endroits : Google Workspace pour les humains, un fournisseur transactionnel pour les e-mails produit, et une plateforme marketing pour les campagnes. Leur SPF à l’apex était déjà lourd, mais il passait encore la plupart du temps, ce qui est la manière de l’e-mail d’encourager les mauvais comportements.

Une nouvelle intégration a été livrée : « Envoyer des invitations depuis votre domaine d’entreprise ». L’ingénierie a supposé que cela impliquait d’ajouter une clé DKIM et de signer en tant que example.com. Hypothèse raisonnable. L’équipe d’intégration a configuré le fournisseur pour utiliser bounce@vendor.example.net comme expéditeur d’enveloppe parce que c’était le défaut, et personne n’a demandé quelle « identité SPF » serait évaluée.

Deux semaines plus tard, les invitations clients ont commencé à rebondir chez un grand récepteur. La raison du rebond mentionnait des échecs SPF pour vendor.example.net, pas pour example.com. Le support a escaladé vers le SRE. Le SRE a regardé le SPF apex pendant dix minutes avant de réaliser que c’était sans rapport avec cette panne. Mauvais domaine. Mauvaise identité.

La correction n’a pas été « ajouter un autre include ». La correction a été de déplacer l’expéditeur d’enveloppe du fournisseur vers mailer.example.com et de publier un SPF dédié pour ce sous-domaine. L’alignement DKIM a été mis à jour pour correspondre. L’incident s’est rapidement terminé, mais le postmortem a été franc : on ne peut pas raisonner sur l’authentification e-mail en regardant l’en-tête From et en se fiant aux impressions.

Mini-histoire 2 : L’optimisation qui a mal tourné

Une équipe IT d’entreprise a décidé de « nettoyer le DNS ». Ils ont remarqué que leur enregistrement SPF utilisait include: pour un fournisseur qui, après inspection, s’étendait à beaucoup de plages ip4. Ils avaient entendu parler de l’aplatissement SPF, et cela sonnait comme un gain de performance. Ils l’ont donc aplati manuellement.

Au début, c’était génial : moins de recherches DNS, chaîne d’inclusions plus courte, moins de tickets intermittents temperror de la part de récepteurs avec des timeouts stricts. Ils ont déclaré victoire et sont passés à autre chose. Un mois plus tard, un petit flux de rapports « le reset de mot de passe n’est jamais arrivé » a commencé à apparaître, provenant d’un sous-ensemble de fournisseurs de boîtes grand public.

Le fournisseur avait ajouté de nouvelles IP d’envoi. L’enregistrement include a été mis à jour. L’enregistrement aplati ne l’a pas été. Le courrier ne tombait pas partout ; il échouait juste assez pour coûter cher et être difficile à prouver. Personne ne voulait revenir en arrière parce que l’aplatissement SPF avait été présenté comme une amélioration de sécurité. Ce n’était pas un mensonge, mais ce n’était pas toute la vérité non plus.

Ils ont finalement reconstruit l’approche : l’aplatissement était automatisé avec un rafraîchissement planifié, les changements étaient diffés et revus, et la liste était limitée aux services fournisseurs réellement utilisés. Le retour de bâton n’était pas l’aplatissement en lui-même. C’était l’aplatissement sans le traiter comme une dépendance vivante.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise globale avait la réputation d’être « lente » pour les changements d’e-mail. Chaque mise à jour SPF nécessitait un propriétaire, un ticket, un plan de rollback, et une période d’observation de 24 heures. Les gens se plaignaient. Le marketing se plaignait plus fort. C’est l’ordre naturel des choses.

Un matin, un fournisseur d’e-mail bien connu a eu une panne DNS. Leur domaine d’inclusion SPF renvoyait par intermittence SERVFAIL. Beaucoup de clients ont vu des temperror sporadiques lors de l’évaluation SPF. Certains récepteurs ont différé le courrier. Certains l’ont traité comme suspect. Chaos, mais chaos poli.

Cette entreprise avait deux avantages : (1) leur SPF apex n’avait qu’une seule inclusion tierce, car presque tout le courrier fournisseur utilisait des sous-domaines délégués, et (2) ils avaient une surveillance qui échantillonnait la résolution SPF depuis plusieurs résolveurs publics et alertait sur SERVFAIL et les anomalies du compte de recherches.

La réponse a été ennuyeuse : rediriger temporairement les mails transactionnels critiques via un fournisseur secondaire déjà autorisé sur un sous-domaine, et attendre la récupération DNS du fournisseur. Pas d’éditions paniquées du SPF apex. Pas de « ajoutez juste cette inclusion » à 9h. Le compte-rendu post-incident a été tout aussi ennuyeux : ils ont documenté la dépendance au fournisseur et conservé l’architecture. En production, ennuyeux est un compliment.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: intermittent failures, sometimes “permerror”

Cause racine : trop de recherches DNS dues à des inclusions imbriquées, plus des mécanismes mx/a à l’intérieur des chaînes d’inclusions.

Correction : réduisez les dépendances : déplacez les fournisseurs sur des sous-domaines, supprimez les inclusions obsolètes, évitez mx/a dans SPF, envisagez un aplatissement géré avec rafraîchissement.

2) Symptom: “SPF fail” but you swear the From domain is correct

Cause racine : vous regardez l’en-tête From ; SPF vérifie le domaine de l’enveloppe (Return-Path).

Correction : inspectez les en-têtes/logs pour trouver MAIL FROM. Corrigez la configuration du domaine d’enveloppe ou publiez le SPF pour le domaine d’enveloppe réel.

3) Symptom: SPF suddenly breaks after “a small DNS cleanup”

Cause racine : plusieurs enregistrements SPF (plusieurs chaînes v=spf1) existent, ou quelqu’un a modifié les guillemets/espaces et cassé le parsing.

Correction : publiez exactement une politique SPF par domaine ; validez avec des outils ; gardez le SPF dans le contrôle de version.

4) Symptom: mail forwarding causes SPF failures

Cause racine : les forwarders renvoient depuis leurs IP ; le SPF du domaine d’origine ne les autorise pas.

Correction : n’autorisez pas tout le monde. Utilisez le DKIM signé avec alignement, plus DMARC. Dans certains écosystèmes, ARC peut aider à préserver les résultats d’authentification lors du transfert.

5) Symptom: SPF passes but DMARC fails

Cause racine : SPF passe pour un domaine d’enveloppe qui ne s’aligne pas avec le domaine From sous DMARC (surtout en alignement strict).

Correction : alignez les identités : utilisez un domaine d’enveloppe correspondant (souvent un sous-domaine du From) et/ou assurez que DKIM d= s’aligne avec le From.

6) Symptom: SPF works for IPv4 senders, fails mysteriously for some receivers

Cause racine : vous envoyez en IPv6 depuis certains hôtes, mais SPF n’autorise que l’IPv4, ou la chaîne d’inclusions se comporte différemment avec des requêtes AAAA et timeouts.

Correction : inventairez les IP d’envoi réelles incluant IPv6 ; autorisez ip6: si nécessaire ; assurez-vous que les MTAs sortants ne fuient pas des chemins IPv6 inattendus.

7) Symptom: vendor mail fails only for some of their regions

Cause racine : vous avez aplati le SPF et manqué de nouvelles pools IP du fournisseur, ou le fournisseur a plusieurs domaines d’inclusion SPF pour différents produits et vous avez inclus le mauvais.

Correction : revenez à l’inclusion fournisseur si vous pouvez vous permettre le budget de recherches, ou implémentez un rafraîchissement automatisé de l’aplatissement avec revue ; vérifiez que vous utilisez le bon include pour le niveau de produit.

8) Symptom: receivers report “temperror” in SPF

Cause racine : timeouts DNS, SERVFAIL, ou serveurs autoritaires instables pour votre domaine ou une cible d’inclusion.

Correction : durcissez le DNS (redondance autoritaire, santé des résolveurs), réduisez le nombre de recherches pour diminuer le temps passé dans le DNS, surveillez depuis plusieurs résolveurs publics.

Listes de vérification / plan pas à pas

Étape par étape : simplifier les inclusions SPF en toute sécurité

1. Inventaire des expéditeurs. Listez chaque système qui envoie du courrier sous votre marque : boîtes humaines, transactionnel, marketing, support, finance, monitoring, CI, et « invitations produit ». Rattachez chacun à un propriétaire.
2. Pour chaque expéditeur, capturez les identités. Domaine From, domaine envelope-from, domaine DKIM d=, plages IP d’envoi (v4/v6), et si le fournisseur supporte un return-path personnalisé.
3. Dessinez le graphe de dépendances SPF actuel. SPF apex plus toutes les inclusions, et les inclusions à l’intérieur de ces inclusions. Comptez les recherches DNS estimées.
4. Décidez la stratégie de domaines. Quels expéditeurs doivent vraiment envoyer en tant que @example.com ? Tout le reste va sur des sous-domaines délégués.
5. Déplacez un expéditeur à la fois vers un sous-domaine. Configurez le fournisseur pour utiliser bounce@mailer.example.com (ou similaire), publiez le SPF pour ce sous-domaine, assurez l’alignement DKIM.
6. Gardez le SPF apex minimal. Habituellement : le fournisseur de mail corporate + le fournisseur transactionnel principal, et seulement s’ils doivent utiliser le domaine apex.
7. Supprimez les inclusions obsolètes. Si un outil est « inactif », retirez-le. Si quelqu’un se plaint plus tard, il pourra réautoriser intentionnellement avec une conception appropriée.
8. Abaissez le TTL avant les gros changements. Faites-le au moins un jour avant si possible. Remontez le TTL après stabilisation.
9. Validez la syntaxe et le budget de recherches. Exécutez des tests d’évaluation SPF pour des IPs et identités représentatives.
10. Déployez et observez. Surveillez les rapports DMARC agrégés et les rebonds entrants. Attendez-vous à un délai dû aux caches et à la cadence des rapports.
11. Documentez le contrat. Pour chaque inclusion/sous-domaine, notez : propriétaire, fournisseur, pourquoi il existe, ce qu’il autorise, et comment le faire tourner.
12. Surveillez la dérive. Les inclusions peuvent changer sans prévenir. Suivez le compte de recherches et la santé DNS comme signal continu.

Checklist opérationnelle : avant d’ajouter un nouveau include:

• Avons-nous réellement besoin d’envoi depuis le domaine apex, ou cela peut-il être un sous-domaine ?
• Quel est le envelope-from du fournisseur et supporte-t-il un return-path personnalisé ?
• Quel est notre budget de recherches actuel et quel coût aura cette inclusion une fois développée ?
• Qui possède cet expéditeur et le ré-attestera trimestriellement ?
• Avons-nous un alignement DKIM qui satisfera DMARC ?
• Quel est le rollback si cette inclusion provoque un permerror ?

Checklist d’urgence : « On a atteint permerror »

• Confirmez permerror (too many DNS lookups) dans les logs ou le feedback du récepteur.
• Identifiez le dernier changement SPF (diff de vos enregistrements DNS).
• Retirez temporairement l'(les) inclusion(s) la(les) moins critique(s) pour repasser sous la limite.
• Si la suppression casse un expéditeur critique, déplacez-le sur un sous-domaine avec son propre SPF comme solution réelle.
• Après stabilisation, effectuez un inventaire complet des expéditeurs et simplifiez correctement.

FAQ

1) Pourquoi existe-t-il une limite de « 10 recherches DNS » dans SPF ?

Parce que les récepteurs doivent évaluer SPF pour d’énormes volumes de courrier. Sans limite, SPF pourrait être abusé pour forcer un travail DNS excessif par message, transformant la réception de mail en test de résistance du DNS.

2) L’ajout d’entrées ip4: génère-t-il des recherches DNS ?

Non. Les mécanismes ip4/ip6 ne nécessitent pas de requêtes DNS lors de l’évaluation SPF. Ils sont peu coûteux pour les récepteurs, mais vous payez le coût de maintenance.

3) Les mécanismes a et mx sont-ils « mauvais » dans SPF ?

Pas intrinsèquement, mais ils sont souvent utilisés paresseusement et peuvent faire exploser le nombre de recherches. Ils ont aussi tendance à autoriser plus d’hôtes que prévu. En 2026, des IP explicites ou des sous-domaines fournisseurs sont généralement plus sûrs.

4) Quelle est la différence entre include: et redirect= ?

include: dit « si la politique incluse passe, considérez-la comme une correspondance ici » et l’évaluation continue si elle ne passe pas. redirect= dit « utilisez la politique de cet autre domaine comme politique pour ce domaine » (typiquement comme modificateur final).

5) Puis-je avoir plusieurs enregistrements TXT SPF pour éviter la longueur ou la complexité ?

Non. Publier plusieurs enregistrements v=spf1 est une erreur courante et entraîne souvent permerror. Vous devez avoir exactement une politique SPF par domaine.

6) Si nous utilisons DMARC, avons-nous encore besoin de SPF ?

Oui. DMARC s’appuie sur le passage et l’alignement de SPF et/ou DKIM. SPF reste une entrée primaire, et beaucoup de récepteurs utilisent les résultats SPF au-delà de l’évaluation DMARC.

7) Pourquoi le transfert casse-t-il SPF, et que fait-on ?

Les forwarders renvoient depuis leurs propres IP, qui ne figurent pas dans votre SPF. La solution durable est la signature DKIM avec alignement, plus DMARC. Dans certains écosystèmes, ARC peut aider à préserver l’authentification lors du transfert.

8) Devrait-on utiliser ~all ou -all ?

Utilisez -all lorsque vous êtes sûr que votre inventaire est correct et que vous appliquez. Utilisez ~all pendant des migrations si vous avez besoin de télémétrie et souhaitez réduire les échecs durs. Mais ne laissez pas ~all indéfiniment ; cela devient une indécision permanente dans le DNS.

9) Quelle est la meilleure façon de simplifier SPF sans aplatir ?

Déléguez. Déplacez le courrier tiers sur des sous-domaines avec SPF dédiés et DKIM aligné. Gardez le SPF apex pour les quelques systèmes qui doivent envoyer en tant que domaine apex.

10) Comment surveiller la dérive des inclusions SPF dans le temps ?

Résolvez périodiquement votre enregistrement SPF, parcourez les inclusions, et suivez le nombre de recherches et les échecs DNS depuis plusieurs résolveurs. Alertez sur les changements, surtout de nouvelles inclusions imbriquées ou de nouveaux mécanismes comme exists.

Conclusion : étapes pratiques suivantes

Si votre enregistrement SPF est une pile d’inclusions, vous n’avez pas un enregistrement SPF. Vous avez un graphe de dépendances que vous ne gérez pas. La voie de sortie n’est pas un kung-fu héroïque du DNS ; c’est l’architecture et la responsabilité.

1. Aujourd’hui : récupérez votre SPF actuel, confirmez que vous avez exactement un v=spf1, et identifiez si vous flirtez avec la limite de 10 recherches.
2. Cette semaine : inventariez les expéditeurs et déplacez au moins un grand expéditeur tiers vers un sous-domaine délégué avec son propre SPF et un DKIM aligné.
3. Ce mois-ci : établissez un propriétaire par expéditeur/inclusion, implémentez une chaîne légère de validation (syntaxe + budget de recherches), et ajoutez une surveillance pour les échecs DNS et la dérive inattendue des inclusions.

SPF n’a pas besoin d’être parfait. Il doit être opérable. Gardez-le sous la limite de recherches, alignez-le avec la façon dont les mails quittent réellement vos systèmes, et arrêtez de traiter le DNS comme un endroit pour cacher la complexité. Vos boîtes de réception — et votre sommeil — s’amélioreront.