Dernière mise à jour : juillet 2026

En bref : Les mécanismes ip4 et ip6 autorisent des adresses IP individuelles ou des sous-réseaux CIDR entiers directement au sein de ton enregistrement SPF. Leur plus grand avantage architectural : ils ne consomment aucune requête DNS lors de l’évaluation.

Si tes serveurs de messagerie fonctionnent sur des adresses IPv4 ou IPv6 dédiées, ou si ton infrastructure d’hébergement t’a attribué des sous-réseaux statiques spécifiques, les déclarer via ip4 et ip6 est la méthode la plus propre et la plus fiable pour les autoriser dans ton enregistrement SPF (Sender Policy Framework).

Comment opèrent les mécanismes ip4 et ip6

Selon le RFC 7208, ces mécanismes vérifient si l’adresse IP du serveur de messagerie qui se connecte (<ip>) est contenue dans un réseau IP donné. Parce que la plage réseau est inscrite en dur directement dans la chaîne TXT, le serveur de messagerie destinataire évalue la correspondance IP directement en mémoire sans lancer la moindre requête réseau externe.

Tu peux spécifier des blocs réseau CIDR individuels :

v=spf1 ip4:192.0.2.0/24 -all

Ou combiner des adresses IP uniques à la fois en IPv4 et en IPv6 :

v=spf1 ip4:192.0.2.10 ip6:2001:db8::/32 -all

Longueurs de préfixe CIDR par défaut en cas d’omission

Si tu n’ajoutes pas de barre oblique suivie d’un préfixe réseau CIDR après l’adresse IP, le standard SPF applique automatiquement des valeurs par défaut. Selon le RFC 7208, si ip4-cidr-length est omis, la valeur par défaut est /32 (correspondant exactement à une seule adresse IPv4). Si ip6-cidr-length est omis, la valeur par défaut est /128 (correspondant exactement à une seule adresse IPv6).

Écrire ip4:192.0.2.10 est donc fonctionnellement identique à écrire ip4:192.0.2.10/32.

Zéro requête DNS : l’atout performance majeur

Le principal avantage opérationnel de ip4 et ip6 réside dans la vitesse d’évaluation et l’économie de requêtes DNS. Le RFC 7208 établit explicitement que les mécanismes all, ip4 et ip6, ainsi que le modificateur exp, ne provoquent aucune requête DNS au moment de l’évaluation SPF. Par conséquent, leur utilisation n’est pas soumise à la limite stricte de 10 requêtes DNS par contrôle d’authentification.

Tandis que des mécanismes comme include, a et mx obligent le serveur destinataire à effectuer des requêtes DNS externes — consommant du temps et imputant ton budget des 10 requêtes — les termes ip4 et ip6 s’évaluent instantanément. Les organisations exploitant des serveurs dédiés ou des infrastructures cloud statiques peuvent fréquemment remplacer de profondes chaînes de include par des plages IP directes, éliminant ainsi le risque de permerror (erreur permanente).

Rappelle-toi toutefois qu’un domaine ne doit jamais publier plusieurs enregistrements SPF distincts. Publier plus d’un enregistrement pour un seul nom de domaine déclenche immédiatement un permerror lors de l’évaluation, quel que soit le nombre de termes ip4 ou ip6 utilisés.

Vérifier ta configuration

Pour confirmer que toutes tes notations de réseau IP sont syntaxiquement valides et que ton enregistrement s’évalue proprement, teste ton domaine à l’aide du scanner gratuit MXAudit. Il détaille la structure exacte de tes mécanismes et confirme quels termes s’évaluent sans requête DNS par rapport à ceux qui en consomment.

Pour des conseils architecturaux complets ou des instructions selon ton panneau de contrôle, consulte le hub SPF et suis nos guides pratiques comme la configuration SPF chez IONOS.

Pour aller plus loin