Votre configuration SPF fonctionne bien avec un seul expéditeur. Puis vous ajoutez Google Workspace, Mailchimp, Zendesk et une API transactionnelle, et Microsoft commence à rejeter les messages avec 550 5.7.515. L'enregistrement qui semblait propre au lancement vient de dépasser la limite de 10 requêtes. Désormais, tous les messages sortants échouent silencieusement à l'authentification.
Voilà le piège. SPF comporte un plafond strict intégré au protocole, que la plupart des équipes atteignent dès l'ajout d'un troisième ou quatrième service d'envoi. La solution habituelle, coller un autre include:, cesse de fonctionner précisément au moment où vous en avez le plus besoin. Pour les bases de la syntaxe, commencez par notre guide sur l'enregistrement SPF des e-mails. Cet article porte sur l'architecture : concevoir une configuration SPF capable de gérer plusieurs expéditeurs, de résister aux changements de fournisseur et de ne pas être réécrite chaque trimestre.
Pourquoi la configuration SPF échoue avec plusieurs expéditeurs
La configuration SPF échoue parce que la RFC 7208 limite l'évaluation à 10 requêtes DNS par enregistrement. Chaque mécanisme include, a, mx, exists et redirect compte, de manière récursive. Si l'include d'un fournisseur en contient trois autres, ils consomment tous votre quota. À 11, les serveurs destinataires renvoient PermError et peuvent rejeter le message.
Le scénario d'échec est presque toujours identique. Vous commencez avec deux includes et une marge confortable. Le marketing ajoute HubSpot, l'assistance adopte Freshdesk et l'équipe technique utilise SendGrid pour les alertes de l'application. La chaîne d'includes de chaque fournisseur est plus profonde que ne le laisse penser sa documentation. Vous atteignez soudain 12 requêtes et Google renvoie 550 5.7.26 sur chaque message.
| Mécanisme | Coûte une requête ? | Note d'exploitation |
|---|---|---|
include: | Oui, plus les inclusions imbriquées | Courant pour les fournisseurs, mais profondeur imprévisible |
ip4: / ip6: | Non | Sans coût de requête, à utiliser pour tout expéditeur statique sous votre contrôle |
mx | Oui | Souvent utilisé à tort; remplacez-le par ip4 lorsque possible |
a | Oui | Inefficace pour SPF; préférez ip4 |
ptr | Oui | Obsolète. Ne l'utilisez pas |
redirect | Oui | Transfère l'évaluation à l'enregistrement d'un autre domaine |
-all / ~all | Non | Fin de la politique; incluez-en toujours une |
Le calcul n'est pas complexe. Il reste simplement invisible jusqu'à la panne. Voilà pourquoi une configuration SPF destinée à plusieurs expéditeurs doit commencer par l'architecture et non par du copier-coller.
Auditez votre enregistrement SPF avant tout ajout
La première étape de toute configuration SPF multi-expéditeur consiste à retirer ce qui ne devrait plus s'y trouver. Beaucoup de domaines conservent des includes de services résiliés depuis des mois ou des années. Chacun gaspille une partie du quota de requêtes. Nettoyez d'abord, construisez ensuite.
Vérifiez ce qui est réellement publié :
dig txt yourdomain.com +shortSuivez ensuite chaque include pour connaître sa profondeur :
dig txt _spf.google.com +short
dig txt spf.protection.outlook.com +shortComparez ces données à vos rapports agrégés DMARC. Si aucun trafic ne provient réellement des IP d'un fournisseur, son include est inutile. Supprimez-le.
Trois gains rapides lors de l'audit :
- Remplacez
mxpar l'IP réelle avecip4:; vous économisez une requête. - Supprimez les includes des services que vous n'utilisez plus.
- Recherchez les enregistrements SPF en double. Deux enregistrements TXT commençant par
v=spf1sur le même domaine provoquent immédiatement un PermError.
Cette seule opération libère souvent 2-3 requêtes. Pour une procédure de nettoyage détaillée, consultez notre guide de configuration d'un enregistrement SPF.
Segmentation par sous-domaines : la configuration SPF qui évolue
La configuration SPF qui gère de manière fiable plusieurs expéditeurs sans atteindre le plafond de 10 requêtes repose sur la segmentation par sous-domaines. SPF est évalué à partir du domaine Return-Path et non de l'en-tête From visible. Placez les expéditeurs non professionnels sur des sous-domaines, et chaque flux reçoit son propre quota neuf de 10 requêtes.
Voici le modèle :
Domaine racine : uniquement les échanges humains
Gardez le domaine racine propre. Seul votre fournisseur principal de boîtes doit y figurer.
v=spf1 include:spf.trekmail.net -allUn include, une requête. Les e-mails de la direction ne tombent pas en panne parce que le marketing a greffé un nouvel outil.
Sous-domaine marketing : campagnes et lettres d'information
; news.example.com
v=spf1 include:spf.hubspot.com include:servers.mcsv.net -allHubSpot et Mailchimp consomment les requêtes de news.example.com, pas celles du domaine racine. Si ce sous-domaine est limité, la messagerie professionnelle continue de fonctionner.
Sous-domaine d'assistance : systèmes de tickets
; help.example.com
v=spf1 include:mail.zendesk.com -allSous-domaine transactionnel : alertes et reçus des applications
; alerts.example.com
v=spf1 include:amazonses.com -allLorsque Zendesk envoie sous l'adresse support@help.example.com, le serveur destinataire consulte le DNS de help.example.com. Il ne touche jamais à l'enregistrement SPF du domaine racine. C'est précisément l'objectif.
| Ancienne méthode | Nouvelle méthode |
|---|---|
| Tous les expéditeurs entassés dans un seul enregistrement SPF racine | Le domaine racine ne contient que le fournisseur principal de boîtes |
| Un changement de fournisseur peut interrompre tous les envois | Les pannes restent isolées dans le sous-domaine concerné |
| Le quota de requêtes est partagé par tous les services | Chaque sous-domaine dispose de son propre quota de 10 requêtes |
| SPF doit être réécrit à chaque nouvel outil | L'architecture résiste aux changements de fournisseurs |
Aplatissement SPF : le dernier recours
Si vos contraintes imposent d'envoyer tous les messages depuis le domaine nu, sans autoriser les sous-domaines, l'aplatissement SPF sert de porte de sortie. Il résout les includes des fournisseurs en adresses IP brutes, puis les énumère comme mécanismes ip4:, qui ne coûtent aucune requête. Cela fonctionne, mais crée une contrainte de maintenance.
Le risque est l'obsolescence. Les fournisseurs SaaS changent régulièrement leurs IP. Si SendGrid ajoute demain une nouvelle plage et que votre enregistrement aplati contient toujours les adresses d'hier, les messages sortants commencent à échouer à SPF. N'effectuez pas cet aplatissement manuellement à moins de pouvoir le vérifier chaque jour. Utilisez un service SPF dynamique automatisé qui surveille les IP des fournisseurs et actualise votre enregistrement TXT à intervalles réguliers.
L'aplatissement est un contournement, pas une architecture. La segmentation par sous-domaines constitue la véritable solution. Ne l'utilisez qu'après avoir réellement épuisé toutes les autres possibilités.
Vérifiez le fonctionnement de la configuration SPF
Après toute modification de SPF, vérifiez la réponse réelle du DNS public. Ne vous fiez pas au tableau de bord du bureau d'enregistrement, à une interface mise en cache ni aux voyants verts de l'outil d'un fournisseur. Interrogez directement le domaine et confirmez la présence d'un seul enregistrement SPF valide par nom d'hôte.
# Check the root record
dig txt example.com +short
# Check a subdomain
dig txt news.example.com +short
# Verify DMARC while you're at it
dig txt _dmarc.example.com +shortVous devez obtenir un enregistrement TXT commençant par v=spf1 pour chaque nom d'hôte. Pas deux. Pas un enregistrement actuel accompagné d'un vestige d'une migration datant de deux ans.
Envoyez ensuite un message de test à Gmail, ouvrez-le, cliquez sur le menu à trois points, choisissez « Afficher l'original », puis cherchez :
SPF: PASS with IP [your sending IP]
DKIM: PASS
DMARC: PASSTout résultat FAIL ou SOFTFAIL signale un problème dans la configuration SPF. Corrigez-le avant d'envoyer de gros volumes. Si vous examinez également des difficultés de réputation qui dépassent SPF, notre guide des signaux de réputation de l'expéditeur offre une vue d'ensemble.
Comment TrekMail simplifie SPF sur plusieurs domaines
Configurer SPF pour un domaine est fastidieux. Le faire pour 50 domaines clients, chacun avec des fournisseurs d'envoi et de DNS différents ainsi qu'un niveau d'entretien variable, consomme énormément de temps. TrekMail conserve une empreinte SPF réduite et prévisible afin de laisser de la place au reste.
L'include principal est include:spf.trekmail.net. Une requête. Aucune redirection imbriquée ni chaîne d'expansion imprévisible. Comparez cela à Microsoft 365, qui consomme souvent 2-3 requêtes via des redirections internes, ou à Google Workspace, dont le comportement peut varier selon la région.
Pour une personne indépendante, votre configuration SPF reste ainsi simple même après l'ajout d'un outil marketing. Pour les équipes, cela réduit les erreurs DNS pendant l'intégration. Pour les agences qui administrent des dizaines ou des centaines de domaines clients, le modèle devient reproductible : ajoutez l'include TrekMail, séparez les autres fournisseurs dans des sous-domaines et évitez le problème du plafond de requêtes. Si vous gérez la messagerie de plusieurs marques, consultez l'architecture générale de l'hébergement e-mail multidomaine.
Le vérificateur d'état DNS de TrekMail signale aussi les conflits SPF dans votre tableau de bord avant qu'ils ne provoquent des pannes en production. Vous voyez le problème avant vos clients. Pour la configuration DNS complète, consultez les enregistrements DNS requis dans la documentation.
Conclusion : concevez SPF une fois et cessez d'y toucher
Une bonne configuration SPF commence par l'architecture, pas par la syntaxe. Auditez les includes obsolètes. Répartissez les expéditeurs entre des sous-domaines afin que chaque flux dispose de son propre quota de 10 requêtes. Gardez le domaine racine propre : un fournisseur de boîtes, un include et un -all. Vérifiez avec dig, pas avec les tableaux de bord.
Si vous souhaitez appliquer ce modèle à un domaine ou à une centaine sans tarification par utilisateur, TrekMail propose un hébergement multidomaine à prix fixe, un seul include SPF propre, un espace mutualisé et un vérificateur DNS qui détecte tôt les erreurs de configuration. Selon les conditions actuelles, l'offre Nano couvre 10 domaines avec votre propre SMTP, sans carte bancaire et gratuitement. Les offres payantes commencent à $3.50/month avec Starter et un SMTP géré, et incluent un essai gratuit de 14-day (carte requise). Consultez les offres actuelles sur trekmail.net/pricing.
