Corriger les e-mails Pardot (Account Engagement) qui partent dans les spams

Marketing Cloud Account Engagement, encore étiqueté Pardot dans une grande partie de l’application, est un produit différent de Marketing Cloud Engagement et s’authentifie d’une tout autre manière. Il vérifie votre domaine d’envoi avec une clé de validation qui prouve la propriété et rien d’autre, traite DKIM comme facultatif, et fait passer chaque rebond par un hôte Salesforce tel que bounce.s7.exacttarget.com : SPF ne s’aligne donc pas sur votre adresse d’expéditeur tant que vous ne demandez pas un chemin de retour personnalisé. Ce guide couvre l’enregistrement DomainKey sur 200608._domainkey, le CNAME du domaine de suivi qui réécrit chaque lien de votre e-mail, le chemin de retour personnalisé pour lequel il faut ouvrir un ticket, et la façon de tester un envoi Account Engagement réel avec Unspam.

Lancer un test de spam gratuit Comment tester vos envois

Pourquoi les e-mails Marketing Cloud Account Engagement finissent dans les spams.

Account Engagement n’a jamais exigé DKIM, si bien que la plupart des comptes n’ont aucun identifiant aligné

Salesforce vérifie un domaine d’envoi avec un enregistrement TXT de clé de validation, et cette clé suffit à elle seule pour envoyer : la documentation indique qu’Account Engagement n’exige pas actuellement d’enregistrement DKIM vérifié sur le domaine d’envoi et se contente de le recommander fortement. DKIM est le seul identifiant qui s’aligne d’origine sur votre adresse d’expéditeur, car le chemin de retour reste sur un hôte Salesforce tant que vous n’ouvrez pas un ticket de support pour un chemin de retour personnalisé. Sans l’enregistrement TXT DomainKey publié sur 200608._domainkey.votredomaine.com, une évaluation DMARC n’a rien d’aligné sur quoi s’appuyer, et une politique p=quarantine ou p=reject sur votre propre domaine filtre alors vos propres campagnes. Domain Management affiche le domaine comme vérifié dans les deux cas, et c’est pourquoi tant de domaines vérifiés ne sont absolument pas authentifiés.

SPF passe pour Salesforce, jamais pour vous

Salesforce documente que les e-mails Account Engagement passent SPF automatiquement parce que Salesforce contrôle l’infrastructure d’envoi, et qu’aucune configuration SPF particulière n’est nécessaire de votre côté. Le serveur de réception contrôle le chemin de retour, que Salesforce documente comme un hôte du type bounce.s7.exacttarget.com, bounce.s10.mc.pd25.com ou bounce.j.s11.pdmailservice.com : la réussite est donc enregistrée pour un domaine Salesforce et l’alignement SPF échoue à chaque envoi. Ajouter un include Salesforce à votre enregistrement SPF racine n’y change rien. Le seul moyen d’aligner le chemin de retour est un chemin de retour personnalisé, que Salesforce met en place via un ticket de support et non depuis un écran du produit.

Tous les liens de l’e-mail pointent encore vers pardot.com

Account Engagement réécrit les liens et les URL personnalisées via le domaine de suivi et, lorsqu’aucun domaine de suivi n’est sélectionné sur une ressource, retombe sur le domaine de suivi principal du compte. Un compte qui n’a jamais validé son propre CNAME sert tout cela depuis le domaine par défaut go.pardot.com : un message qui porte votre marque dans la ligne d’expéditeur porte donc des liens sur un domaine auquel le destinataire n’a aucune raison de se fier. Salesforce recommande d’ajouter un domaine personnalisé et de servir tout le contenu Account Engagement depuis celui-ci. Une fois votre propre domaine de suivi validé et défini avec Set as Primary, Account Engagement réécrit vers lui les URL de vos ressources.

La hiérarchie d’expéditeurs envoie depuis des domaines que vous n’avez jamais configurés

Dans Account Engagement, l’adresse de l’expéditeur décide du domaine d’envoi utilisé : une campagne réglée sur Assigned User, Account Owner ou un champ utilisateur du CRM part donc de l’adresse de chaque commercial. Au moment de l’envoi, Salesforce parcourt la hiérarchie d’expéditeurs de haut en bas et utilise la première adresse dont le domaine est vérifié, et si aucun expéditeur de la hiérarchie n’est valide, l’envoi échoue purement et simplement. Une même campagne peut donc partir sous plusieurs domaines d’expéditeur, dont seuls certains portent un enregistrement DomainKey, ce qui fractionne votre réputation et fait tomber la part non signée dans les spams. Chaque domaine depuis lequel vos utilisateurs envoient a besoin de sa propre entrée dans Domain Management avec les deux enregistrements publiés.

Vous jugez la délivrabilité à partir de tests qui ne sont pas de vrais e-mails

Salesforce documente que l’option ponctuelle Send to Individual Emails ne produit pas de message MIME multipartie : les versions HTML et texte brut partent en deux messages distincts, et beaucoup de systèmes de messagerie considèrent cela comme suspect. Le même article prévient que répéter ces envois de test peut faire l’objet d’un greylisting de l’expéditeur, en nommant Microsoft en particulier, avec des reports de plusieurs heures, et affirme clairement que les tests d’e-mail ne doivent pas servir de mesure de la délivrabilité. Si votre seule preuve est un test envoyé à votre propre adresse professionnelle, vous mesurez un artefact de l’outil de test. Une adresse d’entreprise aux deux extrémités ajoute une seconde défaillance, car le filtre classe comme interne le courrier entre deux adresses de votre domaine, puis le voit arriver depuis un serveur extérieur.

Vous avez appliqué des instructions Marketing Cloud Engagement à un compte Pardot

Marketing Cloud Engagement et Marketing Cloud Account Engagement sont deux produits distincts avec des chemins d’authentification distincts, et les noms sont assez proches pour que des équipes suivent le mauvais mode d’emploi pendant des mois. Il n’existe dans Account Engagement ni Sender Authentication Package, ni Private Domain, ni Reply Mail Management. L’authentification vit dans Account Engagement Settings, puis Domain Management : une clé de validation, un enregistrement DomainKey et un CNAME de domaine de suivi pointant vers go.pardot.com. Acheter SAP pour une organisation Marketing Cloud Engagement ne fait rien pour le courrier qu’envoie votre unité opérationnelle Account Engagement : confirmez donc quel produit a réellement envoyé le message avant de passer un trimestre à configurer l’autre.

Comment Marketing Cloud Account Engagement authentifie vos e-mails.

Account Engagement distingue quatre réalités DNS que la plupart des équipes traitent comme une seule. La clé de validation prouve que le domaine vous appartient et c’est le seul enregistrement requis pour envoyer. L’enregistrement DomainKey est ce qui signe réellement votre courrier. SPF appartient à Salesforce, pas à vous. DMARC n’appartient qu’à vous, car Salesforce indique qu’Account Engagement ne peut pas fournir d’authentification DMARC et que le support ne peut pas aider à la configurer. Seuls deux des quatre viennent du produit : Account Engagement Settings, puis Domain Management, puis le lien Expected DNS Entries à côté du domaine, qui contient la clé de validation et le DomainKey. Salesforce ne fournit aucune valeur SPF ni aucune valeur DMARC. Indépendamment de tout cela, le domaine de suivi est un CNAME vers go.pardot.com et ne doit jamais être le même domaine que votre domaine d’envoi. Contrôlez chaque enregistrement avec les vérificateurs SPF, DKIM et DMARC d’Unspam avant et après la modification.

enregistrement	par défaut	le problème	la solution
Validation key (TXT)	Rien n’est publié tant que vous n’avez pas ajouté le domaine. Depuis le 1er juillet 2023, un domaine doit être vérifié par une clé de validation avant qu’Account Engagement n’envoie depuis lui. Les domaines déjà vérifiés par DKIM sous l’ancienne méthode ont conservé leur statut sans la nouvelle clé.	Un domaine vérifié n’est pas un domaine authentifié. L’état vérifié dans Domain Management signifie seulement que vous avez prouvé la propriété, et les équipes s’arrêtent là en croyant l’authentification terminée. Laissez l’enregistrement TXT publié, car c’est celui sur lequel Account Engagement contrôle la propriété du domaine.	Dans Account Engagement Settings, ouvrez Domain Management, cliquez sur Add New Domain, puis sur Expected DNS Entries dans la colonne Actions et copiez la clé de validation. Publiez-la en enregistrement TXT sur ce domaine ou sur un domaine parent, puis cliquez sur Check DNS Entries pour vérifier. Laissez l’enregistrement en place de façon permanente.
DKIM (DomainKey)	Inactif tant que vous ne le publiez pas. Salesforce indique qu’Account Engagement n’exige pas actuellement d’enregistrement DKIM vérifié pour envoyer depuis un domaine d’envoi, et se contente de le recommander fortement. La clé émise par Account Engagement est en 1024 bits par défaut.	DKIM est le seul identifiant qu’Account Engagement peut aligner sur votre domaine d’expéditeur : sans lui, une évaluation DMARC n’a rien sur quoi s’appuyer et les attentes de Gmail et Yahoo pour les expéditeurs en volume restent non satisfaites. La défaillance est invisible dans le produit, car Domain Management annonce le domaine comme vérifié avec ou sans DomainKey.	Dans Domain Management, ouvrez Expected DNS Entries pour le domaine, copiez la valeur DomainKey et publiez-la en enregistrement TXT sur 200608._domainkey.votredomaine.com. Chez les hébergeurs qui ajoutent la zone à ce que vous saisissez, GoDaddy notamment, ne saisissez que la partie hôte, sinon l’enregistrement se propage avec votre domaine en double. Comptez jusqu’à 24 heures pour que la signature prenne effet, puis confirmez la valeur d= sur un envoi réel avec le vérificateur DKIM d’Unspam.
SPF	Configuré par Salesforce et non par vous. La documentation dit que les e-mails Account Engagement passent SPF automatiquement et qu’aucune configuration SPF particulière n’est nécessaire de votre côté, et Domain Management reflète cette réussite.	La réussite est enregistrée pour le chemin de retour, que Salesforce documente comme bounce.s7.exacttarget.com, bounce.s10.mc.pd25.com ou bounce.j.s11.pdmailservice.com selon le compte. Aucun de ces hôtes n’est votre domaine : l’alignement SPF échoue donc à chaque envoi Account Engagement et DMARC ne peut pas s’appuyer dessus.	Gardez votre propre enregistrement SPF valide pour vos autres expéditeurs et confirmez-le avec le vérificateur SPF d’Unspam, mais n’attendez pas qu’il aide Account Engagement. Pour l’alignement, ouvrez un ticket de support Account Engagement et demandez un chemin de retour personnalisé. Salesforce fournit les enregistrements DNS et vous laisse les publier, et il ne peut y avoir qu’un seul domaine de chemin de retour personnalisé par unité opérationnelle, sans variation par envoi.
DMARC	Absent tant que vous ne le publiez pas. Salesforce est explicite : Account Engagement ne peut pas fournir d’authentification DMARC, la configuration vit hors du produit, et le support n’est pas en mesure d’aider à la mettre en place.	Avec le DomainKey publié, DMARC passe sur le seul alignement DKIM, et c’est ce que Salesforce veut dire quand il affirme que DMARC fonctionne d’origine avec Account Engagement. Sans lui, aucun identifiant ne s’aligne et une politique p=quarantine ou p=reject sur votre propre domaine met vos propres campagnes en quarantaine. Account Engagement ne capte ni ne remonte les échecs DMARC : rien dans l’application ne vous le dira.	Publiez v=DMARC1; p=none; rua=mailto:dmarc@votredomaine.com sur _dmarc.votredomaine.com, confirmez sur un envoi réel que DKIM s’aligne sur votre domaine d’expéditeur, puis durcissez vers quarantine et plus tard reject une fois vos rapports propres. Salesforce recommande de s’appuyer sur un prestataire externe pour les rapports DMARC, puisqu’il n’en capte aucun. Vérifiez l’enregistrement publié avec le vérificateur DMARC d’Unspam.

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 Marketing Cloud Account Engagement avec Unspam.

Account Engagement propose deux tests intégrés et aucun des deux ne mesure le placement. L’onglet Testing de l’éditeur classique lance des aperçus de rendu Litmus et une analyse antispam, et Salesforce précise que les résultats ne garantissent pas qu’un e-mail finisse ou non dans le dossier spam. L’envoi de test de l’éditeur Lightning retire les données des champs de fusion et, si le domaine de la personne connectée n’est pas vérifié, remplace votre adresse d’expéditeur par test@ suivi de votre premier domaine d’envoi vérifié. Unspam ne se connecte ni à l’API Account Engagement ni à aucun autre compte de plateforme : le test honnête est donc un vrai e-mail de liste envoyé à une adresse-témoin depuis votre domaine d’envoi et votre domaine de suivi habituels.

01
Récupérez votre adresse-témoin Unspam et votre Test ID

Lancez un test antispam gratuit ou un test de placement en boîte de réception dans Unspam et copiez l’adresse-témoin générée. Un test de placement livre vers des boîtes-témoins chez Gmail, Outlook, Yahoo, Zoho, ProtonMail, AOL, GMX et Amazon WorkMail, pour que vous voyiez où chaque copie a atterri. Il fournit aussi un Test ID, et vous devez coller cet identifiant dans l’objet ou dans le corps avant d’envoyer. Si vous l’oubliez, le message atteint tout de même les boîtes-témoins, mais il n’est jamais rattaché à votre test.
02
Ajoutez l’adresse-témoin comme prospect sur une liste normale

N’utilisez pas d’Email Test List. Account Engagement les construit à partir de vos propres utilisateurs, en créant un prospect de test pour chacun, jusqu’à 100 destinataires : une adresse-témoin externe ne peut donc pas y figurer. Créez plutôt l’adresse-témoin comme prospect et ajoutez-la à une liste de segmentation nommée par exemple Deliverability Seed, pour que le message suive exactement le chemin d’une campagne.
03
Envoyez-le comme un vrai e-mail de liste, pas comme un test

Envoyez le véritable e-mail à cette liste depuis Account Engagement Email, avec votre expéditeur de production et le même domaine de suivi que vos campagnes. Évitez l’option Send to Individual Emails de l’onglet Testing : Salesforce documente qu’elle découpe le HTML et le texte brut en deux messages distincts au lieu d’un seul message MIME multipartie, et indique que les tests d’e-mail ne doivent pas servir de mesure de la délivrabilité.
04
Vérifiez ce qui est réellement sorti d’Account Engagement

Dans Unspam, confirmez que la valeur d= de DKIM est votre domaine d’envoi et non un hôte Salesforce, que le chemin de retour est bien celui attendu (un hôte du style bounce.s7.exacttarget.com sauf si vous avez un chemin de retour personnalisé), et que chaque lien se résout sur votre domaine de suivi et non sur pardot.com. C’est le premier point du parcours où vous voyez les en-têtes que voit un fournisseur de messagerie.
05
Lisez les résultats et corrigez avant la campagne suivante

Passez en revue le score antispam, les verdicts SPF, DKIM et DMARC mesurés sur l’envoi réel, les contrôles de listes noires et de HTML, le placement par fournisseur en boîte de réception, Promotions, spam ou manquant, les aperçus par client de messagerie y compris en mode sombre, et la heatmap d’oculométrie par IA. Changez une seule chose, renvoyez, et vous pourrez attribuer la différence au lieu de la deviner.

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 Marketing Cloud Account Engagement qui influencent discrètement la livraison.

Vérifié ne veut pas dire authentifié

Domain Management marque un domaine comme vérifié dès que l’enregistrement TXT de la clé de validation se résout, et c’est le seul enregistrement dont Account Engagement a besoin pour envoyer. DKIM figure sur le même écran Expected DNS Entries et n’est que recommandé. Des comptes fonctionnent des années dans cet état, vérifiés et sans jamais signer un seul message avec leur propre domaine. Ouvrez Expected DNS Entries et cherchez précisément la ligne DomainKey plutôt que de vous fier à la mention vérifié.

Les envois de test individuels ne sont pas du MIME multipartie

Salesforce documente que l’option Send to Individual Emails livre le HTML et le texte brut en deux messages distincts au lieu d’un seul message MIME multipartie, que beaucoup de systèmes de messagerie considèrent cela comme suspect, et qu’un usage répété peut valoir un greylisting de l’expéditeur, Microsoft étant nommé précisément, avec des reports de plusieurs heures. Si votre preuve de délivrabilité vient de ce bouton, c’est une preuve sur le bouton. Salesforce recommande plutôt les listes de test, et un envoi réel vers une adresse-témoin externe bat les deux.

Le domaine de suivi et le domaine d’envoi doivent être différents

Salesforce indique qu’utiliser le même domaine pour les deux fonctions entraînera probablement des erreurs d’authentification et des problèmes de délivrabilité. Si go.entreprise.com est votre domaine de suivi, il ne peut pas être aussi votre domaine d’envoi. Les domaines de suivi doivent également être uniques entre unités opérationnelles : une seconde unité a donc besoin de quelque chose comme go2.entreprise.com et non d’un doublon de la première.

L’histoire de la clé DKIM en 2048 bits est contradictoire

Account Engagement émet un DomainKey en 1024 bits par défaut. Le guide de configuration DNS dit que vous pouvez ouvrir un ticket de support pour demander une clé en 2048 bits et qualifie une IP d’envoi dédiée de vivement recommandée avant de le faire. Salesforce décrit ensuite le résultat de deux façons différentes. Un article dit qu’une clé en 2048 bits produit un avertissement Custom DKIM Entry dans le tableau Email Sending Domain et qu’aucune autre action n’est nécessaire tant que vos entrées DNS restent en place. Un autre dit que les clients utilisant une clé en 2048 bits ne verront pas leur domaine d’envoi comme DKIM vérifié dans Account Engagement, même si l’enregistrement est bien présent dans le DNS. Considérez l’indicateur de vérification de l’application comme peu fiable en 2048 bits et confirmez plutôt la signature sur un envoi réel.

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

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

Nos e-mails de test finissent sans arrêt dans les indésirables, mais le support Salesforce nous dit que le compte n’a rien d’anormal

Si vous avez testé avec Send to Individual Emails depuis l’onglet Testing, la documentation de Salesforce dit que ces envois ne sont pas des messages MIME multipartie : le HTML et le texte brut partent en deux messages distincts, et beaucoup de systèmes de messagerie considèrent cela comme suspect. Utiliser une adresse d’entreprise aux deux extrémités empile une seconde défaillance par-dessus, car le filtre classe comme interne le courrier entre deux adresses de votre domaine, puis le voit arriver depuis un serveur tiers extérieur à votre réseau. Salesforce affirme sans détour que les tests d’e-mail ne doivent pas servir de mesure de la délivrabilité.

La solution Arrêtez de tester avec des envois individuels. Faites mettre en liste blanche par votre service informatique l’adresse IP d’envoi Account Engagement, que vous trouvez dans Account Engagement Settings, sous Account Information, dans le champ Sending IPs, pour que les tests internes cessent de déclencher la règle du réseau interne. Mesurez ensuite le placement avec un vrai e-mail de liste vers une adresse-témoin externe plutôt que vers un collègue de votre propre domaine, et lisez les en-têtes de cet envoi. Gardez à l’esprit qu’une série d’envois individuels peut vous valoir un greylisting, surtout chez Microsoft, ce qui fait paraître le prochain envoi réel pire qu’il ne l’est.

La newsletter atteint la boîte de réception, mais tout ce qui part d’un commercial va directement en spam

Les campagnes réglées sur Assigned User, Account Owner ou un champ utilisateur personnalisé du CRM prennent l’adresse d’expéditeur dans la fiche utilisateur : le domaine d’envoi change donc d’un prospect à l’autre. Salesforce évalue la hiérarchie d’expéditeurs de haut en bas au moment de l’envoi et utilise la première adresse dont le domaine est vérifié, ce qui veut dire qu’un domaine de commercial non vérifié bascule en silence vers l’entrée suivante, et que si rien dans la hiérarchie n’est valide, l’envoi échoue. Les domaines que vous n’avez jamais ajoutés dans Domain Management n’ont pas d’enregistrement DomainKey : ces messages partent donc sans signature alors que votre domaine marketing est signé.

La solution Recensez chaque domaine depuis lequel vos utilisateurs envoient et ajoutez-les tous dans Account Engagement Settings, Domain Management, avec la clé de validation et l’enregistrement DomainKey publiés. Là où les commerciaux sont sur un domaine que vous ne pouvez pas authentifier, placez en dernière entrée de la hiérarchie d’expéditeurs un General User ou un Specific User sur un domaine vérifié, et mettez la touche humaine dans l’adresse de réponse plutôt que dans l’expéditeur. Envoyez ensuite depuis chaque domaine vers une adresse-témoin et confirmez que la valeur d= de DKIM correspond avant de vous y fier.

J’ai ajouté le DomainKey il y a une semaine et Account Engagement n’affiche toujours pas DKIM comme vérifié

L’enregistrement DomainKey doit vivre sur 200608._domainkey.votredomaine.com, et les hébergeurs DNS qui ajoutent la zone à ce que vous saisissez en font un nom d’hôte doublé qui ne se résout nulle part. Salesforce cite GoDaddy nommément pour ce comportement. La signature ne démarre pas non plus à l’instant où l’enregistrement se résout : la documentation demande jusqu’à 24 heures après sa mise en place. Et si quelqu’un a demandé une clé en 2048 bits, Salesforce prévient que le domaine n’apparaîtra pas du tout comme DKIM vérifié dans l’application, même avec un enregistrement correct dans le DNS.

La solution Interrogez l’enregistrement directement plutôt que de vous fier à l’application : recherchez 200608._domainkey.votredomaine.com et vérifiez que vous obtenez un seul enregistrement TXT correspondant à la valeur d’Expected DNS Entries, sans domaine doublé ni doublon. Si votre hébergeur ajoute la zone, ne saisissez que la partie hôte. Laissez 24 heures pleines à la signature, envoyez ensuite vers une adresse-témoin et lisez la valeur d= du message livré, seul contrôle qui reflète ce que voient les fournisseurs de messagerie.

Notre propre service informatique a signalé la campagne comme du hameçonnage parce que tous les liens allaient vers pardot.com

Account Engagement réécrit les liens et les URL personnalisées via le domaine de suivi et, si aucun domaine de suivi n’est choisi sur la ressource, utilise le domaine de suivi principal du compte. Un compte qui n’a jamais validé son propre CNAME sert tout cela depuis le domaine par défaut go.pardot.com : la ligne d’expéditeur affiche donc votre marque et chaque href affiche autre chose, ce qui est exactement la forme sur laquelle un filtre antihameçonnage est entraîné. Salesforce recommande d’ajouter un domaine personnalisé et de servir tout le contenu Account Engagement depuis celui-ci.

La solution Ajoutez un domaine de suivi dans Domain Management, pointez le CNAME vers go.pardot.com en production ou go.demo.pardot.com pour un bac à sable, publiez la clé de validation en enregistrement TXT sur votre domaine racine ou déposez le fichier de validation pardot_XXXXXX.txt à la racine de votre site, puis validez-le et choisissez Set as Primary. Cela réécrit vers le nouveau domaine les URL de vos ressources Account Engagement. Choisissez un sous-domaine qui n’est pas votre domaine d’envoi, puisque Salesforce prévient que réutiliser un même domaine pour les deux provoque des erreurs d’authentification, et confirmez sur un envoi-témoin qu’aucun lien pardot.com ne subsiste.

Une partie de notre liste a cessé de recevoir les e-mails sans bruit et personne ne s’était désabonné

Account Engagement marque un prospect comme Undeliverable après un seul hard bounce, ou après cinq soft bounces, et le supprime de tous les envois suivants. Le piège est dans la définition même du hard bounce chez Salesforce : certains serveurs de messagerie renvoient un hard bounce quand le message est suspecté d’être du spam. Une période d’authentification cassée ne vous pousse donc pas seulement dans le dossier spam, elle transforme des destinataires filtrés en prospects supprimés définitivement, et la liste continue de fondre longtemps après que la cause profonde est corrigée.

La solution Corrigez d’abord l’authentification, puis remontez les enregistrements de rebond : Account Engagement vous laisse réinitialiser le compteur de hard bounces ou de soft bounces sur une fiche prospect une fois la cause résolue. Alignez le pic de bounces sur les dates auxquelles vous avez modifié le DNS ou les réglages d’expéditeur pour distinguer une adresse réellement mauvaise d’une adresse filtrée. À l’avenir, gardez les taux de bounce bien sous les 10 % par envoi dont Salesforce dit qu’ils peuvent nuire à votre délivrabilité, et les taux de plainte sous les 0,3 % appliqués par Gmail, et reconstruisez le volume progressivement si vous avez suspendu les envois plus d’une semaine.

La délivrabilité avec Marketing Cloud Account Engagement, vos questions.

Marketing Cloud Account Engagement est-il la même chose que Marketing Cloud Engagement ?

Non. Ce sont deux produits distincts avec des chemins d’authentification distincts, et c’est de loin la première raison pour laquelle un correctif Pardot ne mène nulle part. Account Engagement est le produit anciennement appelé Pardot, et Salesforce affiche encore l’ancien nom dans certaines parties de l’application. Son authentification vit dans Account Engagement Settings, puis Domain Management : une clé de validation, un enregistrement TXT DomainKey et un CNAME de domaine de suivi vers go.pardot.com. Marketing Cloud Engagement utilise le Sender Authentication Package et Private Domain, et aucun des deux n’existe ici.

Dois-je ajouter Salesforce à mon enregistrement SPF pour Account Engagement ?

Non. Salesforce documente que le courrier Account Engagement passe SPF automatiquement parce que Salesforce contrôle l’infrastructure d’envoi, et qu’aucune configuration SPF particulière n’est nécessaire de votre côté. Un include n’aiderait pas davantage, puisque le contrôle porte sur le chemin de retour Salesforce et non sur votre domaine d’expéditeur. Gardez votre propre enregistrement SPF exact pour vos autres expéditeurs, et appuyez-vous sur DKIM pour l’alignement DMARC.

Pourquoi mon courrier Account Engagement semble-t-il venir d’un domaine Salesforce ?

Le chemin de retour des envois Account Engagement est un hôte Salesforce. Salesforce documente des exemples comme bounce.s7.exacttarget.com, bounce.s10.mc.pd25.com et bounce.j.s11.pdmailservice.com, et indique que l’information de chemin de retour ne peut pas être retirée. Gmail fait apparaître l’écart sous la forme d’une ligne via. Publier l’enregistrement DomainKey fait signer DKIM avec votre propre domaine, ce dont DMARC a besoin et ce qui fait disparaître la ligne via dans la plupart des cas, et un chemin de retour personnalisé demandé au support aligne l’enveloppe elle-même.

Comment obtenir l’alignement SPF sur Account Engagement ?

Ouvrez un ticket de support Account Engagement et demandez un chemin de retour personnalisé. Salesforce travaille avec son équipe délivrabilité pour vous fournir les enregistrements DNS à publier et ne configure pas votre DNS à votre place. Il ne peut y avoir qu’un seul domaine de chemin de retour personnalisé par unité opérationnelle, et il n’est pas variable par envoi. Salesforce est clair : cela ajoute un alignement de domaine SPF pour renforcer une politique DMARC existante, pas pour remplacer DKIM. Publiez donc d’abord le DomainKey.

L’analyse antispam de l’onglet Testing me dit-elle si j’atteindrai la boîte de réception ?

Non, et Salesforce le dit. Les tests de rendu et l’analyse antispam de l’onglet Testing de l’éditeur classique reposent sur Litmus, et Salesforce indique que les résultats ne garantissent pas que les e-mails finissent ou non dans le dossier spam, car la réputation de l’expéditeur n’est pas quelque chose qu’une analyse de contenu peut voir. La fonctionnalité arrive avec le pack Advanced Email Analytics, dans les éditions Plus, Advanced et Premium, et en option payante sur Growth, et chaque rendu est conservé 90 jours. Servez-vous-en pour le rendu et le contenu, et mesurez le placement avec un envoi réel.

Unspam peut-il se connecter à mon compte Account Engagement et tester les envois automatiquement ?

Non. Unspam ne s’intègre ni à l’API Account Engagement ni à l’API d’une autre plateforme, et ne se connecte jamais à votre compte. Les deux points de contact sont une adresse-témoin à laquelle vous envoyez et, pour les tests automatisés, des identifiants SMTP que vous fournissez vous-même. Pour Account Engagement, cela veut dire ajouter l’adresse-témoin comme prospect et lancer un vrai e-mail de liste, seule façon de voir les en-têtes, les liens réécrits du domaine de suivi et le placement que reçoivent réellement vos prospects.

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

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

Lancer un test de spam gratuit Test d’Inbox Placement