Defaults.Exposed › Corrections › SPF (Sender Policy Framework)

Comment corriger SPF (Sender Policy Framework)

Le SPF est la ligne, dans les réglages de votre domaine, qui liste les services de messagerie autorisés à envoyer des e-mails au nom de votre entreprise. Sans elle, n'importe qui dans le monde peut envoyer un e-mail qui semble venir de vous — et vos propres e-mails légitimes risquent davantage d'atterrir dans les spams de vos clients.

En clair, pour votre entreprise : N'importe qui peut envoyer des e-mails en se faisant passer pour votre entreprise — à vos clients, vos équipes et vos fournisseurs — factures, demandes de changement de coordonnées bancaires, tout y passe. Dans le même temps, vos vrais devis et factures risquent davantage de finir à la corbeille, et des affaires s'enlisent sans bruit.

Ce que cela peut vous coûter

Un escroc envoie à votre client une facture « de votre part » avec ses propres coordonnées bancaires, et se fait payer. Vous l'apprenez des semaines plus tard quand le client demande où sont ses marchandises — et c'est désormais votre réputation, et peut-être votre responsabilité, qui est en jeu.
Vos devis, factures et réponses atterrissent discrètement dans les spams de vos clients parce que les grands fournisseurs ne peuvent pas vérifier qu'ils viennent vraiment de vous. Les affaires refroidissent et vous n'en saurez jamais la raison.
Un escroc se fait passer pour le dirigeant ou le responsable financier et écrit aux équipes pour réclamer un paiement urgent ou des cartes cadeaux — le message semble réellement venir de votre domaine, alors quelqu'un paie.
Le service informatique ou sécurité d'un prospect plus important contrôle votre domaine, ne voit aucune protection de l'expéditeur, et soit vous écarte, soit vous impose de corriger cela avant de signer — vous coûtant l'affaire ou des semaines de retard.
Vous vous croyez protégé parce qu'un enregistrement SPF existe — mais il est en « soft fail » sans rien pour l'imposer, ou bien il est cassé en silence, si bien que les e-mails usurpés passent quand même.

Pourquoi c'est important. Falsifier l'adresse d'expéditeur d'un e-mail est d'une simplicité enfantine et ne coûte rien à un attaquant. Le SPF est le moyen le moins cher et le plus rapide de rendre votre domaine plus difficile à usurper et de garder vos e-mails légitimes hors des spams. Google et Yahoo mettent désormais activement à la corbeille ou rejettent les e-mails des domaines non authentifiés ; ce n'est donc plus une option — c'est le minimum requis pour que vos e-mails soient simplement distribués.

En bref

À l’heure actuelle, à moins d’avoir correctement configuré le SPF, n’importe qui dans le monde peut envoyer un e-mail qui semble venir de votre entreprise. Cette personne peut envoyer de fausses factures à vos clients, de fausses demandes de paiement à vos équipes, et écrire à vos fournisseurs comme si c’était vous — et les messages auront l’air authentiques, parce que rien sur votre domaine n’indique le contraire.

Le SPF (Sender Policy Framework) est la solution. C’est une simple ligne de texte dans les réglages de votre domaine qui liste les services de messagerie réellement autorisés à envoyer en votre nom. Les fournisseurs destinataires — Gmail, Outlook, tous — consultent cette liste avant de décider si un message est authentique. Pas de liste, ou une liste faible, et ils n’ont rien sur quoi s’appuyer.

Cette page traite de deux choses qui doivent toutes deux être correctes : l’existence même d’un enregistrement SPF, et le fait qu’il soit réglé assez strictement pour réellement jouer son rôle.

Ce que cela peut vous coûter

Voici les façons concrètes et quotidiennes dont un enregistrement SPF absent ou faible se traduit par de l’argent et de la confiance qui s’envolent. Nous ne nommons jamais d’entreprise réelle — ce sont les schémas que nous observons dans les données.

La facture détournée. Un escroc envoie à l’un de vos clients un e-mail qui semble exactement venir de vous, avec une facture d’apparence authentique portant son propre compte bancaire. Votre client la paie. La première chose que vous apprenez, c’est une relance demandant où en est la commande. Vous voilà avec un client en colère, un paiement parti chez un escroc, et une discussion délicate sur qui assume la perte.
L’arnaque au dirigeant. Quelqu’un écrit à votre comptable « de la part » du dirigeant : « Petit service — peux-tu faire passer ce paiement avant la fin de journée ? » Comme le message semble réellement venir de votre domaine, il ne déclenche aucune méfiance. L’argent quitte l’entreprise.
La taxe silencieuse de délivrabilité. Vos devis et factures commencent à atterrir dans les spams de vos clients parce que Gmail et Yahoo ne peuvent pas vérifier qu’ils viennent vraiment de vous. Pas de rejet, pas d’erreur — les affaires deviennent simplement muettes. Vous perdez du chiffre d’affaires sans même pouvoir le constater.
Le contrat perdu. L’équipe achats ou sécurité d’un client plus important effectue un contrôle de base sur votre domaine lors de l’intégration. Elle ne voit aucune authentification de l’expéditeur et vous signale comme un risque. Au mieux, vous corrigez dans l’urgence ; au pire, le client choisit un concurrent qui a réussi le test.
La vague d’empoisonnement de marque. Votre domaine est utilisé dans une campagne d’hameçonnage visant le public. Les personnes piégées se méfient désormais de tout e-mail portant votre nom — si bien que même vos vraies offres et vos renouvellements sont ignorés ou signalés.

Le fil rouge de tout cela : l’attaquant ne dépense rien, et c’est votre entreprise qui en porte le coût et le blâme.

Ce que c’est réellement

Quand un e-mail arrive, le serveur de messagerie destinataire veut savoir une chose : cet e-mail vient-il vraiment de qui il prétend venir ? Le SPF répond à une partie de cette question.

Vous publiez une courte ligne de texte dans les réglages DNS de votre domaine — un « enregistrement TXT » — qui nomme les services de messagerie autorisés à envoyer en votre nom. Quelque chose comme :

v=spf1 include:_spf.google.com include:sendgrid.net -all

En clair, cela se lit ainsi : « Nos vrais e-mails proviennent des serveurs de Google et de ceux de SendGrid — rejetez tout le reste prétendant venir de nous. »

Les deux éléments qui comptent pour votre note :

L’enregistrement existe-t-il ? C’est le plus important (c’est le contrôle e-mail qui pèse le plus lourd à lui seul). Pas d’enregistrement signifie que les destinataires n’ont aucune liste à consulter, donc l’usurpation est grande ouverte. Il y a aussi un mode de défaillance subtil ici : si votre domaine possède deux enregistrements SPF ou plus, les règles prévoient que tous sont invalides — vous n’avez donc en réalité aucun SPF, même si l’inverse semble vrai.
La politique est-elle assez stricte ? Un enregistrement peut exister tout en restant inoffensif. La terminaison — le mécanisme « all » — est l’instruction donnée aux destinataires :
- -all (hard fail) — rejeter tout ce qui ne figure pas sur la liste. Le plus fort. Note maximale.
- ~all (soft fail) + DMARC réglé sur reject — la configuration moderne recommandée. Protection équivalente au hard fail, sans le risque de voir des e-mails légitimes transférés rejetés. Note maximale.
- ~all + DMARC réglé sur quarantine — acceptable, légèrement plus faible ; passez DMARC à reject pour une protection complète.
- ~all seul (sans application DMARC) — faible. Cela dit « probablement faux, distribuez quand même ». Les e-mails usurpés passent toujours. C’est le piège dans lequel beaucoup d’entreprises tombent en se croyant protégées.
- ?all (neutre) — n’offre aucune protection.
- +all — activement dangereux : il dit au monde entier que n’importe qui peut envoyer en votre nom. Ne l’utilisez jamais.

Il existe encore une défaillance invisible : le SPF n’a le droit de déclencher que jusqu’à 10 recherches DNS lors de son évaluation. Empilez trop d’entrées include: et l’enregistrement dépasse cette limite ; à ce moment-là, les destinataires considèrent l’ensemble comme cassé — et vous revoilà sans protection. C’est un problème courant et silencieux pour les entreprises utilisant beaucoup d’outils marketing et SaaS.

À quoi ressemble le « bon » réglage : exactement un enregistrement SPF, listant tous les services qui envoient légitimement en votre nom, se terminant par -all (ou ~all associé à un DMARC en p=reject), et restant confortablement sous la limite des 10 recherches.

Comment corriger (gratuit, ~10 minutes)

Transmettez cette section à la personne qui gère votre domaine ou votre site web — et notez que la correction est gratuite. Il s’agit de modifier un réglage DNS, pas d’acheter un produit. Nous facturons uniquement la surveillance du maintien de cette configuration dans le temps, pas la modification elle-même.

Étape 1 — Listez tous les services qui envoient des e-mails en votre nom. C’est là que les gens se trompent. Notez-les tous : votre fournisseur de boîte mail (Google Workspace, Microsoft 365, etc.), plus tout outil d’infolettre, CRM, service d’assistance, plateforme e-commerce, logiciel de facturation/comptabilité et système de réservation. Si un service envoie des e-mails à votre nom et que vous l’oubliez, votre SPF bloquera ses e-mails dès que vous durcirez la politique.

Étape 2 — Publiez un enregistrement TXT au niveau de votre domaine racine. Combinez les lignes « include » de tous vos expéditeurs en un seul enregistrement. Par plateforme courante :

Google Workspace : include:_spf.google.com
Microsoft 365 : include:spf.protection.outlook.com
SendGrid : include:sendgrid.net
Mailchimp : include:servers.mcsv.net
Zoho : include:zoho.eu (ou le domaine correspondant à votre région)

Un enregistrement combiné ressemble à :

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net -all

Où l’ajouter, selon le fournisseur :

Cloudflare : DNS → Records → Add record → Type TXT, Name @, Content = la valeur ci-dessus.
Admin Microsoft 365 / Google : ils publient la chaîne « include » exacte à utiliser dans leur assistant de configuration ; copiez-la dans l’enregistrement TXT de votre hébergeur DNS.
GoDaddy / la plupart des hébergeurs : gestion DNS → Add → TXT, Host/Name @, Value = l’enregistrement.

Étape 3 — Commencez prudemment, puis appliquez. Le temps de confirmer que votre liste d’expéditeurs est complète, publiez avec ~all (soft fail) afin que rien de légitime ne soit bloqué par accident. Une fois que vous avez confirmé que tous vos vrais e-mails circulent toujours, durcissez vers -all (hard fail) — ou, mieux, conservez ~all et ajoutez une politique DMARC en p=reject, qui est l’association moderne recommandée.

Étape 4 — Assurez-vous d’avoir exactement UN enregistrement. Si un ancien enregistrement SPF existe déjà, modifiez celui-là plutôt que d’en ajouter un second. Deux enregistrements v=spf1 s’annulent mutuellement et vous laissent sans protection.

Étape 5 — Surveillez le nombre de recherches. Si vous avez de nombreux expéditeurs, vous pouvez dépasser la limite des 10 recherches. Si cela arrive, consolidez — certains fournisseurs proposent le « SPF flattening », ou retirez les expéditeurs que vous n’utilisez plus.

Étape 6 — Recontrôlez votre domaine pour confirmer qu’il réussit désormais, avec l’enregistrement présent et la politique stricte.

Erreurs fréquentes

Deux enregistrements SPF. La défaillance silencieuse la plus fréquente. Ajouter un nouvel enregistrement au lieu de modifier l’existant invalide les deux. Il ne doit y en avoir qu’un seul.
S’arrêter à ~all en se croyant fini. Le soft fail sans DMARC derrière est le compromis faible — il a l’air configuré mais ne vous protège quasiment pas. Passez à -all, ou associez ~all à un DMARC p=reject.
Oublier un expéditeur. Durcir vers -all avant d’avoir listé votre logiciel de facturation, votre CRM ou votre outil d’infolettre commencera à bloquer vos propres e-mails légitimes. Listez tout d’abord.
Dépasser la limite des 10 recherches. Chaque include: peut enchaîner d’autres recherches. Trop nombreuses, et l’enregistrement est considéré comme cassé. Gardez-le léger.
Utiliser +all. Cela autorise explicitement tout l’Internet à envoyer en votre nom. C’est pire que de n’avoir aucun enregistrement. Ne le publiez jamais.

Où cela s’inscrit

Le SPF est la fondation, mais il n’est qu’une des trois couches. DKIM ajoute une signature cryptographique prouvant qu’un message n’a pas été altéré, et DMARC est l’instruction qui relie SPF et DKIM et dit aux destinataires ce qu’ils doivent réellement faire des e-mails en échec — y compris bloquer l’usurpation du nom d’expéditeur visible que voient vos clients. Réglez d’abord correctement le SPF (c’est le gain le plus rapide et celui qui pèse le plus lourd), puis ajoutez DKIM et DMARC pour fermer complètement la porte. Les trois corrections sont gratuites.

Configurez-le chez votre hébergeur

Étape par étape pour les fournisseurs courants :

FAQ

Je ne suis pas technique — puis-je m'en occuper moi-même ?

Vous n'avez pas besoin de comprendre les détails. La modification consiste en une ou deux lignes ajoutées aux réglages de votre domaine, faite par la personne qui gère votre site web ou votre prestataire informatique. Transmettez-leur la section « Comment corriger » ci-dessous — cela prend généralement quelques minutes, et c'est gratuit. Nous facturons uniquement la surveillance pour vérifier que tout reste correct dans le temps.

Nous avons déjà un enregistrement SPF — cela veut-il dire que nous sommes couverts ?

Pas forcément. Avoir un enregistrement, c'est la première moitié ; l'avoir réglé de façon stricte, c'est la seconde. Un enregistrement se terminant par « ~all » (soft fail) sans DMARC derrière dit aux serveurs destinataires « c'est peut-être faux, mais distribuez-le quand même » — ce qui n'offre qu'une protection minime. Deux enregistrements SPF, ou un seul qui effectue trop de recherches, est considéré comme cassé et ne vous protège pas du tout, même s'il a l'air d'exister. Les deux moitiés doivent être correctes.

La correction risque-t-elle de casser mes propres e-mails par accident ?

C'est possible si l'enregistrement oublie un expéditeur légitime — par exemple votre logiciel de facturation ou votre outil d'infolettre qui envoie en votre nom. C'est précisément pourquoi l'approche sûre consiste à lister d'abord tous les services qui envoient en votre nom, à publier avec un « ~all » souple le temps de confirmer que rien ne manque, puis à durcir vers le hard fail. Fait dans cet ordre, cela ne cassera rien.

Quelle est la différence entre « ~all » et « -all », et lequel devons-nous utiliser ?

« -all » (hard fail) dit aux destinataires de rejeter tout ce qui ne figure pas sur votre liste — le réglage le plus fort. « ~all » (soft fail) dit « probablement pas légitime, mais acceptez-le quand même ». La meilleure pratique moderne recommande « ~all » combiné à une politique DMARC en « reject » — ce duo offre la même protection que « -all » sans le risque de voir des e-mails transférés rejetés. « ~all » seul, sans DMARC pour l'imposer, est la configuration faible à éviter.

Le SPF arrêtera-t-il à lui seul toute usurpation d'e-mail ?

Non — c'est la première couche essentielle, pas la réponse complète. Le SPF indique quels serveurs peuvent envoyer pour vous, mais il ne dit pas aux destinataires quoi faire en cas d'échec, et il ne couvre pas le nom d'expéditeur visible que voit l'utilisateur. Pour verrouiller totalement l'usurpation, il vous faut aussi DKIM et DMARC. Le SPF est la première étape la plus rapide et la plus efficace : commencez ici, puis ajoutez les deux autres.

Combien de temps avant que cela prenne effet, et cela peut-il coûter quelque chose ?

Les modifications DNS prennent généralement effet en quelques minutes à quelques heures. La correction elle-même est toujours gratuite — il s'agit simplement de modifier un réglage chez votre fournisseur DNS. Quiconque vous dit qu'ajouter un enregistrement SPF nécessite un produit payant se trompe.