SPF, DKIM et DMARC pour Salesforce Marketing Cloud.
Salesforce Marketing Cloud Engagement (anciennement ExactTarget) n'authentifie pas les e-mails comme le ferait un ESP en libre-service. Vous ne pouvez pas coller un enregistrement et cliquer sur « vérifier » — vous devez au contraire acheter un Sender Authentication Package (SAP) ou l'option plus légère Private Domain, Salesforce provisionne alors un sous-domaine d'envoi dédié (et généralement une IP dédiée) pour votre compte, et vous devez soit déléguer ce sous-domaine aux serveurs de noms de Salesforce, soit publier les enregistrements SPF, DKIM et MX exacts que leur équipe délivrabilité vous fournit. Ce guide couvre le véritable workflow SAP : le mécanisme SPF include:cust-spf.exacttarget.com, la clé DKIM partagée 200608 par rapport à la clé dédiée déléguée par CNAME qui s'aligne réellement sur votre domaine, la délégation de sous-domaine par rapport à l'auto-hébergement, la gestion du courrier de réponse (Reply Mail Management) et l'enregistrement DMARC que vous devez ajouter vous-même.
Pourquoi authentifier Salesforce Marketing Cloud ?
Depuis février 2024, Gmail et Yahoo exigent que chaque expéditeur en masse passe SPF, DKIM et une politique DMARC — si vous les manquez, les envois Marketing Cloud sont limités ou classés en spam précisément chez les fournisseurs de messagerie où se trouve votre audience. Une authentification SAP correcte supprime également l'indicateur de domaine partagé / « via », appose votre propre marque sur les liens de suivi de clics, d'images, d'affichage en tant que page web (View-as-webpage) et CloudPages, et permet à SFMC d'envoyer depuis une IP dédiée sur laquelle vous pouvez bâtir une réputation propre. Comme SAP envoie depuis un sous-domaine de votre propre domaine, SPF (enveloppe/return-path sur votre sous-domaine) et DKIM (une clé dédiée sur votre sous-domaine) peuvent tous deux s'aligner sur votre domaine organisationnel pour DMARC — une position plus forte que celle de la plupart des ESP, mais uniquement si vous signez avec la clé DKIM dédiée plutôt qu'avec la clé partagée par défaut 200608 et que vous publiez tout correctement.
La réalité SPF pour Salesforce Marketing Cloud
L'autorisation SPF de SFMC est un véritable include: actif : include:cust-spf.exacttarget.com. Résolvez-le aujourd'hui et vous obtenez un unique enregistrement plat d'environ 50 plages ip4 se terminant par ~all — sans includes imbriqués — il ne coûte donc exactement qu'une seule des dix résolutions DNS de SPF. Deux choses distinguent SFMC d'un fournisseur classique du type « ajoutez cet include à votre SPF ». Premièrement, l'include appartient au sous-domaine d'envoi SAP dédié (p. ex. cloud.yourdomain.com), et non à votre domaine racine/apex — SFMC n'envoie presque jamais avec votre domaine nu, donc le placer sur la racine ajoute généralement une résolution qui ne sert à rien. Deuxièmement, dans la configuration recommandée par Salesforce, vous déléguez tout ce sous-domaine à Salesforce via des enregistrements NS et Salesforce héberge l'enregistrement SPF à votre place, de sorte que vous ne touchez peut-être jamais directement à la chaîne SPF. Ce n'est que si vous auto-hébergez le DNS que vous publiez vous-même v=spf1 include:cust-spf.exacttarget.com ~all sur le sous-domaine. Dans tous les cas, il réside dans l'enregistrement SPF propre au sous-domaine, il n'empiète donc jamais sur le budget de résolutions de votre domaine racine — et c'est pourquoi cet include ne devrait pas, par défaut, être greffé sur le SPF de votre domaine racine.
Deux façons de le configurer
Déléguer le sous-domaine d'envoi à Salesforce (recommandé)
- Ajoutez des enregistrements NS faisant pointer le sous-domaine SAP (p. ex. cloud.yourdomain.com) vers les serveurs de noms de Salesforce
- Salesforce héberge à votre place le SPF (cust-spf.exacttarget.com), la clé DKIM dédiée, le MX de réponse et les enregistrements de suivi
- Salesforce peut faire tourner automatiquement la clé DKIM dédiée — aucune coordination manuelle de clé
- Maintenance minimale ; moins de risques de se tromper en saisissant un enregistrement
- Ne publiez PAS aussi le SPF/DKIM de ce sous-domaine dans votre zone parente
Auto-héberger les enregistrements SAP sur votre propre DNS
- Gardez le DNS en interne et publiez exactement les enregistrements que l'équipe délivrabilité de Salesforce fournit
- SPF : ajoutez v=spf1 include:cust-spf.exacttarget.com ~all sur le sous-domaine d'envoi
- DKIM : publiez le CNAME (ou TXT) propre au compte que Salesforce fournit — ne convertissez pas un CNAME en TXT
- MX : ajoutez l'enregistrement Reply Mail Management sur votre sous-domaine de réponse
- Vous prenez en charge la coordination de la rotation des clés DKIM — plus de contrôle, plus d'entretien
Étape par étape
- 1
Confirmez que vous disposez du SAP ou d'un Private Domain
L'authentification SFMC n'est pas en libre-service. Pour vous authentifier sur votre propre domaine, vous avez besoin du Sender Authentication Package payant (ou de l'option plus légère Private Domain) ; Salesforce le positionne pour les expéditeurs au-delà d'environ 250 000 e-mails/mois. Sans lui, vous envoyez depuis un domaine exacttarget.com partagé pour lequel vous ne pouvez pas publier d'enregistrements. Le provisionnement passe par votre équipe de compte — la partie DNS/config prend souvent environ cinq jours ouvrés une fois votre formulaire de demande soumis, mais la contractualisation et l'allocation d'IP ajoutent du délai, alors commencez ici.
- 2
Décidez de votre sous-domaine d'envoi dédié
SAP provisionne un domaine privé qui est un sous-domaine de votre marque — typiquement cloud.yourdomain.com, email.yourdomain.com ou mkt.yourdomain.com. Chaque adresse From, URL de suivi de lien/image, lien View-as-webpage et CloudPage du compte l'utilisera, alors choisissez un sous-domaine que vous êtes heureux de voir dans les boîtes de réception et les navigateurs sur le long terme.
- 3
Choisissez entre délégation et auto-hébergement du DNS
Préféré : déléguez le sous-domaine d'envoi aux serveurs de noms de Salesforce via des enregistrements NS pour que Salesforce héberge les enregistrements SPF, DKIM, de suivi et de réponse depuis un fichier de zone qu'il gère, et puisse faire tourner les clés DKIM à votre place. Alternative : gardez le DNS en interne et publiez les enregistrements exacts que Salesforce fournit. La délégation demande moins de maintenance ; l'auto-hébergement conserve le contrôle mais implique que vous preniez en charge la coordination de la rotation des clés.
- 4
Voie de la délégation — ajoutez des enregistrements NS pour le sous-domaine
Créez des enregistrements NS pour le sous-domaine d'envoi pointant vers les serveurs de noms Salesforce/ExactTarget que votre équipe fournit (p. ex. cloud.yourdomain.com NS -> les hôtes du fichier de zone de Salesforce). Ne publiez pas aussi le SPF ou le DKIM de ce sous-domaine dans votre zone parente — la zone enfant déléguée devient autoritaire et les enregistrements de la zone parente sont ignorés.
- 5
Voie de l'auto-hébergement — publiez l'enregistrement SPF sur le sous-domaine
Si vous ne déléguez pas, ajoutez un enregistrement TXT sur le sous-domaine d'envoi : v=spf1 include:cust-spf.exacttarget.com ~all. C'est la valeur documentée par Salesforce ; ne resserrez ~all en -all qu'après avoir confirmé que rien d'autre n'envoie avec ce sous-domaine. Conservez un unique enregistrement SPF TXT — jamais deux.
- 6
Publiez la clé DKIM
SAP provisionne une clé DKIM dédiée que Salesforce délègue généralement sous forme de CNAME sur votre sous-domaine d'envoi — un sélecteur propre au compte/à la stack tel que [stack]dkim1._domainkey.cloud.yourdomain.com pointant vers [stack]dkim1._domainkey.sNN.exacttarget.com — de sorte que Salesforce détient et fait tourner la clé privée et que la signature s'aligne sur votre domaine. Les configurations plus anciennes vous remettent à la place une clé publique TXT brute à publier. Le sélecteur partagé 200608 est la clé historique sur exacttarget.com et ne s'aligne PAS sur votre domaine. Publiez exactement ce que Salesforce fournit — vous ne générez jamais la clé vous-même (contrairement au cœur de Salesforce, Setup > DKIM Keys).
- 7
Configurez la gestion du courrier de réponse (Reply Mail Management)
Configurez le domaine de réponse authentifié afin que les réponses des abonnés, les rebonds d'absence du bureau et les demandes de désabonnement manuelles reviennent via SFMC. Cela publie un enregistrement MX sur un sous-domaine de réponse (et un sous-domaine de rebond parallèle) pointant vers l'infrastructure entrante de Salesforce. Sautez cette étape et les réponses à vos campagnes n'aboutissent nulle part d'utile.
- 8
Ajoutez DMARC, puis vérifiez et activez
SAP ne crée pas DMARC — ajoutez vous-même _dmarc.yourdomain.com TXT, en commençant à v=DMARC1; p=none avec une boîte rua. Confirmez que le domaine privé affiche Active/authentifié dans SFMC Setup, envoyez un e-mail de seed, et vérifiez que les en-têtes affichent spf=pass et dkim=pass avec les domaines d= et d'enveloppe alignés sur votre sous-domaine (et non exacttarget.com). Une fois que les rapports agrégés sont propres, passez la politique à quarantine, puis à reject.
Enregistrements à ajouter
Salesforce Marketing Cloud génère les valeurs exactes dans son assistant de configuration — celles-ci illustrent la forme de ce que vous ajouterez chez votre hébergeur DNS.
| Type | Hôte | Valeur |
|---|---|---|
| TXT | cloud.yourdomain.com | v=spf1 include:cust-spf.exacttarget.com ~allSPF sur le sous-domaine d'envoi SAP (méthode auto-hébergée). Dans le modèle de délégation recommandé, Salesforce l'héberge à votre place ; indiqué ici pour les comptes qui gardent le DNS en interne. Le nom du sous-domaine d'envoi est provisionné par compte — à titre d'illustration. Il réside dans le SPF propre au sous-domaine, il ne touche donc jamais au budget de 10 résolutions de votre domaine racine. |
| CNAME | s10dkim1._domainkey.cloud.yourdomain.com | s10dkim1._domainkey.s10.exacttarget.comClé DKIM SAP dédiée, déléguée par CNAME pour que Salesforce puisse la faire tourner — c'est la clé qui s'aligne sur votre domaine pour DMARC. Le sélecteur (p. ex. [stack]dkim1) et le numéro de stack (sNN) sont propres au compte ; publiez exactement ce que Salesforce fournit. Ne convertissez pas un CNAME en TXT et ne raccourcissez pas le nom d'hôte. |
| TXT | <selector>._domainkey.cloud.yourdomain.com | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...Forme DKIM alternative — certaines configurations SAP vous remettent une clé publique TXT brute au lieu d'un CNAME. Le sélecteur est propre au compte et fourni par Salesforce (la valeur partagée et non alignée par défaut est 200608 sur exacttarget.com, pas votre domaine). Clé à titre d'illustration — ne la copiez pas telle quelle. |
| MX | reply.yourdomain.com | reply.s10.exacttarget.comMX de Reply Mail Management pour que les réponses des abonnés, les absences du bureau (OOO) et les demandes de désabonnement passent par SFMC. Un MX de sous-domaine de rebond parallèle (bounce.sNN.exacttarget.com) est également provisionné. Le sous-domaine de réponse, la stack (sNN) et l'hôte MX sont propres au compte — à titre d'illustration. |
| TXT | _dmarc.yourdomain.com | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comVous ajoutez DMARC vous-même — SAP ne le crée jamais. Commencez à p=none, puis resserrez vers quarantine/reject une fois que les rapports sont propres. |
Conservez exactement un seul enregistrement SPF (v=spf1) TXT sur votre domaine racine — fusionnez-y tous vos expéditeurs. Avoir deux enregistrements SPF constitue en soi une erreur.
Le budget de 10 requêtes DNS
SPF est plafonné à une limite stricte de 10 requêtes DNS — dépassez-la et il renvoie une permerror et cesse de valider partout. Voici ce que coûte la configuration de Salesforce Marketing Cloud sur ce budget.
Salesforce Marketing Cloud utilise 1 de vos 10 requêtes ; les mécanismes ip4: et ip6: sont gratuits.
DKIM
Deux scénarios DKIM différents coexistent dans Salesforce Marketing Cloud. La valeur par défaut historique est une unique clé partagée avec le sélecteur 200608 — créée en 2006 et utilisée par tous les comptes SFMC sans domaine privé. Elle est publiée sur exacttarget.com, signe en d=exacttarget.com et ne s'aligne donc PAS sur votre domaine From pour DMARC ; s'agissant d'un sélecteur TXT figé, elle est aussi peu commode à faire tourner. Lorsque vous provisionnez SAP / un domaine privé, Salesforce émet à la place une clé DKIM dédiée et la délègue généralement via un CNAME sur votre sous-domaine d'envoi — un sélecteur propre au compte/à la stack tel que s10dkim1._domainkey.cloud.yourdomain.com pointant vers s10dkim1._domainkey.s10.exacttarget.com — de sorte que Salesforce détient et fait tourner la clé privée tandis que la signature s'aligne sur votre domaine organisationnel. Certaines configurations vous remettent encore une clé publique TXT brute à publier à la place. Dans tous les cas, Salesforce fournit toujours l'enregistrement exact ; vous ne générez jamais la clé vous-même, contrairement au cœur de Salesforce Sales/Service Cloud où vous la créez sous Setup > DKIM Keys. Comme une clé SAP dédiée signe avec un sous-domaine de votre propre domaine, c'est la voie la plus fiable vers un passage DMARC — vérifiez que votre package inclut une clé dédiée et alignée sur le domaine plutôt que de vous appuyer sur la valeur partagée par défaut 200608.
DMARC
SAP ne crée ni ne gère DMARC — c'est à vous de le publier. Ajoutez un enregistrement TXT à _dmarc.yourdomain.com : commencez par v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com pour collecter les rapports agrégés sans affecter la distribution. Comme SAP envoie depuis un sous-domaine de votre domaine, SPF peut s'aligner via l'enveloppe/return-path sur ce sous-domaine et DKIM peut s'aligner via la clé SAP dédiée — DMARC peut donc passer sur l'un ou l'autre, DKIM étant l'aligneur le plus solide. La clé partagée 200608 seule ne s'aligne pas (elle signe en exacttarget.com), assurez-vous donc que votre compte signe avec la clé dédiée avant de passer à l'application. Surveillez la politique de sous-domaine : si vous définissez p=reject, ajoutez sp= délibérément et confirmez d'abord que le sous-domaine d'envoi SAP est entièrement authentifié. Ne passez de p=none -> quarantine -> reject qu'après que les rapports confirment que l'ensemble de votre courrier SFMC légitime (et autre) passe de façon alignée.
Vérifiez que tout fonctionne réellement
Interrogez le SPF du sous-domaine d'envoi (dig +short TXT cloud.yourdomain.com) et confirmez qu'il se résout en include:cust-spf.exacttarget.com, puis vérifiez le sélecteur DKIM que Salesforce vous a fourni (p. ex. dig +short CNAME s10dkim1._domainkey.cloud.yourdomain.com, ou une résolution TXT si l'on vous a remis une clé brute — pas le sélecteur partagé 200608). Envoyez une campagne de test/seed vers une boîte que vous contrôlez et inspectez les en-têtes : Authentication-Results doit afficher spf=pass et dkim=pass, et le domaine DKIM d= ainsi que le domaine d'enveloppe SPF doivent tous deux être votre propre sous-domaine (aligné), et non exacttarget.com. Dans Marketing Cloud Setup, confirmez que le domaine privé / SAP affiche Active et authentifié (et non Pending). Ensuite, faites passer le sous-domaine d'envoi et votre enregistrement _dmarc dans le vérificateur SPF, DKIM & DMARC de Qualisend ainsi que dans le contrôle de santé de domaine pour détecter les fautes de frappe, les enregistrements en proxy ou une politique DMARC manquante avant de monter en volume.
Pièges courants
- Configuration DNS
Ce n'est pas en libre-service. Vous ne pouvez pas simplement publier des enregistrements et commencer à envoyer — SAP / Private Domain est une option payante que l'équipe de Salesforce provisionne (environ cinq jours ouvrés pour le DNS une fois votre formulaire déposé, plus le délai de contractualisation) et est positionnée pour les expéditeurs au-delà d'environ 250 000 e-mails/mois. Pas de SAP signifie que vous envoyez depuis un domaine exacttarget.com partagé que vous ne pouvez pas authentifier.
- Configuration DNS
Le bon produit, les bons enregistrements. include:cust-spf.exacttarget.com et le sélecteur 200608 concernent UNIQUEMENT Marketing Cloud Engagement (ExactTarget). Le cœur de Salesforce Sales/Service Cloud utilise include:_spf.salesforce.com avec des clés que vous générez sous Setup > DKIM Keys, et Account Engagement (Pardot) utilise ses propres CNAME de tracker — ne les fusionnez jamais en un seul enregistrement SPF.
- Casse l'authentification
Sous-domaine, pas racine. SAP envoie depuis un sous-domaine dédié (p. ex. cloud.yourdomain.com), et l'include/DKIM/MX y résident. Ne greffez pas cust-spf.exacttarget.com sur votre SPF racine/apex sauf si votre adresse From SFMC est réellement sur le domaine racine — pour la plupart des comptes, cela ajoute simplement une résolution qui ne sert à rien.
- Configuration DNS
200608 est la clé partagée — et elle ne s'aligne pas. Le sélecteur 200608 est l'unique clé DKIM partagée de Marketing Cloud (depuis 2006), publiée sur exacttarget.com ; elle signe en exacttarget.com, elle ne vous donne donc aucun DKIM aligné sur le domaine pour DMARC, et en tant que sélecteur TXT figé, elle est difficile à faire tourner. L'alignement de domaine provient de la clé SAP dédiée que Salesforce délègue via CNAME — vérifiez que votre package en inclut une.
- Configuration DNS
Délégation et enregistrements manuels s'opposent. Si vous déléguez le sous-domaine via NS à Salesforce, ne publiez PAS aussi le SPF/DKIM de ce sous-domaine dans votre zone parente — la zone enfant déléguée est autoritaire et vos enregistrements parents sont silencieusement ignorés.
- Configuration DNS
Publiez les enregistrements exactement. Ne convertissez pas un CNAME Salesforce en TXT, ne raccourcissez pas les noms d'hôte et ne mettez pas les enregistrements en proxy (pas de nuage orange Cloudflare) — chacune de ces actions casse le DKIM, le routage des réponses ou la résolution du return-path.
- Configuration DNS
Budget SPF et qualificateur. cust-spf.exacttarget.com est un unique enregistrement plat uniquement ip4 = une seule résolution (sans imbrication), mais il est volumineux. La valeur documentée par Salesforce se termine par ~all ; ne resserrez en -all qu'une fois certain que rien d'autre n'envoie avec ce sous-domaine.
- Configuration DNS
DMARC vous incombe. SAP ne créera pas _dmarc — sans politique DMARC publiée, l'application des exigences des expéditeurs en masse de Gmail et Yahoo limitera ou classera en indésirable vos envois Marketing Cloud.
Construisez votre enregistrement SPF
Salesforce Marketing Cloud n'a pas besoin d'un include: SPF sur votre domaine racine — utilisez le générateur pour assembler un enregistrement propre et unique pour vos autres expéditeurs, en le limitant à une seule ligne.
Sending sources
Search for each platform you send email through and tick it.
Search for your email platform above, or .
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listSPF Salesforce Marketing Cloud — FAQ
Lectures complémentaires
Une fois publié, confirmez que tout se résout correctement avec la vérification de l'état du domaine, puis identifiez qui envoie en votre nom grâce à l'analyseur de rapports DMARC. Parcourez toutes les sources d'envoi dans le générateur. L'authentification ne représente toutefois que la moitié de la délivrabilité — une IP ou un domaine d'envoi inscrit sur une liste vous fait toujours atterrir dans les spams, quelle que soit la propreté de votre SPF ; il vaut donc la peine de surveiller les listes noires avec la surveillance des listes noires.
Authentifié — maintenant, gardez votre liste propre
Réussir SPF, DKIM et DMARC vous mène jusqu'à la boîte de réception ; une liste propre vous y maintient. Vérifiez la vôtre — commencez gratuitement avec 100 crédits, sans carte bancaire.