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.

Prérequis

  • Un compte domainfactory avec au moins un domaine
  • L’accès au menu client

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 en ton nom — 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 domainfactory

domainfactory te décharge de l’écriture de l’enregistrement : les réglages du serveur de noms comprennent un assistant SPF. Tu réponds à trois questions sur ton comportement d’envoi, et le système génère l’entrée correspondante — les experts peuvent ensuite l’ajuster via Modifier manuellement.

Une particularité qu’aucun autre grand hébergeur allemand ne fait de cette manière : lors de l’enregistrement, deux entrées SPF sont créées — une pour ton-domaine.tld et une pour *.ton-domaine.tld. L’entrée wildcard couvre ainsi aussi tous les sous-domaines qui n’ont pas leur propre enregistrement.

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 réglages du serveur de noms

Connecte-toi au menu client et sélectionne Réglages du serveur de noms. Clique sur Modifier à côté de ton domaine, puis sur Ajouter une entrée…

3. Remplir l’assistant SPF

Sous Type, choisis SPF. Le formulaire de saisie affiche maintenant trois questions de configuration :

OptionCe que cela signifie
Envoi d’e-mails par scriptsDes formulaires d’envoi, un logiciel de boutique ou des plugins de CMS envoient-ils des e-mails directement depuis l’espace web ? Alors l’IP du serveur web doit figurer dans l’enregistrement.
Serveur SMTPUtilises-tu les serveurs de messagerie domainfactory ? Tu peux aussi y indiquer d’autres serveurs de messagerie à toi.
ExhaustivitéCela capture-t-il toutes les adresses IP d’envoi — ou y a-t-il d’autres serveurs SMTP ?

En bas, le formulaire affiche l’entrée SPF générée. Si tout convient, clique sur Enregistrer — domainfactory crée alors les deux entrées (domaine + wildcard).

La question des scripts est la plus importante. Un formulaire de contact WordPress sans plugin SMTP envoie via le serveur web. Si tu réponds Non à la question, son IP manque dans l’enregistrement — et ce sont précisément ces e-mails qui finissent dans les spams.

4. Sous-domaines et nouveaux domaines

Sous-domaine avec son propre envoi (par ex. newsletter.example.com) : crée simplement une autre entrée SPF et mets le sous-domaine dans le champ Nom d’hôte — l’entrée ne s’applique alors qu’à lui.

Automatiquement pour les nouveaux domaines : passe à l’onglet Réglages par défaut dans les réglages du serveur de noms (s’il n’est pas visible : clique d’abord en haut à gauche sur Annuler la sélection du domaine), ajoute-y une entrée SPF avec un nom d’hôte vide — chaque domaine nouvellement commandé reçoit alors l’entrée automatiquement.

5. Ajouter des services d’envoi supplémentaires (si nécessaire)

Tu saisis un outil de newsletter ou un CRM via l’assistant sous Serveur SMTP — ou via Modifier manuellement comme valeur include: issue de la documentation du service. Ce qui reste important : un seul enregistrement SPF par (sous-)domaine.

6. 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.

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 (la limite est de 10).

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

Envoi par scripts refusé alors que le CMS envoie des e-mails. Les formulaires de contact, les confirmations de commande de boutique et les notifications de plugins passent souvent par le serveur web. Si son IP manque dans l’enregistrement, ce sont précisément ces e-mails qui échouent — réponds honnêtement à la question « Envoi d’e-mails par scripts » de l’assistant, ou passe à l’envoi SMTP.

« Exhaustivité » répondue trop optimistement. Si tu déclares que toutes les IP sont capturées alors qu’un CRM ou un service de newsletter envoie encore, tu bloques ces services.

Un second enregistrement créé manuellement. Chez domainfactory aussi, la règle tient : une seule entrée SPF par (sous-)domaine — deux enregistrements v=spf1 provoquent un permerror. L’assistant fait cela correctement ; sois prudent lors des retouches manuelles.

+all en modification manuelle. Un +all autorise n’importe quel serveur à envoyer et rend tout l’enregistrement inutile — 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