Qu'est-ce que le mécanisme SPF ptr — et pourquoi figure-t-il encore dans 950 631 enregistrements ? (2026)

Publié 2026-07-03

Chiffres au 2026-06-29 · méthodologie v7. Recensement agrégé portant sur 261 millions de domaines notés. Tous les chiffres sont agrégés — jamais l’enregistrement d’une entreprise en particulier. Voir comment nous notons.

ptr est un mécanisme SPF qui autorise des expéditeurs au moyen d’une requête DNS inverse — et la norme SPF elle-même dit « ne l’utilisez pas » depuis 2014. 12 ans plus tard, 950 631 domaines le publient encore. Cela représente environ 1 sur 146 des 139 millions d’enregistrements SPF présents sur Internet portant un mécanisme que la spécification a déprécié avant même que certains de ces domaines ne soient enregistrés.

Ce que ptr était censé faire

ptr dit : « accepte le courrier de tout serveur dont le DNS inverse renvoie vers mon domaine ». Cela semble élégant — aucune liste d’adresses IP à maintenir. En pratique, cela oblige le destinataire à effectuer une requête inverse sur l’adresse IP qui se connecte, puis à confirmer par requête directe chaque nom d’hôte renvoyé. La RFC 7208 (§5.5) l’a déprécié en termes clairs : le mécanisme est « lent, moins fiable que d’autres mécanismes en cas d’erreurs DNS, et impose une lourde charge de ressources sur les serveurs de noms .arpa » — et indique qu’il « NE DEVRAIT PAS être utilisé ».

Pourquoi c’est encore un piège en 2026

Trois raisons pour lesquelles un mécanisme déprécié il y a 12 ans compte toujours :

Il consomme votre budget de requêtes. Chaque ptr compte dans le plafond strict de SPF de 10 requêtes DNS par vérification — la limite qui, une fois dépassée, invalide l’enregistrement entier avec une PermError. Un mécanisme qui ne fait rien de fiable vous coûte quand même le budget dont vos vrais mécanismes include: ont besoin.
Il échoue de façon imprévisible. Le DNS inverse est le coin le moins bien entretenu de la plupart des réseaux. Lorsque la requête ptr expire ou que la confirmation directe échoue, votre courrier légitime perd la validation SPF sur laquelle il comptait.
Certains destinataires l’ignorent entièrement. Parce que la norme le déprécie, certaines implémentations ignorent tout simplement ptr — de sorte que les expéditeurs qu’il était censé autoriser n’ont jamais été protégés au départ.

D’où il vient

Presque personne ne choisit ptr aujourd’hui. Il arrive par héritage : un guide de configuration rédigé en 2009, un modèle copié d’une ancienne configuration serveur, un enregistrement « qui fonctionne » migré intact à travers trois changements d’hébergement. C’est le schéma que notre recensement observe pour chaque mécanisme déprécié-mais-présent : les vieux conseils ne meurent pas, ils sont copiés-collés. Les domaines portant ptr ne sont pas négligents — ils suivent des instructions qui ont été retirées il y a 12 ans.

Comment le corriger — gratuit, cinq minutes

Trouvez votre enregistrement SPF (dig TXT votredomaine.com ou vérifiez gratuitement).
S’il contient ptr, identifiez quels serveurs s’appuyaient dessus.
Remplacez le ptr par la forme précise : un bloc ip4:/ip6: pour les serveurs que vous contrôlez, ou l’include: documenté par votre fournisseur.
Pendant que vous y êtes, vérifiez que l’enregistrement se termine par un vrai qualificateur — voir ~all vs -all.

Foire aux questions

Que signifie ptr dans un enregistrement SPF ? Il autorise tout serveur dont le DNS inverse renvoie vers votre domaine. La RFC 7208 §5.5 l’a déprécié en 2014 comme lent et peu fiable, et indique qu’il NE DEVRAIT PAS être utilisé — pourtant 950 631 domaines le publient encore au 2026-06-29.

Le mécanisme SPF ptr est-il jamais valide ? Il s’analyse encore, et certains destinataires l’évaluent toujours — mais la norme le déconseille dans tous les cas, certains destinataires l’ignorent, et il dépense l’une de vos dix requêtes DNS. Il n’existe aucune configuration moderne où ptr est la bonne réponse.

Que devrais-je utiliser à la place de ptr ? Des blocs ip4:/ip6: pour les serveurs que vous contrôlez, ou l’include: documenté par votre fournisseur. Les deux sont déterministes, rapides et fiables — tout ce que ptr n’est pas.

Est-ce que ptr compte dans la limite de 10 requêtes SPF ? Oui — chaque ptr coûte au moins une des dix requêtes DNS qu’un destinataire effectuera avant d’abandonner avec une PermError. Sur des enregistrements déjà chargés de mécanismes include:, le mécanisme mort peut être celui qui vous fait dépasser la limite.

Vérifiez votre enregistrement à la recherche de fantômes

Un mécanisme déprécié il y a 12 ans, toujours présent dans votre DNS, est exactement le genre de chose que personne ne cherche. La recherche prend une demi-minute.

Vérifiez votre domaine → · Corriger SPF → · Deux enregistrements SPF = aucun → · Le modèle de maturité SPF → · Données agrégées uniquement. Données stockées et traitées dans l’UE.

Qu'est-ce que le mécanisme SPF ptr — et pourquoi figure-t-il encore dans 950 631 enregistrements ? (2026)