Dernière mise à jour : juillet 2026

En bref : Le mécanisme exists dans un enregistrement SPF construit dynamiquement un nom de domaine (souvent en insérant des macros comme l’adresse IP de connexion) et effectue une requête DNS de type A. Il permet des politiques d’autorisation complexes et personnalisées.

Alors que les sites web standards autorisent généralement les expéditeurs via des blocs IP directs (ip4) ou des références externes tierces (include), les grands fournisseurs de messagerie et les passerelles de sécurité exigent souvent des règles d’autorisation dynamiques basées sur les détails du client ou les paramètres de l’enveloppe e-mail. Le standard SPF (Sender Policy Framework) propose le mécanisme exists spécifiquement pour gérer ces architectures avancées.

Comment fonctionne le mécanisme exists

Selon le RFC 7208, le mécanisme exists sert à construire un nom de domaine arbitraire utilisé pour une requête DNS d’enregistrement A. Le mécanisme correspond (pass) si la recherche DNS pour le domaine construit renvoie au moins un enregistrement A valide (par exemple 127.0.0.2). Si la requête renvoie NXDOMAIN (aucun enregistrement trouvé), le mécanisme ne correspond pas et l’évaluation passe au terme suivant.

La véritable puissance de exists repose sur l’expansion des macros SPF. Un déploiement classique utilise la macro %{i}, qui est dynamiquement remplacée par l’adresse IP du serveur de connexion lors de l’évaluation :

v=spf1 exists:%{i}._spf.example.com -all

Si un serveur de messagerie avec l’IP 192.0.2.10 tente de livrer un message, le serveur destinataire construit 192.0.2.10._spf.example.com et cherche un enregistrement A. Si un enregistrement A existe, la vérification réussit. Cette architecture permet aux fournisseurs de gérer des millions d’adresses IP autorisées sur des zones DNS ultra-rapides sans modifier l’enregistrement TXT du domaine.

Schémas complexes basés sur les données d’enveloppe

D’après le RFC 7208, le mécanisme exists permet des schémas complexes impliquant des parties arbitraires de l’enveloppe e-mail pour déterminer ce qui est autorisé.

En plus de l’adresse IP de connexion (%{i}), les administrateurs de domaine peuvent intégrer l’adresse e-mail de l’expéditeur (%{s}), la partie locale (%{l}) ou la partie domaine (%{o}) directement dans le nom d’hôte interrogé. Un serveur de noms faisant autorité personnalisé peut alors évaluer des permissions granulaires précises, vérifiant si cette IP spécifique est autorisée pour cette adresse expéditrice précise.

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

Parce que le mécanisme exists effectue une requête DNS en direct chaque fois qu’un e-mail est évalué, il consomme ton budget de requêtes DNS. Le RFC 7208 spécifie que les mécanismes include, a, mx, ptr et exists, ainsi que le modificateur redirect, provoquent des requêtes DNS lors de l’évaluation.

Les implémentations SPF doivent strictement limiter le nombre total de ces termes à 10 requêtes au cours de l’évaluation afin d’éviter une surcharge excessive sur le système de noms de domaine (DNS). Dépasser cette limite amène le serveur destinataire à interrompre le traitement et à renvoyer un permerror (erreur permanente), ce qui entraîne fréquemment le rejet de l’e-mail ou son classement en spam. Par ailleurs, un domaine ne doit jamais publier plusieurs enregistrements SPF distincts, ce qui déclenche également un permerror immédiat.

Vérifier ta configuration

Pour t’assurer que tes expressions exists dynamiques se résolvent correctement et respectent le budget des 10 requêtes, audite ton domaine avec le scanner gratuit MXAudit. Il simule l’expansion des macros et met en évidence les goulots d’étranglement de syntaxe et de requêtes.

Pour une documentation complète sur les configurations d’authentification et des guides par fournisseur, consulte le hub SPF et suis nos tutoriels pratiques comme la configuration SPF chez IONOS.

Pour aller plus loin