Guide · Courriel
SPF : recenser toutes ses sources d’envoi
Le DNS ne connaît pas votre organisation. Avant de modifier SPF, il faut retrouver chaque service qui envoie réellement avec votre domaine, puis décider comment l’authentifier.
Réponse courte
Comment recenser toutes les sources qui envoient des courriels pour votre domaine ?
Partez des usages, pas de l’enregistrement DNS : messagerie des employés, infolettres, formulaires du site, facturation, réservation, recrutement, soutien, signatures et systèmes transactionnels. Pour chacun, identifiez le fournisseur, le domaine visible dans « De », le domaine de retour et la méthode SPF ou DKIM recommandée.
Croisez cet inventaire avec les rapports DMARC et les journaux des services. Retirez une source de SPF seulement après avoir confirmé qu’elle n’envoie plus. Maintenez un seul enregistrement SPF par nom de domaine et surveillez la limite de recherches DNS définie par la norme.
Ce que SPF vérifie réellement
SPF permet au propriétaire d’un domaine de publier quels serveurs sont autorisés à envoyer avec ce domaine dans l’identité SMTP MAIL FROM ou HELO. Cette identité technique peut différer du domaine que la personne voit dans le champ « De ».
SPF ne signe pas le contenu et ne prouve pas à lui seul que le message visible vient de votre organisation. DMARC ajoute la condition d’alignement avec le domaine visible.
À retenir
Un résultat SPF positif sur le domaine d’un fournisseur ne protège votre domaine que si l’alignement DMARC est aussi satisfait.
Commencer par les processus qui envoient
Sources souvent oubliées
- Messagerie humaine Microsoft 365, Google Workspace ou le serveur de l’hébergeur.
- Site web formulaire de contact, réinitialisation de mot de passe, commandes et notifications.
- Marketing infolettres, automatisations et gestion de relations clients.
- Opérations facturation, devis, signature électronique, réservation et soutien.
- Ressources humaines recrutement, paie, avantages sociaux ou sondages.
- Équipements et anciens systèmes scanneurs, outils de surveillance, applications internes et services oubliés.
Demandez à chaque responsable ce qui envoie, à quelle fréquence et avec quelle adresse visible. Les flux mensuels et annuels sont ceux qu’un échantillon court manque le plus facilement.
Lire un enregistrement SPF sans le recopier aveuglément
Un enregistrement commence par v=spf1. Les mécanismes ip4 et ip6 autorisent des adresses; include délègue une partie de la décision à un autre domaine; a et mx s’appuient sur d’autres enregistrements DNS. Le mécanisme all, placé à la fin, correspond à tout ce qui n’a pas déjà été reconnu.
Les qualificatifs les plus vus sont - pour un échec ferme et ~ pour un échec souple. Leur choix vient après l’inventaire et les tests. Copier l’enregistrement d’une autre organisation peut autoriser ses fournisseurs et oublier les vôtres.
Détail technique
La norme prévoit aussi redirect pour confier l’évaluation à un autre enregistrement. include et redirect n’ont pas le même sens : le premier ajoute un mécanisme; le second remplace le reste de l’évaluation quand aucun mécanisme précédent ne correspond.
La limite de recherches DNS est une contrainte de conception
RFC 7208 limite à dix le nombre total de termes qui peuvent déclencher une recherche DNS pendant une évaluation. Des chaînes d’include imbriquées consomment aussi ce budget. Dépasser la limite peut produire une erreur permanente au lieu d’une autorisation.
Comptez les dépendances réelles, pas seulement le nombre d’include visibles sur la première ligne. Avant d’aplatir des adresses IP, vérifiez le contrat du fournisseur : ses plages peuvent changer, et une copie figée devient vite fausse.
À retenir
Réduisez les sources inutiles avant de chercher à compresser l’enregistrement.
Relier SPF aux rapports DMARC
Les rapports agrégés DMARC montrent quels systèmes envoient et quels domaines SPF ou DKIM ils présentent. Ils aident à repérer un service légitime oublié, un ancien fournisseur ou un flux qui passe SPF sans s’aligner avec le domaine visible.
SPF peut perdre son alignement lors de certains transferts parce que l’identité MAIL FROM change. DKIM offre alors une autre voie d’alignement, si la signature reste valide. La préparation DMARC examine les deux mécanismes plutôt que de charger SPF de tout résoudre.
Modifier sans couper les envois légitimes
-
Capturer l’état actuel
enregistrement, rapports disponibles, fournisseurs connus et responsables.
-
Classer chaque source
active et légitime, à confirmer, ancienne à retirer ou inconnue à enquêter.
-
Configurer chez le fournisseur
suivre sa documentation pour SPF et surtout DKIM, avec un domaine aligné quand possible.
-
Tester un flux réel
message reçu, en-têtes d’authentification et rapport DMARC; un test unique ne couvre pas les envois rares.
-
Retirer progressivement
une source à la fois, avec une fenêtre d’observation et un retour arrière documenté.
Attention
Ne passez pas directement de ~all à -all pendant que l’inventaire est incomplet. Le qualificatif n’invente pas les sources manquantes; il rend leurs échecs plus explicites.
Les erreurs qui reviennent
À éviter
- Deux enregistrements SPF la sélection de plusieurs enregistrements pour un même nom produit une erreur permanente.
- Autoriser tout avec +all ce mécanisme correspond à toutes les sources et détruit la valeur d’autorisation de SPF.
- Empiler les include sans vérifier les recherches DNS et les services devenus inutiles.
- Oublier le domaine de retour alors que c’est lui que SPF évalue, pas nécessairement le champ « De ».
- Retirer un flux rare trop vite comme la facturation mensuelle, les avis annuels ou la récupération de compte.
Questions fréquentes
Puis-je avoir plusieurs enregistrements SPF ?
Pas pour le même nom. Une évaluation qui sélectionne plusieurs enregistrements SPF produit une erreur permanente. Les autorisations doivent être réunies dans un seul enregistrement cohérent.
Les rapports DMARC montrent-ils toutes les sources ?
Ils montrent les flux observés par les destinataires qui participent aux rapports, pas un inventaire garanti de toute l’organisation. Croisez-les avec les propriétaires de processus et les journaux des fournisseurs.
Faut-il terminer SPF avant de configurer DKIM ?
Non. Les deux peuvent progresser ensemble. Pour DMARC, un seul mécanisme aligné doit réussir; DKIM est souvent la voie la plus stable pour les services tiers.
Votre enregistrement SPF est devenu illisible ?
Une revue de domaine peut établir les sources, les dépendances DNS et le plan de correction avant tout durcissement DMARC.
Faire vérifier le domaine Revenir au guide DMARC