SkyQon SkyQon
Demander une démo
English Français Deutsch Nederlands
Authentification e-mail · SPF

Trop de recherches DNS dans le SPF : pourquoi le courrier échoue et comment corriger

Dernière vérification le 11 novembre 2026 · Rédigé par l'équipe d'ingénierie SkyQon

La réponse courte

Le SPF autorise un destinataire à effectuer au plus 10 recherches DNS pendant qu'il vérifie votre enregistrement (RFC 7208, section 4.6.4). Chaque terme include, a, mx, ptr et exists compte, tout comme redirect, y compris ceux qui se trouvent dans les enregistrements de vos fournisseurs. À 11, la vérification s'arrête sur une PermError, le SPF échoue pour chaque message, et DMARC ne repose alors plus que sur DKIM.

Le calcul, sur un seul enregistrement

Une entreprise fictive, example.com, envoie du courrier via Microsoft 365 et un service d'assistance Freshdesk. Il y a des années, quelqu'un a aussi ajouté SendGrid. L'enregistrement compte cinq termes et semble inoffensif :

v=spf1 mx include:spf.protection.outlook.com include:email.freshdesk.com include:sendgrid.net -all
TermeCe que le destinataire doit rechercherRecherches
mxLes hôtes de messagerie du domaine.1
include:spf.protection.outlook.comMicrosoft 365. Son enregistrement ne liste que des adresses.1
include:email.freshdesk.comFreshdesk. Son enregistrement inclut SendGrid (2) et quatre enregistrements Freshdesk régionaux (1 chacun).7
include:sendgrid.netSendGrid. Son enregistrement inclut un enregistrement supplémentaire qui lui est propre.2
-allFaire échouer tout le reste. Aucune recherche.0
Total, pour une limite de 1011 : PermError

Deux modifications ramènent le total à 8. Les adresses de SendGrid arrivent déjà via l'enregistrement de Freshdesk : l'include séparé coûte donc 2 recherches et n'ajoute aucune adresse. Si le courrier ne sort que par Microsoft 365, le terme mx n'apporte rien non plus. 11 − 2 − 1 = 8, avec de la place pour un fournisseur de plus.

Coûts des fournisseurs mesurés le 11 novembre 2026 sur le DNS public. Les fournisseurs modifient leurs propres enregistrements sans préavis : c'est pourquoi le vérificateur les lit en direct plutôt que dans une liste.

Ce qui casse, et qui s'en aperçoit

  • Le destinataire s'arrête à la onzième recherche. Le résultat est une PermError, une erreur permanente. Il ne lit pas le reste de votre enregistrement : même vos serveurs Microsoft 365 ne sont plus reconnus. RFC 7208 §4.6.4
  • La plupart des destinataires traitent une PermError comme un échec. Ce qu'ils en font leur appartient : dossier spam, refus ou score de réputation abaissé. Aucun ne vous prévient. RFC 7208 §8.7
  • DMARC perd sa moitié SPF. DMARC réussit quand SPF ou DKIM réussit et correspond à votre domaine From. Avec un SPF cassé, chaque message qui n'est pas signé DKIM pour votre domaine échoue à DMARC et, sous p=quarantine ou p=reject, il est filtré ou refusé. RFC 7489 §3.1
  • Cela peut casser sans que vous ne changiez rien. Les recherches contenues dans l'enregistrement d'un fournisseur sont modifiables par ce fournisseur. Un enregistrement à 9 aujourd'hui atteint 11 le jour où un fournisseur ajoute une région.
  • Vous êtes le dernier informé. Aucun destinataire ne vous envoie d'e-mail pour une PermError. Vos rapports agrégés DMARC la montrent un jour plus tard, si quelqu'un les lit.

Comptez votre propre enregistrement

Le vérificateur SPF gratuit dessine votre arbre d'include avec le coût de chaque branche : vous voyez quel fournisseur consomme vos recherches.

Gratuit, sans compte. Nous lisons uniquement le DNS public et ce que vos serveurs montrent à quiconque s'y connecte.

Corriger, étape par étape

  1. Listez ce qui envoie réellement du courrier au nom de votre domaine

    Lisez vos rapports agrégés DMARC, ou interrogez chaque équipe : assistance, CRM, facturation, newsletters. Un include pour un service que plus personne n'utilise est une recherche que vous récupérez gratuitement.

  2. Comptez chaque branche, pas seulement vos propres termes

    Lancez le vérificateur SPF. Il suit chaque include jusqu'au dernier enregistrement et montre ce que coûte chacun. Commencez par la branche la plus coûteuse.

  3. Supprimez les doublons et les entrées mortes

    Retirez les include de services que vous avez quittés, les include déjà contenus dans l'enregistrement d'un autre fournisseur, et les termes mx ou a pour des hôtes qui n'envoient jamais de courrier. Retirez ptr dans tous les cas : RFC 7208 indique qu'il SHOULD NOT être utilisé (§5.5).

  4. Déplacez les envois en masse vers un sous-domaine

    Envoyez les newsletters avec un return-path sur un sous-domaine tel que news.example.com, doté de son propre enregistrement SPF. Ce nom dispose de son propre budget de 10 recherches et, avec l'alignement relâché par défaut de DMARC, il correspond toujours au courrier d'example.com.

  5. Listez vos propres serveurs fixes par adresse

    Un serveur que vous exploitez, avec une adresse fixe, peut être listé en ip4: ou ip6:. Ces termes ne coûtent rien. Ne copiez pas ainsi les adresses d'un fournisseur : les fournisseurs les modifient sans vous prévenir.

  6. Contrôlez à nouveau, puis continuez à surveiller

    Contrôlez une fois de plus après la propagation de la modification DNS. Laissez ensuite SkyQon surveiller le domaine : il vous alerte à 9 ou 10 recherches, avant qu'une modification chez un fournisseur ne vous fasse dépasser la limite.

Erreurs fréquentes

Ne compter que les include visibles

Cinq termes semblent sans risque. La limite s'applique à tout l'arbre, et le seul include de Freshdesk coûte à lui seul 7 aujourd'hui.

Dans le résultat SkyQon : chaque include affiche son propre sous-total, et la branche la plus coûteuse est signalée.

Croire qu'un include répété est gratuit

Si deux fournisseurs incluent le même enregistrement, le destinataire le recherche deux fois et les deux comptent. RFC 7208 ne prévoit aucune déduplication.

Dans le résultat SkyQon : un include répété apparaît dans chaque branche qui l'utilise, à chaque fois avec son coût.

Copier les adresses d'un fournisseur dans votre enregistrement

Cela réduit le décompte aujourd'hui. Quand le fournisseur ajoute un serveur, votre copie l'ignore, et son courrier échoue à votre SPF sans aucune erreur nulle part. Un service SPF hébergé qui réécrit votre enregistrement a la même faiblesse en sens inverse : son include se trouve dans votre enregistrement, et si ce service s'arrête, votre authentification e-mail s'arrête aussi.

Dans le résultat SkyQon : les termes ip4 et ip6 coûtent 0 dans l'arbre. Le vérificateur ne peut pas savoir si une plage copiée appartient toujours au fournisseur : c'est pourquoi nous déconseillons de copier.

Ajouter un second enregistrement SPF pour un nouveau fournisseur

Deux enregistrements TXT commençant par v=spf1 constituent à eux seuls une PermError, quel que soit le décompte (RFC 7208 §3.2). Ajoutez le nouvel include à votre unique enregistrement.

Dans le résultat SkyQon : un constat d'enregistrements multiples, avec les deux enregistrements affichés.

Ce que SkyQon fait et ne fait pas

Ce que ça trouve

Votre enregistrement SPF et chaque enregistrement qu'il inclut, avec les recherches que coûte chaque branche. Également : plus d'un enregistrement SPF, une valeur d'exemple telle que <ip> laissée dans l'enregistrement, plus de deux recherches vides, et un all qui laisse tout le monde envoyer.

Ce que vous obtenez

Le décompte par rapport à la limite de 10, la branche à couper en premier, votre enregistrement dans un encadré à copier et, sur un domaine surveillé, une alerte à 9 ou 10 recherches et une autre au-delà de 10.

Ce que ce n’est pas

Nous n'hébergeons ni ne réécrivons votre enregistrement SPF. Votre SPF reste le vôtre : aucun include SkyQon à l'intérieur, et rien qui cesse de fonctionner si vous nous quittez.

Recherches SPF : les questions fréquentes

Quels termes SPF comptent dans la limite de 10 recherches ?
include, a, mx, ptr et exists, plus le modificateur redirect. ip4, ip6, all et exp ne coûtent rien. Le qualificatif et un suffixe CIDR ne changent rien : ~include, +a et a/24 coûtent chacun 1.
Les recherches à l'intérieur d'un include comptent-elles ?
Oui. Le destinataire suit chaque include jusqu'au bout, et chaque terme de recherche de chaque enregistrement qu'il atteint compte dans le même budget de 10. C'est ainsi qu'un seul include peut coûter 7.
La limite s'applique-t-elle par enregistrement ou par message ?
Par vérification SPF : une évaluation de votre enregistrement pour un message, avec tout ce qu'elle entraîne. Un sous-domaine doté de son propre enregistrement repart de 0.
Qu'est-ce qu'une recherche vide ?
Une recherche qui ne renvoie aucune réponse, ou une réponse indiquant que le nom n'existe pas. RFC 7208 indique que les destinataires devraient en autoriser au plus deux par vérification ; au-delà, c'est une PermError. La cause habituelle est un include qui pointe vers un enregistrement de fournisseur supprimé.
Le terme mx coûte-t-il plus d'une recherche ?
Il coûte 1 dans la limite de 10. Les recherches d'adresses des hôtes de messagerie qu'il renvoie ne comptent pas dans les 10, mais il ne peut pas y en avoir plus de 10, sinon le terme mx lui-même renvoie une PermError.
Un sous-domaine hérite-t-il de mon enregistrement SPF ?
Non. Le SPF est vérifié sur le domaine exact de l'expéditeur d'enveloppe, ou sur le nom HELO du serveur. Un sous-domaine qui envoie du courrier a besoin de son propre enregistrement. Un sous-domaine qui n'en envoie jamais devrait publier v=spf1 -all pour que personne d'autre ne puisse l'utiliser.
Pourquoi SkyQon n'aplatit-il pas mon enregistrement SPF ?
L'aplatissement remplace les include par les adresses actuelles du fournisseur. Le décompte baisse jusqu'à ce que le fournisseur change une adresse, puis le courrier échoue sans avertissement. Le SPF hébergé ou dynamique évite cela en plaçant l'include de la société d'hébergement dans votre enregistrement : votre authentification e-mail dépend alors de cette société. Nous comptons, expliquons et alertons à la place, et l'enregistrement reste le vôtre.
À quelle fréquence SkyQon refait-il le décompte ?
Sur un domaine surveillé, chaque analyse refait le décompte de tout l'arbre. Le plan Free surveille jusqu'à 5 domaines et vous alerte à 9 ou 10 recherches, puis à nouveau au-delà de 10. Le vérificateur de cette page est un décompte ponctuel que vous pouvez lancer à tout moment.
Mon décompte diffère de celui d'un autre outil. Lequel a raison ?
Les outils diffèrent sur deux points : le fait de compter un include répété à chaque fois (RFC 7208 compte chaque évaluation, et nous aussi), et ce qui se passe quand une branche ne peut pas être lue. Si un serveur DNS ne répond pas, nous marquons le décompte comme incomplet au lieu de deviner.
Corriger le SPF corrige-t-il DMARC ?
Seulement la moitié SPF. DMARC réussit quand SPF ou DKIM réussit et correspond à votre domaine From. Une signature DKIM avec votre propre domaine permet au courrier de continuer à réussir DMARC même un jour où le SPF échoue : mettez donc en place les deux.

Sources

Pages associées

Soyez prévenu à 9, pas après 11.

Ajoutez votre domaine au plan Free. SkyQon refait le décompte de votre arbre SPF à chaque analyse et vous alerte avant qu'une modification chez un fournisseur ne vous fasse dépasser la limite.

Surveiller mon domaine gratuitement Ouvrir le vérificateur SPF