Un e-mail transféré échoue à SPF — pourquoi c'est incorrigible, et ce qui marche vraiment (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.

Vous ne pouvez pas faire passer SPF pour un e-mail transféré — le transfert casse SPF par conception, et la solution honnête est un DKIM aligné, qui survit au transfert. L’échelle est celle de tout le recensement : 7 355 985 des 138 927 207 domaines publiant du SPF autorisent le seul include de transfert de Namecheap, avec une part de SPF strict de <0.1 %, selon le recensement Defaults.Exposed de 261 millions de domaines.

Ci-dessous : pourquoi aucun enregistrement SPF que vous pourriez écrire ne survit au transfert, pourquoi SRS et ARC ne sont pas des outils que vous contrôlez, et la solution qui tient — la signature DKIM avec votre propre domaine comme pass DMARC — plus le seul cas qui casse aussi DKIM (les listes de diffusion qui réécrivent les messages) et quoi faire de ce résidu.

Pourquoi le transfert casse-t-il SPF ?

Les serveurs de réception évaluent SPF contre le domaine du Return-Path (RFC5321.MailFrom), pas l’en-tête From. Quand vous envoyez directement, l’IP de votre serveur figure dans votre enregistrement SPF et la vérification passe. Quand votre destinataire fait suivre automatiquement le message — vers un Gmail personnel, via un alias universitaire, par le produit de transfert d’un registrar — c’est le serveur du transféreur qui le retransmet, en gardant généralement votre domaine dans le Return-Path. Le récepteur final se demande alors : ce serveur de transfert est-il autorisé dans votre enregistrement SPF ?

Il ne l’est pas, et ne le sera jamais : vous n’avez pas choisi le transféreur, vous ignorez son existence, et le même message transféré demain via un autre service échouerait depuis une autre IP. SPF répond à une seule question — « cette IP vient-elle d’un serveur autorisé par le domaine du Return-Path ? » — et pour le courrier transféré, la vraie réponse est non. L’échec, c’est SPF qui fonctionne comme spécifié, pas votre enregistrement qui serait faux.

Le recensement montre à quel point ce chemin est courant : 7 355 985 domaines autorisent l’include de transfert d’e-mail de Namecheap (spf.efwd.registrar-servers.com) — le produit de transfert d’un seul fournisseur, tiré des 139 millions de publieurs SPF — avec une part de SPF strict de <0.1 % et seulement 0,2 % appliquant DMARC. Ce modèle souple n’est pas de la négligence : le transfert est précisément là où un -all strict rate sa cible, et le fournisseur dont le produit est le transfert livre en conséquence. L’histoire complète du qualificateur est dans notre rapport ~all vs -all, et le panorama fournisseur par fournisseur dans quel fournisseur d’e-mail donne le SPF le plus solide.

Ne puis-je pas simplement ajouter le serveur du transféreur à mon enregistrement SPF ?

Non — et le pourquoi, c’est tout l’article :

Vous ne pouvez pas énumérer les transféreurs. N’importe quel destinataire, n’importe où, peut faire suivre votre courrier via n’importe quel service. Votre enregistrement SPF devrait lister des serveurs dont vous ne pouvez pas connaître l’existence à l’avance.
Les lister anéantirait l’objectif. Les grands services de transfert relaient le courrier de millions de clients. Mettez leurs plages dans votre enregistrement et chaque message relayé par n’importe lequel de leurs utilisateurs — y compris un usurpateur — passe SPF en votre nom.

La même logique exclut d’assouplir votre qualificateur pour « faire marcher le transfert » : le qualificateur n’est pas la raison de l’échec du courrier transféré, et une fois DMARC en jeu, il change moins de choses que la plupart des guides ne le prétendent — voir les données sur le qualificateur. L’enregistrement n’est pas le levier ici. Arrêtez de tirer dessus.

Et SRS et ARC — ne corrigent-ils pas le transfert ?

Ils s’y attaquent — mais ni l’un ni l’autre n’est à vous de déployer :

Mécanisme	Ce qu’il fait quand le courrier est transféré	Qui le contrôle	Corrige votre DMARC ?
SPF	Échoue : l’IP du transféreur n’est pas dans votre enregistrement	Vous le publiez ; le transfert le met en échec	Non
SRS (Sender Rewriting Scheme)	Le transféreur réécrit le Return-Path vers son propre domaine pour que sa retransmission passe SPF	Le transféreur	Non — le pass SPF appartient désormais au domaine du transféreur, qui ne s’aligne pas avec votre From
ARC (RFC 8617)	Le transféreur scelle les résultats d’authentification d’origine ; le récepteur final peut faire confiance à la chaîne scellée	Le transféreur et le récepteur	Parfois — à la discrétion du récepteur, pas la vôtre
DKIM aligné	La signature voyage dans le message et se vérifie encore après transfert, avec votre domaine dessus	Vous	Oui

Données et état des mécanismes au 2026-06-29.

SRS fait disparaître le problème SPF du transféreur, pas le vôtre : réécrire le Return-Path change à qui appartient le SPF vérifié, tandis que votre en-tête From — le domaine que DMARC défend — reste intact. ARC est une décision de confiance entre opérateurs d’infrastructure. Si un guide vous dit d’« implémenter SRS » en tant que propriétaire de domaine, il vous a confondu avec le fournisseur de transfert.

Comment faire survivre mes e-mails au transfert ?

Faites de DKIM, aligné avec votre domaine, votre pass DMARC. Une signature DKIM est de la cryptographie transportée dans les en-têtes du message : elle se vérifie où que le message finisse, quel que soit le nombre de serveurs qui l’ont relayé, tant que le contenu signé n’a pas été modifié. DMARC n’a besoin que d’un seul pass aligné — SPF ou DKIM — donc quand le transfert tue la jambe SPF, un DKIM aligné garde le message authentifié.

Lancez le scan gratuit sur defaults.exposed avant de toucher au DNS. Il montre si vous avez DKIM tout court, s’il signe avec votre domaine, et où en est votre DMARC — pour corriger la vraie lacune au lieu de vous battre avec votre enregistrement SPF.
Confirmez que le transfert est réellement votre problème. Dans l’en-tête Authentication-Results d’un message concerné, le courrier direct passe SPF tandis que la copie transférée échoue depuis l’IP du service de transfert. Si SPF et DKIM passent mais que DMARC échoue quand même, vous avez plutôt un problème d’alignement — voir DMARC échoue mais SPF et DKIM passent.
Activez la signature DKIM avec votre propre domaine chez chaque service d’envoi — fournisseur de messagerie d’abord, puis ESP et expéditeurs transactionnels. Les réglages par défaut des fournisseurs signent souvent avec le domaine du fournisseur, qui ne s’aligne pas ; vous voulez d=yourdomain. Commencez par comment réparer DKIM, avec les parcours de clics pour Google Workspace et Microsoft 365.
Vérifiez l’alignement, pas seulement un pass. Le domaine d= de la signature doit correspondre à votre domaine From ; un dkim=pass sur le domaine de quelqu’un d’autre ne fait rien pour votre DMARC.
Laissez votre enregistrement SPF tranquille. Gardez-le exact pour votre courrier direct — il authentifie encore l’essentiel de votre trafic et reste votre seconde jambe DMARC. Cessez simplement d’essayer de lui faire couvrir les transféreurs.
Relancez le scan, puis montez DMARC par paliers, délibérément — section suivante, et le guide de déploiement de p=none à p=reject.

Cette combinaison — SPF plus un DMARC appliqué reposant sur un DKIM aligné — est le schéma qui résiste au transfert, et elle est rare : sur les 77,5 millions de domaines publiant ~all, seuls 9,2 % (7 116 774) l’adossent à une politique DMARC appliquée, et à peine 3,87 % des 261 millions de domaines évalués (10 092 481) complètent la triade SPF + DKIM + DMARC appliqué, selon le recensement (2026-06-29).

Et les listes de diffusion qui réécrivent les messages ?

Le seul chemin de transfert auquel un DKIM aligné ne survit pas : les listes de diffusion qui modifient le message — une étiquette [nom-de-liste] dans l’objet, un pied de page de désabonnement, une pièce jointe supprimée. Changez le contenu signé et le hachage du corps ne correspond plus, donc DKIM échoue aussi (dkim=fail: body hash did not verify est le guide dédié à cet échec). Les deux jambes DMARC sont alors mortes, et seule la liste peut l’atténuer (réécriture du From, scellement ARC).

Ce résidu est exactement ce à quoi sert la montée DMARC par paliers. Traverser p=quarantine avec une rampe pct en surveillant les rapports agrégés montre quelle part de votre courrier réel passe par des listes qui réécrivent avant qu’une politique p=reject ne commence à le rejeter. Ne sautez pas à reject sur un domaine dont les utilisateurs vivent sur des listes de diffusion ; ne stationnez pas non plus à p=none pour toujours. Le guide de déploiement par paliers parcourt la rampe.

Foire aux questions

Le transfert casse-t-il aussi DKIM ? Le transfert simple, non : la signature voyage avec le message et se vérifie chez le récepteur final. DKIM ne casse que lorsque le contenu signé est modifié en transit — les étiquettes d’objet et pieds de page des listes de diffusion étant le cas classique — raison pour laquelle le résidu des listes se gère par les paliers de politique DMARC, pas par quoi que ce soit dans le DNS.

Dois-je passer de -all à ~all pour que le transfert cesse d’échouer ? Changer le qualificateur ne fera pas passer les transféreurs — ce n’est pas la raison de leur échec. Il est parlant que l’include de transfert de Namecheap, 7 355 985 domaines et la plus grande population dédiée au transfert du recensement (2026-06-29), soit livré avec une part de SPF strict de <0.1 % : le SPF souple est sans doute le modèle correct pour un produit de transfert. Voir le rapport ~all vs -all pour ce que le qualificateur change réellement.

Pourquoi mon courrier passe-t-il SPF en envoi direct mais échoue-t-il quand quelqu’un le transfère ? Le récepteur vérifie si l’IP du dernier serveur émetteur est autorisée par l’enregistrement SPF de votre domaine Return-Path. Direct : votre serveur, dans votre enregistrement, pass. Transféré : le serveur du transféreur, pas dans votre enregistrement, fail. Votre enregistrement n’a pas changé — l’IP émettrice, si.

Puis-je mettre en place SRS pour corriger cela ? Seulement si vous êtes le transféreur. SRS tourne sur le serveur qui effectue le transfert, et même là où il tourne, le pass SPF obtenu appartient au domaine du transféreur et ne s’aligne pas avec votre From — votre DMARC a toujours besoin de la jambe DKIM.

SPF est-il inutile si le transfert le casse de toute façon ? Non. La plupart du courrier est distribué directement, là où SPF fonctionne exactement comme prévu, et il reste l’une de vos deux jambes DMARC. Sur les 261 086 232 domaines du recensement (2026-06-29), 138 927 207 publient du SPF — gardez le vôtre exact via la page de réparation SPF, et laissez DKIM porter le reste transféré.

Envoyez le rapport au propriétaire

Si vous corrigez cela pour un client ou votre employeur, bouclez la boucle avec des preuves. Une fois le DKIM sur domaine personnalisé en ligne et DMARC monté par paliers, relancez le scan gratuit et transférez le rapport noté au propriétaire de l’entreprise : daté, en langage clair, montrant que le domaine reste authentifié même quand son courrier est transféré. C’est l’artefact pour le renouvellement de la cyber-assurance et le prochain questionnaire fournisseur — un avant-après documenté, pas « j’ai activé un truc ».

Vérifiez votre domaine → · DMARC échoue mais SPF et DKIM passent → · Réparer DKIM → · Comment nous notons → · Données agrégées uniquement. Données stockées et traitées dans l’UE.