Formatage des enregistrements SPF : guillemets et espaces qui cassent discrètement les e-mails

novembre 13, 2025 • février 3, 2026 • Lecture : 28 min • Views: 10

Cet article vous a aidé ?

Les e-mails tombent en panne de la façon la plus insultante : ils « fonctionnent pour la plupart » jusqu’au jour où ils ne fonctionnent plus, et vos dirigeants apprennent alors l’expression SPF permerror à partir d’un message de rebond à 6h12.

Il s’agit des pannes stupides — les pièges liés aux guillemets et aux espaces dans les enregistrements TXT SPF qui transforment une politique parfaitement valide en échec silencieux, échec intermittent ou en festival de blâme envers un fournisseur. Si vous gérez des systèmes en production, vous n’avez pas besoin d’un vague « vérifiez votre DNS ». Vous avez besoin d’une liste de contrôle, d’un playbook de diagnostic rapide et d’une opinion ferme sur les endroits où les humains ne devraient pas être autorisés à taper des guillemets doubles.

Pourquoi le formatage casse SPF (même quand le texte semble correct)

SPF, c’est du texte. DNS, c’est du texte. Les humains aiment le texte. Voilà le problème.

SPF est évalué par des récepteurs et des passerelles qui analysent un enregistrement TXT en une séquence de mécanismes et de modificateurs. Les règles d’analyse sont strictes dans les aspects ennuyeux et étonnamment permissives dans les aspects confus. Le résultat : un enregistrement peut sembler correct dans une interface DNS, sembler correct dans une capture d’écran, et être interprété différemment selon les résolveurs, les bibliothèques et les récepteurs de mail.

Les erreurs de formatage se répartissent en quelques catégories :

Présentation DNS vs format filaire DNS : des outils comme dig affichent des guillemets ; les fournisseurs DNS stockent des chaînes ; les bibliothèques joignent des « character-strings ». Les gens copient les guillemets dans la valeur et publient accidentellement des guillemets littéraux.
Espaces et tokenisation : les mécanismes SPF sont séparés par des espaces. Les espaces supplémentaires sont généralement tolérés, mais pas toujours là où on le pense. Les tabulations, espaces insécables et la « mise en forme intelligente » des interfaces peuvent créer des tokens qui ne s’analysent pas comme prévu.
Fractionnement en plusieurs chaînes : la RDATA TXT DNS peut contenir plusieurs character-strings. Beaucoup de fournisseurs scindent les valeurs longues. Le traitement SPF concatène ces chaînes sans ajouter d’espace. Si la coupure se produit au mauvais endroit, vous pouvez souder deux tokens en un seul token invalide.
Plusieurs enregistrements SPF : plus d’une politique SPF au même nom est une erreur de protocole. Ce n’est pas « il en choisira un ». C’est « certains récepteurs traitent cela comme permerror et échouent SPF ».
Requêtes et redirections : ce n’est pas du formatage, mais ça apparaît dans la même file d’incidents. Les include/redirect font exploser le nombre de requêtes DNS, et SPF retourne permerror. Les gens « corrigent » souvent ça en aplatissant, ce qui introduit de nouveaux risques de formatage.

Une raison supplémentaire pour laquelle cela fait mal : les échecs SPF ne provoquent pas toujours des rebonds. Beaucoup de récepteurs traitent SPF comme un signal, pas comme une barrière stricte, surtout quand la politique DMARC est relâchée. Vous n’aurez donc pas une panne nette — juste des « problèmes de délivrabilité », des placements en spam et une fuite lente de confiance.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Quand vous êtes d’astreinte et qu’un dirigeant transfère « Pourquoi ce fournisseur dit que nos e-mails sont usurpés ? », vous n’avez pas besoin de philosophie. Vous avez besoin d’un ordre de triage qui converge.

Premier : vérifier ce qui est réellement publié (pas ce que montre votre interface DNS)

Interrogez le TXT du domaine exact utilisé dans le MAIL FROM / Return-Path (souvent un sous-domaine). Beaucoup d’organisations modifient example.com alors que l’expéditeur utilise bounces.example.com.
Comptez les enregistrements SPF : s’il y a plus d’une valeur TXT v=spf1, traitez cela comme un incendie jusqu’à preuve du contraire.
Recherchez les artefacts de guillemets : caractères de guillemets en début ou fin à l’intérieur de la chaîne publiée, et les « guillemets échappés » provenant du copier/coller.

Deuxième : évaluer la façon dont les récepteurs l’analyseront

Joindre les chaînes TXT scindées et revérifier les limites de tokens (particulièrement autour de include:, ip4:, redirect= et des qualificateurs comme ~all).
Exécuter une évaluation SPF contre une IP d’expéditeur connue (ou au moins valider la syntaxe). Ne supposez pas que « semble correct » signifie « s’analyse correctement ».
Vérifier le nombre de requêtes DNS si vous êtes proche de la limite ; un include de plus peut vous faire dépasser 10.

Troisième : confirmer ce qui a échoué en production

Obtenir un vrai exemple d’entête d’un destinataire ayant échoué montrant Authentication-Results. C’est le récepteur qui vous dit comment il a interprété votre SPF.
Comparer entre récepteurs (Gmail vs Microsoft vs une passerelle de sécurité). Si l’un dit « permerror » et un autre dit « none », vous avez probablement un problème de multi-enregistrement, de fractionnement ou de résolveur.
Vérifier la propagation et le cache avant de continuer à changer les enregistrements comme un joueur de machine à sous.

Idée paraphrasée de Werner Vogels (CTO d’Amazon) : « Tout échoue, tout le temps. » Les échecs de formatage SPF sont juste la version e-mail de cette vérité.

Faits et contexte historique (les bizarreries qui comptent)

SPF a commencé comme “Sender Permitted From” au début des années 2000, créé pour lutter contre l’usurpation et le spam ; il est ensuite devenu « Sender Policy Framework ». Les noms importent moins que les mécaniques DNS.
SPF est publié dans des enregistrements DNS TXT principalement pour la compatibilité ascendante. Il y a eu un type RR SPF dédié, mais TXT a gagné le déploiement.
Les enregistrements TXT DNS peuvent contenir plusieurs « character-strings » (morceaux). Les outils les affichent avec des guillemets, ce qui trompe les humains en leur faisant croire que les guillemets font partie de la valeur.
SPF a une limite stricte de 10 recherches DNS lors de l’évaluation (pour des mécanismes comme include, a, mx, ptr, exists et redirect). Un outil marketing enthousiaste peut vous condamner.
SPF vérifie le domaine de l’expéditeur d’enveloppe (MAIL FROM / Return-Path), pas l’en-tête « From: » que voient les utilisateurs. C’est pourquoi SPF peut réussir alors que le phishing fonctionne encore.
DMARC dépend de l’alignement entre SPF (domaine d’enveloppe) et le domaine de l’en-tête From, ou de l’alignement DKIM. SPF peut être parfait et échouer DMARC si les domaines ne sont pas alignés.
Certains récepteurs traitent plusieurs enregistrements SPF comme permerror et effectuent effectivement un échec SPF. D’autres en choisissent un ou fusionnent — quoi qu’il en soit, c’est suffisamment indéfini pour être dangereux.
La notion d’espace dans DNS n’existe pas ; l’espace dans SPF oui. DNS stocke des octets. SPF interprète des octets comme des tokens. Confondre ces couches provoque les erreurs exactes dont parle cet article.
Les anciens mécanismes SPF comme PTR étaient largement utilisés et sont maintenant déconseillés car lents et fragiles. Vous en trouverez encore dans des enregistrements hérités comme des cron jobs oubliés.

Comment SPF est analysé : ce que les récepteurs évaluent réellement

Clarifions le modèle mental, car la plupart des bugs de formatage SPF viennent d’une mauvaise compréhension de celui-ci.

Deux couches : encodage TXT DNS vs analyse texte SPF

Couche DNS : un enregistrement TXT est une ou plusieurs chaînes. Les fournisseurs peuvent le stocker comme une longue chaîne, ou le scinder. Sur le réseau, c’est une liste de morceaux préfixés par leur longueur. Les résolveurs renvoient les morceaux ; les clients les concatènent typiquement.

Couche SPF : une fois concaténé, SPF est une seule chaîne commençant par v=spf1, suivie de mécanismes et de modificateurs séparés par des espaces. Chaque mécanisme peut avoir un qualificateur optionnel : + (pass), - (fail), ~ (softfail), ? (neutral).

Ce que voit le récepteur (simplifié)

Le récepteur reçoit une connexion d’une IP. Il lit le domaine expéditeur d’enveloppe (parfois le nom HELO est utilisé pour les vérifications d’identité HELO SPF, mais le grand important est MAIL FROM). Il interroge le TXT pour ce domaine. Il sélectionne l’enregistrement SPF (si exactement un). Il évalue les mécanismes jusqu’à ce que l’un corresponde. S’il ne peut pas évaluer (erreur de syntaxe, erreurs DNS, trop de recherches), vous obtenez permerror ou temperror.

Permerror n’est pas « un peu échoué »

permerror signifie que la politique publiée est cassée ou viole des limites. Beaucoup de récepteurs traitent permerror comme un échec ou comme un « pas de signal », selon leur politique. Cette incohérence est la raison pour laquelle les erreurs de formatage sont si pénibles : vous n’obtenez pas un seul mode d’échec clair.

Guillemets et espaces : modes de défaillance que vous pouvez reproduire

1) Copier les guillemets depuis `dig` dans le DNS

dig affiche les chaînes TXT entre guillemets. Les gens voient :

cr0x@server:~$ dig +short TXT example.com
"v=spf1 ip4:203.0.113.10 include:_spf.vendor.example ~all"

Puis ils collent l’ensemble — y compris les guillemets — dans une interface DNS qui traite déjà la valeur comme une chaîne brute. Résultat : la valeur publiée devient "v=spf1 ... ~all" (avec des caractères de guillemets littéraux). Certains parseurs SPF plantent immédiatement ; d’autres ignorent les guillemets initiaux puis butent plus loin. C’est une excellente façon de créer un problème qui n’apparaît que chez un fournisseur de boîte mail.

Que faire : publier le texte sans guillemets entourants, sauf si votre interface DNS l’exige spécifiquement (et la plupart des interfaces modernes ne le font pas). Si l’interface affiche des guillemets dans son aperçu, c’est généralement seulement de la présentation.

2) « Guillemets intelligents » et espaces insécables provenant de systèmes de ticket

SPF attend des espaces ASCII et une ponctuation ASCII. Coller depuis un e-mail formaté ou un outil de chat peut introduire :

des espaces insécables (U+00A0) au lieu d’espaces
des guillemets typographiques (« ») au lieu de guillemets droits (« )
des tirets demi-cadratin (–) au lieu de traits d’union (-) dans de rares cas (généralement dans des noms de domaine copiés dans du texte)

Les récepteurs varient dans la façon dont ils traitent cela. Beaucoup considéreront l’enregistrement entier comme invalide.

3) Scinder un enregistrement en plusieurs chaînes TXT au mauvais endroit

C’est la panne « a l’air correcte » la plus courante. DNS permet :

cr0x@server:~$ dig +short TXT example.com
"v=spf1 ip4:203.0.113.10 include:_spf.vendor.example"
" ~all"

Ces deux chaînes sont concaténées en :

v=spf1 ip4:203.0.113.10 include:_spf.vendor.example ~all

C’est correct car la deuxième chaîne commence par un espace.

Mais si votre fournisseur scinde ainsi :

cr0x@server:~$ dig +short TXT example.com
"v=spf1 ip4:203.0.113.10 include:_spf.vendor.ex"
"ample ~all"

Cela concatène en include:_spf.vendor.example ~all, toujours correct.

Et si la coupure est faite comme ceci :

cr0x@server:~$ dig +short TXT example.com
"v=spf1 ip4:203.0.113.10 include:_spf.vendor.example"
"~all"

Vous obtenez alors include:_spf.vendor.example~all qui est un seul token. C’est de la garbage. Certains parseurs le traitent comme un mécanisme inconnu ; d’autres comme une erreur de syntaxe. Dans tous les cas, vous n’appliquez pas ce que vous pensez appliquer.

Règle : si un enregistrement est scindé, assurez-vous que la frontière soit sur une limite de token et que les espaces soient préservés. En cas de doute, démarrez explicitement la chaîne suivante par un espace.

4) Plusieurs enregistrements TXT contenant chacun `v=spf1`

Classique. Quelqu’un ajoute un fournisseur et « ajoute juste un autre enregistrement SPF » parce que l’interface DNS permet plusieurs entrées TXT au même nom.

SPF dit : un seul enregistrement. Si vous en publiez deux, beaucoup d’évaluateurs renvoient permerror. Certains en choisiront un, ce qui est pire car ça « marche » jusqu’à ce qu’un résolveur change de comportement.

5) Espaces supplémentaires et tabulations : pas toujours inoffensifs

Plusieurs espaces entre mécanismes sont généralement acceptés. Les tabulations, retours chariot, ou espaces bizarres collés ne sont pas systématiquement acceptés. Aussi : un espace final à la fin d’un morceau peut mal se combiner lors de la concaténation avec le morceau suivant.

6) Échappement qui ressemble à de l’échappement

Les fichiers de zone TXT utilisent parfois des barres obliques inverses pour échapper des guillemets. Les interfaces fournisseurs varient : certaines attendent du texte brut ; d’autres un style fichier de zone. Si vous collez \"v=spf1 ...\" vous pouvez publier littéralement des barres obliques, des guillemets et de la tristesse.

Blague #1 : SPF est le seul endroit où un seul espace manquant peut couler du chiffre d’affaires et compter quand même comme « juste un enregistrement texte ».

Tâches pratiques : commandes, sorties et décisions (12+)

Ce sont des tâches de terrain : exécutez la commande, interprétez la sortie, prenez une décision. Faites-les dans l’ordre lorsque vous déboguez, ou choisissez celles qui correspondent à vos symptômes.

Task 1: Identify the SPF identity domain from a real message

Command: extract Return-Path and Authentication-Results from a stored message (example using a saved raw email).

cr0x@server:~$ grep -E '^(Return-Path|Authentication-Results):' -n sample.eml
12:Return-Path: <bounces@mail.example.com>
45:Authentication-Results: mx.google.com; spf=permerror (google.com: domain of bounces@mail.example.com has multiple SPF records) smtp.mailfrom=bounces@mail.example.com

Ce que cela signifie : SPF est évalué pour mail.example.com (ou possiblement le sous-domaine bounces), pas nécessairement pour example.com.

Décision : interrogez le TXT pour le domaine exact dans smtp.mailfrom=. Ne « corrigez » pas l’apex si le mail utilise un sous-domaine.

Task 2: Query TXT records as the world sees them

cr0x@server:~$ dig TXT mail.example.com +noall +answer
mail.example.com.  300 IN TXT "v=spf1 include:_spf.vendor.example ~all"

Ce que cela signifie : il y a un enregistrement TXT et il contient une seule chaîne (dans cette réponse).

Décision : valider la syntaxe et le nombre de requêtes ; si plusieurs réponses ou plusieurs chaînes v=spf1, arrêtez et corrigez d’abord cela.

Task 3: Detect multiple SPF policies at one name

cr0x@server:~$ dig +short TXT mail.example.com | grep -i 'v=spf1'
"v=spf1 include:_spf.vendor.example ~all"
"v=spf1 ip4:203.0.113.10 ~all"

Ce que cela signifie : deux enregistrements SPF. C’est une erreur de protocole et cela donne probablement permerror quelque part.

Décision : fusionnez les mécanismes en un seul enregistrement SPF ; supprimez l’extra.

Task 4: Check for literal quotes inside the published string

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

Ce que cela signifie : la chaîne TXT inclut des caractères de guillemets réels au début et à la fin (échappés pour l’affichage). Cela casse souvent l’analyse.

Décision : éditez l’enregistrement DNS pour supprimer les guillemets internes ; publiez v=spf1 ... en texte brut.

Task 5: Spot multi-string TXT splitting and verify boundaries

cr0x@server:~$ dig TXT example.com +noall +answer
example.com. 300 IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.vendor.example" "~all"

Ce que cela signifie : deux character-strings. Ils seront concaténés sans espace inséré, donnant ...vendor.example~all.

Décision : corrigez la coupure pour que la deuxième chaîne commence par un espace, ou conservez l’enregistrement comme une seule chaîne si votre fournisseur le permet.

Task 6: Compare results from multiple resolvers (caching/proxy issues)

cr0x@server:~$ dig @1.1.1.1 +short TXT mail.example.com
"v=spf1 include:_spf.vendor.example ~all"
cr0x@server:~$ dig @8.8.8.8 +short TXT mail.example.com
"v=spf1 include:_spf.vendor.example" "~all"

Ce que cela signifie : différents résolveurs renvoient un découpage TXT différent (toujours potentiellement équivalent), ou vous observez une propagation partielle ou une mauvaise configuration DNS multi-fournisseurs.

Décision : si le découpage change les limites de tokens (comme ci-dessus), traitez comme cassé ; sinon, surveillez le TTL/la propagation et vérifiez la cohérence de vos serveurs autoritaires.

Task 7: Ask the authoritative name servers directly

cr0x@server:~$ dig NS example.com +short
ns1.dns-provider.example.
ns2.dns-provider.example.
cr0x@server:~$ dig @ns1.dns-provider.example TXT mail.example.com +noall +answer
mail.example.com. 300 IN TXT "v=spf1 include:_spf.vendor.example ~all"
cr0x@server:~$ dig @ns2.dns-provider.example TXT mail.example.com +noall +answer
mail.example.com. 300 IN TXT "v=spf1 include:_spf.vendor.example" "~all"

Ce que cela signifie : vos serveurs autoritaires sont en désaccord. Ce n’est pas de la « propagation ». C’est de l’incohérence.

Décision : arrêtez d’éditer SPF et corrigez la chaîne de publication DNS (push de zone, synchronisation fournisseur, ou split-brain). Les récepteurs de mail tomberont sur l’un ou l’autre.

Task 8: Validate SPF syntax with a local parser (quick sanity)

Installez un outil (le nom du paquet varie selon la distribution ; montré ici comme si déjà installé) et validez le texte d’enregistrement que vous entendez publier.

cr0x@server:~$ spfquery --scope mfrom --id bounces@mail.example.com --ip 203.0.113.10
pass: domain of bounces@mail.example.com designates 203.0.113.10 as permitted sender

Ce que cela signifie : pour cette IP, la politique SPF renvoie pass. La syntaxe est au moins analysable par cet outil.

Décision : si cela renvoie permerror, corrigez le formatage ou les limites de recherche avant de poursuivre.

Task 9: Force a permerror check by evaluating lookup-heavy records

cr0x@server:~$ spfquery --scope mfrom --id bounces@mail.example.com --ip 198.51.100.25
permerror: too many DNS lookups

Ce que cela signifie : vous avez dépassé la limite de 10 recherches SPF. Cela arrive souvent après « encore un include de plus ».

Décision : réduisez les includes/redirects, retirez a/mx si inutile, ou repensez l’architecture d’envoi (sous-domaines dédiés par fournisseur). Ne colmatez pas ça avec un aplatissement aléatoire sauf si vous contrôlez le processus de mise à jour.

Task 10: Inspect record text for non-ASCII whitespace

Récupérez l’enregistrement TXT et regardez les octets. Cela détecte les espaces insécables et d’autres sabotages invisibles.

cr0x@server:~$ dig +short TXT mail.example.com | tr -d '\n' | hexdump -C | head
00000000  22 76 3d 73 70 66 31  c2 a0 69 6e 63 6c 75  |"v=spf1..inclu|
00000010  64 65 3a 5f 73 70 66  2e 76 65 6e 64 6f 72  |de:_spf.vendor|
00000020  2e 65 78 61 6d 70 6c  65 20 7e 61 6c 6c 22  |.example ~all"|

Ce que cela signifie : c2 a0 est un espace insécable (UTF-8). Ce n’est pas un espace ASCII normal.

Décision : retapez l’enregistrement dans un éditeur de texte brut ou dans l’interface DNS sans espaces fantaisie. Traitez tout caractère non-ASCII comme suspect.

Task 11: Confirm what your MTA is using as envelope sender

Exemple Postfix : vérifiez que smtpd_sender_restrictions ne réécrit pas, et vérifiez les maps canonicals si utilisées.

cr0x@server:~$ postconf -n | egrep 'myhostname|mydomain|sender_canonical|smtp_generic_maps'
myhostname = mx1.internal.example
mydomain = example.com
sender_canonical_maps =
smtp_generic_maps =

Ce que cela signifie : aucune réécriture canonique configurée ici (du moins dans cet extrait). Si vous attendiez une adresse de rebond sur un sous-domaine, elle peut être définie dans votre application ou ESP, pas dans Postfix.

Décision : identifiez le véritable domaine MAIL FROM dans des messages réels envoyés (Task 1) et publiez SPF là-bas.

Task 12: Pull authoritative SPF record and normalize to one line

Cela facilite la détection des tokens soudés à cause d’un fractionnement.

cr0x@server:~$ dig @ns1.dns-provider.example TXT mail.example.com +short | tr -d '\n' | sed 's/" "/ /g'
"v=spf1 include:_spf.vendor.example ~all"

Ce que cela signifie : après une normalisation naïve, vous pouvez voir s’il manque un espace entre les morceaux.

Décision : si vous voyez des motifs comme example~all ou cominclude:, corrigez les frontières des morceaux.

Task 13: Verify no accidental semicolons or commas crept in

Les points-virgules ne sont pas des séparateurs valides en SPF. Certains humains « formatent » SPF comme un fichier de conf.

cr0x@server:~$ dig +short TXT mail.example.com | tr -d '\n' | grep -E '[;,]'
"v=spf1 ip4:203.0.113.10; include:_spf.vendor.example, ~all"

Ce que cela signifie : vous avez des séparateurs que SPF ne comprend pas. Beaucoup d’évaluateurs renvoient permerror.

Décision : retirez la ponctuation ; les mécanismes doivent être séparés par des espaces.

Task 14: Check DMARC alignment when SPF “passes” but DMARC fails

cr0x@server:~$ grep -i '^Authentication-Results:' -n sample.eml
45:Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=bounces.vendor-mail.example; dmarc=fail (p=reject) header.from=example.com

Ce que cela signifie : SPF a réussi pour bounces.vendor-mail.example, mais DMARC a échoué parce que l’en-tête From est example.com et que le domaine SPF n’est pas aligné (et peut-être que DKIM n’est pas aligné non plus).

Décision : corrigez l’alignement (domaine MAIL FROM personnalisé pour le fournisseur sous votre domaine, ou alignement DKIM), pas le formatage SPF.

Blague #2 : Les interfaces DNS qui réenroulent automatiquement les enregistrements TXT sont comme des stagiaires avec sudo — parfois utiles, souvent confiants, et toujours sans surveillance.

Trois mini-récits d’entreprise tirés du terrain

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

C’était une entreprise de taille moyenne avec une configuration normale : mail interne, un CRM et quelques outils SaaS envoyant pour leur compte. Le marketing voulait qu’une nouvelle plateforme d’événements soit ajoutée avant un lancement produit, évidemment.

L’ingénieur effectuant la modification a supposé que le fournisseur DNS voulait la valeur SPF « exactement comme affichée dans dig ». C’est une hypothèse raisonnable si vous avez passé des années à regarder des fichiers de zone et pas assez de temps à fixer les éditeurs DNS basés navigateur. Il a collé l’enregistrement en incluant les guillemets entourants. L’interface l’a accepté. Personne n’a crié. Le changement est sorti.

Le lendemain matin, la délivrabilité était… étrange. Gmail affichait SPF permerror pour certains destinataires, tandis qu’une passerelle de sécurité utilisée par des partenaires affichait SPF none. Le fournisseur de la plateforme insistait pour dire que ses IPs étaient correctes. L’équipe mail interne assurait que leurs serveurs sortants étaient bons. Pendant ce temps, les commerciaux transféraient des captures d’écran de rebonds comme s’il s’agissait de rapports d’incident. Ils n’avaient pas tort.

La correction a pris cinq minutes une fois que quelqu’un a extrait l’enregistrement et a remarqué que la chaîne TXT publiée commençait littéralement par un caractère guillemet. Le diagnostic a pris trois heures parce que tout le monde faisait confiance à ce que l’aperçu de l’interface DNS affichait, et parce que l’équipe n’avait pas de playbook standard « interroger l’autoritaire et hexdump si nécessaire ».

Leçon : ne faites jamais confiance à ce que l’interface rend. Faites confiance à ce que le résolveur retourne. Et n’acceptez pas d’éditions SPF sans vérification par une requête en ligne de commande.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre entreprise avait fait grossir son enregistrement SPF jusqu’à en faire un monstre : cinq includes, quelques mécanismes mx et a « au cas où », et un redirect pour le mail legacy. Ils flirtaient avec la limite des 10 recherches. Parfois ça passait ; parfois c’était permerror, selon les timeouts DNS et la façon dont les récepteurs développaient les includes.

Quelqu’un a proposé une optimisation : « Aplatissons SPF. On résout tous les includes, on les convertit en entrées ip4: et ip6:, et on publie un enregistrement sans recherches. » Sur le papier, super : évaluation plus rapide, moins de dépendances DNS, moins de risque de permerror.

En pratique, leur script d’aplatissement a émis une longue chaîne que l’interface du fournisseur DNS a automatiquement enveloppée en plusieurs character-strings. Les points de coupe étaient arbitraires. Une coupure est arrivée entre ip4:198.51.100.0/ et 24. Une autre est arrivée entre include: et le domaine. Une troisième a supprimé un espace de séparation.

L’enregistrement était syntaxiquement cassé, et maintenant tous les récepteurs le voyaient. Avant l’« optimisation », seuls certains récepteurs rencontraient permerror quand des recherches échouaient. Après l’« optimisation », l’enregistrement était manifestement invalide. Leur monitoring (qui ne vérifiait qu’un seul résolveur) ne l’a pas détecté parce que ce résolveur renvoyait un découpage différent qui masquait l’un des bugs de frontière dans leur vérificateur simpliste.

Ils ont récupéré en revenant en arrière puis en implémentant correctement l’aplatissement : contrôles des frontières de morceaux, espaces initiaux explicites sur les chaînes de continuation, et validation automatisée contre plusieurs résolveurs avant publication. L’aplatissement peut fonctionner, mais c’est désormais une chaîne d’approvisionnement logicielle. Traitez-la comme telle.

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

Une organisation proche de la finance avait une culture « l’authentification des e-mails est de la prod », ce qui est plus rare qu’il ne devrait l’être. Ils avaient une pratique simple : tout changement SPF exigeait l’exécution d’un petit runbook avec captures d’écran interdites. Uniquement des commandes réelles. Ils avaient aussi une politique : chaque système d’envoi majeur a son propre sous-domaine avec son propre SPF.

Quand le service achat a imposé un nouvel outil RH qui nécessitait des privilèges d’envoi, l’équipe n’a pas touché à example.com. Ils ont créé hrmail.example.com pour ce système, publié un SPF minimal là-bas et configuré le fournisseur pour l’utiliser comme domaine de rebond. L’apex SPF est resté stable, et le chaos marketing est resté confiné.

Deux mois plus tard, le fournisseur a fait pivoter son infrastructure et mis à jour sa cible d’include. Beaucoup de clients ont vu des permerrors SPF intermittents dus aux chaînes de recherche et aux timeouts. Cette organisation non. Pourquoi ? Leur enregistrement SPF n’avait qu’un include et rien d’autre. Beaucoup de marge dans le budget de recherches, et un chemin d’évaluation propre.

La partie ennuyeuse — segmentation par sous-domaine, plus une étape de validation obligatoire en ligne de commande — a fait que l’incident n’a jamais atteint leur pager. Il n’a atteint que leur revue hebdomadaire « changements fournisseur », où ils ont hoché la tête, n’ont rien mis à jour, et sont retournés au travail réel.

Erreurs fréquentes : symptôme → cause → correction

1) Symptom: SPF permerror “multiple SPF records”

Cause racine : Plus d’un enregistrement TXT au même nom contient v=spf1 (souvent créé en ajoutant un « enregistrement SPF » d’un fournisseur au lieu de mettre à jour l’existant).

Correction : Consolidez en exactement une politique SPF. Supprimez les entrées TXT SPF supplémentaires. Si vous avez besoin de politiques séparées, utilisez des sous-domaines distincts et configurez les fournisseurs pour utiliser ceux-ci comme MAIL FROM.

2) Symptom: SPF permerror “invalid domain found” or “invalid mechanism”

Cause racine : Soudure de tokens due à la concaténation de chunks TXT sans espace (ex. include:_spf.vendor.example~all), ou une coupure au milieu d’un token.

Correction : Assurez-vous que les coupures se produisent aux limites de tokens et incluez un espace initial dans le chunk suivant. Republiez et vérifiez avec dig montrant la séparation des tokens prévue.

3) Symptom: SPF fails at Gmail but “works” elsewhere

Cause racine : Différents évaluateurs gèrent différemment les espaces/guillemets malformés ; ou certains choisissent un enregistrement SPF tandis que d’autres renvoient permerror ; ou incohérence DNS entre serveurs autoritaires.

Correction : Interrogez plusieurs résolveurs et serveurs autoritaires. Retirez les guillemets littéraux. Éliminez les enregistrements SPF multiples. Normalisez en une seule chaîne propre (ou scindez soigneusement).

4) Symptom: SPF intermittently permerror “too many DNS lookups”

Cause racine : Le nombre de recherches dépend de l’ordre d’expansion des includes et des timeouts DNS ; vous êtes proche du plafond de 10 recherches.

Correction : Réduisez les includes, retirez a/mx/ptr, et segmentez par sous-domaine. Si vous aplatissez, automatisez et validez les frontières de tokens et le chunking.

5) Symptom: SPF is “neutral” or “none” unexpectedly

Cause racine : Enregistrement SPF introuvable pour le domaine MAIL FROM (vous avez modifié le mauvais nom), ou l’enregistrement commence par des caractères indésirables à cause de guillemets/collage.

Correction : Confirmez le domaine d’identité depuis les entêtes. Publiez SPF là-bas. Assurez-vous que l’enregistrement commence exactement par v=spf1 (pas de guillemets initiaux, pas de BOM, pas d’espaces étranges).

6) Symptom: SPF passes but DMARC fails (and you still land in spam)

Cause racine : Échec d’alignement des domaines : le domaine SPF n’est pas aligné avec l’en-tête From, et DKIM n’est pas aligné (ou absent).

Correction : Configurez un domaine de rebond personnalisé sous votre domaine organisationnel pour le fournisseur, ou corrigez l’alignement DKIM. Ne continuez pas à « peaufiner » le formatage SPF.

7) Symptom: SPF fails only for IPv6 senders

Cause racine : Vous avez ajouté des entrées ip4: mais oublié ip6:, ou vous comptiez sur a/mx qui ne couvrent pas IPv6 comme attendu ; parfois combiné avec des erreurs de coupure autour de tokens ip6:.

Correction : Ajoutez des mécanismes ip6: explicites si nécessaire, validez la tokenisation de l’enregistrement, et testez avec une IP expéditrice IPv6.

Listes de contrôle / plan étape par étape

Checklist: publishing an SPF record without breaking it

Décidez des domaines d’identité : listez chaque domaine MAIL FROM utilisé (apex, sous-domaine marketing, sous-domaines de rebond fournisseurs).
Un domaine, un enregistrement SPF : assurez-vous qu’exactement une valeur TXT contenant v=spf1 existe par domaine d’identité.
Rédigez l’enregistrement dans un éditeur de texte brut : pas de texte enrichi, pas de mise en forme provenant d’un système de ticket.
Restez simple : privilégiez des ip4:/ip6: explicites pour vos propres MTA ; utilisez include: seulement si nécessaire.
Évitez les mécanismes legacy : n’utilisez pas ptr. Soyez prudent avec a et mx ; ils consomment des recherches et changent quand DNS change.
Planifiez la limite des 10 recherches : comptez includes et redirects, et supposez que les fournisseurs ont leurs propres includes.
Si vous devez scinder les chaînes TXT : ne scindez qu’aux limites de tokens et commencez les chaînes de continuation par un espace.
Publiez et vérifiez depuis les NS autoritaires : interrogez chaque serveur autoritaire directement.
Vérifiez depuis plusieurs résolveurs publics : attrapez les bizarreries de propagation/caching.
Validez avec un évaluateur SPF : testez au moins une IP expéditrice connue bonne et une IP connue mauvaise.
Capturez des preuves : conservez le texte exact de l’enregistrement, les sorties de requêtes et le ticket de changement. Vous en aurez besoin plus tard.

Step-by-step: merging two SPF records safely

Tirez tous les enregistrements TXT et isolez ceux contenant v=spf1.
Copiez les mécanismes dans un enregistrement unique, en préservant l’ordre pour que les correspondances les plus spécifiques viennent en premier.
Gardez exactement un mécanisme all à la fin (ex. ~all ou -all selon votre maturité de politique).
Publiez l’enregistrement fusionné et supprimez les doublons.
Exécutez la validation du nombre de recherches et des vérifications SPF réelles (Task 8/9).

Step-by-step: fixing a broken split TXT record

Interrogez l’enregistrement et observez le découpage exact (dig ... +answer).
Concaténez mentalement les chaînes (ou avec un script rapide) et cherchez des tokens soudés.
Éditez l’enregistrement de sorte que chaque chaîne de continuation commence par un espace sauf si elle continue délibérément un token (rare et risqué).
Re-interrogez les serveurs autoritaires et vérifiez à la fois le découpage et le texte reconstruit.
Retestez l’évaluation SPF depuis une IP expéditrice connue.

FAQ

1) Do I need quotes around my SPF record in DNS?

Généralement non. Les guillemets sont souvent juste la façon dont les outils affichent les chaînes TXT. Si votre interface DNS demande un champ valeur, entrez v=spf1 ... sans guillemets entourants sauf si l’interface documente explicitement qu’elle les exige.

2) Why does `dig` show quotes then?

Parce que les enregistrements TXT sont des chaînes, et les guillemets sont une convention d’affichage sûre. Ils ne font pas nécessairement partie des données stockées comme vous l’imaginez.

3) Is splitting an SPF record across multiple TXT strings valid?

Oui, tant que le texte concaténé résultant est un SPF valide. Le piège : la concaténation n’insère pas d’espaces. Si votre séparation supprime un espace entre tokens, vous cassez l’enregistrement.

4) What’s the simplest “safe” SPF record?

Pour un domaine qui n’envoie que par une source connue, quelque chose comme v=spf1 ip4:203.0.113.10 -all est propre et robuste. Les environnements réels sont plus complexes ; le principe est de garder l’ensemble des mécanismes minimal et explicite.

5) Why did SPF start failing after adding one vendor include?

Vous avez probablement atteint la limite des 10 recherches DNS, ou la nouvelle chaîne d’include a introduit des timeouts. Les récepteurs peuvent renvoyer permerror quand ils ne peuvent pas compléter l’évaluation. Validez le nombre de recherches avant et après tout changement d’include.

6) Can I publish SPF at the apex and be done?

Seulement si tous vos expéditeurs utilisent le domaine apex comme MAIL FROM et que vous pouvez garder la politique dans les limites. En pratique, utiliser des sous-domaines par fournisseur est plus propre : rayon d’impact séparé, changements plus simples, moins de conflits accidentels.

7) Why does SPF pass but mail still lands in spam?

SPF est un signal parmi d’autres. Si DMARC échoue (alignement), DKIM est absent/cassé, ou votre réputation d’expédition est mauvaise, vous pouvez toujours finir en spam. Ne confondez pas « SPF pass » avec « délivrabilité résolue ».

8) What does SPF permerror mean operationally?

Votre politique SPF n’est pas évaluable telle que publiée (erreur de syntaxe, enregistrements multiples, trop de recherches, etc.). Traitez-la comme un bug de configuration en production. Corrigez-la comme vous corrigeriez un jeu de règles de pare-feu cassé : soigneusement, avec validation et plan de rollback.

9) Are extra spaces in SPF always fine?

Les espaces ASCII supplémentaires entre tokens le sont généralement. Les tabulations, espaces insécables et le fractionnement de chaînes qui supprime des espaces requis ne le sont pas. Si vous déboguez un enregistrement qui « a l’air correct », vérifiez les octets.

10) Should we flatten SPF to avoid lookup limits?

Parfois. L’aplatissement échange des recherches DNS d’exécution contre une chaîne de maintenance qui doit rester correcte lorsque les fournisseurs font pivoter les IPs. Si vous aplatissez, automatisez les mises à jour, validez la syntaxe et les frontières de chunks, et surveillez la dérive. Sinon, vous remplacez un mode de panne par un autre plus coûteux.

Prochaines étapes à déployer cette semaine

Si vous ne faites que trois choses, faites celles-ci :

Inventoriez vos domaines MAIL FROM à partir d’entêtes réels, pas de la mémoire collective. Publiez SPF là où il est réellement évalué.
Imposez « un v=spf1 par nom » et ajoutez un contrôle lint DNS dans votre processus de changement. Les enregistrements SPF multiples sont un auto-sabotage.
Adoptez un rituel de vérification : interrogez les serveurs autoritaires, vérifiez les frontières des chunks, et exécutez une évaluation SPF pour au moins une IP expéditrice avant de déclarer victoire.

SPF n’est pas difficile. Il est simplement impitoyable là où les humains aiment être décontractés : espaces, guillemets et « petites modifications ». Traitez-le comme une configuration de production, parce que vos e-mails commerciaux le sont déjà.