Dernière mise à jour : juillet 2026

En bref : après ce guide, ton domaine publie un enregistrement SPF correct. Les serveurs de messagerie destinataires peuvent alors reconnaître quels serveurs sont autorisés à envoyer en ton nom — et écarter les expéditeurs falsifiés.

Ce guide s’applique à l’hébergement web Netcup. Sur les vServeurs et serveurs root, tu exploites ton propre serveur de messagerie — là, tu écris l’enregistrement SPF pour qu’il corresponde à ta propre infrastructure.

Prérequis

Qu’est-ce que SPF ?

SPF (Sender Policy Framework) est un enregistrement TXT dans le DNS de ton domaine. Il liste les serveurs de messagerie autorisés à envoyer des e-mails avec ton domaine comme expéditeur. Les serveurs destinataires consultent l’enregistrement à chaque message entrant et vérifient si le serveur qui livre le message figure sur la liste. Sans SPF, n’importe quel serveur peut envoyer des e-mails au nom de ton domaine — et tes e-mails légitimes finissent plus vite dans les spams, car les grands destinataires comme Gmail attendent désormais tout simplement SPF.

Pour situer les choses : SPF seul n’est pas une protection complète. Ce n’est qu’associé à DKIM et DMARC qu’il devient une base solide. Mais SPF est le point d’entrée le plus simple.

Le point de départ chez Netcup

Dans le CCP, il n’y a pas de type d’enregistrement SPF dédié — SPF est un enregistrement TXT ordinaire sur l’hôte @. Pour l’hébergement web, Netcup documente exactement cette valeur :

v=spf1 mx a include:_spf.webhosting.systems ~all

Selon Netcup, l’enregistrement autorise le serveur derrière ton enregistrement A, les serveurs derrière ton enregistrement MX et le relais de messagerie Netcup. Note la réserve de Netcup : l’enregistrement ne fonctionne comme prévu que si les paramètres DNS par défaut sont utilisés et que les e-mails sont envoyés exclusivement via les serveurs de messagerie du produit — l’envoi via le serveur web (par ex. phpmail ou sendmail) ou via des serveurs de messagerie externes n’est explicitement pas couvert.

Guide étape par étape

1. Vérifier si SPF est déjà actif

Le plus rapide, via le terminal :

dig TXT example.com +short | grep spf1

Si un enregistrement avec v=spf1 revient, ton domaine publie déjà SPF. Autre possibilité : entre ton domaine dans le scanner MXAudit gratuit — il vérifie en même temps la syntaxe de l’enregistrement et les limites de lookups.

2. Ouvrir les paramètres DNS dans le CCP

Connecte-toi au CCP et ouvre l’élément de menu Domaines. Clique sur l’icône de loupe à côté de ton domaine et passe à l’onglet DNS.

3. Créer (ou modifier) l’entrée TXT

Il ne peut y avoir qu’une seule entrée SPF par domaine. Si un enregistrement TXT avec v=spf1 existe déjà, modifie-le ; n’en crée pas un second.

Si l’entrée manque, crée-la ainsi :

ChampValeur
Hôte@
TypeTXT
Destinationv=spf1 mx a include:_spf.webhosting.systems ~all

4. Ajouter des expéditeurs supplémentaires (si nécessaire)

Si tu envoies aussi via d’autres services — outil de newsletter, CRM, système de boutique — leurs serveurs doivent aussi figurer dans l’enregistrement. Tu trouveras la valeur include nécessaire dans la documentation du service en question (cherche « SPF »). Modifie l’entrée existante et ajoute l’include avant le ~all :

v=spf1 mx a include:_spf.webhosting.systems include:spf.newsletter-dienst.de ~all

Garde un œil sur le budget de lookups en le faisant — plus de détails juste après.

5. Attendre que la modification soit en ligne

Les modifications DNS prennent du temps : selon le TTL et la mise en cache, il peut s’écouler quelques heures avant que chaque serveur dans le monde voie le nouvel enregistrement.

Les composants en détail

ComposantSignification
v=spf1identifiant de version, toujours au début
mxautorise les serveurs derrière l’enregistrement MX de ton domaine
aautorise le serveur derrière l’enregistrement A/AAAA de ton domaine
include:_spf.webhosting.systemsautorise l’infrastructure Netcup (imbrique les listes IPv4 et IPv6)
~allsoftfail : tous les autres serveurs sont considérés comme suspects, mais l’e-mail est généralement quand même accepté

Le budget de lookups : SPF autorise au maximum 10 lookups DNS par vérification. L’enregistrement par défaut de Netcup est inhabituellement coûteux ici : mx (1) + a (1) + include:_spf.webhosting.systems (1) — et cet include imbrique en interne deux includes supplémentaires pour IPv4 et IPv6 (1 chacun). Cela fait 5 lookups sur 10 avant même d’avoir ajouté le moindre service externe. Deux ou trois includes de newsletter ou de CRM plus tard, cela devient serré ; MXAudit compte pour toi.

Vérifier le résultat

Vérifie ta configuration avec le scanner MXAudit gratuit — il montre immédiatement si ton enregistrement SPF est syntaxiquement correct et combien de lookups DNS il consomme.

Ou directement dans le terminal :

dig TXT example.com +short | grep spf1

La sortie doit contenir exactement un enregistrement avec v=spf1.

Erreurs fréquentes

PHP mail() et envoi via le serveur web. Les formulaires WordPress et consorts envoient souvent directement via le serveur web — selon Netcup, ce chemin précis n’est pas couvert par l’enregistrement SPF et provoque des problèmes de distribution. Utilise plutôt SMTP via les serveurs de messagerie Netcup (par ex. via un plugin SMTP dans ton CMS).

Deux enregistrements SPF. Deux entrées TXT avec v=spf1 mènent à un permerror — les serveurs destinataires ignorent alors totalement SPF. Toutes les sources doivent tenir dans un seul enregistrement.

Dépassement de la limite de lookups DNS. L’enregistrement par défaut de Netcup consomme déjà 5 des 10 lookups autorisés (voir ci-dessus). Quiconque ajoute beaucoup de services atteint la limite plus vite que chez d’autres hébergeurs.

+all à la fin. Un +all autorise n’importe quel serveur à envoyer et rend tout l’enregistrement inutile. On le voit encore dans de vieux posts de forum — ne le copie pas.

Le transfert échoue. Si un destinataire fait suivre automatiquement ton e-mail, SPF échoue souvent chez le destinataire final — le serveur de transfert ne figure pas dans ton enregistrement. C’est une faiblesse de conception de SPF, pas une erreur de configuration ; DKIM et DMARC couvrent ce cas.

Pour aller plus loin