SPF trop large (+all ou trop d'includes) après un incident
Un SPF en +all, ou trop d’includes, laisse usurper ou casse le lookup (limite des 10). Après un incident, on serre sur les envois réels : site, ESP, messagerie OVH. On teste avant de passer DMARC en reject — sinon les devis tombent avec le spam.
N'importe qui peut usurper, ou le lookup casse (10 includes). Serrez sur les envois réels : site, ESP, ovh mail. Testez avant de passer DMARC en reject.
Ce que le SPF autorise, concrètement
Le TXT SPF liste qui a le droit de poser un message dont le Return-Path (enveloppe) est votre domaine. Ce n’est pas une décoration DNS. Un `+all` dit : tout le monde. Un include d’un prestataire « marketing » que vous n’utilisez plus dit : eux aussi, encore. Après un piratage, c’est une invitation à continuer le spoof « légitime » aux yeux de SPF.
Beaucoup de zones PME sont un héritage : include Google + include OVH + include Mailchimp 2018 + include un outil de facture + `~all`. Ça passe jusqu’au jour où le 11e lookup casse tout, ou jusqu’au jour où on veut du DMARC reject. Imprimez le TXT, numérotez les includes, attribuez-en un responsable chacun. Ce qui n’a pas de nom sort.
On ne forge pas de SPF d’attaque ici. On lit votre TXT, on compte les includes, on les aligne sur les envois de la semaine dernière — pas sur un fantasme « on sait jamais ».
+all, ~all, -all : le soir d’un spam
`+all` : à retirer. Tout de suite. C’est le plus clair des cadeaux. `~all` (softfail) : acceptable en transition. `-all` : le but, une fois l’inventaire bon. Pendant l’incident, passer à `-all` + DMARC reject le même soir est le combo qui jette les devis (Apple / DMARC).
Un `?all` neutral ne sert à rien pour se défendre. Remplacez-le quand vous touchez la zone.
Le redirect SPF vers un autre domaine : comprenez où ça mène. Un redirect vers un prestataire mort laisse un trou ou un break.
- Retirer +all sans attendre le roman DMARC.
- Ne pas mettre -all le soir si l’inventaire n’est pas fait.
- Un seul TXT SPF (plusieurs TXT SPF = comportement imprévisible).
La limite des 10 lookups
Chaque include, a, mx, redirect compte (et les includes imbriqués aussi). Au-delà, SPF permerror : autant dire que ça ne marche plus. Les outils « SPF flatten » existent ; ils ont un coût de maintenance (IP qui bougent). Pour une PME, moins d’includes vaut mieux qu’un flatten magique oublié.
Après incident, on en profite pour jeter Mailchimp 2018, le include « partenaire SEO », le a: trop large. On descend sous 10 largement.
Un permerror soudain (quelqu’un a ajouté un include) explique des bounces « du jour au lendemain » sans nouveau spam. Lisez la zone avant de crier au FAI.
Inventaire : qui envoie vraiment
Mails du site (devis, form, Woo). Messagerie du nom (OVH, Microsoft 365, Google, Infomaniak). ESP newsletter. Outils (Factur-X, CRM, support). Imprimantes / scan. Relisez les journaux d’envoi et les RUA : les IP qui apparaissent sans include sont soit de l’abus, soit un oubli.
Le CMS qui passe par mail() de l’hébergeur : l’IP du mutualisé doit être couverte (souvent via include de l’hébergeur ou a:mx). Si vous basculez vers un SMTP authentifié, retirez le trop-plein ensuite.
Les sous-domaines : un SPF du apex ne couvre pas forcément boutique. ou mail. Chaque envelope domain a le sien. Voir séparer transactionnel.
Serrer sans casser OVH / Microsoft / Brevo
Gardez l’include officiel actuel de votre messagerie (la doc du jour, pas un forum 2016). Gardez l’ESP que vous utilisez encore. Retirez le reste. Documentez dans un fichier interne « SPF = ces 3 includes, revue le … ».
Microsoft et Google publient des includes qui en cachent d’autres : ça mange la limite. D’où l’intérêt de ne pas empiler trois ESP « au cas où ».
Un changement DNS : TTL, test, 24–48 h de RUA avant reject. Pas cinq éditions de zone dans la nuit.
Tester avant reject
Envoyez : un mail messagerie, un form site, un mail ESP, un Woo « commande » si boutique. Vérifiez l’authentification reçue (pas seulement « ça arrive »). Puis quarantine. Puis reject.
Orange / Free : testez-les (FAI). Un SPF parfait + domaine encore listé chez Orange = toujours le silence.
Les outils de « score SPF 10/10 » ne voient pas votre imprimante. L’inventaire humain, si.
SPF n’est pas le journal d’envoi
Un SPF serré n’arrête pas un script chez vous qui envoie avec un envelope aligné (il est « autorisé »). Couper le script d’abord. Le SPF serre le spoof et le voisin trop inclus, pas le PHP à la racine.
Inversement, un journal propre + SPF +all : le spoof continue. Les deux le même dossier.
Guide emails : source, listes, auth. Cet article est la ligne auth SPF.
Après : une revue à chaque nouvel outil
Un CRM « on a juste mis l’API » ajoute souvent un include. Ticket interne : qui touche le TXT. Registrar verrouillé, accès DNS limité.
Un include qui réapparaît : humain (agence) plus souvent que fantôme. Comme le wildcard DNS.
Créer un espace si le site envoie encore tout seul. La zone, un infogérant mail si elle est illisible. Page domaine blacklisté.