SPF (Sender Policy Framework)

SPF (Sender Policy Framework) est un protocole d'authentification email qui publie, via un enregistrement DNS TXT, la liste des serveurs autorisés à envoyer des emails au nom de votre domaine. Quand un serveur destinataire reçoit un email prétendument issu de `prospkt.fr`, il interroge l'enregistrement SPF du domaine et vérifie que l'IP source figure bien dans la liste autorisée. SPF est l'un des trois piliers d'authentification email obligatoires en 2026 (avec DKIM et DMARC) et un prérequis pour atteindre la boîte de réception principale.

Comment SPF fonctionne

SPF s'appuie sur un seul enregistrement DNS de type TXT, ajouté à la zone DNS du domaine expéditeur. Exemple :

prospkt.fr.    TXT    "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.42 -all"

Lecture :

  • v=spf1 : version du protocole.
  • include:_spf.google.com : autorise tous les serveurs déclarés par Google Workspace.
  • include:sendgrid.net : autorise SendGrid à envoyer pour ce domaine.
  • ip4:203.0.113.42 : autorise une IP statique précise.
  • -all : tout autre serveur est rejeté (fail strict).

Les 4 mécanismes de qualification

SymboleNomEffet
+PassAutorise (défaut)
?NeutralAucune position
~SoftFailSuspect — accepter mais marquer
-FailRejeter

Pour le cold email B2B, viser -all (strict). ~all (softfail) est toléré mais affaiblit le signal.

Limites natives de SPF

  1. 10 lookups DNS maximum : si votre enregistrement include trop de tiers (Google + SendGrid + Mailchimp + Lemlist…), vous dépassez le quota et SPF passe en permerror, ce qui équivaut à un échec.
  2. Cassé par les forwards : un email transféré change d'IP source, ce qui invalide SPF (DKIM rattrape ce cas).
  3. N'est pas suffisant seul : sans DKIM et DMARC, un domaine SPF-only n'est plus considéré comme correctement authentifié depuis février 2024 par Gmail et Yahoo.

Erreurs les plus fréquentes

  • Plusieurs enregistrements SPF sur un même domaine : invalide, doit être fusionné en un seul.
  • Oubli d'un fournisseur lors d'un changement (passage de Mailchimp à Brevo) → les emails partent en spam silencieusement.
  • +all à la fin : ouvre la porte à n'importe quel spammeur usurpant votre domaine.

Application concrète

Checklist SPF en 5 minutes :

  1. Lister tous les services qui envoient des emails pour votre domaine (Google Workspace, CRM, outil de cold email, Stripe, transactionnel, etc.).
  2. Construire un seul enregistrement SPF combinant tous les include: correspondants.
  3. Tester via mxtoolbox.com/spf.aspx — vérifier l'absence d'erreurs et le respect du quota 10 lookups.
  4. Publier dans la zone DNS, terminer par -all (jamais +all).
  5. Re-vérifier 24h après propagation, et à chaque ajout d'un nouvel outil d'emailing.

Astuce avancée : pour les setups complexes (> 10 lookups), utiliser un service de flattening SPF (DMARCLY, EasyDMARC) qui résout dynamiquement les include en IPs statiques pour rester sous le quota.

Comment Prospkt utilise ce concept

Prospkt n'envoie pas d'email lui-même. La plateforme se positionne en couche données : enrichissement, scoring, signaux. Vous restez donc maître de votre infrastructure SPF/DKIM/DMARC sur votre outil d'envoi (Lemlist, Instantly, Smartlead, etc.). Notre rôle est de garantir qu'en amont, la donnée envoyée est propre — emails vérifiés, contacts actifs — pour que votre SPF ne soit jamais sollicité sur des destinataires invalides.

Voir en action sur Prospkt

Définitions associées

Cold email B2B

Le cold email B2B est un email de prospection envoyé à un contact professionnel sans interaction préalable, dans le but d'initier une conversation commerciale et de générer des opportunités de vente.

Lire la définition →

Délivrabilité email

La délivrabilité email désigne la capacité d'un email à atteindre la boîte de réception principale du destinataire — et non l'onglet Promotions, l'onglet Spam ou un rejet pur et simple. C'est l'indicateur composite qui résulte de l'authentification du domaine (SPF, DKIM, DMARC), de la réputation de l'IP et du domaine expéditeur, de la qualité de la liste, du contenu de l'email et du comportement des destinataires. En cold email B2B, une délivrabilité inférieure à 85 % rend toute campagne non viable, peu importe la qualité du copywriting.

Lire la définition →

DKIM (DomainKeys Identified Mail)

DKIM (DomainKeys Identified Mail) est un protocole d'authentification email qui ajoute une signature cryptographique à chaque message envoyé. Cette signature, calculée à partir d'une clé privée détenue par l'expéditeur, est vérifiée côté destinataire à l'aide d'une clé publique publiée dans le DNS du domaine. DKIM prouve deux choses : l'email provient bien du domaine prétendu, et son contenu n'a pas été altéré en transit. C'est le deuxième pilier d'authentification après [SPF](/glossaire/spf-sender-policy-framework) et un prérequis pour DMARC en mode `reject`.

Lire la définition →

DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance) est le protocole qui orchestre [SPF](/glossaire/spf-sender-policy-framework) et [DKIM](/glossaire/dkim-domainkeys-identified-mail) en publiant une politique claire : que faire si l'un de ces deux protocoles échoue ? Accepter, marquer comme suspect ou rejeter ? DMARC ajoute aussi un canal de reporting qui remonte chaque jour les emails envoyés sous votre domaine, légitimes ou usurpés. Depuis février 2024, DMARC en mode au moins `none` (mode reporting) est exigé par Gmail et Yahoo pour tout expéditeur de plus de 5 000 emails/jour.

Lire la définition →

Questions fréquentes

SPF tout seul suffit-il pour envoyer du cold email ?
Non. Depuis février 2024, Gmail et Yahoo exigent SPF + DKIM + DMARC alignés pour les expéditeurs de plus de 5 000 emails/jour. SPF seul vous expose à un placement spam systématique.
Que se passe-t-il si SPF dépasse 10 lookups DNS ?
L'enregistrement passe en état `permerror` (erreur permanente), considéré comme un échec de validation. Les emails sont alors traités comme non authentifiés. Solution : SPF flattening ou consolidation des fournisseurs.
Faut-il utiliser `-all` ou `~all` ?
`-all` (fail strict) est recommandé en production pour une protection maximale et un signal d'authentification fort. `~all` (softfail) peut servir en phase de migration ou de test, mais devrait toujours être migré vers `-all` une fois la configuration stabilisée.
SPF protège-t-il contre le phishing ?
Partiellement. SPF empêche un attaquant d'usurper votre domaine sur l'enveloppe SMTP, mais ne couvre pas l'usurpation du champ From visible (display name spoofing). Pour ça, il faut DMARC en mode `reject`.

Sur le même sujet

Prêt à transformer votre prospection ?

Découvrez comment Prospkt peut vous aider à identifier et contacter vos futurs clients plus efficacement.

Commencer gratuitement