SPF, DKIM et DMARC pour Salesforce.
Salesforce (Sales, Service et Platform Cloud) authentifie votre domaine en trois éléments distincts et, depuis la version Spring '26, il refuse d'envoyer des e-mails depuis un domaine que vous n'avez pas vérifié. SPF est un véritable include partagé (include:_spf.salesforce.com) que vous fusionnez dans votre unique enregistrement SPF racine. DKIM est une paire d'enregistrements CNAME « selector » que vous générez dans Configuration - Clés DKIM, puis que vous activez - et créer une clé DKIM active est aussi la méthode recommandée pour satisfaire la nouvelle vérification du domaine d'envoi de Salesforce. DMARC est un quatrième enregistrement, distinct, que Salesforce ne crée jamais pour vous. Le piège qui déroute presque tout le monde : Salesforce envoie les rebonds depuis son propre domaine de return-path, si bien que SPF ne s'aligne pas sur votre adresse From - c'est DKIM qui porte réellement DMARC.
Pourquoi authentifier Salesforce ?
Authentifier les e-mails Salesforce n'est plus une simple formalité optionnelle - depuis la version Spring '26 (l'application a débuté le 9 mars 2026 et s'est déployée jusqu'à fin avril 2026), Salesforce bloque tout e-mail rédigé par un utilisateur ou automatisé envoyé depuis un domaine non vérifié. Les envois manuels échouent dans le compositeur d'e-mails avec « Not allowed to send from an unauthorized domain », et les flux automatisés échouent silencieusement, affichant « 550 5.7.1 Delivery not authorized, message discarded » uniquement dans vos journaux d'e-mails. En plus de cela, depuis février 2024, Gmail et Yahoo exigent que tout expéditeur en masse (environ 5 000 messages ou plus par jour) réussisse SPF, DKIM et DMARC avec alignement, et Microsoft a commencé à appliquer les mêmes règles au courrier à fort volume vers Outlook.com en 2025. Le comportement par défaut de Salesforce casse discrètement DMARC : il appose un return-path sur son propre domaine de rebond, si bien que SPF authentifie mais ne s'aligne pas sur votre adresse From, et par défaut il n'y a aucune signature DKIM sur votre domaine - ce qui signifie qu'un e-mail Salesforce d'apparence correcte peut malgré tout échouer à DMARC partout. Configurer une clé DKIM résout les deux problèmes d'un coup : elle satisfait l'exigence de vérification du domaine et vous donne une signature alignée qui fait passer DMARC, de sorte que la réputation que vous bâtissez s'accumule sur votre propre domaine au lieu de ricocher sur l'infrastructure partagée de Salesforce.
La réalité SPF pour Salesforce
Le cœur de Salesforce est un véritable fournisseur « include » : il existe un seul mécanisme partagé réel, include:_spf.salesforce.com, que vous ajoutez à l'unique enregistrement SPF TXT de votre domaine racine, par ex. v=spf1 include:_spf.salesforce.com ~all. Mais soyez clair sur son rôle. L'include se résout en v=spf1 exists:%{i}._spf.mta.salesforce.com -all - un enregistrement à macro exists qui autorise les IP d'envoi actuelles de Salesforce - et il coûte DEUX de vos 10 recherches DNS SPF (une pour l'include lui-même, une pour le mécanisme exists imbriqué). La nuance importante : ajouter cet include autorise Salesforce pour SPF mais ne rend PAS SPF aligné. Par défaut, Salesforce utilise son propre domaine comme envelope-from / Return-Path (son domaine de gestion des rebonds), si bien que la vérification SPF s'exécute sur le domaine de Salesforce, pas le vôtre - ce qui signifie que SPF passe mais ne s'aligne pas sur votre adresse From visible, et DMARC n'en tire rien. C'est pourquoi DKIM n'est pas optionnel ici : DMARC a besoin d'au moins un mécanisme aligné, et sur Salesforce ce mécanisme est DKIM. Publiez tout de même l'include (c'est la recommandation documentée de Salesforce et il autorise proprement les IP d'envoi), mais considérez DKIM - et non SPF - comme l'élément qui porte votre validation DMARC.
Deux façons de le configurer
Clé DKIM (recommandé)
- Déléguée en CNAME vers custdkim.salesforce.com afin que Salesforce détienne les clés privées et en assure la rotation
- Vous donne une signature DKIM alignée - le mécanisme qui fait réellement passer DMARC
- Une clé DKIM active satisfait aussi l'exigence de vérification du domaine d'envoi de Spring '26
- Une seule clé peut couvrir plusieurs domaines d'adresse From via son Domain Match Pattern
Authorized Email Domains - TXT (vérification uniquement)
- Un seul enregistrement TXT sur _sfdv.yourdomain.com (ou l'apex) prouve que vous possédez le domaine
- Satisfait l'exigence de vérification de Spring '26 pour que les envois ne soient pas bloqués
- Ne signe PAS votre courrier - aucune signature DKIM, aucun alignement DMARC qui en découle
- À utiliser uniquement comme solution provisoire ; il vous faut toujours une clé DKIM pour la délivrabilité
Étape par étape
- 1
Définissez votre niveau d'accès de délivrabilité
Depuis Configuration, utilisez la Recherche rapide pour ouvrir E-mail - Délivrabilité. Réglez « Accès à l'envoi d'e-mails » (niveau d'accès) sur « Tous les e-mails » pour que Salesforce envoie réellement le courrier sortant - les sandbox et certaines organisations ont par défaut « E-mails système uniquement » ou « Aucun accès », ce qui supprime silencieusement vos messages de test avant même que l'authentification n'entre en jeu.
- 2
Créez une clé DKIM
Depuis Configuration, recherchez « Clés DKIM » dans la Recherche rapide et cliquez sur Créer une clé. Choisissez 2048 bits pour la taille de la clé RSA. Saisissez un Selector unique (par ex. example-sf-a) et un Alternate Selector unique (par ex. example-sf-b). Saisissez le Domaine depuis lequel vous envoyez et un Domain Match Pattern (par ex. example.com pour couvrir ce domaine, ou un motif plus large pour les sous-domaines), puis enregistrez. Remarque : le champ Domaine est définitif une fois enregistré.
- 3
Publiez les deux enregistrements CNAME DKIM
Ouvrez la page Détails de la clé DKIM - Salesforce affiche un CNAME et un CNAME alternatif. Chez votre hébergeur DNS, créez les deux en tant qu'enregistrements CNAME : l'hôte example-sf-a._domainkey.yourdomain.com pointant vers la cible affichée par Salesforce, comme example-sf-a.k4tyd2.custdkim.salesforce.com (et le selector -b vers sa propre cible custdkim.salesforce.com). Copiez les cibles exactes - un seul caractère erroné casse la signature. Si votre DNS est derrière Cloudflare, réglez-les sur DNS-only (nuage gris).
- 4
Activez la clé DKIM
Après la propagation des CNAME (quelques minutes, jusqu'à 48-72 heures), revenez dans Configuration - Clés DKIM, ouvrez la clé et cliquez sur Activer. Salesforce ne vous laissera pas activer tant que les deux CNAME ne se résolvent pas dans le DNS public. Une fois active, Salesforce signe le courrier sortant avec d=yourdomain.com et votre domaine compte comme vérifié pour l'exigence de Spring '26.
- 5
Ajoutez ou fusionnez l'include SPF
Chez votre hébergeur DNS, publiez UN SEUL enregistrement SPF TXT sur la racine (hôte @) : v=spf1 include:_spf.salesforce.com ~all. Si vous envoyez déjà via Google Workspace, Microsoft 365, un outil marketing, etc., fusionnez include:_spf.salesforce.com dans cette unique ligne v=spf1 existante - ne créez jamais un second enregistrement SPF. Cela autorise les IP de Salesforce (cela coûte 2 recherches) mais rappelez-vous qu'il ne s'alignera pas de lui-même.
- 6
Vérifiez le domaine si vous n'utilisez pas encore DKIM
Si vous devez débloquer l'envoi avant que DKIM ne soit en place, utilisez l'alternative TXT : Configuration - Recherche rapide « Authorized Email Domains » - Ajouter, saisissez votre domaine, et Salesforce génère une clé de vérification. Publiez-la en tant qu'enregistrement TXT (hôte _sfdv.yourdomain.com ou l'apex), attendez la propagation, puis modifiez le domaine et activez « Verify domain ownership ». Cela prouve la propriété mais ne signe pas le courrier - une clé DKIM reste l'objectif.
- 7
Pointez votre adresse Org-Wide vers le domaine vérifié
Chaque adresse From doit être sur un domaine vérifié. Depuis Configuration, ouvrez la Recherche rapide - « Organization-Wide Addresses », et assurez-vous que les adresses depuis lesquelles vos utilisateurs, flux et alertes e-mail envoient (par ex. no-reply@yourdomain.com) sont sur le domaine que vous venez d'authentifier. Les adresses Org-Wide non vérifiées sont la cause la plus fréquente de blocage des envois automatisés.
- 8
Publiez votre enregistrement DMARC
Salesforce ne crée jamais DMARC. Ajoutez un enregistrement TXT sur _dmarc.yourdomain.com : v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none est en mode surveillance uniquement - il ne change rien à la délivrabilité pendant que vous confirmez que le courrier Salesforce passe DKIM aligné sur votre domaine. Conservez exactement un enregistrement _dmarc pour tout le domaine.
- 9
Envoyez un test et lisez les en-têtes
Envoyez un vrai message depuis une adresse Org-Wide Salesforce vers une boîte Gmail, ouvrez-le et choisissez le menu à trois points - Afficher l'original. Vous voulez DKIM: PASS avec signed-by / d=yourdomain.com (et non salesforce.com) et DMARC: PASS. SPF affichera généralement le domaine de return-path de Salesforce - c'est normal ; c'est DKIM qui doit porter la validation DMARC.
Enregistrements à ajouter
Salesforce 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 | @ | v=spf1 include:_spf.salesforce.com ~allSPF racine - conservez exactement UN enregistrement SPF ; fusionnez cet include dans votre ligne v=spf1 existante si vous en avez une. Coûte ~2 recherches DNS (include + exists imbriqué). Autorise Salesforce mais ne s'aligne pas. |
| CNAME | example-sf-a._domainkey | example-sf-a.k4tyd2.custdkim.salesforce.comSelector DKIM 1 - à titre d'illustration. Copiez la cible exacte depuis votre page Détails de la clé DKIM ; la chaîne de partition k4tyd2 est propre à votre clé. |
| CNAME | example-sf-b._domainkey | example-sf-b.e6mxu6.custdkim.salesforce.comSelector DKIM alternatif - à titre d'illustration. Le second selector permet à Salesforce d'effectuer la rotation des clés sans que vous touchiez à nouveau au DNS. Utilisez la valeur exacte affichée par Salesforce. |
| TXT | _sfdv | 00D000000000P18=1AB00000000000BClé de vérification Authorized Email Domains - à titre d'illustration et propre à chaque organisation. Nécessaire uniquement si vous utilisez la méthode de propriété TXT au lieu (ou avant) une clé DKIM active ; l'apex fonctionne aussi comme hôte. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comVous l'ajoutez vous-même - Salesforce ne le crée jamais. Un par domaine ; commencez à p=none et durcissez plus tard. |
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 sur ce budget.
Salesforce utilise 2 de vos 10 requêtes ; les mécanismes ip4: et ip6: sont gratuits.
DKIM
DKIM est la pièce maîtresse de l'authentification Salesforce, car c'est le seul mécanisme qui s'aligne sur votre domaine - et, depuis Spring '26, une clé DKIM active est la méthode recommandée par Salesforce pour vérifier la propriété du domaine afin que vos envois ne soient pas bloqués. Créez-la dans Configuration - Recherche rapide - « Clés DKIM » - Créer une clé : choisissez 2048 bits, saisissez un Selector unique et un Alternate Selector unique (Salesforce utilise deux selectors pour pouvoir effectuer une rotation des clés), spécifiez le Domaine, et définissez un Domain Match Pattern qui contrôle quels domaines d'adresse From cette clé signe. Après avoir enregistré, la page Détails de la clé DKIM affiche un CNAME et un CNAME alternatif - par exemple example-sf-a._domainkey.yourdomain.com vers example-sf-a.k4tyd2.custdkim.salesforce.com et example-sf-b._domainkey.yourdomain.com vers example-sf-b.e6mxu6.custdkim.salesforce.com. Comme il s'agit de CNAME délégués vers custdkim.salesforce.com (et non de TXT que vous collez), Salesforce conserve les clés privées et effectue la rotation des clés publiées derrière les deux selectors sans que vous ayez jamais à ré-éditer le DNS. Deux choses que l'on oublie : le champ Domaine est définitif une fois enregistré (il faudrait créer une nouvelle clé pour le changer), et vous ne pouvez pas cliquer sur Activer tant que les deux CNAME ne se résolvent pas réellement dans le DNS public. Publiez les deux enregistrements, attendez la propagation, puis revenez dans Clés DKIM et cliquez sur Activer - c'est seulement à ce moment que Salesforce commence à signer le courrier sortant avec d=yourdomain.com. Les anciennes clés DKIM de Salesforce étaient des clés TXT auto-gérées que vous génériez et colliez ; la clé DKIM « sécurisée » moderne est la version à CNAME délégué décrite ici et c'est celle que vous devez utiliser.
DMARC
DMARC est un enregistrement de politique TXT distinct sur votre domaine que Salesforce ne crée pas - vous le publiez vous-même sur _dmarc.yourdomain.com, en commençant par v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none est en mode surveillance uniquement : il ne change rien à la délivrabilité pendant que vous observez les rapports agrégés (rua) pour confirmer que le courrier Salesforce passe DKIM aligné sur votre domaine. C'est l'étape où la particularité d'alignement de Salesforce compte le plus : parce que Salesforce envoie les rebonds depuis son propre domaine de return-path, SPF authentifie mais ne s'aligne pas, si bien que sur le courrier Salesforce DMARC passe uniquement sur l'alignement DKIM. C'est très bien - DMARC n'exige qu'un seul mécanisme aligné - mais cela signifie que votre clé DKIM doit être active et signer avant que vous ne durcissiez la politique, sinon le courrier Salesforce légitime échouera. Surveillez les rapports pendant une semaine ou deux, assurez-vous que Salesforce (et tout autre expéditeur - Google Workspace, Microsoft 365, outils marketing) affiche un passage aligné, puis passez à p=quarantine et finalement à p=reject. Conservez exactement un enregistrement _dmarc pour tout le domaine organisationnel ; n'en ajoutez jamais un second juste pour Salesforce.
Vérifiez que tout fonctionne réellement
Ne vous fiez pas au seul statut affiché sur la page Clés DKIM de Salesforce - confirmez sur un vrai message. Envoyez depuis l'une de vos adresses à l'échelle de l'organisation (Org-Wide Addresses) vers une boîte Gmail, ouvrez le message et choisissez le menu à trois points - Afficher l'original. Vous voulez DKIM: PASS avec signed-by / d=yourdomain.com (s'il affiche salesforce.com, votre clé n'est pas active ou votre adresse Org-Wide est sur le mauvais domaine) et DMARC: PASS. SPF affichera généralement un domaine de return-path Salesforce plutôt que le vôtre - c'est normal, car c'est DKIM, et non SPF, qui assure l'alignement. Dans Salesforce, la page Détails de la clé DKIM doit indiquer Active. Passez ensuite votre domaine dans le contrôle de santé de domaine de Qualisend pour confirmer que l'enregistrement SPF, les deux CNAME de selector DKIM et l'enregistrement DMARC se résolvent tous proprement et que SPF reste sous la limite de 10 recherches ; une fois que les rapports agrégés DMARC commencent à arriver, déposez-en un dans l'analyseur de rapports DMARC pour confirmer que Salesforce apparaît comme une source alignée et validée.
Pièges courants
- Couverture
Application de Spring '26 : Salesforce bloque désormais le courrier provenant de domaines non vérifiés - les envois manuels échouent avec « Not allowed to send from an unauthorized domain » et les flux automatisés échouent silencieusement, journalisant « 550 5.7.1 Delivery not authorized, message discarded » dans les journaux d'e-mails. Activez une clé DKIM (ou vérifiez via Authorized Email Domains) pour chaque domaine utilisé par vos adresses Org-Wide.
- Couverture
SPF ne s'aligne pas sur Salesforce. Il envoie les rebonds depuis son propre domaine de return-path, si bien que l'include SPF autorise mais ne s'aligne jamais sur votre adresse From - DMARC repose entièrement sur DKIM. Ajouter l'include sans clé DKIM active ne vous donnera PAS de validation DMARC.
- Couverture
Le champ Domaine de la clé DKIM est définitif. Une fois enregistré, vous ne pouvez plus modifier le domaine (ni les selectors) - il faudrait créer une nouvelle clé. Faites-le correctement et utilisez le Domain Match Pattern pour couvrir les domaines depuis lesquels vous envoyez réellement.
- Configuration DNS
Vous ne pouvez pas activer DKIM tant que les deux CNAME ne se résolvent pas. Le bouton Activer ne fonctionnera pas tant que le DNS est encore en cours de propagation ; attendez (jusqu'à 48-72 heures) et revérifiez avec une recherche DNS avant de réessayer.
- Couverture
Le niveau d'accès de délivrabilité bloque silencieusement les envois. Si « Accès à l'envoi d'e-mails » est réglé sur « E-mails système uniquement » ou « Aucun accès » (courant dans les sandbox), Salesforce supprime votre courrier sortant quel que soit le DNS - réglez-le sur « Tous les e-mails » dans Configuration - Délivrabilité.
- Couverture
Email Relay contourne la signature DKIM de Salesforce. Si vous routez le courrier sortant via votre propre serveur SMTP dans Configuration - Email Relay, Salesforce ne signe pas le courrier - votre relais est responsable de SPF et DKIM, et ces enregistrements Salesforce ne s'appliquent pas à ce chemin.
- Configuration DNS
Ceci couvre le cœur de Salesforce (Sales/Service/Platform), pas Marketing Cloud ni Pardot. Marketing Cloud Engagement utilise son propre Sender Authentication Package (SAP) avec des CNAME différents, et Account Engagement (Pardot) a sa propre configuration - chaque famille de produits s'authentifie séparément.
- Casse l'authentification
Conservez un seul enregistrement SPF. Fusionnez include:_spf.salesforce.com dans votre unique ligne v=spf1 - deux enregistrements SPF TXT sur le même domaine constituent une PermError qui casse SPF pour tous les expéditeurs.
Construisez votre enregistrement SPF
Salesforce est présélectionné ci-dessous. Ajoutez toutes les autres plateformes par lesquelles vous envoyez, puis publiez l'enregistrement fusionné unique.
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).
- 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 — 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.