Compte gratuit

Gardez vos requêtes sous contrôle

Créez un compte en moins de 30 secondes pour conserver 6 mois d'historique, partager vos requêtes et déclencher des alertes email ou webhook sur chaque diff.

  • Historique consultable 6 mois
  • Alertes diff email & webhook
  • Surveillance des pics de latence
S'inscrire

Vérificateur de syntaxe SPF

Comprendre la structure d'un enregistrement SPF

Le Sender Policy Framework (SPF) définit quelles machines sont autorisées à envoyer des e-mails pour votre domaine. La politique est publiée dans un enregistrement TXT commençant par v=spf1 suivi d'une liste de mécanismes et de modificateurs. Cette page détaille ce que le validateur contrôle et comment interpréter la réponse de l'API.

Anatomie d'une règle SPF

Un enregistrement SPF est une suite de termes séparés par des espaces. Chaque terme peut débuter par un qualificateur (+, -, ~, ?), être suivi d'un mécanisme (ip4, mx, include...) ou d'un modificateur (redirect=, exp=).

v=spf1 ip4:203.0.113.0/24 include:_spf.example.net -all

Éléments indispensables

  • v=spf1 — la version doit être présente et positionnée en début d'enregistrement.
  • Mécanismes — au moins un mécanisme (ip4, ip6, mx, include...) définit les expéditeurs autorisés.
  • Directive finale — un mécanisme terminal (-all, ~all, ?all ou +all) clôture la politique et indique comment traiter les messages non correspondants.

Modificateurs optionnels

  • include: enchaîne un autre enregistrement SPF et déclenche des requêtes DNS supplémentaires.
  • redirect= délègue l'évaluation à un autre domaine. Il doit apparaître en dernier et ne peut pas coexister avec all.
  • exp= pointe vers un TXT d'explication. Ce champ est obsolète et purement informatif.

Pièges fréquents détectés par l'outil

  1. Enregistrement trop long. Au-delà de 450 caractères, la politique est rejetée.
  2. Termes inconnus ou dupliqués. Les mécanismes mal orthographiés et les modificateurs répétés génèrent des erreurs.
  3. Préfixes IP ou domaines invalides. Le validateur vérifie la syntaxe des réseaux CIDR et des noms d'hôtes.
  4. Limites de requêtes dépassées. L'analyse SPF s'arrête après 10 requêtes DNS cumulant include, mx, a, ptr et exists.
  5. Politiques permissives. Le qualificateur ? et +all diminuent la protection et s'affichent comme avertissements.

Ce que contrôle le validateur

  • Enveloppe de l'enregistrement — valeur vide, absence de v=spf1, guillemets finaux ou caractères parasites déclenchent des erreurs de syntaxe.
  • Mécanismes et modificateurs — les termes inconnus ou dupliqués (unknown_mechanism, unknown_modifier, duplicate_modifier) sont rejetés ; redirect doit apparaître une seule fois, en dernier, et jamais avec all.
  • Valeurs et opérandes — un argument manquant ou mal formé pour include, a, mx, exists, ip4, ip6 ou redirect remonte mechanism_missing_value / mechanism_invalid_value.
  • Fins de politique et qualificateurs faibles — les multiples all, les qualificateurs neutres ? et les terminaisons permissives s'affichent en avertissements pour inciter au durcissement.
  • Pression DNS — boucles, plus de 10 requêtes ou trop de réponses vides (lookup_limit_exceeded, lookup_cycle, void_lookup_limit_exceeded) sont signalées avec un compteur pour éviter un permerror SPF en production.

Bonnes pratiques avant publication

  • Simplifiez la règle et supprimez les mécanismes inutiles pour rester sous les limites de requêtes.
  • Préférez des plages ip4 et ip6 maîtrisées par votre organisation ou votre prestataire.
  • Documentez chaque chaîne include et vérifiez régulièrement les domaines délégués.
  • Testez la valeur finale avec ce validateur puis interrogez le DNS une fois publiée pour confirmer la propagation.

En validant la syntaxe avant publication, vous limitez le risque d'une politique SPF cassée et évitez les investigations longues lorsque les messages commencent à être refusés.