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

Sans le Sender Authentication Package (SAP) ou un Private Domain, Marketing Cloud envoie avec un Return-Path sur un hôte Salesforce, 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 pas 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.

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.

Salesforce indique que les envois SAP et Private Domain incluent une politique SPF, mais quand vous envoyez avec un Private Domain dont le domaine de base ne correspond pas au domaine SAP (par exemple secondbrand.com quand le domaine SAP est e.firstbrand.com), l’alignement SPF n’est pas obtenu sans activation du multi-bounce domain. Vous ne pouvez pas l’activer vous-même : vous le demandez par un dossier auprès de l’assistance Salesforce. 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.

Salesforce indique que les domaines configurés en SAP ou en Private Domain respectent les exigences d’authentification en incluant une politique SPF, en signant avec DKIM et en définissant une politique DMARC, et que la politique DMARC d’un domaine délégué se modifie par une demande à l’assistance. Un domaine From hors de cette configuration, ou un domaine dont vous hébergez vous-même le DNS, n’a pas d’enregistrement DMARC tant que vous n’en publiez pas. 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. Interrogez _dmarc sur ce domaine, publiez ou demandez une politique avec une adresse de reporting rua, puis durcissez-la dès que l’alignement DKIM et SPF ressort propre sur un envoi réel.

Une IP dédiée fait partie du SAP, et Salesforce indique que pour maintenir sa réputation il faut envoyer 100 000 e-mails ou plus par mois (le SAP lui-même est obligatoire au-delà de 250 000 par mois). 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 progressivement : le guide de chauffe de Salesforce s’étale sur environ 30 jours, en démarrant par un petit volume quotidien vers vos abonnés les plus engagés et en l’augmentant à chaque étape tout 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.

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.

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.

D’après Salesforce, un Private Domain dont le domaine de base ne correspond pas à votre domaine SAP n’obtient aucun alignement SPF tant que le multi-bounce domain n’est pas activé, et vous le demandez par un dossier auprès de l’assistance au lieu de l’activer dans l’interface de Marketing Cloud. D’ici là, le courrier de ce second domaine garde un Return-Path sur le domaine SAP et l’alignement SPF ne passera pas pour lui.

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.

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 une fois son enregistrement DomainKey publié, 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.

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.

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 en masse, qui démarrent à 5 000 messages par jour vers Gmail.

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.

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.

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.