Délivrabilité et DNS

Enregistrement SPF : configurer un domaine professionnel

Par Alexey Bulygin
Configuration d’une entrée DNS TXT SPF pour un domaine de messagerie professionnelle

Votre e-mail est revenu en erreur. Il n'a pas été classé comme spam: le serveur l'a refusé. Il a renvoyé 550 5.7.26 ou 550 5.7.515, et le message n'a pas été livré. Un enregistrement SPF pour l'e-mail absent ou mal structuré peut être en cause, mais ces codes ne prouvent pas à eux seuls que SPF est le seul problème.

Depuis février 2024, Google et Yahoo imposent des exigences d'authentification qui dépendent de la catégorie et du volume de l'expéditeur. Un SPF incorrect peut entraîner un refus ou nuire à la distribution. Tout domaine de messagerie professionnelle mérite donc cette vérification, y compris le vôtre.

Google: 550 5.7.26 - Les e-mails non authentifiés ne sont pas acceptés

Microsoft: 550 5.7.515 - Identité de l'expéditeur non authentifiée

Ce guide va droit à la configuration: des exemples adaptés à votre installation, les pièges discrets des configurations apparemment correctes et un test sur un envoi réel. SPF est un élément d'un ensemble de trois mécanismes. Pour comprendre son articulation avec DKIM et DMARC, consultez les bases de la sécurité de la messagerie professionnelle.

Qu'est-ce qu'un enregistrement SPF pour l'e-mail?

Un enregistrement SPF est une entrée TXT du DNS qui indique quels serveurs peuvent envoyer des messages avec le domaine de l'enveloppe SMTP. À la réception d'un message, Gmail ou Outlook consulte le DNS et compare l'IP d'envoi aux autorisations. SPF produit un résultat tel que pass ou fail; l'acceptation, le refus et le classement du message relèvent ensuite de la politique du destinataire.

SPF vérifie l'enveloppe SMTP, et plus précisément le domaine de MAIL FROM, pas l'adresse «De» visible dans la boîte du destinataire. Le TXT se publie sur ce domaine, à la racine (@) ou sur le sous-domaine utilisé pour l'enveloppe. Pour comprendre l'ensemble des entrées DNS, le guide configurer l'e-mail sur votre domaine reprend le processus depuis le début.

La règle de l'enregistrement unique

RFC 7208, la spécification SPF, prévoit un seul enregistrement TXT commençant par v=spf1 pour chaque domaine évalué. Si un serveur destinataire en trouve deux, il renvoie PermError. SPF ne peut plus être évalué correctement tant que le doublon subsiste, sans que cela implique nécessairement le refus de tous les messages.

C'est une erreur fréquente lorsqu'on ajoute un fournisseur à un domaine déjà hébergé chez Google Workspace ou ailleurs: on crée un deuxième enregistrement au lieu de modifier le premier.

Vérifiez l'existant avant toute modification:

dig +short txt yourdomain.com

Comptez les lignes qui commencent par v=spf1. S'il y en a deux, l'évaluation produit un PermError. Corrigez d'abord ce doublon.

SituationRésultat
Un enregistrement SPF, syntaxe correctePeut authentifier les IP autorisées ✓
Deux enregistrements SPF sur le même domainePermError: évaluation SPF impossible ✗
Aucun SPF sur le domaineSPF absent; exigences du destinataire potentiellement non respectées ✗

Incorrect: ces deux enregistrements provoquent PermError lors de l'évaluation du domaine:

v=spf1 include:_spf.google.com -all
v=spf1 include:spf.trekmail.net -all

Correct: fusion en un seul enregistrement SPF:

v=spf1 include:_spf.google.com include:spf.trekmail.net -all

Votre SPF: la configuration minimale

Le contenu exact dépend des serveurs qui envoient réellement vos messages. N'autorisez que ceux que vous utilisez. Chaque include: supplémentaire consomme le budget d'évaluation et ajoute des plages IP que vous ne maîtrisez pas.

Cas A: SMTP géré par TrekMail (offres Starter et Agency)

Si votre offre payante TrekMail inclut l'envoi géré et qu'il s'agit du seul service qui envoie pour le domaine de l'enveloppe, cette ligne peut le couvrir. Vérifiez d'abord tous les expéditeurs:

v=spf1 include:spf.trekmail.net -all

Cas B: offre gratuite TrekMail (votre propre SMTP)

Si l'offre Nano permet de connecter votre fournisseur SMTP, comme Amazon SES, SendGrid ou Mailgun, autorisez ses IP, pas celles de TrekMail:

v=spf1 include:amazonses.com -all

Remplacez include:amazonses.com par la valeur indiquée dans la documentation du fournisseur pour votre installation. N'autorisez pas de plages IP inutilisées.

Cas C: installation hybride - TrekMail + Google Workspace

Vous migrez depuis Google ou conservez les deux services pendant la transition? S'ils utilisent le même domaine d'enveloppe pour l'envoi, fusionnez-les dans un seul enregistrement:

v=spf1 include:spf.trekmail.net include:_spf.google.com -all

Composants de l'enregistrement

ComposantFonction
v=spf1Marqueur de version. Doit figurer en premier.
include:Délègue l'autorisation à la politique SPF d'un fournisseur tiers.
-allHard fail: déclare les autres expéditeurs non autorisés. À utiliser après inventaire, en évaluant la transition depuis ~all.

~all (soft fail) indique qu'un expéditeur n'est probablement pas autorisé, mais ne garantit pas la livraison. -all exprime une politique plus stricte sans obliger le destinataire à refuser le message. Avant de l'utiliser en production, recensez tous vos services d'envoi légitimes. ~all peut servir temporairement pendant une installation ou une transition.

La limite de 10 termes nécessitant le DNS

La spécification SPF (RFC 7208) fixe une limite de 10 termes déclenchant des recherches DNS pendant l'évaluation, et non de toutes les requêtes DNS individuelles. include:, a, mx et le modificateur redirect comptent, y compris les termes évalués dans les politiques référencées. ip4: et ip6: ne comptent pas. Au-delà de 10, l'évaluation renvoie PermError.

Ce piège peut rester invisible. Votre SPF passe un validateur de syntaxe parce que sa syntaxe est correcte. Mais si le serveur parcourt des références imbriquées et que le total des termes évalués dépasse 10, SPF échoue avec une erreur.

Ce qui compte dans la limite:

  • include: (et les termes imbriqués effectivement évalués)
  • a, mx, redirect

Ce qui ne compte pas:

  • ip4: et ip6:: les IP explicites évitent cette chaîne de recherches
  • all

Vérifiez votre enregistrement avant publication, puis analysez ses références:

dig +short txt yourdomain.com

Si les références imbriquées sont nombreuses, vous pouvez aplatir le SPF en remplaçant include: par des entrées ip4: explicites, à condition de maintenir ces plages à jour. Autre possibilité: répartir les envois entre plusieurs sous-domaines d'enveloppe, chacun disposant de son budget.

Valider votre enregistrement SPF

Ne vous fiez pas uniquement aux voyants verts du panneau DNS: une syntaxe correcte ne prouve pas que l'envoi fonctionne. Testez SPF lors d'une transmission SMTP réelle. Vous verrez ainsi le résultat calculé par Gmail pour ce message, sans garantie de placement dans la boîte de réception.

  1. Envoyez un e-mail depuis votre domaine vers un compte Gmail que vous contrôlez.
  2. Ouvrez le message dans Gmail.
  3. Cliquez sur le menu à trois points → Afficher l'original.
  4. Recherchez Authentication-Results.

Exemple de résultat positif:

spf=pass (google.com: domain of team@yourdomain.com designates 192.0.2.1 as permitted sender)
RésultatSignificationCorrection
spf=softfailL'IP n'est pas autorisée et ~all s'appliqueAutorisez l'IP légitime; passer à -all ne l'autorise pas
spf=failL'IP n'est pas autorisée et -all s'appliqueAjoutez l'IP d'envoi si elle est légitime
spf=permerrorErreur de syntaxe, doublon ou plus de 10 termes nécessitant le DNSCorrigez d'abord la structure
spf=noneAucun SPF sur le domaine évaluéPubliez le TXT sur ce domaine, à @ s'il s'agit de la racine

permerror signifie que la politique SPF n'a pas pu être évaluée correctement, pas simplement qu'une IP manque. Corrigez les doublons, le nombre de termes et la syntaxe avant de modifier les autorisations.

Les erreurs SPF courantes

De nombreux échecs SPF viennent de cinq erreurs. Certaines se corrigent en moins de 10 minutes, même si la propagation DNS et les vérifications peuvent prendre plus de temps.

ErreurConséquence
Utiliser +allAutorise n'importe quelle IP à envoyer avec votre domaine d'enveloppe. À éviter absolument.
Utiliser le mécanisme ptrDéconseillé par la spécification, lent et peu fiable.
Faute dans le domaine inclusinclude:google.com ne remplace pas la valeur documentée include:_spf.google.com.
Espace après les deux-pointsip4: 1.2.3.4 est invalide. Écrivez ip4:1.2.3.4, sans espace.
Utiliser ~all en production sans réévaluationSoft fail ne garantit ni livraison ni refus. Envisagez -all après inventaire.

Les fautes de domaine sont particulièrement pénibles: un validateur de syntaxe ne vérifie pas forcément que la référence mène à une politique SPF valide. Consultez toujours la documentation du fournisseur pour connaître la valeur exacte.

Gérer SPF sur plusieurs domaines

Configurer SPF sur un domaine peut prendre 10 minutes. Le maintenir sur 50 domaines clients demande un suivi continu. Chaque nouvel outil marketing peut rendre l'authentification incomplète, parfois sans alerte jusqu'au premier signalement de messages refusés.

Pour les agences et les prestataires de services gérés, la standardisation facilite ce suivi. S'ils sont inclus dans votre offre, le tableau de bord multidomaine et l'assistant SPF/DKIM/DMARC de TrekMail aident à harmoniser les configurations. Les offres payantes annoncées à partir de $3.50/mois peuvent inclure l'envoi SMTP géré: vérifiez les tarifs et fonctionnalités actuels. Avec l'offre Nano, si elle permet de connecter votre propre fournisseur SMTP, vous utilisez ce fournisseur et gérez la réputation de ses IP selon ses conditions, ce qui peut convenir à des comptes SES ou Mailgun déjà préparés pour l'envoi.

Un modèle commun peut simplifier la migration de clients vers TrekMail, à condition de l'adapter aux expéditeurs réels de chaque domaine. Pour organiser la messagerie à grande échelle, consultez la gestion des e-mails clients pour les agences. Pour une nouvelle installation, le guide créer une adresse e-mail avec votre domaine détaille tout le processus.

SPF: liste de contrôle avant publication

Avant de publier, suivez cette liste dans l'ordre:

  1. Vérifiez l'existant: dig +short txt yourdomain.com, une seule ligne v=spf1.
  2. Recensez tous les services utilisant votre domaine d'enveloppe: messages transactionnels, marketing et outils de support.
  3. Rédigez un seul enregistrement couvrant tous ces services. Fusionnez, ne dupliquez pas.
  4. Utilisez -all après inventaire complet; réévaluez ~all et évitez +all.
  5. Comptez les termes nécessitant le DNS et gardez une marge sous 10.
  6. Publiez le TXT sur le domaine d'enveloppe, à @ s'il s'agit de la racine.
  7. Envoyez un test à Gmail et consultez Afficher l'original pour vérifier spf=pass.

Les consignes Google pour les expéditeurs distinguent les catégories d'envoi; les expéditeurs en nombre doivent configurer SPF, DKIM et DMARC. Un SPF correct est une première étape. DKIM et DMARC complètent l'authentification, mais même la réussite des trois ne garantit pas la boîte de réception.

Une fois SPF configuré, revérifiez-le lorsque vous changez de fournisseur ou que ses exigences évoluent. Une mauvaise configuration peut entraîner des erreurs d'authentification et des retours en erreur. Essayez TrekMail gratuitement si Nano reste disponible sans carte bancaire. Les offres annoncées à partir de $3.50/mois et l'essai gratuit de 14 jours dépendent des conditions en vigueur.

Partager cet article

Nous utilisons les technologies nécessaires au fonctionnement et à la sécurité de TrekMail. En confirmant, vous autorisez aussi des analyses limitées et la mesure publicitaire décrites dans notre Politique relative aux cookies.

Se connecter à TrekMail

Accédez à votre tableau de bord, vos boîtes et vos DNS.

ou

12 caractères les mots de passe correspondent

ou

E-mail de réinitialisation envoyé

Si un compte existe pour cette adresse, nous venons d’envoyer les instructions de réinitialisation du mot de passe.

En continuant, vous acceptez les Conditions d’utilisation et la Politique de confidentialité de TrekMail.