2026 Salesforce : e-mails de test non envoyés ? Vérifier la validation du domaine d’expéditeur

L’e-mail de test n’arrive pas, ou Salesforce signale un refus d’envoi.

Solution la plus rapide : identifiez le domaine réellement utilisé dans l’adresse d’expédition et vérifiez son statut dans l’organisation concernée ; s’il n’est pas validé, configurez une clé DKIM valide ou un domaine de messagerie autorisé vérifié, puis relancez le test. Une boîte de réception de test permet de contrôler l’arrivée du message, mais ne remplace pas cette validation.

Cet article s’adresse aux administrateurs Salesforce qui doivent recenser les domaines utilisés par leur organisation.
Il aide aussi les développeurs à vérifier les déclenchements Apex ou Flow et les équipes QA à isoler les problèmes d’envoi des problèmes de réception.

Dernière mise à jour : 24 octobre 2026. Les règles et les étapes ont été recoupées avec la documentation d’aide et les notes de version officielles de Salesforce. Leur application peut dépendre de l’organisation et de son état de configuration ; vérifiez toujours l’interface cible avant de modifier le DNS.

L’échec vient-il du déclenchement, du refus ou de la réception ?

Avant de toucher à la configuration DNS, classez le symptôme. Trois situations différentes peuvent produire le même constat côté testeur : « aucun e-mail reçu ».

• Aucune tentative d’envoi identifiable : l’action attendue n’a peut-être pas eu lieu. Le formulaire n’a pas validé la demande, la règle n’a pas correspondu aux critères, ou le flux d’automatisation s’est arrêté avant l’envoi.
• Tentative refusée ou abandonnée par Salesforce : le déclenchement peut avoir fonctionné, mais l’organisation ou le service d’envoi peut rejeter le message. Le domaine associé à l’adresse From fait partie des éléments à examiner.
• Message transmis, mais absent de la boîte attendue : le diagnostic se déplace vers la réception. Vérifiez l’adresse du destinataire, les dossiers de courrier indésirable et les contrôles appliqués par le système de réception, sans conclure que le domaine Salesforce est nécessairement en cause.

Salesforce précise que ses exigences de validation concernent l’envoi depuis des domaines d’expéditeur concernés par la règle. Elles ne signifient pas que chaque type de courriel, chaque mécanisme d’envoi et chaque organisation se comporte exactement de la même manière. Les conditions, exceptions et déploiements peuvent varier : utilisez les exigences officielles de validation des domaines d’e-mail et l’état affiché dans l’organisation comme référence, plutôt qu’une ancienne procédure copiée d’un autre environnement.

Une distinction évite beaucoup de fausses pistes : la vérification de l’adresse d’un utilisateur et la validation du domaine d’expéditeur ne sont pas équivalentes. Une adresse personnelle peut être confirmée sans que le domaine utilisé par une adresse d’organisation ou une automatisation satisfasse l’exigence applicable. Les détails de cette séparation figurent dans la documentation Salesforce sur la vérification de l’adresse utilisateur et l’authentification du domaine.

Administrateur : inventaire réel plutôt que domaine supposé

Commencez par relever les adresses From effectivement configurées, et non celles que l’équipe pense utiliser. Une organisation peut combiner des adresses d’utilisateurs, des adresses d’expéditeur à l’échelle de l’organisation, des notifications générées par des automatisations et des fonctions spécialisées. Parmi les configurations à inclure dans l’inventaire figurent les adresses utilisées avec Email-to-Case ou Experience Cloud, si ces fonctions interviennent dans le parcours testé.

Pour chaque adresse, notez l’adresse complète, le domaine après le signe « @ », la fonction qui l’utilise et l’environnement concerné. Une adresse affichée dans un modèle de courriel n’est pas nécessairement l’adresse effective de l’envoi : Apex, Flow ou une configuration d’organisation peuvent sélectionner une autre valeur. En cas de doute, comparez la configuration avec les informations d’une tentative d’envoi.

Salesforce documente les méthodes permettant d’identifier les domaines utilisés par l’organisation. Suivez les indications de son guide sur l’identification des domaines d’e-mail, puis confrontez les résultats à vos paramètres d’expéditeur et aux scénarios QA. Vérifiez les sous-domaines séparément : la présence d’un domaine principal dans votre inventaire ne permet pas de conclure qu’un sous-domaine employé par un autre service est également couvert.

Une bonne fiche d’inventaire comporte au minimum les éléments suivants :

• le nom de l’environnement : production, sandbox ou autre organisation autorisée ;
• l’adresse From configurée et le domaine correspondant ;
• le parcours qui utilise cette adresse : action utilisateur, notification, scénario Email-to-Case ou autre ;
• la personne qui gère le domaine et les enregistrements DNS ;
• le statut observé dans Salesforce, avec la date de vérification et une capture ou une référence interne.

Ce relevé limite un coût discret mais fréquent : faire modifier le mauvais domaine, puis répéter les tests sans toucher à la cause réelle. Si l’adresse d’expédition est gérée à l’échelle de l’organisation, ne supposez pas que la vérification d’une adresse individuelle suffit. Et si plusieurs domaines sont utilisés, une validation réussie pour l’un ne prouve rien pour les autres.

Responsable DNS : choisir une méthode que l’équipe peut maintenir

Salesforce cite deux voies de validation du domaine d’envoi : une clé DKIM valide ou un domaine de messagerie autorisé qui a été vérifié. Le choix doit tenir compte de la configuration déjà en place, de la personne habilitée à modifier le DNS et de la capacité de l’équipe à maintenir cette configuration. La documentation officielle présente les précisions et cas à prendre en compte pour la validation.

Une clé DKIM sert à l’authentification des messages et doit être configurée selon les paramètres fournis pour le domaine utilisé. Si votre organisation dispose déjà d’une configuration DKIM compatible, demandez au responsable DNS de confirmer qu’elle correspond bien au domaine d’expédition concerné et que le statut attendu est reconnu dans Salesforce. Ne réutilisez pas au hasard une clé liée à un autre sous-domaine ou à une autre organisation.

La méthode du domaine autorisé est une autre possibilité, lorsque le domaine et la procédure sont adaptés à l’organisation. La personne responsable du DNS doit suivre les instructions de Salesforce, publier les enregistrements demandés et confirmer que le statut est bien vérifié dans l’interface. La procédure Salesforce de configuration d’un domaine de messagerie autorisé est la référence pour les valeurs et étapes propres à cette option. Ne recopiez pas un enregistrement vu dans un ancien ticket ou dans un environnement différent.

Ni SPF ni DMARC ne remplacent, à eux seuls, les méthodes de validation du domaine décrites ici. Ces mécanismes ont leur rôle dans la politique d’authentification et de traitement des e-mails, mais les ajouter ne démontre pas automatiquement que le domaine satisfait l’exigence Salesforce. Il faut aussi séparer deux résultats : la configuration DNS publiée et le statut de validation constaté dans l’organisation.

Pour réduire les allers-retours, le développeur ou l’administrateur peut fournir une demande de changement précise : adresse From observée, domaine extrait, organisation concernée, méthode proposée et résultat attendu dans l’interface. Le responsable DNS renvoie ensuite les changements réalisés et les éléments utiles à la vérification. Ce transfert de responsabilité est plus sûr qu’un partage d’identifiants ou qu’une modification de paramètres de production pour dépanner un test.

Responsable de sandbox : contrôler l’organisation de test à part

Une sandbox est un environnement distinct, pas un prolongement garanti de la configuration de production. Le fait que la production affiche un domaine validé ne suffit donc pas pour conclure que les tests peuvent envoyer des messages depuis la sandbox. Contrôlez le statut dans l’organisation de test elle-même et établissez quel domaine correspond à l’adresse From réellement utilisée dans cet environnement.

Pour une Salesforce sandbox, la séquence utile est simple : repérez d’abord le domaine de l’expéditeur, vérifiez les paramètres disponibles dans la sandbox, puis confirmez que la méthode de validation requise est configurée et reconnue. Si le test utilise une adresse d’organisation différente de celle de production, vérifiez cette adresse et son domaine au lieu de supposer qu’ils sont interchangeables.

Certaines organisations peuvent avoir accès à des options ou à des états transitoires qui ne sont pas identiques à ceux d’une autre organisation. Salesforce publie aussi des informations sur les erreurs et les étapes de déploiement ; ne transformez pas une exception observée dans un compte en règle générale. Lorsqu’une option de remplacement d’adresse ou une dérogation apparaît dans l’interface, vérifiez son applicabilité dans la documentation actuelle et dans l’organisation cible avant de bâtir le plan de test dessus.

Évitez en particulier de désactiver une protection en production pour faire fonctionner un essai en sandbox. Cela augmente le risque pour les messages réellement envoyés et ne permet pas d’identifier si le blocage venait de la configuration de test, de l’automatisation ou de la réception. Si la sandbox n’est pas prête, consignez le blocage comme prérequis d’environnement et demandez une configuration autorisée, plutôt que de contourner le contrôle.

Développeur : relier le déclenchement, l’adresse From et le journal

Une validation de domaine ne déclenche pas un message à elle seule. Commencez par vérifier le parcours testé : l’action utilisateur a-t-elle été enregistrée ? Les critères du Flow ont-ils été satisfaits ? Le code Apex a-t-il atteint la branche d’envoi ? Une règle, une notification ou un autre mécanisme s’est-il exécuté dans l’organisation concernée ? Conservez l’identifiant du scénario ou les journaux applicatifs disponibles pour relier le test à l’événement Salesforce.

Ensuite, vérifiez l’adresse From retenue au moment de l’envoi. Un modèle de courriel peut contenir une adresse visible différente de celle que sélectionne l’automatisation. Relevez son domaine et comparez-le à l’inventaire de l’administrateur. Si une adresse a été modifiée entre production et sandbox, cette différence peut expliquer pourquoi un environnement passe le test et l’autre non.

Les journaux Salesforce permettent de rapprocher l’activité d’envoi des résultats et des informations d’erreur qu’ils exposent. Consultez le format officiel des journaux de messagerie et recherchez les échecs permanents ou les mentions explicites d’un domaine non vérifié. Une note de version officielle décrit également des informations d’erreur liées à ces contrôles : utilisez la documentation Salesforce sur les messages d’erreur de validation pour interpréter le texte effectivement affiché, sans extrapoler à partir d’un message isolé.

Un journal ne fournit pas toujours à lui seul le diagnostic complet. Il peut indiquer une tentative ou un refus, mais ne prouve pas forcément que le message est arrivé dans la boîte du destinataire ni qu’il y est lisible. Salesforce précise aussi des conditions d’utilisation et limites concernant les demandes de journaux ; consultez ses considérations officielles sur les journaux de messagerie avant de planifier la collecte. Si aucune ligne pertinente n’apparaît, vérifiez d’abord la fenêtre et les critères de recherche ainsi que le déclenchement.

Après une correction, relancez le même scénario dans l’environnement autorisé et consignez séparément le déclenchement observé, l’état du domaine, le résultat consigné dans le journal et la preuve de réception. Cette séparation évite d’attribuer au DNS un échec dû à une condition d’automatisation, ou à la boîte de test un message que Salesforce n’a jamais tenté d’envoyer.

QA : valider les preuves séparément

La boîte de test doit servir à observer la réception, pas à certifier la configuration d’envoi. Commencez par confirmer qu’une tentative a été acceptée ou traitée dans le parcours Salesforce et que le test utilise le destinataire attendu. Ensuite, examinez la boîte contrôlée : arrivée du message, adresse From, objet, contenu, liens et rendu utile au scénario. Pour un message de réinitialisation ou de confirmation, vérifiez également que le lien ou le code correspond au test en cours, et non à un message précédent.

Gardez trois preuves distinctes dans le rapport QA :

• preuve de configuration : domaine d’expédition identifié et statut observé dans l’organisation ;
• preuve d’exécution : action, Apex, Flow ou autre automatisation effectivement déclenchée ;
• preuve de réception : message trouvé dans la boîte contrôlée et contenu inspecté.

Cette méthode répond à une question pratique : « Que savons-nous réellement ? » Une boîte vide signifie seulement qu’aucun message n’y a été observé. Elle ne démontre pas à elle seule un échec de validation du domaine, une erreur Salesforce ou un défaut de filtrage chez le destinataire. Si les journaux montrent un refus, reprenez le diagnostic côté Salesforce ; si l’envoi a été traité mais que le message est absent, élargissez alors l’enquête à l’adresse de destination et au chemin de réception.

Pour les tests récurrents, documentez le domaine, l’environnement et le destinataire de test attendus dans le cas QA. Cela aide à détecter une dérive de configuration après une actualisation de sandbox ou une modification d’adresse. Une adresse réutilisée sans contrôle peut aussi rendre ambiguë l’identification du message ; choisissez un destinataire isolé et un protocole de vérification qui n’expose pas de données personnelles réelles.

Liste de contrôle avant une nouvelle exécution

• [ ] Le test porte sur une organisation que l’équipe est autorisée à administrer ou à utiliser.
• [ ] L’automatisation attendue s’est déclenchée, ou son absence est documentée.
• [ ] L’adresse From réellement utilisée a été relevée dans l’environnement testé.
• [ ] Le domaine de cette adresse, y compris le sous-domaine éventuel, figure dans l’inventaire.
• [ ] Le statut de validation a été vérifié dans la même organisation Salesforce que celle du test.
• [ ] Le responsable DNS a confirmé la méthode retenue : clé DKIM valide ou domaine de messagerie autorisé vérifié.
• [ ] Les enregistrements et leur statut ont été comparés aux instructions Salesforce applicables, sans substituer SPF ou DMARC à la validation.
• [ ] Les journaux ont été examinés pour repérer une tentative, un refus et une éventuelle erreur permanente.
• [ ] La boîte de test est contrôlée seulement après confirmation d’une tentative d’envoi.
• [ ] Le rapport distingue l’état de configuration, le résultat de l’automatisation et la preuve de réception.

Choisir le bon prochain geste selon la preuve

Pour organiser les destinataires contrôlés sans mélanger les usages, vous pouvez consulter le guide de choix d’adresse. Si le protocole de QA doit aussi examiner le transfert de messages vers une boîte de travail, les possibilités de transfert de courrier peuvent servir de piste ; elles ne prouvent ni la validation du domaine Salesforce ni la bonne exécution d’un envoi.

Quand le domaine est validé, l’automatisation déclenchée et le journal cohérent, une boîte de réception contrôlée reste utile pour vérifier l’arrivée et la lisibilité du courriel. Pour un essai ponctuel — inscription à votre propre application, notification ou contrôle de rendu — Tempsender peut fournir une adresse temporaire sans inscription, utilisable immédiatement, afin de ne pas exposer la boîte principale au bruit des tests. Cela ne corrige pas une configuration d’expéditeur et ne convient pas aux comptes importants qui exigent une récupération durable, des échanges en réponse ou un historique conservé. Consultez Tempsender comme une option de réception de test, après avoir établi que Salesforce a bien tenté l’envoi.

Questions fréquentes