Transfert d'e-mails : SPF fail et e-mails transférés en spam

Ce qui se passe lors d'un transfert

SPF (Sender Policy Framework) vérifie une seule chose : le serveur qui livre l'e-mail a-t-il le droit d'envoyer pour le domaine de l'expéditeur ? C'est l'adresse d'expédition technique, dans l'enveloppe de l'e-mail, qui compte, et non l'expéditeur visible.

Un exemple : votre client écrit à info@example.com. Votre hébergeur transfère l'e-mail vers une boîte Gmail privée. Gmail voit maintenant le serveur de votre hébergeur comme expéditeur, mais l'enveloppe contient toujours le domaine du client. Le serveur de votre hébergeur ne figure pas dans l'entrée SPF du client. Résultat : spf=fail. Le fonctionnement détaillé de SPF est expliqué sur SPF expliqué : qui peut envoyer pour vous ?.

DMARC exige que SPF ou DKIM réussisse et corresponde au domaine visible de l'expéditeur (alignement). Après un transfert, SPF est presque toujours perdu. La réussite de DMARC dépend donc uniquement de DKIM.

Quand DKIM survit au transfert

DKIM est une signature numérique qui couvre les en-têtes et le contenu de l'e-mail. Elle n'est pas liée au serveur, mais à l'e-mail lui-même. Un simple transfert qui ne modifie rien laisse la signature valide. On obtient alors : SPF fail, DKIM pass, DMARC pass.

DKIM se casse dès que quelque chose est modifié en route :

• Une liste de diffusion ajoute un préfixe comme « [Comité] » devant l'objet.
• Une liste ou une passerelle ajoute un pied de page ou une clause de non-responsabilité.
• Un filtre de sécurité réécrit les liens ou marque l'objet avec « [EXTERNE] ».
• Un serveur réencode le texte ou les pièces jointes.

L'en-tête affiche alors généralement dkim=fail (body hash did not verify). La signification de ces messages est détaillée sur Signature DKIM invalide : «body hash did not verify» et autres erreurs. Si SPF et DKIM échouent tous les deux, DMARC échoue. Avec p=quarantine, l'e-mail arrive dans les spams, avec p=reject, il est refusé.

Les transferts les plus courants

• Transfert vers une boîte privée : info@ ou l'adresse personnelle est transférée automatiquement vers Gmail, Bluewin ou Outlook.com.
• Alias ou liste de distribution chez l'hébergeur : comptabilite@ distribue les e-mails à plusieurs adresses externes.
• Listes de diffusion et groupes : associations, fédérations, groupes de projet. Ici, l'e-mail est souvent modifié.
• Adresses d'études ou d'anciens élèves transférées, et anciennes adresses après un changement de domaine.

Le bouton « Transférer » d'Outlook n'est pas concerné. Il crée un nouvel e-mail avec votre adresse comme expéditeur, vérifié normalement.

SRS et ARC expliqués simplement

SRS (Sender Rewriting Scheme) est une solution pour celui qui transfère. Il remplace l'adresse d'enveloppe par la sienne, par exemple SRS0=…=client.example.org=info@transfert.example.net. Le destinataire vérifie alors SPF par rapport au domaine du serveur de transfert, et SPF réussit. Selon sa documentation, Microsoft 365 réécrit ainsi les e-mails transférés vers l'extérieur. Important : SRS sauve SPF, mais pas l'alignement DMARC, car le domaine SPF est désormais celui du serveur de transfert. Pour DMARC, DKIM reste déterminant.

ARC (Authenticated Received Chain) est une sorte de procès-verbal. Le serveur de transfert note les résultats SPF, DKIM et DMARC constatés chez lui et scelle cette note avec des en-têtes comme ARC-Seal. Le destinataire peut faire confiance à ce sceau, sans y être obligé. ARC est décrit comme norme expérimentale (RFC 8617). Microsoft 365 permet aux administrateurs de définir des sceaux ARC de confiance. ARC dépend du serveur de transfert et du destinataire : en tant qu'expéditeur, vous ne pouvez pas l'activer.

Si vos e-mails sont transférés : aligner DKIM

Vous ne pouvez pas influencer l'endroit où vos clients transfèrent leurs e-mails. Mais vous pouvez faire en sorte que DKIM tienne.

1. Activer DKIM pour chaque canal d'envoi : Microsoft 365, Google Workspace, boîte chez l'hébergeur, outil de newsletter, comptabilité, boutique en ligne. Pour Microsoft 365, cela signifie par exemple deux entrées CNAME selector1._domainkey.example.com et selector2._domainkey.example.com. Guide : Microsoft 365 : les e-mails arrivent en spam, DKIM est souvent désactivé.
2. Signer avec votre propre domaine : la signature doit porter d=example.com (ou un sous-domaine). Si l'outil de newsletter signe uniquement avec son propre domaine, DKIM réussit, mais n'est pas aligné. Après un transfert, cet e-mail échoue alors à DMARC.
3. Vérifier : envoyez un e-mail de test à une adresse transférée vers une boîte Gmail. Dans Gmail, sous « Afficher l'original », vous devriez voir : SPF fail ou neutral, DKIM pass avec votre domaine, DMARC pass.
4. Durcir seulement ensuite : passez à p=quarantine ou p=reject seulement lorsque tous les canaux d'envoi signent de manière alignée. Une entrée ressemble alors à ceci : v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com.

Si vous transférez vous-même : récupérer plutôt que rediriger

Si vous redirigez votre adresse professionnelle vers une boîte privée, le problème touche les e-mails de vos clients et fournisseurs. Vous ne pouvez pas réparer leur DKIM. De plus, le filtre antispam de la boîte de destination apprend que du spam passe aussi par votre serveur.

• Mieux vaut récupérer : intégrez la boîte professionnelle directement en IMAP dans votre logiciel ou votre application de messagerie. L'e-mail reste dans la boîte professionnelle, rien n'est transféré. Attention : selon Google, Gmail sur le web cesse en 2026 la récupération d'autres boîtes par POP. Dans l'application Gmail, vous pouvez ajouter un autre compte en IMAP.
• Si un transfert est nécessaire : demandez à votre hébergeur si les transferts sont réécrits avec SRS et s'il appose des sceaux ARC.
• Listes de distribution avec destinataires externes : limitez-les au strict nécessaire.

Reconnaître les transferts dans le rapport DMARC

Dans les rapports DMARC quotidiens (bases : Lire un rapport DMARC : ce que contiennent les fichiers XML et quoi en faire), les transferts présentent un schéma typique :

• L'adresse IP source n'appartient pas à vos canaux d'envoi, mais par exemple à un grand fournisseur de messagerie, une haute école ou un hébergeur.
• Peu d'e-mails par source, mais beaucoup de sources différentes.
• SPF fail ou SPF pass pour un domaine tiers, et en même temps DKIM pass pour example.com : sans danger, DMARC réussit.
• SPF fail et DKIM fail pour une source dont le nom inverse ressemble à un serveur de listes : une liste de diffusion qui modifie les e-mails.
• Certains destinataires indiquent comme motif forwarded, mailing_list ou trusted_forwarder lorsqu'ils n'ont volontairement pas appliqué votre règle.

En comparaison, l'usurpation (spoofing) : des sources inconnues sans signature DKIM valide de votre domaine, souvent en grand nombre et depuis des pays sans lien avec vous.

Erreurs typiques

• Ajouter le serveur de transfert à votre propre entrée SPF : vous autorisez ainsi des serveurs tiers à envoyer en votre nom. Cela ne résout rien et affaiblit la protection.
• Assouplir SPF de -all à ~all : DMARC échoue quand même, car SPF n'est pas aligné.
• Remettre DMARC sur p=none : cela ouvre votre domaine aux usurpations, au lieu de réparer DKIM.
• DKIM uniquement pour la boîte principale : les newsletters et factures envoyées par des systèmes tiers restent sans signature alignée.

Ce que DomainRadar prend en charge

DomainRadar analyse automatiquement vos rapports DMARC, attribue les sources à des fournisseurs connus et distingue les transferts des véritables usurpations. Vous voyez quel canal d'envoi n'a pas de signature DKIM alignée, avant de durcir votre règle.

Décodeur de rejets