Defaults.Exposed › Corrections › Guides

SPF échoue pour vos outils SaaS ? Pourquoi cela arrive et l'ordre de correction — édition Europe (2026)

Publié 2026-07-08

Chiffres au 2026-06-29 · méthodologie v7. Données de recensement agrégées sur 261 millions de domaines évalués. Voir comment nous notons.

Quand un outil SaaS « échoue SPF », votre enregistrement n’est généralement pas le problème : le courrier échoue l’alignement DMARC, ou votre chaîne d’includes a dépassé la limite de 10 lookups DNS de SPF. 2 119 539 des 138 927 207 domaines publiant SPF sont à 9–10 lookups — à un include SaaS du gouffre — selon le recensement Defaults.Exposed portant sur 261 086 232 domaines.

Ci-dessous : comment déterminer lequel des deux problèmes vous avez, puis l’ordre de correction — scanner d’abord, trouver le domaine depuis lequel l’outil envoie réellement, faire passer le fournisseur au DKIM en domaine personnalisé, et n’ajouter un include SPF que là où cela aide vraiment — plus les spécificités pour HubSpot, Salesforce, Mailchimp et SendGrid.

Pourquoi le courrier d’un outil SaaS échoue-t-il SPF ?

Trois schémas couvrent presque tous les cas :

Données au 2026-06-29.

La ligne en gras est là où se trouve la plupart des gens. Ajouter des lignes include: pour chaque outil n’y change rien — et chaque ligne vous rapproche de la deuxième ligne : au moins 797 263 domaines ont déjà dépassé la limite de 10 lookups, et leur SPF retourne désormais un PermError qui ne protège rien. Chiffres complets dans le rapport SPF PermError.

Quel domaine SPF vérifie-t-il réellement ?

Pas celui de votre en-tête From. Les destinataires évaluent SPF contre le domaine du Return-Path (le RFC5321.MailFrom, aussi appelé adresse de rebond ou envelope-from) — l’en-tête From que voit votre destinataire ne joue aucun rôle dans la vérification SPF elle-même.

Ce seul fait explique la plupart des « échecs SPF SaaS ». Votre plateforme marketing envoie avec un Return-Path du type [email protected] ; SPF est vérifié contre vendor.com et passe proprement. Puis DMARC demande si ce domaine vérifié par SPF correspond à votre domaine From. Ce n’est pas le cas, donc la branche SPF de DMARC échoue et votre tableau de bord dit « SPF échoue ». Modifier votre propre enregistrement SPF ne peut pas corriger cela — votre enregistrement n’a jamais été consulté.

Quel est l’ordre de correction ?

1. Lancez d’abord le scan gratuit. Il vous dit en une passe si votre SPF est manquant, dupliqué, au-dessus de la limite de lookups ou correct, et où en est DMARC — avant que vous touchiez au DNS.
2. Trouvez le Return-Path que l’outil utilise réellement. Envoyez-vous un test depuis l’outil et lisez l’en-tête Return-Path (et Authentication-Results) dans le message brut. Cela vous indique dans quelle ligne du tableau ci-dessus vous vous trouvez.
3. Activez le DKIM en domaine personnalisé du fournisseur. Chaque outil SaaS sérieux propose « l’authentification de domaine » : quelques enregistrements CNAME qui lui permettent de signer DKIM en tant que votre domaine. Cette signature s’aligne avec votre domaine From, donc DMARC passe via DKIM — durablement, et même quand le courrier est transféré. C’est le correctif qui dure.
4. Ajoutez l’include SPF du fournisseur seulement s’il utilise votre return-path — vous avez activé son domaine de rebond personnalisé, ou il envoie réellement avec votre domaine dans l’enveloppe. Un include pour un fournisseur qui rebondit via son propre domaine n’apporte rien et dépense votre budget de lookups.
5. Comptez vos lookups DNS avant d’enregistrer. La limite est de 10 lookups résolus, les includes comptent de façon récursive, et 2 119 539 domaines sont déjà à 9–10 — le p99 du recensement est 9. Proche de la limite ? Retirez d’abord les includes des outils que vous n’utilisez plus. Vous venez de changer de prestataire de messagerie ? Vérifiez s’il reste un second enregistrement — deux enregistrements SPF équivalent à un PermError.
6. Relancez le scan et confirmez. SPF passe sur le bon domaine, DKIM est aligné, DMARC passe. La référence complète se trouve sur comment corriger SPF ; des guides par prestataire comme SPF sur GoDaddy et DMARC sur IONOS couvrent les clics dans les panneaux DNS.

Que devriez-vous faire pour HubSpot, Salesforce, Mailchimp et SendGrid ?

HubSpot. Connectez votre domaine d’envoi dans les réglages de HubSpot et publiez les deux CNAME DKIM qu’il fournit (hs1-… / hs2-…). Cela aligne DKIM avec votre domaine From. Vous n’avez pas besoin d’un include SPF HubSpot sauf si vous avez configuré HubSpot pour utiliser votre propre domaine de rebond.

Salesforce. Créez une clé DKIM dans Salesforce Setup et publiez la paire de CNAME qu’il génère. Si Salesforce envoie avec le return-path de votre organisation, ajoutez include:_spf.salesforce.com et configurez le domaine de rebond — c’est le grand CRM où l’include SPF est souvent réellement nécessaire.

Mailchimp. Authentifiez votre domaine et publiez les CNAME DKIM k2 / k3. L’alignement Mailchimp est DKIM uniquement — il n’y a plus d’include SPF à ajouter, et en ajouter un depuis un vieux tutoriel ne fait que gaspiller des lookups.

SendGrid. Complétez l’authentification de domaine (« sécurité automatisée ») : trois CNAME gérant à la fois DKIM et le return-path sur votre propre sous-domaine. Aucun include SPF nécessaire. Sur les 740 321 domaines dont le SPF autorise sendgrid.net, seuls 18,0% ont un DMARC appliqué (données au 2026-06-29) — la plupart des expéditeurs SendGrid s’arrêtent une étape trop tôt.

Zendesk et tous les autres : même schéma. Trouvez la page « authentification de domaine » de l’outil, publiez ses CNAME DKIM, et ne touchez à SPF que si l’outil documente qu’il utilise votre return-path.

SPF est-il différent pour les entreprises européennes ?

Non — SPF, DKIM et DMARC fonctionnent de façon identique partout. Ce qui diffère en Europe, c’est le contexte : qui pose la question, et ce que vos voisins ont déjà fait.

Votre ccTLD fixe la barre locale. Les ccTLD européens publient SPF bien au-dessus des taux .com, mais les domaines qui finissent le travail — une politique DMARC appliquée par-dessus — sont la minorité partout :

Données au 2026-06-29. France : 13,65% de DMARC appliqué ; Italie : 5,24%.

Le défaut de votre hébergeur européen compte. 4 346 526 domaines autorisent les serveurs de messagerie EU d’IONOS (_spf-eu.ionos.com) dans leur SPF — et seuls 0,3% se terminent par un -all strict, avec 1,0% en DMARC appliqué. Les 2 132 049 d’OVH font mieux sur la rigueur (43,7%) mais seuls 2,2% appliquent DMARC (données au 2026-06-29). Si vous n’avez jamais touché à votre enregistrement, vous êtes sur ces défauts.

Les régulateurs le nomment désormais. L’article 21(2)(j) de NIS2 exige des entités dans son périmètre qu’elles sécurisent leurs communications, et le règlement d’exécution de la Commission (UE) 2024/2690 détaille les mesures de sécurité e-mail et DNS. L’authentification e-mail est la pièce concrète, vérifiable — et, chose rare pour la conformité, gratuite à corriger.

Sur la résidence des données : le scanner et le recensement Defaults.Exposed tournent sur AWS eu-west-1, nous ne publions que des chiffres agrégés, et un scan ne vérifie que le domaine que vous demandez.

Questions fréquentes

Mon vérificateur SPF dit « pass » mais le tableau de bord de l’outil dit que SPF échoue — pourquoi ? Le vérificateur a testé votre enregistrement ; le destinataire a testé le domaine du Return-Path que l’outil a réellement utilisé, puis DMARC l’a comparé à votre domaine From. C’est un échec d’alignement, pas un échec d’enregistrement — corrigé avec le DKIM en domaine personnalisé du fournisseur, pas avec des modifications SPF.

Devrais-je simplement ajouter l’include SPF pour chaque outil que nous utilisons ? Non. Chaque include dépense une partie du budget de 10 lookups de SPF, de façon récursive : 2 119 539 des 138 927 207 domaines publiant SPF sont à 9–10 lookups, et au moins 797 263 sont au-dessus — leur SPF retourne un PermError et ne protège rien (données au 2026-06-29).

L’include corrige-t-il aussi DMARC ? Seulement si l’outil envoie avec votre return-path, donc si SPF passe et s’aligne. Pour la plupart des outils SaaS, ce n’est pas le cas — c’est pourquoi le DKIM aligné, pas SPF, est la branche qui fait passer DMARC pour le courrier SaaS.

Est-ce une obligation légale dans l’UE ? Pour les entités dans le périmètre de NIS2, l’article 21(2)(j) et le règlement d’exécution (UE) 2024/2690 font de la sécurité e-mail une obligation. Même hors périmètre, les assureurs et questionnaires clients le demandent de plus en plus — et au 2026-06-29, aucun ccTLD européen n’amène même un tiers de ses domaines à une politique DMARC appliquée (29,43% pour .nl au mieux ; 5,24% pour .it).

Envoyez le rapport au propriétaire

Une fois les CNAME en ligne, relancez le scan et transmettez le rapport noté au chef d’entreprise ou au client. Il montre, en langage clair, ce qui échouait, ce que vous avez corrigé et où en est désormais le domaine — exactement la preuve dont il a besoin pour le renouvellement d’assurance ou le questionnaire de sécurité client, par écrit plutôt que sur votre parole.

Vérifiez votre domaine gratuitement

Voyez exactement quelle branche de SPF, DKIM et DMARC échoue — en privé et réservé au propriétaire.

Vérifiez votre domaine → · Corriger SPF → · SPF PermError : « too many DNS lookups » → · Comment nous notons → · Données agrégées uniquement. Données stockées et traitées dans l’UE.