Analyse de l’enregistrement SPF (Sender Policy Framework) et évaluation de la politique d’envoi

1. Vue d’ensemble SPF Analysis

Cette ligne de votre rapport DNSprobe regroupe tout ce qui concerne votre politique SPF : enregistrement brut, vue parsée des mécanismes, domaines include, IP résolues et score final.

Pourquoi c’est important

SPF fait partie des briques de base de l’authentification du courriel. S’il est absent ou mal configuré, d’autres protections comme DMARC ou l’alignement seront bien moins efficaces.

Comment lire ce bloc

Commencez par vérifier en haut que le Host, la Value et le TTL correspondent à ce que vous avez configuré chez votre fournisseur DNS. Examinez ensuite les tableaux de mécanismes et de domaines include, puis la politique all et le score qui résument la sévérité de votre configuration.

Bonnes pratiques générales

• Publier exactement un seul enregistrement SPF pour un hôte donné, commençant par v=spf1.
• Garder la politique aussi simple et lisible que possible pour faciliter les évolutions futures.
• Utiliser le SPF Evaluation Score comme indicateur rapide, mais toujours valider les changements avec votre fournisseur de courriel.

2. Enregistrement SPF : Host, Value et TTL

L’en-tête du bloc SPF Analysis affiche l’hôte sur lequel vit la politique (souvent le domaine nu), la valeur TXT brute et son TTL en secondes.

Pourquoi c’est important

SPF est découvert via le DNS. Si l’enregistrement est publié au mauvais endroit, comporte une erreur dans le préfixe v=spf1 ou est mis en cache trop longtemps, les serveurs de réception peuvent mal interpréter votre politique.

Comment DNSprobe le vérifie

DNSprobe interroge vos serveurs DNS autoritaires pour les enregistrements TXT à l’apex du domaine et recherche celui qui commence par v=spf1. Il affiche ensuite le texte exact et le TTL retournés par le DNS.

Problèmes fréquents visibles ici

• Aucun enregistrement SPF, ou plusieurs chaînes v=spf1 publiées sur le même hôte.
• Texte SPF publié sur le mauvais nom d’hôte (par exemple uniquement sur mail.example.com au lieu de example.com).
• Ligne de version SPF mal formée ou préfixe v=spf1 manquant.

Bonnes pratiques pour l’enregistrement SPF

• Publier un seul enregistrement SPF à l’apex du domaine pour le trafic normal.
• Utiliser un TTL plutôt court tant que vous ajustez la politique, puis l’augmenter une fois la configuration stabilisée.
• Éviter de mélanger d’autres usages TXT dans le même enregistrement; garder SPF séparé.

3. Mécanismes SPF et cibles

La partie Parsed SPF du bloc détaille les mécanismes a, mx, ip4, ip6, exists, redirect, etc., et indique vers quelles cibles ils pointent et comment ils se résolvent.

Pourquoi les mécanismes sont importants

Chaque mécanisme est une règle qui peut faire passer ou échouer une IP émettrice. Comprendre les mécanismes utilisés revient à savoir quels systèmes sont autorisés à envoyer du courriel.

Comment DNSprobe interprète les mécanismes

DNSprobe lit la chaîne SPF de gauche à droite, extrait les mécanismes et leurs qualificateurs (+, -, ~, ?), et pour ceux basés sur des noms d’hôtes, résout les IP correspondantes. Ces informations sont affichées dans le tableau Mechanism / Target / Resolution.

Problèmes courants liés aux mécanismes

• Utiliser des mécanismes larges comme a ou mx sans s’assurer que tous les hôtes associés sont censés envoyer du courriel.
• S’appuyer sur des mécanismes obsolètes ou risqués comme ptr, ou sur des chaînes redirect très complexes.
• Inclure par erreur des infrastructures de test ou héritées qui ne devraient plus envoyer.

Bonnes pratiques pour les mécanismes

• Privilégier des plages ip4/ip6 explicites ou des mécanismes a/mx limités aux bons hôtes.
• Éviter autant que possible ptr et les redirections trop complexes.
• Réviser régulièrement la liste des IP résolues pour s’assurer qu’elles correspondent toujours à vos systèmes d’envoi.

4. Hôtes include et IP résolues

De nombreux fournisseurs vous demandent d’utiliser des mécanismes include: afin que leurs propres politiques SPF soient intégrées à la vôtre. DNSprobe affiche ces hôtes include et les plages IP qui en résultent.

Pourquoi les includes méritent votre attention

Les includes sont pratiques, mais chacun ajoute des requêtes DNS et importent des plages d’IP que vous ne contrôlez pas directement. Il est important de savoir quels fournisseurs peuvent envoyer en votre nom.

Comment DNSprobe développe les includes

Pour chaque include:host, DNSprobe récupère la politique SPF de ce domaine, collecte les plages IP correspondantes et les affiche dans le tableau Include Hosts / Resolved IPs. Il ajoute également leurs requêtes au compteur global de lookups SPF.

Problèmes typiques liés aux includes

• Trop d’includes imbriqués, ce qui amène à atteindre ou dépasser la limite de 10 requêtes DNS imposée par SPF.
• Anciens fournisseurs encore référencés via include: alors qu’ils n’envoient plus aucun courriel pour vous.
• Includes qui importent des plages IP extrêmement larges, autorisant involontairement de grands réseaux tiers.

Bonnes pratiques pour les includes

• Inclure uniquement les fournisseurs qui envoient réellement du courriel pour votre domaine.
• Auditer périodiquement les IP résolues pour confirmer qu’elles restent pertinentes.
• Surveiller le nombre total de lookups DNS et simplifier la politique avant d’atteindre la limite stricte des 10 requêtes.

5. Politique SPF all et score d’évaluation

En bas de la section Parsed SPF, DNSprobe résume le mécanisme all (par exemple -all, ~all, ?all, +all) et explique comment il traite les expéditeurs non autorisés, ainsi que le SPF Evaluation Score.

Pourquoi le mécanisme all est crucial

Le mécanisme all est la règle par défaut appliquée lorsqu’aucun mécanisme précédent ne correspond. Il détermine si les expéditeurs inconnus sont rejetés, considérés comme suspects ou acceptés.

Comment DNSprobe évalue votre politique all

DNSprobe lit le mécanisme all final, le qualifie de Fail (-all), SoftFail (~all), Neutral (?all) ou Pass (+all), puis combine cette information avec d’autres facteurs comme le nombre de lookups et la qualité de la syntaxe pour calculer un score sur 5. Une courte explication sous la politique all décrit l’effet concret.

Problèmes fréquents signalés ici

• Utiliser +all, qui autorise pratiquement n’importe quelle IP à envoyer du courriel pour votre domaine, ce qui est considéré comme une très mauvaise pratique.
• Absence de mécanisme all à la fin de la politique, laissant les serveurs de réception deviner comment traiter les expéditeurs inconnus.
• Dépassement de la limite de 10 requêtes DNS, ce qui amène certains serveurs à considérer l’évaluation SPF comme une erreur permanente.

Bonnes pratiques pour la politique all et le score

• Visez -all lorsque vous êtes sûr que tous vos systèmes légitimes d’envoi sont couverts.
• Utilisez ~all comme étape de transition pendant que vous surveillez DMARC et les journaux avant de passer à une politique plus stricte.
• Considérez le score et l’explication comme un guide, mais validez toujours les changements avec des tests et de la supervision réelle.

6. Tester les enregistrements SPF manuellement depuis votre propre terminal

DNSprobe analyse votre enregistrement SPF, résout les mécanismes include et met en évidence les problèmes potentiels comme des plages trop larges ou des adresses IP dupliquées. Vous pouvez inspecter vous-même l’enregistrement SPF brut depuis un terminal en interrogeant les enregistrements TXT et en filtrant la politique SPF.

Linux : utiliser dig (outils BIND)

Sur la plupart des distributions Linux, la commande dig est fournie par le paquet d’outils BIND. Les commandes suivantes interrogent tous les enregistrements TXT à la racine de votre domaine, puis se concentrent spécifiquement sur l’enregistrement SPF qui commence par v=spf1 :

                dig example.com TXT
                dig example.com TXT +short
    
                # Optionnel : filtrer les enregistrements TXT pour n’afficher que la politique SPF (la ligne qui commence par v=spf1)    
                dig example.com TXT | grep "v=spf1"
        

macOS : utiliser dig avec les outils intégrés

macOS inclut dig dans ses outils en ligne de commande. Ouvrez Terminal et exécutez les mêmes commandes que sous Linux pour lister les enregistrements TXT et isoler la politique SPF de votre domaine :

                dig example.com TXT
                dig example.com TXT +short
    
                # Optionnel : filtrer les enregistrements TXT pour n’afficher que la politique SPF (la ligne qui commence par v=spf1)    
                dig example.com TXT | grep "v=spf1"
        

Windows : utiliser nslookup

Sous Windows, l’outil historique nslookup permet d’interroger les enregistrements TXT de votre domaine. Exécutez les commandes suivantes dans une fenêtre Invite de commandes ou PowerShell, puis repérez la ligne TXT qui commence par v=spf1, qui correspond à votre politique SPF :

                nslookup -type=TXT example.com
    
                REM Optionnel : interroger les enregistrements TXT pour un hôte de messagerie spécifique (par exemple mail.example.com) plutôt que pour la racine du domaine    
                nslookup -type=TXT mail.example.com
        

Important : n’interrogez que les enregistrements DNS de domaines que vous possédez ou que vous êtes autorisé à analyser. Certains fournisseurs peuvent considérer des requêtes répétées et automatisées sur des domaines tiers comme du trafic abusif.