C'est la panne la plus frustrante de la sécurité email, parce qu'elle survient au moment précis où vous essayez de bien faire. Vous découvrez un expéditeur légitime dans vos rapports DMARC, vous l'ajoutez consciencieusement à votre enregistrement SPF, et le lendemain une partie de votre courrier n'arrive plus. Rien n'a échoué visiblement. Vous avez juste franchi une limite dont personne ne vous avait parlé.
La règle, et pourquoi elle existe
La norme SPF impose un maximum de dix résolutions DNS pour évaluer un enregistrement. Au-delà, la vérification s'arrête et renvoie permerror.
La limite n'est pas arbitraire : sans elle, un enregistrement SPF malicieusement construit ferait exécuter des centaines de requêtes DNS au serveur destinataire pour chaque message reçu. C'est un mécanisme anti-amplification, et il n'est pas négociable.
Ce qui compte, et ce qui ne compte pas
C'est là que tout le monde se trompe. La limite ne porte pas sur le nombre de mécanismes écrits, mais sur les résolutions déclenchées.
| Mécanisme | Coût | Remarque |
|---|---|---|
include: | 1, plus le coût de l'inclus | Récursif : c'est là que ça explose |
a | 1 | |
mx | 1, plus une par serveur retourné | Sournois : dix serveurs, dix résolutions |
exists: | 1 | |
redirect= | 1, plus le coût de la cible | |
ip4: ip6: | 0 | Aucune résolution : c'est la porte de sortie |
all | 0 |
Le piège, c'est include:. Un include: vers un grand fournisseur de messagerie peut à lui seul en consommer trois ou quatre, parce qu'il inclut lui-même d'autres enregistrements. Trois prestataires de ce type, et vous êtes à la limite sans avoir écrit dix mécanismes.
Autre subtilité : les inclusions changent sans vous prévenir. Un fournisseur qui réorganise son infrastructure peut ajouter une inclusion dans son propre enregistrement. Votre SPF était à neuf hier, il est à onze aujourd'hui, et vous n'avez rien touché.
Comment savoir où vous en êtes
Comptez avant de modifier, pas après. Un outil de vérification SPF vous donne le total effectif en développant chaque inclusion. Retenez trois seuils :
- 8 ou moins : vous avez de la marge.
- 9 ou 10 : vous êtes en sursis. La prochaine réorganisation chez un fournisseur vous fait basculer.
- 11 ou plus : c'est déjà cassé. Vérifiez tout de suite si vos flux passent encore par DKIM.
Comment redescendre
Quatre leviers, dans l'ordre où nous les appliquons.
1. Retirer ce qui n'envoie plus
Le levier le plus rentable, et celui qu'on saute toujours. Sur un enregistrement accumulé depuis des années, un tiers des inclusions concerne des services qui n'envoient plus rien. Les rapports DMARC le disent : une source qui n'apparaît dans aucun rapport depuis trois mois n'a plus rien à faire dans votre SPF.
2. Basculer sur DKIM plutôt que SPF
Le vrai correctif de fond. Un prestataire qui signe vos messages en DKIM avec votre domaine n'a plus besoin de figurer dans votre SPF : DMARC passe dès qu'un des deux mécanismes s'aligne.
C'est le seul levier qui traite la cause. Les trois autres repoussent l'échéance.
3. Remplacer une inclusion par ses adresses IP
ip4: ne coûte aucune résolution. Un prestataire dont l'infrastructure est stable et documentée peut être transcrit directement en plages d'adresses.
4. Séparer les domaines d'envoi
L'approche structurelle, et la seule qui tienne à l'échelle. Le marketing envoie depuis news.votre-domaine.fr, les notifications applicatives depuis app.votre-domaine.fr, le courrier humain depuis le domaine principal.
Chaque sous-domaine a son propre enregistrement, donc ses propres dix résolutions. Le bénéfice dépasse la limite technique : une campagne marketing mal notée n'entache plus la réputation du domaine qui porte vos échanges commerciaux.
L'erreur à ne pas commettre
Ne remplacez jamais votre -all par ~all ou ?all pour « faire passer » le courrier. Vous ne réparez rien : vous annoncez publiquement que n'importe qui peut envoyer en votre nom. Le permerror reste, et vous avez renoncé à la protection en prime.