Corriger les e-mails Salesforce Marketing Cloud qui partent dans les spams

Quand les envois Marketing Cloud Engagement commencent à atterrir dans les spams, la cause est presque toujours la façon dont l’authentification est provisionnée, pas votre objet. Sans le Sender Authentication Package, vos domaines de bounce et d’encapsulation des liens restent sur des hôtes appartenant à Salesforce comme exacttarget.com et mc.pd25.com, donc SPF ne s’aligne jamais et DKIM signe le mauvais domaine. Ce guide couvre la différence entre SAP et Private Domain, le piège d’alignement du domaine par défaut, le warm-up d’une IP dédiée, le multi-bounce domain et la Reply Mail Management, plus la façon de tester un envoi Marketing Cloud réel avec Unspam. Notez qu’Account Engagement (Pardot) est un produit distinct, qui s’authentifie différemment.

Lancer un test de spam gratuit Comment tester vos envois

Pourquoi les e-mails Salesforce Marketing Cloud finissent dans les spams.

Vos domaines de bounce et de liens appartiennent encore à Salesforce (exacttarget.com)

Sans le Sender Authentication Package (SAP), Marketing Cloud envoie avec un Return-Path sur un hôte Salesforce comme bounce.s7.exacttarget.com ou bounce.s10.mc.pd25.com, et encapsule chaque URL de lien et d’image dans des domaines Marketing Cloud. SPF passe face au domaine de Salesforce mais ne s’aligne jamais sur votre domaine From, et les liens encapsulés se lisent comme un écart aux yeux de Gmail. Le correctif est le SAP, qui provisionne un Private Domain authentifié signant DKIM avec votre domaine et met l’encapsulation des liens et des images à votre marque. Confirmez le domaine d= et le domaine des liens sur un envoi réel, pas seulement dans le DNS.

Vous avez acheté un Private Domain mais pas le SAP complet, donc les liens disent encore Marketing Cloud

Un Private Domain seul est une option d’authentification uniquement : il applique SPF et DKIM à un sous-domaine d’envoi mais n’encapsule ni les liens ni les images et n’inclut pas d’IP dédiée. Le domaine SAP (ou le domaine Marketing Cloud par défaut) sert encore pour les URL d’images, View as Webpage, les CloudPages et l’encapsulation des liens. Les filtres voient votre domaine From sur l’enveloppe mais un domaine différent sur chaque lien cliquable, ce qui affaiblit la confiance. Si vous voulez une mise à la marque complète, il vous faut la configuration SAP entière, pas seulement le Private Domain.

L’alignement SPF reste inactif jusqu’à ce que quelqu’un active le multi-bounce domain

Même après le SAP, le domaine de bounce prend par défaut une valeur statique liée à votre domaine SAP, donc le Return-Path peut encore ne pas correspondre à votre domaine From visible et l’alignement SPF échoue. Salesforce dispose d’une fonction multi-bounce domain qui permet au domaine de bounce de s’aligner sur un domaine comme bounce.yourdomain.com, pour que SPF s’aligne, mais le réglage n’est pas visible dans l’interface : vous devez demander à l’assistance Salesforce de l’activer. L’alignement DKIM seul suffit à faire passer DMARC, mais activer le multi-bounce domain vous donne un second identifiant aligné et des rapports DMARC plus propres.

DMARC n’a jamais été publié, parce que Salesforce ne le crée pas pour vous

Quand Salesforce configure votre Private Domain ou votre domaine SAP dans le DNS, aucun enregistrement DMARC par défaut n’est ajouté au domaine d’envoi. Beaucoup de comptes Marketing Cloud tournent des années avec un DKIM aligné mais aucune politique DMARC sur le domaine From. Depuis les règles de février 2024 de Gmail et Yahoo pour les expéditeurs en masse, ceux qui dépassent 5 000 messages par jour vers Gmail doivent publier au moins p=none. Ajoutez vous-même un enregistrement v=DMARC1 avec une adresse de reporting rua, puis durcissez la politique dès que l’alignement DKIM et SPF ressort propre sur un envoi réel.

Vous avez monté une IP dédiée et envoyé le volume complet dès le premier jour

Une IP dédiée fait partie du SAP et ne vaut en général la peine qu’au-delà d’environ 250 000 messages par mois, le volume que Salesforce recommande pour garder la réputation d’une IP chaude. Une IP toute neuve n’a aucun historique auprès de Gmail et de Yahoo, donc un envoi vers toute la liste ressemble à un canon à spam. Chauffez-la sur 4 à 6 semaines : démarrez autour de 500 messages par jour vers vos abonnés les plus engagés, puis montez le volume progressivement à chaque étape en surveillant les plaintes. En dessous de ce seuil de volume, une IP dédiée trop peu utilisée peut faire moins bien que le pool partagé chauffé de Salesforce.

Les réponses bouncent ou disparaissent sans la Reply Mail Management

Par défaut, les réponses à un envoi Marketing Cloud partent vers une adresse Salesforce sans réponse et sont jetées, et une adresse From incapable de recevoir du courrier est en soi un signal négatif pour certains filtres. La Reply Mail Management (RMM), qui fait partie du SAP, route les réponses vers une boîte gérée, écarte le bruit des absences et des bounces, et peut transférer les vraies réponses à votre équipe. Configurez la RMM pour que votre adresse From accepte le courrier et que le désabonnement par réponse fonctionne, plutôt que d’envoyer depuis une adresse qui engloutit toutes les réponses.

Comment Salesforce Marketing Cloud authentifie vos e-mails.

Marketing Cloud signe et gère les bounces sur une infrastructure qu’il maîtrise, donc il n’y a rien à coller dans votre SPF racine pour l’alignement. L’authentification tient à une seule chose : avez-vous provisionné un Private Domain authentifié (seul ou dans le cadre du Sender Authentication Package) et publié votre propre enregistrement DMARC ? Vous pouvez contrôler chaque enregistrement ci-dessous avec les checkers SPF, DKIM et DMARC d’Unspam, avant et après le changement.

enregistrement	par défaut	le problème	la solution
DKIM	Sans Private Domain ni SAP, Marketing Cloud signe en DKIM avec un domaine appartenant à Salesforce, pas avec votre domaine From. Vous ne pouvez pas téléverser vos propres clés : Salesforce détient la clé privée et vous remet les enregistrements à publier.	Le domaine d= de DKIM ne correspond pas à votre domaine From, donc l’alignement DMARC échoue et le message se lit comme envoyé pour le compte d’un domaine Salesforce.	Provisionnez un Private Domain authentifié (ou le SAP complet), pour que DKIM signe avec votre sous-domaine, puis publiez les enregistrements CNAME ou TXT exacts que Salesforce fournit (par exemple s1._domainkey.email.yourbrand.com), ou déléguez le sous-domaine aux serveurs de noms Salesforce (ExactTarget) que Salesforce vous indique s’ils gèrent votre DNS. Confirmez la signature avec le DKIM checker d’Unspam.
SPF	Le domaine du Return-Path (bounce) est un hôte Salesforce comme bounce.s7.exacttarget.com ou bounce.s10.mc.pd25.com, donc SPF passe, mais face au domaine de Salesforce plutôt qu’au vôtre.	SPF passe sans alignement, ce qui explique que les rapports DMARC montrent un SPF pass mais un alignement SPF fail sur les envois par défaut. Ajouter un include Salesforce à votre SPF racine ne change rien.	Demandez à l’assistance Salesforce d’activer le multi-bounce domain, pour que le Return-Path puisse s’aligner sur un domaine comme bounce.yourbrand.com. C’est désactivé par défaut et le réglage n’est pas exposé dans l’interface ; en attendant, l’alignement DKIM seul suffit à satisfaire DMARC. Servez-vous du SPF checker d’Unspam pour confirmer que votre enregistrement publié reste valide.
DMARC	Salesforce ne crée pas d’enregistrement DMARC quand il configure votre Private Domain ou votre domaine SAP dans le DNS, donc beaucoup de comptes n’en ont aucun.	Gmail et Yahoo attendent au moins p=none sur le domaine From des expéditeurs au-delà de 5 000 messages par jour, et une politique quarantine ou reject sans DKIM aligné peut envoyer vos propres campagnes dans les spams.	Publiez vous-même v=DMARC1; p=none avec une adresse rua à _dmarc.yourbrand.com, confirmez que DKIM s’aligne sur un envoi réel, puis durcissez vers quarantine ou reject une fois les rapports propres. Marketing Cloud ne capture ni ne rapporte les échecs DMARC, donc appuyez-vous sur votre propre flux rua et sur le DMARC checker d’Unspam.
Link and image wrapping	Les liens, les images, View as Webpage et les CloudPages passent par des domaines appartenant à Salesforce jusqu’à l’activation du SAP Account Branding complet. Un Private Domain seul n’y change rien.	Chaque lien cliquable pointe vers un domaine Marketing Cloud que vous ne maîtrisez pas, alors que votre From affiche votre marque : un écart que certains filtres traitent comme du hameçonnage.	Configurez le SAP Account Branding complet, pour que l’encapsulation des liens et des images utilise votre domaine authentifié ; un Private Domain autonome authentifie l’enveloppe mais laisse l’encapsulation sur le domaine SAP ou par défaut.

Une fois ces enregistrements mis à jour, vérifiez qu’ils passent avec les outils gratuits d’Unspam : SPF checker, DKIM checker et DMARC checker.

Comment tester une campagne Salesforce Marketing Cloud avec Unspam.

L’aperçu de Marketing Cloud et l’envoi de test depuis l’éditeur d’e-mail ne se comportent pas comme un envoi de production : le suivi, les liens encapsulés et le routage peuvent différer. Unspam ne se connecte pas à l’API de Marketing Cloud, donc le seul test honnête est un envoi réel vers une adresse de test, par votre chemin d’envoi habituel.

01
Récupérez votre adresse de test Unspam

Lancez un test antispam ou un test de placement en boîte de réception dans Unspam et copiez l’adresse de test qu’il génère. Les tests de placement en boîte de réception comprennent des adresses chez Gmail, Outlook, Yahoo, Zoho, ProtonMail, AOL, GMX et Amazon WorkMail, pour que vous voyiez le placement par fournisseur.
02
Ajoutez l’adresse de test dans Marketing Cloud

Dans Email Studio, créez une Data Extension ou une liste nommée par exemple Deliverability Seeds et ajoutez l’adresse Unspam comme abonné, ou ajoutez-la à une audience de test existante que vous pouvez cibler directement.
03
Envoyez le vrai e-mail, pas un aperçu

Utilisez un Guided Send ou un User-Initiated Send du véritable e-mail vers l’audience de test, par votre profil d’expéditeur habituel, pour qu’il parte sur votre vrai domaine d’envoi, votre vraie IP et avec les liens encapsulés. Évitez le Test Send de l’éditeur, qui peut router et encapsuler différemment de la production.
04
Confirmez qu’il vient bien de votre domaine authentifié

Dans Unspam, vérifiez que DKIM signe votre sous-domaine (et non un domaine Salesforce), que le Return-Path s’aligne si vous avez activé le multi-bounce domain, et que les liens encapsulés utilisent votre domaine à votre marque plutôt qu’un hôte Marketing Cloud.
05
Lisez les résultats dans Unspam

Passez en revue le score de spam, les résultats SPF, DKIM et DMARC sur l’envoi réel, les contrôles des listes noires et du HTML, le placement par fournisseur entre Boîte de réception, Promotions, Spam ou Absent, les prévisualisations dans les clients de messagerie en mode sombre compris, et la heatmap d’eye-tracking par IA. L’assistant de correction par IA signale ce qu’il faut changer avant votre prochaine campagne.

Le même test affiche votre campagne dans plus de 50 clients de messagerie réels, dont Gmail, Outlook, Apple Mail, iPhone et Android, chacun en mode clair et en mode sombre, grâce aux prévisualisations dans les clients de messagerie, pour confirmer le placement et le rendu en une seule passe.

Les fonctions Salesforce Marketing Cloud qui influencent discrètement la livraison.

La vérification du domaine n’est pas de l’authentification

Le bouton Register Domain dans From Address Management génère un token TXT que vous ajoutez au DNS, mais cela prouve seulement que vous possédez le domaine, pour que Marketing Cloud vous laisse envoyer en son nom. Cela n’applique ni SPF, ni DKIM, ni DMARC. Un domaine peut être vérifié et échouer quand même à tous les contrôles d’alignement. L’authentification demande un Private Domain ou le SAP complet, pas seulement une vérification.

Le multi-bounce domain est invisible jusqu’à ce que l’assistance l’active

Le réglage qui aligne votre domaine de bounce sur un domaine comme bounce.yourbrand.com n’est pas exposé dans l’interface de Marketing Cloud. Vous ne pouvez pas l’activer en libre-service : vous devez ouvrir un dossier auprès de l’assistance Salesforce et demander l’activation du multi-bounce domain. D’ici là, votre Return-Path reste sur le domaine SAP et l’alignement SPF ne passera pas.

Le Private Domain n’encapsule pas les liens, seul le SAP le fait

Des équipes achètent souvent un Private Domain en s’attendant à des messages entièrement à leur marque, puis découvrent que les liens et les images passent encore par un domaine Marketing Cloud. L’encapsulation des liens et des images, les CloudPages et la mise à la marque de View as Webpage ne viennent qu’avec le SAP Account Branding complet. Si des liens à votre marque comptent pour votre réputation, confirmez que vous avez le SAP, pas seulement un Private Domain.

Account Engagement (Pardot) est un produit différent

Si vous envoyez en réalité par Account Engagement plutôt que par Marketing Cloud Engagement, la configuration diffère : il signe DKIM avec votre domaine d’envoi par défaut, utilise un Return-Path du type bounce.s7.exacttarget.com qui n’est pas aligné SPF sauf si vous demandez un chemin de retour personnalisé, et ne fournit pas d’authentification DMARC. N’appliquez pas les étapes du SAP Marketing Cloud à un compte Pardot : vérifiez d’abord quel produit envoie.

Ce que rencontrent les expéditeurs Salesforce Marketing Cloud sur le terrain.

Les problèmes de délivrabilité que les expéditeurs Salesforce Marketing Cloud rencontrent le plus souvent, chacun avec la solution qui le règle.

La même personne a reçu la même campagne trois fois, puis nous a signalés comme spam

Quand votre Subscriber Key est un Contact ID du CRM au lieu de l’adresse e-mail, une même adresse peut vivre sous plusieurs clés et SFMC traite chacune comme un contact distinct. Les envois depuis une Data Extension ne dédoublonnent pas par adresse sauf si vous l’activez, et les envois déclenchés ne dédoublonnent jamais : une personne reçoit donc la même campagne une fois par enregistrement, clique sur le bouton spam, et le pic de plaintes pousse Gmail et Yahoo à vous filtrer.

La solution Pour les envois depuis une Data Extension, activez l’option Remove Duplicates dans la sélection d’audience ; elle est désactivée par défaut et dédoublonne par adresse e-mail, ce qui rattrape une adresse présente sous plusieurs SubscriberKeys dans cet envoi. Les envois par liste dédoublonnent toujours automatiquement au moment de l’envoi, mais cette case ne fait rien pour les activités e-mail de Journey Builder ni pour les envois déclenchés, qui n’ont aucun dédoublonnage. Le correctif durable est en amont : normalisez sur une seule ContactKey ou SubscriberKey stable, dédoublonnez dans votre CRM ou votre CDP pour que chaque personne soit un enregistrement de référence unique, et auditez la liste All Subscribers pour repérer la même adresse sous plusieurs clés.

Gmail a commencé à nous filtrer en masse, et il s’est avéré que notre promo était classée Transactional

Une Send Classification Transactional retire par défaut le lien de désabonnement visible, le bloc d’adresse postale et l’en-tête List-Unsubscribe en un clic, ce qui est correct pour un reçu mais devient un manquement de conformité dès que le message porte du contenu promotionnel. Des équipes classent à tort du courrier commercial en transactionnel, par mauvais clic ou pour étouffer les désabonnements, et depuis février 2024 cet en-tête en un clic manquant enfreint les règles de Gmail et Yahoo pour les expéditeurs au-delà de 5 000 messages par jour.

La solution Auditez vos Send Classifications face à ce que chaque e-mail contient réellement et envoyez tout ce qui est promotionnel sous une Send Classification Commercial. C’est la classification Commercial qui fait ajouter par Marketing Cloud le lien de désabonnement visible et injecter les en-têtes List-Unsubscribe et List-Unsubscribe-Post en un clic, présents sur tous les envois commerciaux et impossibles à désactiver. Séparément, confirmez que le Delivery Profile utilisé pour l’envoi a un contenu d’en-tête et de pied de page configuré avec votre adresse postale CAN-SPAM, puisque ce bloc vient du Delivery Profile et non de la classification. Restreignez qui peut choisir la Send Classification et modifier les Sender et Delivery Profiles, et réservez Transactional strictement aux vrais reçus, réinitialisations de mot de passe et confirmations de commande.

Notre remise s’est effondrée sans que nous touchions à rien : c’était un inconnu sur notre IP partagée

Sur le pool d’IP partagées de SFMC, votre réputation est soudée à celle de tous les autres locataires : un voisin bruyant qui débite du spam ou des bounces déclenche des blocages B2C chez Yahoo, AOL et Microsoft, et des reports chez Gmail, même avec une authentification parfaite. L’assistance confirmera que les équipes Deliverability et Abuse sont mobilisées mais ne nommera ni l’expéditeur en cause ni la remédiation en cours, ce qui donne l’impression que rien n’est réparable.

La solution Ouvrez un dossier et joignez des éléments qui distinguent vos envois de l’effondrement du pool : journaux de bounces, codes SMTP de report et de blocage, votre taux de plaintes, et le statut sur les listes noires montrant que toute la plage a bougé ensemble alors que vos indicateurs restaient stables. Escaladez auprès de l’assistance et de votre équipe de compte, et demandez soit un transfert vers un pool partagé en meilleure santé (accordé à la discrétion de Salesforce : traitez-le comme une demande), soit le lancement de votre migration vers une IP dédiée via votre chargé de compte. Sur Email Studio classique, chauffez la nouvelle IP manuellement sur 4 à 6 semaines, en démarrant autour de 500 messages par jour vers vos abonnés les plus engagés et en montant le volume progressivement tout en surveillant les plaintes. Sur Marketing Cloud Next, Salesforce automatise le warm-up de l’IP dédiée sur environ les 35 premiers jours.

Après notre migration vers Marketing Cloud, la remise chez Gmail est passée d’instantanée à plusieurs heures de retard

Après migration, des expéditeurs sur le pool partagé SFMC rapportent des messages qui stagnent en file ou se font reporter à répétition par Gmail : ils arrivent donc des heures plus tard, alors que SPF, DKIM et DMARC passent tous. Gmail applique une vigilance accrue au fort volume marketing de l’IP partagée, et le courrier transactionnel sensible au temps, coincé derrière les campagnes en masse, se fait ralentir avec lui.

La solution Récupérez les en-têtes complets et lisez les horodatages Received de bas en haut pour prouver où se situe le retard, chez SFMC avant la remise ou chez Gmail qui reporte à répétition avec un 4xx, plutôt que de le deviner. Confirmez un report côté Gmail face à la réputation de votre domaine et de votre IP dans Google Postmaster Tools, puisque Marketing Cloud ne fait pas remonter les motifs de report. Si le courrier transactionnel est la victime, séparez-le sur son propre sous-domaine et son propre routage, avec un Sender Profile distinct et une Send Classification transactionnelle, et au volume une IP dédiée ou la Transactional Messaging API, pour qu’il ne reste pas coincé derrière les files de campagnes. Si c’est le pool partagé qui reporte, escaladez chez Salesforce pour un changement de pool ou une IP dédiée, et vérifiez que vous ne chauffez pas une IP neuve vers le volume complet trop vite.

Les User-Initiated Sends de Marketing Cloud partent dans les spams alors que les e-mails de Journey arrivent pour l’essentiel en boîte de réception

Des expéditeurs avec SPF, DKIM et DMARC tous configurés voient quand même leurs User-Initiated Sends atterrir dans les spams, suivis de quelques e-mails de Journey. Les User-Initiated Sends ciblent souvent des destinataires inactifs ou agacés, ce qui fait chuter vite la réputation de domaine, et ces dégâts se répandent sur les Journeys qui partagent le même domaine et la même IP d’envoi.

La solution Ce n’est pas un problème de configuration d’authentification, c’est un problème de réputation et d’audience. Contrôlez l’alignement, pas seulement la configuration : SPF et DKIM peuvent passer alors que le domaine From visible, le Return-Path et le domaine de signature sont mal alignés, ce que les fournisseurs traitent tout de même comme plus risqué. Supprimez les destinataires non engagés des User-Initiated Sends et effacez les contacts inscrits il y a des mois qui n’ont jamais ouvert, pour que ces envois cessent de générer des plaintes qui se répandent sur vos Journeys. Gardez un contenu modélisé court et utile, et si vous êtes sur une IP dédiée, envoyez régulièrement, puisque les trous de volume remettent à zéro votre réputation d’expéditeur.

La délivrabilité avec Salesforce Marketing Cloud, vos questions.

Pourquoi mes messages Marketing Cloud semblent-ils venir d’un domaine Salesforce ?

Votre compte n’a pas provisionné de Private Domain authentifié, donc DKIM signe avec un domaine appartenant à Salesforce et les liens sont encapsulés dans des hôtes Marketing Cloud comme exacttarget.com. Mettez en place un Private Domain pour aligner DKIM sur votre sous-domaine, et le SAP Account Branding complet pour mettre l’encapsulation des liens et des images à votre marque. La seule vérification du domaine n’y change rien.

Dois-je ajouter Salesforce à l’enregistrement SPF de mon domaine ?

Non. Marketing Cloud maîtrise le domaine du Return-Path, donc SPF est évalué face à l’infrastructure de Salesforce et passe déjà, sans alignement. Ajouter un include à votre SPF racine ne change rien à l’alignement. Ce qui aligne SPF, c’est de demander à l’assistance Salesforce d’activer le multi-bounce domain, et l’alignement DKIM via un Private Domain permet déjà à DMARC de passer tout seul.

Quelle différence entre le Private Domain et le Sender Authentication Package ?

Le Private Domain est une option d’authentification seule : SPF et DKIM sur un sous-domaine d’envoi, sans IP dédiée ni mise à la marque des liens et des images. Le SAP est l’ensemble complet : Private Domain plus une IP dédiée, l’Account Branding pour l’encapsulation des liens et des images, et la Reply Mail Management. Salesforce recommande une IP dédiée aux expéditeurs au-delà d’environ 250 000 messages par mois.

Une IP dédiée me sortira-t-elle du dossier spam ?

Seulement si vous avez le volume pour la garder chaude. Une IP dédiée vient avec le SAP et se justifie en général au-delà d’environ 250 000 messages par mois. Une IP neuve doit être chauffée sur 4 à 6 semaines, en démarrant autour de 500 messages par jour vers des abonnés engagés, et une IP dédiée trop peu utilisée peut faire moins bien que le pool partagé chauffé de Salesforce. Corrigez l’authentification, l’hygiène de liste et le taux de plaintes avant de vous tourner vers une IP dédiée.

Unspam peut-il se connecter à mon compte Marketing Cloud et tester les envois automatiquement ?

Non. Unspam ne s’intègre ni à l’API de Marketing Cloud ni à celle d’aucun autre ESP. Le mode opératoire est manuel par choix : ajoutez l’adresse de test d’Unspam à une Data Extension ou à une liste, lancez un vrai Guided Send vers elle, puis lisez les résultats dans Unspam. C’est le seul moyen de tester exactement le message que reçoivent vos abonnés, authentification et liens encapsulés compris.

J’utilise Pardot, pas Marketing Cloud Engagement. Ces étapes s’appliquent-elles ?

Pas directement. Account Engagement (anciennement Pardot) est un produit distinct qui signe DKIM avec votre domaine d’envoi par défaut et utilise un domaine de bounce Salesforce qui n’est pas aligné SPF, sauf si vous demandez un chemin de retour personnalisé. Il ne fournit pas non plus d’authentification DMARC. Confirmez quel produit envoie vos messages, puis suivez le parcours d’authentification de ce produit plutôt que de mélanger les deux.

Les informations sur la plateforme Salesforce Marketing Cloud ont été vérifiées à partir de la documentation publique en June 2026 et ont pu changer depuis. Salesforce Marketing Cloud est une marque de son propriétaire respectif. Unspam n’est ni affilié à Salesforce Marketing Cloud ni approuvé par Salesforce Marketing Cloud.

Testez votre prochaine campagne Salesforce Marketing Cloud avant vos abonnés.

Lancer un test de spam gratuit Test d’Inbox Placement