La plupart des exemples d'enregistrement SPF disponibles en ligne sont trop simplifiés ou encombrés de cas particuliers peu utiles. Voici des modèles adaptés à la production pour les trois configurations qui couvrent 95% des domaines. Un seul enregistrement TXT, commençant par v=spf1 et se terminant par -all. En cas d'erreur, des destinataires comme Google et Microsoft peuvent rejeter le message avec des erreurs SMTP peu explicites telles que 550 5.7.26.
Choisissez ci-dessous le scénario qui vous correspond, collez l'enregistrement, puis consacrez-vous aux sujets qui demandent réellement votre attention.
Modèles d'enregistrement SPF pour chaque configuration d'envoi
Un bon exemple doit correspondre à votre infrastructure réelle, et non à une configuration hypothétique comprenant six outils SaaS. Les trois scénarios suivants couvrent les domaines avec un seul expéditeur, les configurations hybrides et les structures complexes à plusieurs expéditeurs. Chaque modèle est prêt à être publié sous forme d'enregistrement DNS TXT sur le domaine racine.
Scénario 1 : un seul expéditeur (un fournisseur gère tout)
Vous envoyez tous les e-mails par une seule plateforme. Il s'agit de la configuration la plus simple et généralement de celle à privilégier.
TrekMail (offre Starter, Pro ou Agency) :
v=spf1 include:spf.trekmail.net -allGoogle Workspace :
v=spf1 include:_spf.google.com -allMicrosoft 365 :
v=spf1 include:spf.protection.outlook.com -allUn include et un -all. C'est tout. Vous utilisez 1 requête DNS sur les 10 autorisées.
Scénario 2 : expéditeur hybride (boîte de réception + service transactionnel)
Vous utilisez un fournisseur principal pour la boîte de réception et un service distinct pour les messages transactionnels ou marketing. Cette situation est courante avec l'offre Nano de TrekMail, qui utilise votre propre SMTP, ou lorsqu'un outil comme Amazon SES ou Mailchimp est ajouté.
TrekMail Free + Amazon SES :
v=spf1 include:amazonses.com -allGoogle Workspace + Mailchimp :
v=spf1 include:_spf.google.com include:servers.mcsv.net -allDeux inclusions et deux requêtes, auxquelles s'ajoutent les éventuelles requêtes imbriquées des fournisseurs. Le total reste dans les limites.
Scénario 3 : plusieurs expéditeurs (risque élevé)
Cet exemple couvre la messagerie d'entreprise, le CRM, l'assistance et la plateforme RH, tous autorisés sur un même domaine. C'est souvent ici que les problèmes commencent.
v=spf1 include:spf.trekmail.net include:hubspot.com include:mail.zendesk.com include:spf.bamboohr.com -allSur le papier, il y a quatre inclusions. Toutefois, chaque include peut contenir des requêtes imbriquées. HubSpot peut à lui seul en ajouter 3-4. Si la chaîne totale dépasse 10, les destinataires renvoient PermError et considèrent le message comme non authentifié. Si votre structure ressemble à celle-ci, la section suivante sur la limite est indispensable.
Fonctionnement de la syntaxe SPF : les éléments essentiels
SPF est une liste d'autorisation fondée sur le DNS et définie dans la RFC 7208. Elle indique aux serveurs destinataires quelles adresses IP peuvent envoyer des messages pour votre domaine. Voici les composants d'un exemple réel :
| Composant | Exemple | Fonction |
|---|---|---|
| Version | v=spf1 | Obligatoire. Doit constituer les premiers caractères de l'enregistrement. |
| Include | include:spf.trekmail.net | Autorise toutes les IP indiquées dans l'enregistrement SPF d'un autre domaine. |
| Mécanisme IP | ip4:192.0.2.1 | Autorise directement une IP statique. Ne consomme aucune requête DNS. |
| HardFail | -all | Rejette toute IP qui n'est pas explicitement indiquée. Utilisez cette option. |
| SoftFail | ~all | Marque les IP absentes comme suspectes. À réserver aux tests de transition. |
Pour suivre toute la procédure, y compris les outils de validation et les risques de l'aplatissement, consultez notre guide de configuration d'un enregistrement SPF.
La limite de 10 requêtes : là où de nombreux enregistrements SPF échouent
La RFC 7208 limite les requêtes DNS à 10 par évaluation SPF. Cette règle contribue à prévenir les attaques par déni de service, mais elle constitue aussi une contrainte importante pour une entreprise en croissance.
Ces mécanismes consomment chacun 1 requête : include, a, mx, redirect, exists, ptr (obsolète, ne l'utilisez pas).
Ceux-ci n'en consomment aucune : ip4, ip6, all.
Les requêtes sont récursives. L'ajout de include:bluehost.com consomme 1 requête. Si l'enregistrement SPF de Bluehost contient include:spf.protection.outlook.com, cette requête imbriquée compte dans votre limite. Avec 3-4 fournisseurs utilisant des inclusions imbriquées, vous pouvez déjà dépasser 10.
La limite des requêtes vides, souvent oubliée
La RFC 7208 §11.1 ajoute une limite secondaire : au maximum 2 requêtes DNS sans résultat, qu'il s'agisse de NXDOMAIN ou d'une réponse vide. Une faute dans include:spf.trekmaill.net, avec un 'l' supplémentaire, consomme 1 requête vide. Deux fautes font échouer l'ensemble de l'enregistrement.
Corriger la limite sans aplatir l'enregistrement
Avant d'aplatir un enregistrement SPF, envisagez des solutions plus simples. L'aplatissement, qui résout les inclusions en IP brutes, est fragile : les IP peuvent changer et l'enregistrement devient obsolète. Les deux approches suivantes sont généralement plus durables.
Utiliser des sous-domaines pour séparer les expéditeurs
N'accumulez pas tous les outils sur le domaine racine. Chaque sous-domaine dispose d'un nouveau budget de 10 requêtes.
- Messagerie d'entreprise :
@company.com, uniquement votre fournisseur principal (TrekMail, Google, etc.) - Marketing :
@news.company.com, Mailchimp, HubSpot - Assistance :
@support.company.com, Zendesk, Freshdesk
Cette stratégie permet de monter en charge. Si vous gérez plusieurs domaines ou comptes clients, la segmentation par sous-domaines garde chaque enregistrement SPF concis et vérifiable. Elle isole également la réputation du domaine, afin qu'une campagne marketing problématique ne nuise pas aux messages transactionnels.
Remplacer les requêtes DNS par des mécanismes IP
Si votre serveur de messagerie possède une IP statique, indiquez directement cette IP au lieu d'utiliser un mécanisme a.
Consomme 1 requête :
v=spf1 a:mail.company.com -allConsomme 0 requête :
v=spf1 ip4:192.0.2.55 -allChaque ip4 ou ip6 utilisé en remplacement libère une requête pour les outils SaaS qui exigent include.
Erreurs SPF critiques qui nuisent à l'acheminement
Erreur 1 : deux enregistrements SPF sur le même domaine
C'est l'une des erreurs les plus fréquentes. Vous ne pouvez pas publier deux enregistrements TXT commençant par v=spf1 sur le même domaine. Les deux échoueront avec PermError.
Incorrect :
TXT: v=spf1 include:_spf.google.com -all
TXT: v=spf1 include:spf.trekmail.net -allCorrect :
TXT: v=spf1 include:_spf.google.com include:spf.trekmail.net -allFusionnez-les systématiquement en un seul enregistrement. Pour comprendre la cause et suivre un exemple complet, consultez l'enregistrement SPF pour l'e-mail. Notre guide de configuration d'un enregistrement SPF présente toute la procédure depuis le début.
Erreur 2 : utiliser +all
N'utilisez jamais +all. Cette valeur autorise tout et indique aux serveurs que n'importe qui peut envoyer des messages au nom de votre domaine. Utilisez toujours -all (HardFail).
Erreur 3 : compter uniquement sur SPF pour les messages transférés
SPF compare l'IP d'envoi au domaine de l'expéditeur de l'enveloppe. Lors d'un transfert, l'IP change, mais pas cet expéditeur. La vérification SPF échoue donc.
C'est pourquoi DKIM existe : il signe le contenu et peut résister au transfert. Si vous dépendez de listes de diffusion ou du transfert d'e-mails, SPF seul ne suffit pas. Il faut DKIM et, idéalement, une politique DMARC qui accepte l'un ou l'autre. Le Sender Rewriting Scheme (SRS) complète le dispositif en réécrivant l'expéditeur de l'enveloppe afin que SPF réussisse au saut suivant.
Comment TrekMail simplifie la gestion de SPF
Gérer les enregistrements DNS d'un domaine est fastidieux. Sur 50 ou 100 domaines clients, les erreurs peuvent s'accumuler.
L'approche de TrekMail dépend de votre offre :
- Free ($0/mo, sans carte) : votre propre SMTP. Vous incluez l'enregistrement SPF de votre fournisseur. Contrôle complet et coût nul.
- Starter ($3.50/mo) et Pro ($10/mo) : SMTP géré. Ajoutez
include:spf.trekmail.netet nous gérons l'infrastructure IP sous-jacente. Lorsque les serveurs changent, votre DNS reste inchangé. - Agency (.25/mo) : le même SMTP géré, conçu pour plusieurs domaines. Appliquez un modèle SPF normalisé aux domaines clients. Une seule inclusion conserve une marge de requêtes pour les autres outils.
Toutes les offres payantes incluent un essai gratuit de 14 jours, avec carte requise. L'assistant SPF/DKIM/DMARC intégré vous accompagne dans la configuration DNS et signale les erreurs avant la mise en production.
Votre liste de contrôle SPF
Tous les exemples de ce guide suivent les mêmes principes. Un bon enregistrement SPF reste simple si l'on évite la complexité superflue. Voici la séquence de vérification :
- Comptez vos requêtes. Exécutez
dig TXT yourdomain.comou utilisez un validateur SPF. Au-delà de 10, l'enregistrement échoue déjà. - Fusionnez les doublons. Un domaine, un enregistrement
v=spf1. - Séparez les gros expéditeurs. Placez les outils marketing et d'assistance sur des sous-domaines.
- Remplacez les mécanismes
aparip4lorsque vos serveurs sont statiques. - Terminez par
-all. Sans exception.
Si vous préférez éviter toute modification du DNS, l'offre gratuite de TrekMail fournit une messagerie fonctionnelle sans coût initial. Les offres payantes gèrent l'infrastructure SPF.
