Vérifier votre domaine d’envoi d’e-mails
REDA fonctionne sur Salesforce, qui exige la vérification du domaine utilisé pour envoyer vos e-mails. Si les adresses de votre équipe se terminent par @yourcompany.com, vous devez prouver que votre organisation contrôle yourcompany.com, généralement au moyen d’un enregistrement DNS. Sans vérification ni option de substitution applicable, Salesforce bloque les e-mails envoyés depuis ce domaine. La vérification du domaine est distincte de la confirmation d’une adresse utilisateur et de la connexion au compte. Cet article explique le principe, l’enregistrement à publier, les questions de votre équipe informatique et la procédure complète. Il s’adresse à la personne qui configure une organisation REDA lors de sa mise en place ; aucune connaissance préalable du DNS n’est nécessaire.
Attention aux intitulés similaires. Si vous voyez deux entrées Domaines de messagerie autorisés, choisissez celle située directement sous E-mail, et non celle de Messagerie unifiée : leurs fonctions diffèrent.
Autorisations nécessaires. Administration des e-mails pour modifier les domaines autorisés et Personnaliser l’application pour gérer les clés DKIM et la délivrabilité. Vous aurez aussi besoin d’une personne autorisée à modifier le DNS public de votre entreprise, souvent dans une autre équipe. Lancez cette demande suffisamment tôt.
Qu’est-ce qu’un domaine d’envoi d’e-mails, et pourquoi Salesforce le vérifie-t-il ?
Le domaine d’envoi est la partie de l’adresse située après @. Pour ana.silva@yourcompany.com, il s’agit de yourcompany.com. Lorsqu’un utilisateur envoie un e-mail en masse depuis REDA, ou lorsqu’un traitement envoie une notification, un relevé propriétaire ou une alerte avec cette adresse, Salesforce envoie le message au nom de votre entreprise.
La vérification de l’adresse individuelle consiste à envoyer un lien que l’utilisateur doit ouvrir. Cela prouve qu’il peut lire cette boîte de réception, mais pas que l’organisation Salesforce est autorisée à envoyer au nom du domaine. La vérification supplémentaire du domaine prouve que l’organisation le contrôle ; elle complète la vérification individuelle.
Il existe donc deux niveaux de vérification indépendants :
| Niveau | Preuve apportée | Méthode |
|---|---|---|
| Domaine : l’exigence supplémentaire | Votre organisation contrôle le domaine et peut l’utiliser comme domaine d’expéditeur dans Salesforce | Un enregistrement DNS : clé DKIM active ou domaine de messagerie autorisé vérifié |
| Utilisateur : la vérification de l’adresse | La personne peut lire cette boîte de réception | Salesforce envoie un lien de vérification à l’adresse ; l’utilisateur l’ouvre |
Salesforce a déployé cette obligation dans le cadre de l’exigence de vérification des domaines d’envoi de Spring ’26. Les organisations existantes ont bénéficié d’une liste temporaire de domaines déjà utilisés, avec des échéances de vérification en 2026. Vérifiez le calendrier applicable à votre organisation. La règle concerne aussi les sandbox et s’applique séparément à chaque domaine et sous-domaine : vérifier yourcompany.com ne vérifie pas mail.yourcompany.com.
Comment le problème se manifeste
Les symptômes suivants peuvent apparaître. Certains concernent la vérification du domaine ; d’autres, la confirmation de l’adresse ou la session de connexion :
| Symptôme | Emplacement |
|---|---|
| Après un changement d’adresse, l’utilisateur ouvre le lien de confirmation et arrive sur la page de connexion, sans mise à jour de l’adresse. Ce symptôme peut venir de la session ou de la vérification d’identité ; il ne prouve pas, à lui seul, un défaut de vérification du domaine. | Enregistrement utilisateur dans Configuration |
| Message anglais « Not allowed to send from an unauthorized domain. » : l’envoi depuis un domaine non autorisé est refusé. | Éditeur d’e-mails lors d’une tentative d’envoi |
| Message indiquant que le domaine de l’adresse n’est pas vérifié et demandant de contacter l’administrateur Salesforce. | Message affiché à l’utilisateur |
| L’adresse de l’utilisateur n’apparaît pas dans la liste De lors de la rédaction. | Éditeur d’e-mails |
550 5.7.1 Delivery not authorized, message discarded | Configuration → fichiers journaux des e-mails |
| Un e-mail intitulé « Contactez votre administrateur Salesforce pour vérifier votre domaine de messagerie. » ou un avis d’échec intitulé « Messages Salesforce non remis ». | E-mail adressé à l’utilisateur concerné |
| Un avertissement sur la page d’accueil de Configuration indique que des e-mails ont été abandonnés à cause de la vérification du domaine. | Accueil de Configuration |
550 5.7.1.Deux moyens de prouver le contrôle du domaine
Salesforce accepte deux méthodes. Une seule suffit par domaine : vous publiez dans son DNS un enregistrement que seul son administrateur peut créer, puis Salesforce le vérifie.
| Méthode | Principe | Quand la choisir |
|---|---|---|
| Clé DKIM (recommandée par Salesforce) | Salesforce génère une clé de signature. Vous publiez les enregistrements DNS correspondants et activez la clé ; les e-mails sortants sont ensuite signés cryptographiquement. | Lorsque votre équipe messagerie/DNS peut participer à la configuration. La signature contribue également à la délivrabilité et limite le risque de classement comme indésirable. |
| Domaine de messagerie autorisé | Salesforce génère une clé de vérification. Vous la publiez dans un enregistrement DNS TXT, puis Salesforce la relit. | Pour débloquer rapidement les envois, ou si DKIM n’est pas envisageable. Cette méthode satisfait à la vérification du domaine sans ajouter de signature aux e-mails. |
La suite décrit la méthode du domaine de messagerie autorisé, qui nécessite un enregistrement DNS et permet de préparer les envois lors de la mise en place de REDA. Si le domaine possède déjà une clé DKIM active dans cette organisation, il est vérifié : consultez d’abord Configuration → Clés DKIM pour éviter une configuration inutile.
Étape 1 : ajouter le domaine et récupérer sa clé
@ dans les adresses des utilisateurs, par exemple yourcompany.com , sans @ , sans www. et sans point final. Cliquez sur Enregistrer . 00D000000000P08=1TB00000000000B : l’identifiant de l’organisation, le signe égal et une clé propre au domaine. Copiez la chaîne entière, y compris le signe égal. Elle constitue la valeur du TXT à demander à votre équipe DNS. yourcompany.com et un service notifications.yourcompany.com, prévoyez deux entrées, deux clés et deux enregistrements DNS.Étape 2 : publier un enregistrement DNS TXT
Le DNS est l’annuaire public qui associe les noms de domaine à leurs informations. Un enregistrement TXT contient du texte libre. Les contrôles de propriété peuvent utiliser ce texte comme preuve, puisque seul l’administrateur du domaine peut le publier. Votre équipe informatique ou votre prestataire DNS, par exemple Cloudflare, GoDaddy ou Route 53, crée l’enregistrement.
Salesforce accepte trois emplacements. La valeur reste identique ; seul le nom de l’enregistrement change.
| Option | Nom de l’enregistrement | Usage |
|---|---|---|
| 1 | yourcompany.com : la racine du domaine | Facile à expliquer, mais ajoute un TXT à la racine, où peuvent déjà se trouver d’autres enregistrements, notamment SPF. DMARC utilise normalement son propre nom, _dmarc. |
| 2 — recommandée ici | _sfdv.yourcompany.com | Un nom dédié à la vérification Salesforce, séparé des enregistrements de messagerie existants à la racine. |
| 3 | <18-digit-orgId>._sfdv.yourcompany.com | Lorsque plusieurs organisations Salesforce utilisent le même domaine d’expéditeur : chacune possède son nom d’enregistrement distinct. |
Avec l’option 2, l’enregistrement complet est le suivant : son nom utilise le sous-domaine _sfdv et sa valeur est la clé obtenue à l’étape 1. Le TTL par défaut convient.
Name TTL CLASS TYPE VALUE
--------------------------------------------------------------------
_sfdv.yourcompany.com. 600 IN TXT "00D000000000P08=1TB00000000000B"Cet ajout ne modifie ni le routage des e-mails ni les entrées SPF, DKIM ou DMARC existantes. Conservez-les : vous ajoutez uniquement la preuve de vérification.
@yourcompany.com. Une organisation et un domaine : choisissez l’option 2, avec _sfdv. Si le groupe possède aussi une organisation Salesforce distincte pour ses équipes commerciales, utilisant le même domaine @yourcompany.com, chaque organisation génère sa propre clé. L’option 3 permet de publier <its own 18-digit org ID>._sfdv.yourcompany.com pour chacune, sans confondre leurs noms. Remplacez le texte entre chevrons par son identifiant d’organisation à 18 caractères. Vérifiez ce point avant la création pour éviter de modifier les enregistrements ensuite.;. Salesforce accepte ces deux formes.Ce que cet enregistrement permet à Salesforce
Votre équipe informatique ou sécurité peut demander ce qu’elle autorise en publiant ce TXT. Voici les réponses.
La vérification consiste à lire le DNS public. Salesforce recherche le TXT au nom choisi, compare son contenu à la clé générée et enregistre le résultat. Ce contrôle ne modifie pas le DNS.
| Question | Réponse |
|---|---|
| Salesforce prend-il le contrôle du domaine ? | Non. Il effectue une consultation publique et ne peut ni créer, ni modifier, ni supprimer les enregistrements DNS. |
| La valeur est-elle confidentielle ? | Non. Le DNS est public. La valeur contient un identifiant d’organisation et une clé de vérification opaque ; elle n’accorde pas d’accès à l’organisation et ne sert pas à s’authentifier. |
| Le TXT modifie-t-il la réception des e-mails ? | Non. Le TXT sous _sfdv. ne définit pas le routage des e-mails. Les enregistrements SPF, DKIM et DMARC existants restent inchangés. |
| Peut-on retirer cet enregistrement ? | Oui. Le supprimer retire la preuve publiée dans le DNS, sans modifier les autres enregistrements du domaine. |
| REDA a-t-il besoin d’accéder à notre DNS ? | Non. Votre équipe ou prestataire publie l’enregistrement. Informez REDA lorsqu’il est disponible. |
Étape 3 : vérifier le contrôle du domaine dans Salesforce
Les changements DNS mettent un certain temps à se propager. Un nouvel enregistrement est souvent visible en quelques minutes, mais Salesforce recommande de prévoir jusqu’à 72 heures. Le délai réel dépend notamment des caches et des TTL. Intégrez ce délai à votre planification.
= et, pour l’option 3, la forme à 18 caractères de l’identifiant d’organisation.Étape 4 : choisir la vérification de l’adresse utilisateur
Le domaine autorisé possède aussi un réglage de vérification de l’adresse avant envoi. Dans l’interface à case à cocher décrite par la procédure d’origine, il s’appelle Require Email Verification et est activé par défaut. La documentation Salesforce actuelle présente une sélection, « Demander la vérification de l’adresse pour envoyer un e-mail ». Elle contrôle la vérification au niveau de l’utilisateur, indépendamment du contrôle DNS du domaine. Vérifiez l’interface disponible dans votre version.
Le réglage par défaut demande toujours la vérification individuelle. La sélection actuelle propose aussi une vérification uniquement pour les adresses mises à jour, ou aucune vérification d’adresse avant envoi. Le tableau compare les deux extrêmes ; choisir une exception relève de la politique de sécurité de votre organisation.
| Réglage | Effet | Conséquence |
|---|---|---|
| Vérification toujours requise : valeur par défaut, ou Oui dans l’ancienne interface | L’utilisateur doit vérifier son adresse au moyen du lien avant de l’utiliser pour envoyer, y compris après un changement. | Conserve le contrôle individuel, avec une étape supplémentaire lors de l’intégration des utilisateurs. |
| Vérification jamais requise : Jamais, ou Non dans l’ancienne interface | Les adresses de ce domaine peuvent servir aux envois sans vérification individuelle par e-mail. Cela ne remplace pas les contrôles du compte ou de la connexion. | Supprime cette étape d’envoi mais réduit le contrôle individuel. Dans l’interface actuelle, ce choix limite également la modification des adresses aux utilisateurs autorisés à gérer les utilisateurs ou à modifier toutes les données. |
Ouvrez Configuration → Domaines de messagerie autorisés → Modifier en regard du domaine. Dans l’ancienne interface, désélectionnez Require email verification uniquement si cette décision est approuvée ; dans l’interface actuelle, choisissez la valeur correspondant à votre politique, puis Enregistrer. La page Délivrabilité propose aussi Vérifier la propriété des domaines d’envoi d’e-mails par clé DKIM : cette option concerne tous les domaines possédant une clé active. Selon la documentation actuelle, elle conserve la vérification lors d’un changement d’adresse ; le réglage par domaine offre davantage de précision.
Débloquer une confirmation d’adresse pendant la propagation DNS
Si un utilisateur doit confirmer un changement d’adresse avant que le DNS soit disponible, le lien peut échouer parce qu’il est ouvert hors d’une session Salesforce authentifiée. Il arrive alors sur la page de connexion sans terminer la confirmation. La séquence suivante peut résoudre ce problème de session individuel :
Deux autres paramètres peuvent produire un retour à la connexion : la vérification d’identité lors d’un changement d’adresse e-mail, dans Configuration → Vérification de l’identité, qui peut nécessiter l’accès à l’ancienne adresse ; et le SSO, lorsqu’un cookie de page de démarrage provoque une déconnexion et perd la destination du lien.
Dépannage
| Symptôme | Cause possible | Correction |
|---|---|---|
| Le lien renvoie à la connexion et l’adresse n’est pas mise à jour | Absence de session Salesforce, lien expiré, vérification d’identité ou SSO | Connectez-vous d’abord dans le même navigateur, puis ouvrez un lien récent. Vérifiez la configuration de l’identité. Contrôlez séparément le domaine et le réglage de vérification de l’adresse avant envoi. |
| L’éditeur refuse l’envoi depuis un domaine non autorisé | Vérification du domaine manquante | Réalisez les étapes 1 à 3 pour ce domaine |
| Le statut indique Ownership Verified = No, soit un contrôle de propriété non validé, après publication du TXT | Propagation DNS incomplète ou contrôle non relancé | Attendez, puis cliquez sur Modifier et Enregistrer pour relancer la vérification |
| La vérification échoue malgré un enregistrement apparemment correct | Identifiant court à 15 caractères dans le nom de l’option 3, absence du signe = dans la valeur ou erreur de nom | Vérifiez le nom, la valeur et l’identifiant à 18 caractères. La valeur doit correspondre exactement à la clé affichée dans Configuration. |
| Certains utilisateurs peuvent envoyer, d’autres non, avec un domaine apparemment identique | Les utilisateurs concernés emploient un sous-domaine | Ajoutez et vérifiez chaque sous-domaine séparément |
| Les e-mails d’un flux, d’une alerte ou d’un automatisme n’arrivent pas, sans erreur visible | Abandon possible lors du contrôle du domaine | Recherchez 550 5.7.1 Delivery not authorized dans les fichiers journaux des e-mails de Configuration |
| Les e-mails du sandbox ne partent plus après son actualisation | La vérification n’est pas héritée automatiquement à la création d’un sandbox | Importez le domaine autorisé depuis la production, si la copie y est autorisée, ou configurez-le dans le sandbox |
yahoo.com ou icloud.com, utilisez dans Délivrabilité l’option Utiliser une adresse e-mail de substitution pour les domaines non vérifiés. Elle remplace l’adresse De. Selon les options disponibles, vous pouvez sélectionner une adresse d’organisation vérifiée ; à défaut, Salesforce emploie son adresse de substitution. Le domaine initial reste non vérifié. Les adresses @gmail.com, @hotmail.com et @outlook.com sont déjà exemptées du contrôle du domaine.Références officielles Salesforce
La vérification du domaine est une exigence Salesforce, et sa documentation fait référence. Les URL et les réglages peuvent évoluer avec les versions. Si un lien change ou si votre écran diffère, recherchez le titre ou l’identifiant de l’article dans l’aide Salesforce.
Pour aller plus loin
- Créer des utilisateurs et leur accorder l’accès à REDA : préparer leur intégration et leurs droits.
- Configurer les e-mails en masse : choisir les adresses d’expéditeur à l’échelle de l’organisation et vérifier leur domaine.
- Envoyer des e-mails depuis REDA : le parcours utilisateur.
- Services e-mail REDA : présentation : la réception des e-mails, distincte de cette obligation d’envoi.
- Sécuriser votre organisation REDA : replacer ce contrôle dans la configuration de sécurité.
Questions fréquentes
Non. Votre équipe informatique ou votre prestataire DNS publie l’enregistrement. REDA peut vous communiquer le nom et la valeur nécessaires, puis contrôler le résultat dans Configuration.
Non. Chaque domaine et sous-domaine nécessite sa propre vérification : domaine autorisé avec sa clé et son TXT, ou clé DKIM active correspondante.
Non. L’une des deux méthodes suffit. Salesforce recommande DKIM, qui contribue aussi à la délivrabilité. Vous pouvez ajouter un domaine autorisé pour le copier dans les sandbox, car les clés DKIM ne se copient pas.
Oui. La vérification n’est pas automatiquement héritée à leur création. Importez un domaine autorisé depuis la production si sa copie est permise, configurez la vérification dans le sandbox ou utilisez l’option de substitution dans Délivrabilité.
Souvent quelques minutes, mais Salesforce recommande de prévoir jusqu’à 72 heures. Après propagation, modifiez et enregistrez à nouveau le domaine autorisé pour relancer le contrôle.
Une exception est possible, mais doit relever de la politique de votre organisation. L’ancienne interface propose une case Require Email Verification ; la sélection actuelle distingue la vérification systématique, celle des adresses modifiées et l’absence de vérification avant envoi. Conservez la valeur par défaut sauf décision explicite, limitez les droits de gestion des utilisateurs et contrôlez les restrictions de votre version. Ce réglage ne vérifie ni le compte ni la connexion.
Les domaines @gmail.com, @hotmail.com et @outlook.com sont exemptés du contrôle du domaine. Pour les autres, activez Utiliser une adresse e-mail de substitution pour les domaines non vérifiés dans Délivrabilité. L’envoi utilise une adresse de substitution : une adresse d’organisation vérifiée si elle est configurée, ou celle de Salesforce à défaut.
Cet article vous a-t-il été utile ?