Un email de réinitialisation de mot de passe part. Il n’arrive jamais. Pas de message d’erreur côté expéditeur, pas de bounce, pas d’alerte dans votre outil d’envoi. Juste le silence. Dans une partie des cas, la cause est un enregistrement SPF qui a dépassé sa limite de 10 requêtes DNS, sans que personne dans l’organisation ne s’en soit rendu compte. C’est ce qu’on appelle un PermError. Il survient bien plus souvent qu’on ne le croit dans les entreprises qui utilisent plusieurs services SaaS pour leurs envois.
Ce qu’est la limite SPF et pourquoi elle existe
Le SPF (Sender Policy Framework) est un protocole d’authentification email qui permet à un domaine de déclarer quels serveurs sont autorisés à envoyer en son nom. La limite de 10 lookups DNS par vérification SPF est inscrite dans la RFC 7208 (IETF, 2014), la spécification officielle du protocole. Elle n’est pas optionnelle : la RFC stipule qu’une implémentation SPF doit retourner une erreur permanente si ce seuil est dépassé.
La raison technique est concrète. Chaque mécanisme SPF de type include:, a, mx, ptr ou exists déclenche une requête DNS supplémentaire. Sans plafond, une règle SPF malveillante ou mal configurée pourrait forcer les serveurs de réception à enchaîner des dizaines de requêtes DNS, créant une charge excessive sur les résolveurs récursifs et ouvrant la porte à des attaques par déni de service. Les mécanismes ip4:, ip6: et all ne déclenchent aucune requête et ne comptent pas dans la limite.
Ce plafond date de l’époque où une entreprise avait rarement plus d’un ou deux prestataires d’envoi email. En 2014, Microsoft 365 n’existait pas sous ce nom, Salesforce Marketing Cloud s’appelait encore Exact Target et HubSpot ne représentait qu’une fraction de son usage actuel. La limite a été pensée pour un monde qui n’est plus le nôtre.
Pourquoi les entreprises SaaS d’aujourd’hui atteignent cette limite sans s’en apercevoir
Le problème tient à la façon dont les services email modernes publient leurs propres enregistrements SPF. Un include: vers un prestataire ne coûte pas un seul lookup : il en coûte autant que le prestataire en a défini dans son propre enregistrement, inclusions imbriquées comprises. Google Workspace (_spf.google.com) consomme entre 3 et 5 lookups à lui seul. Microsoft 365 (spf.protection.outlook.com) en consomme 3 à 5 selon la configuration régionale. Ajoutez SendGrid (1 à 3), Salesforce (1 à 3) et HubSpot (1 à 2) : le total dépasse 10 avant même d’avoir ajouté le service de facturation, la plateforme RH ou l’outil de support.
Ce qui aggrave la situation : les prestataires peuvent modifier leur infrastructure DNS sans vous prévenir. Le service auquel vous avez délégué un include: il y a six mois peut avoir ajouté de nouveaux serveurs entre-temps, faisant passer votre décompte de 9 à 12 lookups sans aucune action de votre côté. Selon les données de dmarcchecker.app portant sur le top 1 million de domaines (2024), 2% des domaines ayant un enregistrement SPF valide ont déjà une configuration invalide causant une PermError. Ce chiffre paraît faible mais représente des milliers d’organisations dont les emails légitimes sont affectés en permanence, souvent sans que les équipes IT le sachent.
Ce qui se passe concrètement quand le seuil est dépassé
Quand une vérification SPF atteint 11 requêtes DNS, le serveur de réception retourne un résultat permerror, une erreur permanente non récupérable. Ce que devient l’email dépend ensuite de la politique DMARC configurée sur le domaine expéditeur.
Avec p=none, l’email est généralement livré malgré le PermError. Le domaine est traité comme non authentifié. C’est une fausse tranquillité : les emails passent. La protection contre l’usurpation du domaine n’existe pas. Avec p=quarantine, les emails atterrissent en spam, sans alerte côté expéditeur. Avec p=reject, la politique la plus stricte et celle que Google et Yahoo exigent depuis février 2024 pour les expéditeurs de plus de 5000 messages par jour, les e-mails sont rejetés. Confirmations de commande, réinitialisations de mot de passe, alertes de sécurité et communications internes disparaissent sans laisser de trace dans les outils d’envoi.
C’est le scénario le plus difficile à diagnostiquer. L’email part. Il ne revient pas. Il n’arrive pas.
Le SPF flattening : pourquoi la solution rapide empire les choses
La réaction la plus courante face à ce problème est le « flattening » SPF : on remplace tous les mécanismes include: par les adresses IP correspondantes, ce qui ramène le nombre de lookups à zéro ou presque. Le résultat immédiat est positif. Les effets à moyen terme sont plus problématiques.
Le CTO de dmarcian résume bien le problème de fond : la plupart des enregistrements flattés finissent par autoriser des plages d’adresses IP bien trop larges, appartenant aux grands hébergeurs cloud, dont une partie ne correspond à aucun serveur d’envoi réel du prestataire. Des acteurs malveillants peuvent exploiter ces plages autorisées pour envoyer depuis votre domaine. On résout un problème de délivrabilité en créant un problème de sécurité.
L’autre difficulté est la maintenance. Les prestataires email changent leurs pools d’IP régulièrement, sans préavis. Un enregistrement flatté doit être mis à jour manuellement à chaque modification, sinon les nouveaux serveurs du prestataire se retrouvent exclus et les emails qu’ils traitent échouent l’authentification SPF. Le flattening convertit un problème de configuration en charge opérationnelle permanente.
Les approches qui tiennent sur la durée
La première étape est un audit du décompte réel. Des outils comme MXToolbox, le SPF Record Checker de dmarcian analysent votre enregistrement SPF et comptent les lookups en cascade, inclusions imbriquées comprises. Sans cet audit, il est impossible de savoir où en est réellement le compteur.
La segmentation par sous-domaines est la solution architecturale la plus fiable. Déplacer les emails marketing sur marketing.votredomaine.com et les emails transactionnels sur notifications.votredomaine.com donne à chaque sous-domaine son propre quota de 10 lookups. Cette séparation a un avantage supplémentaire : un problème de réputation sur les campagnes marketing n’affecte pas les emails transactionnels critiques.
Pour les domaines qui ne peuvent pas facilement segmenter, les macros SPF sont une alternative sérieuse. Elles déplacent l’évaluation hors de la chaîne de lookups standard, en passant la vérification à un service externe via une requête DNS unique. Des solutions fonctionnent sur ce principe. Le revers est réel : si l’infrastructure du prestataire tombe, l’authentification SPF du domaine tombe avec elle.
La mesure la plus souvent négligée reste la suppression des entrées devenues inutiles. Beaucoup d’enregistrements SPF accumulent des include: vers des prestataires que l’entreprise n’utilise plus depuis des mois ou des mécanismes a et mx hérités d’une configuration ancienne. Un audit annuel récupère souvent plusieurs lookups sans toucher à l’architecture d’envoi.
Surveiller dans le temps, pas seulement corriger une fois
Un enregistrement SPF conforme aujourd’hui peut franchir le seuil demain si un prestataire modifie son infrastructure. Les rapports DMARC agrégés (format RUA) sont l’indicateur le plus accessible : ils montrent la proportion d’emails qui passent ou échouent l’authentification SPF pour chaque domaine expéditeur déclaré. Tout pic soudain d’échecs SPF mérite une investigation immédiate sur le décompte de lookups.
La limite des 10 lookups SPF est une contrainte de 2014 que la RFC 7208 n’a pas révisée depuis. Les organisations qui basculent vers DMARC en mode enforcement, comme Google l’exige depuis 2024 pour les expéditeurs de volume, la découvrent parfois au pire moment : quand leurs emails critiques cessent d’arriver et que personne ne sait pourquoi.
Qu’est-ce qu’un PermError SPF ?
Un PermError SPF est une erreur permanente retournée par le serveur de réception quand la vérification SPF ne peut pas être complétée, notamment parce que le nombre de requêtes DNS dépasse 10. Contrairement à un TempError (erreur temporaire récupérable), un PermError persiste jusqu’à correction de l’enregistrement SPF. DMARC traite un PermError comme un échec SPF à part entière.
Les mécanismes ip4 et ip6 comptent-ils dans la limite des 10 lookups ?
Non. Les mécanismes ip4:, ip6: et all ne déclenchent aucune requête DNS et ne comptent pas dans la limite. Seuls les mécanismes qui nécessitent une résolution DNS sont comptabilisés : include:, a, mx, ptr, exists et le modificateur redirect.
Comment savoir si mon enregistrement SPF dépasse la limite ?
Des outils comme MXToolbox SPF Checker, le vérificateur de domaine de dmarcian analysent l’enregistrement SPF et comptent les lookups DNS en cascade, inclusions imbriquées comprises. Un résultat supérieur à 10 confirme que l’enregistrement retourne un PermError à chaque vérification, quelle que soit la politique DMARC en place.
