Dernière mise à jour : juillet 2026

En bref : Le mécanisme ptr dans un enregistrement SPF autorise les serveurs d’envoi en effectuant des recherches DNS inverses. Cependant, le RFC 7208 recommande expressément de ne plus le publier en raison d’une latence élevée, d’une fiabilité médiocre et d’une charge excessive sur les serveurs de noms racines.

Aux débuts du standard SPF (Sender Policy Framework), le mécanisme ptr semblait être un moyen pratique d’autoriser automatiquement tous les noms d’hôte appartenant à un domaine sans devoir inscrire en dur des adresses IP individuelles. Aujourd’hui, la spécification officielle du protocole déconseille vivement son utilisation.

Comment fonctionne le mécanisme ptr

Lorsqu’un enregistrement SPF inclut le mécanisme ptr :

v=spf1 ptr ~all

le serveur de messagerie destinataire exécute un processus de vérification DNS inverse en plusieurs étapes. Il prend l’adresse IP du serveur qui se connecte et interroge le DNS pour trouver son enregistrement PTR et récupérer le nom d’hôte. Ensuite, il effectue une recherche directe (A ou AAAA) sur ce nom d’hôte résolu pour vérifier que la liste d’adresses IP renvoyée contient l’adresse IP d’origine du serveur et que le nom d’hôte appartient bien au domaine interrogé.

Pourquoi le RFC 7208 déconseille ptr

La spécification du RFC 7208 indique expressément que ce mécanisme ne doit pas être publié (SHOULD NOT be published).

Le standard met en évidence plusieurs inconvénients opérationnels majeurs, reposant sur des années d’expérience de déploiement :

  1. Lent et peu fiable : Le mécanisme est lent, il est moins fiable que d’autres mécanismes en cas d’erreurs DNS, et il impose une lourde charge sur les serveurs de noms de la zone .arpa. Même un bref délai d’attente lors d’une recherche inverse peut faire échouer l’authentification d’un e-mail légitime.
  2. Contraintes de prérequis strictes : Si ce mécanisme est utilisé, des enregistrements PTR corrects doivent impérativement être en place pour les hôtes du domaine et le mécanisme ptr devrait être l’un des tout derniers mécanismes vérifiés.
  3. Alternatives supérieures disponibles : Après de nombreuses années d’expérience de déploiement SPF, il a été conclu que ptr n’est pas nécessaire et que des alternatives plus fiables doivent être utilisées à la place.

La limite des 10 requêtes DNS et l’erreur permerror

En plus des problèmes de latence et de fiabilité, le mécanisme ptr pèse lourdement sur ton budget de requêtes DNS. Le RFC 7208 définit que les mécanismes include, a, mx, ptr et exists, ainsi que le modificateur redirect, provoquent des requêtes DNS lors de l’évaluation.

Parce que les implémentations SPF doivent limiter le nombre total de ces termes à 10 requêtes au cours de l’évaluation, dépasser cette limite entraîne l’arrêt immédiat du traitement par le serveur destinataire et le renvoi d’un permerror (erreur permanente). Étant donné qu’une seule évaluation ptr déclenche plusieurs requêtes DNS sous-jacentes, s’y fier épuise rapidement ton budget. De plus, un domaine ne doit jamais publier plusieurs enregistrements SPF distincts, ce qui entraînerait également un permerror immédiat.

Alternatives fiables

Au lieu d’utiliser ptr, tu dois adopter des mécanismes directs et performants :

  • ip4 et ip6 : Si tu opères depuis des adresses IP dédiées ou des sous-réseaux statiques, les termes IP directs s’évaluent instantanément et sans aucune requête DNS.
  • include : Si tu délègues l’envoi de tes e-mails à des plateformes tierces externes, pointer vers leur enregistrement SPF dédié via include assure une autorisation propre et facile à maintenir.

Auditer ta configuration

Si des mécanismes ptr obsolètes subsistent dans tes enregistrements DNS, supprime-les et audite ton domaine avec le scanner gratuit MXAudit. Il met en évidence les termes dépréciés et compte avec précision tes requêtes par rapport à la limite de 10 requêtes DNS.

Pour en savoir plus sur la modernisation de ton architecture d’authentification ou la configuration d’hébergeurs spécifiques, explore le hub SPF et nos guides pratiques comme la configuration SPF chez IONOS.

Pour aller plus loin